viernes, 16 de octubre de 2009

La seguridad en KMKey Makhno

0 comentarios
 
Hemos puesto especial empeño en hacer hacer de KMKey Makhno un producto con el máximo de garantías en cuanto a seguridad. Para ello hemos llevado a cabo diversas mejoras, que junto con las ya existentes en versiones anteriores y las propias de la plataforma Zope, ofrecen el máximo de protección frente a posibles intrusiones. Pasamos a detallar a continuación el funcionamiento de los distintos componentes implicados:

1) Seguridad de los datos. Para garantizar que cada objeto es visible únicamente para aquellos usuarios que dispongan de los permisos pertinentes, KMKey confía en la probada robustez de Zope (el servidor de aplicaciones) y su immejorable sistema de permisos y control de accesos sobre ZODB, que permiten granular al máximo la definición de los accesos.
  • 1.1) Errores de programación. Zope verifica que cada acceso a cada objeto esté siendo llevado a cabo por un usuario con permisos, y eso lo hace de forma independiente al código de la aplicación, de manera que un eventual error de programación se traduce en una alerta de seguridad y una negación de acceso, nunca en un acceso a datos restringidos.
  • 1.2) Inyecciones SQL. Puesto que la base de datos usada es ZODB (orientada a objetos, aunque a la postre todos los datos acaben guardados en SQL si así se configura), todo el código de la aplicación está libre de ataques por inyección de SQL, que son uno de los mayores peligros en aplicaciones web clásicas

2) Seguridad en la autentificación. Uno de los puntos vulnerables de cualquier aplicación web o cliente/servidor es aquel en que el usuario se autentifica, es decir, proporciona su usuario y su password, y éste viaja a través de la red. Este proceso es susceptible de ser interceptado por terceros (por ejemplo mediante el uso de sniffers), cosa que les permitiría conocer el usuario y la clave. En este sentido, KMKey proporciona dos niveles de seguridad:
  • 2.1) Conexión no encriptada, autentificación mediante MD5. Para los casos en los que el servidor web no disponga de un certificado de seguridad que permita conexiones seguras HTTPS (posibilidad sólo disponible para servidores dedicados, y de elevado coste si el certificado se firma por una autoridad certificadora), KMKey evita enviar la clave plana a través de la web. En lugar de eso, la propia página de entrada encripta el password con el algoritmo unidireccional MD5. Ello implica que aunque esta clave encriptada fuera interceptada, sería imposible obtener la clave original (puesto que MD5 es un algoritmo de hash, de una sola dirección). Dado que las claves también son almacenadas encriptadas mediante el mismo algoritmo, ello da la posibilidad de autentifcar al usuario de una forma mucho más segura y asegura que ningún "robo" de datos acabará con la obtención de las claves de usuario.
  • 2.2) Conexión encriptada con certificado de servidor. En caso de que el servidor KMKey sea dedicado, existe la posibilidad de instalar un certificado de servidor que permita conexiones seguras HTTPS. En este supuesto, la autentificación se lleva a cabo sobre un canal seguro, y es virtualmente imposible interceptar los datos con los medios actuales. Como inconvenientes a esta opción está la alerta de seguridad que la mayoría de navegadores dan si el certificado de seguridad no se encuentra firmado por una autoridad certificadora, y el elevado coste de obtener esta firma.

3) Seguridad de la sesión. Una vez el usuario ha sido autentificado, para mantener la sesión mientras se usa la aplicación, KMKey utiliza una cookie de sesión. Sabiendo que este sistema puede también ser vulnerable a ataques mediante sniffers, se ha implementado un modelos de sesiones que ofrezca las máximas garantías. Para ello se utiliza una cookie de sesión totalmente aleatoria, imposible de calcular, se hace caducar la sesión a los 20 minutos de inutilización, y se verifica en cada petición que la IP de origen coincide con la del usuario que ha abierto la sesión. De esta forma, aunque una cookie de una sesión en curso fuera "robada", el atacante sería rechazado por la verificación de IP's de origen. La única alternativa más segura que este sistema es el uso de certificados de cliente, pero son usados en muy pocas ocasiones por su complejidad de desplegado (generación de certificados para cada usuario e instalación en todos sus puestos de trabajo).

4) Seguridad de las comunicaciones. Todos los datos que circulan a través de internet sin una conexión segura HTTPS de las descritas anteriormete son susceptibles de ser interceptados y leídos por personas expertas en tráfico de redes. Por ello, si los datos contenidos en KMKey son de elevada confidencialidad, es recomendable el uso de alguna de las siguientes opciones:
  • 4.1) Certificado de seguridad en servidor y conexión HTTPS requerida. Como se ha expuesto anteriormente, es una opción con algunos inconvenientes y reservada para servidores dedicados
  • 4.2) VPN (Virtual Private Network). De forma que la conexión al servidor se realice siempre sobre canales de comunicación seguros, en este caso a más bajo nivel que el certicado HTTPS. A efectos prácticos, requiere que los usuarios se autentifiquen primeramente en la VPN y, una vez conectados a ésta, puedan acceder al servidor KMKey
  • 4.3) Firewall de restricción de IP's. Una opción con menos garantías que las anteriores, pero de implementación mucho más sencilla, es restringir el acceso al servidor a determinados rangos de IP's (para ello debemos conocer previamente los rangos de IP's que pueden tener nuestros usuarios potenciales). Eso consigue evitar accesos de fuera de nuestras oficinas, por ejemplo, aunque también redunda en una limitación de la movilidad de los usuarios.
  • 4.4) Acceso LAN. La opción más restrictiva consiste en limitar el acceso al servidor sólo a los usuarios de la red local, de forma que garantizamos que cualquier acceso proviene del interior de nuestras dependencias
5) Seguridad en el software base. Todo lo anterior puede no servir de nada si nuestro sofware de base, léase el sistema operativo o el servidor de aplicaciones, tiene errores graves de seguridad que permitan un acceso directo al servidor. Por ello recomendamos siempre instalar KMKey sobre servidores GNU/Linux con distribución Debian versión stable, usando apache 2 como servidor web y un firewall como iptables. Con una correcta configuración, son una muy buena protección contra ataques de intrusos.

Consejos prácticos: La seguridad es algo a tener muy en cuenta en la implementación de cualquier herramienta web, y tanto los servidores web como las aplicaciones deben ofrecer las máximas garantías. Ahora bien, debemos tener muy presente que el 90% de los ataques se realizan siempre sobre PC's de escritorio, que suelen ser infinitamente más vulnerables, y una vez conseguido el control del PC local, se actúa contra servidores que lo consideren "de confianza", o incluso se pueden encontrar documentos de usuarios y claves de acceso, o datos confidenciales en los escritorios de trabajo. Por ello, una buena política de cambio de passwords, o una correcta supervisión de los puestos de trabajo pueden ser tanto o más importantes que la seguridad del servidor.
Leer más...
viernes, 2 de octubre de 2009

ZOORRA sin servidor gráfico

0 comentarios
 
La actual implementación de ZOORRA requiere que en el servidor haya alguna sesión gráfica abierta. Esta restricción viene dada por OpenOffice, que aunque permitía un modo silencioso para ejecutar macros aún requería un entorno gráfico que a veces usaba para mostrar errores.

Una solución habitual para resolver este problema era la instalación de un servidor gráfico "falso", algo así como redireccionar la salida gráfica a /dev/null. Esa solución, práctica porque no requiere la instalación de un entorno gráfico en un servidor que no lo necesita, también tiene el inconveniente que un error en la ejecución de OpenOffice resulta en una pantalla gráfica esperando una confirmación que jamás podrá recibir y sin atender a las posteriores peticiones.

Las versiones más recientes de OpenOffice finalmente han ofrecido una solución definitiva a este problema largamente reivindicado, el modo "headless". En este modo de ejecución la aplicación ya no genera ningún mensaja gráfico y así deja de exigir la conexión a un servidor X.

En Debian esta funcionalidad viene dada por el paquete openoffice.org-headless que por defecto no se instala con la suite ofimática, así que lo instalaremos explícitamente:

# apt-get install openoffice.org-headless

Una vez instalado deberíamos probar que efectivamente funciona correctamente sin ningún servidor X en ejecución. Los gestores de escritorio de KDE y Gnome dan la posibilidad de dar "acceso de consola" en la pantalla de inicio de sesión, dentro de un menú. Una vez nos encontremos con la consola de texto a pantalla completa, iniciamos una sesión normalmente y ejecutamos las siguientes órdenes:

$ openoffice -headless
$ ps x | grep headless

Si todo va bien, deberíamos ver el proceso aún en ejecución. En este estado, la ejecución de OpenOffice resulta inaccesible porque no hemos especificado aún ningún puerto de conexión (de eso ya se ocupará ZOORRA), así que lo terminaremos con la orden kill y el número de proceso que aparece a la izquierda:

(salida hipotética de la orden ps)
12345 tty1 Sl 0:00 /usr/lib/openoffice/program/...
67890 tty1 S+ 0:00 grep headless
$ kill 12345

Si no lo hacemos, las siguientes ejecuciones a OpenOffice parecerá que no harán nada porque, si ya existe una instancia en ejecución, la aplicación intenta aprovechar la misma. Esto también es importante para el usuario que ejecute ZOORRA, ya que no podrá usar OpenOffice en modo visual, así que es recomendable usar el mismo usuario del sistema con el que se ejecute el servidor Zope.

Finalmente, para que la instalación actual de ZOORRA se aproveche del modo headless de OpenOffice habrá que modificar el fichero /usr/local/zoorra/zoorra.py. Hay que ir con algo de cuidado pues es un fichero algo largo. En él buscaremos la cadena "-invisible" y la cambiaremos por "-headless" respetando las comillas.

En futuras versiones incluiremos como opción de configuración de ZOORRA la posibilidad de ejecución en modo "headless", de modo que no sea necesario modificar el fichero .py en ningún caso.
Leer más...

Avanzando hacia KMKey Makhno

0 comentarios
 
Seguimos avanzando a buen ritmo hacia la próxima versión de KMKey, que se llamará Makhno, y que tiene prevista su liberación en noviembre. Recordamos la lista de objetivos que propusimos:

1) Gestión de Equipo. Es sin duda la funcionalidad menos trabajada, por lo que va a ser la primera en abordarse. Además, en lo referente a permisos, requiere simplificación de la configuración de los usos más comunes

1.1) La asignación de perfiles a usuarios no puede ser más engorrosa, hay que rehacerla completamente, y de paso incorporar la asignación de perfiles a grupos enteros

1.2) Se deben poder asignar fácilmente a un expediente contactos ya existentes en la aplicación, independientemente de que se tengan o no permisos de gestión del equipo

1.3) En la vista de grupos relacionados sería conveniente poder desplegar, en árbol, los contactos asociados a cada grupo

1.4) En la vista de consulta de grupos se necesitas nuevos criterios de filtro, en especial uno por el tipo de grupo (de permisos, cliente, proveedor, etc)

1.5) En la vista de consulta de contactos también se requieren nuevos criterios de filtro, en especial uno por su condición de usuario / recurso / simple contacto

1.6) La definición de perfiles a usar, perfiles a bloquear en expedientes, perfiles a bloquear en el acceso al patrón, etc, debe ajustarse al tipo de patrón (de proyecto, de píldora, de contacto etc)
de forma que se simplifique especialmente el caso de definición de la seguridad en patrones de proyectos

1.7) Las recomendaciones de configuración de permisos de http://kmkey-es.blogspot.com/2009/05/configuracion-basica-de-permisos.html se han mostrado especialmente útiles cuando existen varios departamentos o líneas de negocio disjuntos. Deberíamos ajustar las configuraciones por defecto del programa para permitir realizarlas fácilmente desde la interfície del propio KMKey (ahora requieren uso del ZMI)

2) Usabilidad. Hacer más fácil ciertos usos del programa, en especial es vital la agilidad para filtrar lo que deseamos ver

2.1) Mejorar definición de filtros. Es muy engorroso definir nuevos filtros y usarlos.

2.2) Filtro por defecto y último filtro. Recordar para cada usuario el último filtro usado, y poder definir en cada instalación qué filtro se quiere aplicar por defecto

2.3) Filtros rápidos. El objetivo es que introduciendo una palabra en el propio navtree, sin necesidad de cambiar de pantalla, obtengamos un filtro de expedientes rápido

3) Nuevas vistas para los datos ya existentes.

3.1) En Control Gantt Real versus Gantt Previsto

3.2) En Control comparación entre esfuerzo real y horas planificadas

3.3) En Planificación / Recursos tener una vista con los recursos en el eje Y para visualizar más facilmente su ocupación detallada

3.4) Pantalla de tres ejes para economia, con las tareas en eje Y, el calendario en el eje X, y el total económico en el cruce, y pudiendo ver el detalle haciendo click en cada punto

4) Cerrar el ciclo. Se trata de vincular de alguna forma la información de los ejes. O sea, que la planificación temporal se vincule con la planificación de esfuerzo, y ésta a su vez con la
planificación económica en horas valoradas. Estas vinculaciones deben ser opcionales, y en todo caso dejar a criterio de configuración / usuario la propagación de cambios

Además de todo eso, va a haber importantes mejoras de rendimiento, sobretodo en lo que a grabación de datos se refiere, y alguna que otra mejora de usabilidad adicional. También vamos a liberar la versión adaptada a KMKey del ZSQLCatalog, que permite usar un catálogo basado en postgresql, y que es muy recomendable para instalaciones con gran volumen de datos.

Pepararse, que llega la revolución de KMKey Makhno (quede claro que no es un coñac)
Leer más...