Open Source Document Management System | OpenKM

buenas, soy nuevo aqui. ire directo al grano para no aburriros, me gustaria saber que defensas trae por defecto OpenKM frente a ataques dedicados por parte de Hackers o Crackers y tambien que defensas se le pueden implementar que no vengan configuradas.
no espero que alguien mencione el 100% pero hasta el mas minimo aporte me ayudaria a comprender el riesgo que se corre al iniciar. muchas gracias de antemano.

Esto no es tanto un problema de openkm como tal sino un tema de configuración de servidor ( en función de si esta en una intranet o extranet el tema sera distinto ). Yo lo que te comentaré será el caso de una extranet y lo que deberías hacer:
1- Adquirir un certificado SSL ( o generar uno ), aquí tienes una entrada muy interesante http://wiki.openkm.com/index.php/Open_SSL sobre el tema
2- Configurar un firewal y solo permitir el puerto 443
3- Configurar apache para que solo funcione por el puerto 443
4- Configurar el proxy en apache sobre tomcat esto lo tiene explicado aqui http://wiki.openkm.com/index.php/Third- ... L_and_more
5- La seguridad de las claves y nombres de usuarios ( para evitar ataques por fuerza bruta ) -> mirar habitualmente los logs para detectar si esto esta pasando, incluso se podría generar facilmente un report para controlar cuando un usuario ha intentado entrar mas de N veces en un periodo de tiempo corto y deshabilitarlo ( esto es fácil de hacer )
6- Controlar los bugs de seguridad en el sistema operativo, apache, tomcat y java ( y estar actualizado )

Esto sería lo mínimo ( a partir de aquí puedes hacer mas cosas ).

Relativo a OpenKM internamente tiene una auditoria completa por ip, usuario etc OKM_ACTIVITY que todas las operaciones del usuario ( desde obtener los hijos de una carpeta a borrar documentos etc... ) quedan registradas.

Hay 2 niveles de hackeo:
1- No tener acceso a openkm y acceder ( eso es mas o menos lo que te he contado antes )
2- Tener acceso y escalar a administrador ( esto ahora mismo no se me ocurre ninguna forma de hacerlo, sin antes ser administrador de openkm o siendo administrador del servidor, esta última opción no es trivial ).

A las últimas - esto ya lo hemos pensado - a parte de encriptar el contenido de los documentos ( cosa que ahora se puede hacer ) podríamos habilitar un repositorio totalmente encriptado ( el único problema que tiene esto, para que veas que esta pensado es que el buscador no funcionaría para el contenido, el resto si que seria operativo y la previsualización sería un caso bastante especial ). No sé si esto te ayuda o te liará.

Aunque la mejor opción es la que ya te han comentado, yo todavía voy un paso por detrás y lo que he hecho es lo siguiente:
En primer lugar (aunque sea una obviedad) poner contraseñas MUY FUERTES. En mi caso particular, tengo la manía de poner passwords diferentes en todos los servicios, y como al final es imposible de recordarlas todas, utilizo la aplicación KeePassX que me las centraliza, y además me las genera.
En segundo lugar, he habilitado ÚNICAMENTE la conexión por SSL al Tomcat generándome yo mismo el certificado (es una instalación casera). El motivo es que así me ahorro "escuchas" incómodas.
En tercer lugar, al ser una instalación "casera" (y supongo que esto no te aplica) lo que he hecho ha sido reenviar el puerto interno 8443 al externo 443 en el router, "camuflando" un poco la dirección y no dar pistas así de entrada.
En cuarto lugar desactivar todas las aplicaciones no necesarias que suelen venir con el tomcat "by default".

Basicamente la mía es una instalación en la que se aplica el principio de "seguridad por oscuridad", pero como ya te han dicho por aquí, lo mejor es implementar un Apache (como capa adicional), y cortar todo lo que no sea un 443 (que eso lo hace el router por mi).