Evitar fugas de información mediante metadatos con Alfresco

Tras hablar de las fugas de información en el “capítulo” anterior, donde explicaba la problemática existente con la gestión de los metadatos internos de los contenidos de cara a posibles análisis y extracción de información que no queramos hacer pública, he preparado la siguiente prueba de concepto para poder limpiar metadatos internos de archivos de imágenes (jpg, png) y pdf con Alfresco. Concretamente usaremos Exiftool, una herramienta hecha en Perl que soporta la edición, y por lo tanto, borrado de metadatos internos de los siguientes formatos y tipos de metadatos más conocidos (ver en la página de Exiftool todos los formatos soportados, que son muchos más):

Formato Información adicional
EPS, EPSF, PS R/W [Encapsulated] PostScript Format
EXIF R/W/C Exchangable Image File Format metadata (TIFF-based)
GIF R/W Compuserve Graphics Interchange Format
IND, INDD, INDT R/W Adobe InDesign Document/Template (XMP metadata only)
JPEG, JPG R/W Joint Photographic Experts Group image (see table below)
PDF R/W Adobe Portable Document Format
PNG, JNG, MNG R/W Portable/JPEG/Multiple-image Network Graphics
TIFF, TIF R/W Tagged Image File Format
XMP R/W/C Extensible Metadata Platform sidecar file

En esta prueba de concepto no veremos como automatizar el borrado de metadatos en ficheros ofimáticos de MS Office u Open Office, ya que Exiftool no soporta esos formatos, aunque los desconozco, parece ser que hay librerías que pueden permitir automatizarlo y añadirlo de la misma forma que comento en este artículo. Hace unos días Chema Alonso, de Informática 64, me comentó que ellos tienen una aplicación que se puede invocar desde línea de comandos y soporta esos formatos que podría servir para mejorar este que os muestro hoy, pero no tengo más detalles.

DISCLAIMER: Recordad que este artículo no es más que una prueba para demostrar que se puede hacer, aunque en mis pruebas no he visto ningún problema que afecte a la estabilidad de la plataforma, no me hago responsable si rompes algo 😉

Bien, empecemos. Vamos a ver la instalación, configuración, prueba y uso.

  • Instalación de exiftool y módulo de ejecución de comandos en Alfresco:

Para realizar esta prueba de concepto he utilizado Alfresco Enterprsie 4.0.0 pero igualmente valdría para la versión Community. Aparte de tener un Alfresco 4.0 instalado y funcionando necesitamos tener instalado Exiftool, podéis descargar de esta dirección la aplicación para Windows, Linux o MacOSX. También podéis descargarlo e instalarlo directamente usando Yum o Apt en vuestra distribución de Linux favorita. Uso Linux en este ejemplo así que todos los comandos y rutas serán en base a este sistema operativo, para hacerlo en Windows deberías cambiar rutas, etc. En MacOSX también lo he probado y este proceso es igual que en Linux.

Una vez instalado Exiftool, posiblemente lo tendremos en la ruta /usr/bin/exiftool por lo tanto en el PATH del sistema operativo y podremos invocarlo ejecutando en una consola simplemente “exiftool” (sin comillas). Para asegurarnos que funciona correctamente asegúrate que tiene permisos de ejecución (chmod +x)  y ejecuta exiftool contra una imagen o pdf que tengas:

[bash]
$ exiftool foto.jpg
[/bash]

Si todo va bien, verás una lista todos los metadatos que contiene la foto como veíamos en las capturas del artículo anterior.

Ahora vamos a ver como se realiza el borrado de todos los metadatos de un fichero desde línea de comandos para terminar todas las comprobaciones:

[bash]
$ exiftool -all= −overwrite_original foto.jpg
[/bash]

Con el anterior comando se borran todos los metadatos del fichero (-all=) y sobrescribe el fichero que se trata (−overwrite_original). Una vez ejecutado el comando vuelve a ejecutar el comando inicial de lectura para comprobar que realmente se han borrado todos los metadatos y funciona correctamente.

Ahora que tenemos instalado el comando principal para limpiar vamos al siguiente paso. La instalación del módulo que nos permitirá implementar una acción consistente en una llamada a un comando, es decir, a un script de shell. Le conté la idea a mi compañero en Alfresco Rui Fernandes y me dedicó unos minutos para hacer un módulo que permite ejecutar un comando sobre un nodo del repositorio (gracias amigo!), yo he adaptado el módulo a la ejecución de exiftool y podéis descargar el AMP desde aquí:

http://dl.dropbox.com/u/357018/cmd-line-action-clean-metadata-1.0.1.amp

Una vez tengamos descargado el módulo cmd-line-action-clean-metadata-1.0.1.amp, debemos instalarlo a alfresco.war con la herramienta alfresco-mmt (parando antes el servidor de aplicaciones). Para hacer esa tarea de forma sencilla copiamos el módulo al directorio “amps/” que debe estar en la raíz de la instalación de Alfresco. Posteriormente ejecutamos el script apply_amps.sh que está en “bin/” también en la raíz de la instalación. Si no hemos tenido ningún problema tras la ejecución del script ya tenemos el módulo instalado, podemos ver que ha hecho un backup automático de alfresco.war y que ha limpiado ficheros temporales del anterior despliegue.

  • Configuración del módulo para que la acción ejecute nuestro limpiador:

Teniendo el módulo de la acción instalado, ahora debemos configurarlo para usarlo posteriormente en una regla de Alfresco y aplicar la limpieza de metadatos internos de un contenido o contenidos concretos.

Primero debemos crear el script que vamos a ejecutar, lo llamaremos file-metadata-removal-script.sh y lo pondremos en el directorio “bin/” de la instalación de Alfresco, con el siguiente contenido tan sencillo:

[bash]
#!/bin/bash

# Script for calling File Metadata Removal Tool command
/usr/bin/exiftool -all= -overwrite_original $1
[/bash]

Recuerda hacerlo ejecutable con el comando “chmod +x file-metadata-removal-script.sh”.

Por último en alfresco-global.properties debemos añadir el siguiente nuevo parámetro donde indicamos la ruta absoluta del script (modifícala con la ruta del script en tu servidor):

[bash]
#Cleaner metadata script
file.metadata.removal.command=/opt/alfresco-enterprise-4.0.0/bin/file-metadata-removal-script.sh
[/bash]

Hecho lo anterior ya podemos arrancar el servidor de aplicaciones y probarlo.

  • Prueba:
  1. Accede a Alfresco Share con un usuario con permisos para crear una carpeta y crea una carpeta en un sitio.
  2. Crea una regla simple como la siguiente, donde se ejecuta la acción “Clean internal metadata”:
  3. Sube o mueve un fichero del tipo jpg, png o pdf al directorio donde has creado la regla. Sus metadatos internos serán extraídos como siempre por Alfresco y los usará para añadirlos a la información del contenido en su propia base de datos como veíamos en el artículo anterior. Pero también lo limpiará en el propio fichero interno que se almacena en el contentstore. También puedes mover un fichero que ya esté en el repositorio a esa carpeta y se ejecutará la limpieza.
  4. Como ves, es una acción totalmente transparente para el usuario. En los logs podremos ver más información.
  • Logs:

En el fichero alfresco.log podremos ver las siguientes cadenas donde vemos que el nodo de turno se ha limpiado correctamente (1 image files updated):

[bash]
2012-02-27 01:01:32,908  INFO  [rfernandes.cmdlineaction.CmdLineActionExecuter] [defaultAsyncAction4] Binary content store URL fetched: 2012/2/26/22/25/c1a9d2e3-9779-4dc5-aaea-927c1e8bc3a5.bin

2012-02-27 01:01:32,928  INFO  [rfernandes.cmdlineaction.CmdLineActionExecuter] [defaultAsyncAction4] Command line to execute: /opt/alfresco-enterprise-4.0.0/bin/file-metadata-removal-script.sh /opt/alfresco-enterprise-4.0.0/alf_data/contentstore/2012/2/26/22/25/c1a9d2e3-9779-4dc5-aaea-927c1e8bc3a5.bin

2012-02-27 01:01:32,928  INFO  [rfernandes.cmdlineaction.CommandExecutor] [defaultAsyncAction4] Executing: /opt/alfresco-enterprise-4.0.0/bin/file-metadata-removal-script.sh /opt/alfresco-enterprise-4.0.0/alf_data/contentstore/2012/2/26/22/25/c1a9d2e3-9779-4dc5-aaea-927c1e8bc3a5.bin

2012-02-27 01:01:33,332  INFO  [rfernandes.cmdlineaction.CommandExecutor] [Thread-143] OUTPUT>    1 image files updated

2012-02-27 01:01:33,338  INFO  [rfernandes.cmdlineaction.CommandExecutor] [defaultAsyncAction4] ExitValue: 0
[/bash]

Por defecto se usa el modo INFO en el log del módulo, pero con la siguiente cadena se podría modificar en log4j.properties:

[bash]
log4j.logger.org.alfresco.demo.rfernandes.cmdlineaction=info
[/bash]

  • Comprobar con exiftool:

Podemos comprobar con exiftool que realmente se ha limpiado el contenido lanzando el comando contra el nodo directamente:

[bash]
$ exiftool /opt/alfresco-enterprise-4.0.0/alf_data/contentstore/2012/2/26/22/25/c1a9d2e3-9779-4dc5-aaea-927c1e8bc3a5.bin
[/bash]

Y veremos que sólo se muestran los metadatos básicos del contenido, no los que pueden aportar más información. Ojo con lanzar comandos directamente a los contenidos en el contentstore, no lo hagas con comandos que no sepas realmente lo que hacen, podrías generar una inconsistencia en el repositorio. La implementación ideal sería usando código java así que cuidado con lo que hacéis 😉

  • Reglas:

En este ejemplo hemos visto una sencilla regla para probar la limpieza de los ficheros, para usar esta idea en un sistema real deberíamos saber como vamos a integrar Alfresco con un sistema web, por ejemplo con un portal o un canal de publicación, y ejecutar la acción con los contenidos que vayan a ser usados por ese portal o canal independientemente de cómo se acceda a Alfresco (CMIS, API nativa, etc.). Si lo que usamos es el Transfer Service de Alfresco, también deberíamos crear una regla para que se limpien los contenidos cuando salgan del repositorio con destino otro sistema.

  • Conclusión:

Como hemos visto en este artículo, hay opciones muy válidas para llevar a cabo la tarea de limpieza de contenidos para evitar fugas de información mediante los metadatos usando Alfresco. Seguro que con esta idea como base se pueden hacer cosas mucho más potentes. Los comentarios y mejoras son bienvenidos.

Contenidos, metadatos y las fugas de información

Llevo un tiempo escribiendo algunas cosas sobre seguridad y Alfresco (que iré publicando), una de los temas que más interés me despierta es la fuga de información, concretamente mediante datos que no vemos directamente pero que están ahí, que están en los contenidos, es decir, en los metadatos ocultos (o no tan ocultos) de los ficheros. De esto se ha hablado mucho, por ejemplo en España contamos con Chema Alonso que ha escrito gran cantidad de información al respecto en http://www.elladodelmal.com.

¿Quién no recuerda el famoso “Caso Blair”? Se publicó un fichero sobre la Guerra de Irak y las armas de destrucción masiva y se demostró (mediante los datos ocultos en el fichero) que había sido manipulado por gente de su gabinete y por lo tanto mentía en cuanto a la procedencia de la información. Más información en inglés y en español.

¿De qué estoy hablando? Voy a aclarar algunos conceptos para no liarnos y ponernos en situación.

Cualquier fichero contiene la información del mismo fichero, por ejemplo, un fichero foto.jpg contendrá una imagen, pero también contiene más información que no se ve a simple vista, son los metadatos o propiedades de dicho fichero que nos aportan más información sobre el mismo. En esos metadatos de la foto se pueden ver datos sobre la cámara con la que se ha realizado, fecha en la que se hizo, software con la que se ha editado, una miniatura, información sobre la localización donde se tomó y muchos datos más. Propiedades parecidas también se encuentran en ficheros Adobe PDF, MS Office, Open Office y un largo etcétera. En el caso de ficheros DOC o DOCX incluso podríamos extraer información sobre las personas que lo han editado, nombres de usuario, impresoras donde se ha enviado, recursos compartidos accedidos, etc. Por lo tanto, analizando esas propiedades podemos extraer mucha información valiosa.

Gracias a Google u otros buscadores es muy fácil localizar los ficheros publicados en internet por parte de una organización concreta, tan fácil como buscar algo así: “inurl:dominio.com filetype:pdf”

Hay millones de webs que publican esta información sin tratar previamente, sin saber realmente que información están dejando visible al resto del mundo. Incluso en España está contemplado el borrado o limpieza de esta información en el Esquema Nacional de Seguridad pero tras hacer unos cuantos escaneos de webs españolas de referencia es evidente parece que no tiene mucho éxito.

Fijaros si es importante este concepto que organizaciones como la NSA (National Security Agency de los Estados Unidos) o SANS, han publicado informes sobre los riesgos que supone este problema. Podéis acceder a los mismos aquí:

http://www.nsa.gov/ia/_files/app/pdf_risks.pdf

http://www.sans.org/reading_room/whitepapers/privacy/document-metadata-silent-killer_32974

¿Cómo puedo ver todo esto que comentas? Existen varias herramientas que nos permiten extraer este tipo de datos, analizarlos y poder averiguar cierta información que podrían permitir realizar intrusiones, uso fraudulento de la misma u otras actividades “interesantes”. Voy a enumerar algunas:

FOCA, también con versión online.

libextractor.

Metagoofil.

Exiftool.

Maltego.

Sin lugar a dudas, la más completa y además con sabor español es FOCA, escrita por la empresa Informatica64, tiene una versión gratuita y funciona sobre Windows. Esta herramienta nos permite extraer toda la información oculta en los ficheros, analizarlos y recolectar la información de forma gráfica e intuitiva, incluso puede dibujar un mapa de red con los datos extraídos como direcciones IP o nombres de máquinas. En este enlace se puede ver una conferencia en la DEFCON que es auto explicativa (merece la pena verla entera). Cabe recordar que FOCA nació para hacer auditorías y recolección de datos, y la extracción de metadatos es una de las muchas cosas que hace esta herramienta.

¿Y cómo puedo prevenir este tipo de situaciones? ¿Cómo limpio los archivos que voy a sacar fuera de mi ordenador o que voy a publicar en alguna página en internet? Hay algunas herramientas que nos permiten hacerlo y generalmente es una tarea totalmente manual que debe hacer el usuario por su cuenta (con lo que eso conlleva).

Con OOMetaextractor podemos borrar los metadatos de los documentos de OpenOffice. En el propio MS Office 2007 y versiones superiores hay una opción al guardar que nos permite borrar la información personal, para versiones anteriores hay un plugin que permite hacerlo. En el caso de PDF, para eliminar toda la información interna debemos usar Adobe Acrobat 8.0 o un plugin para versiones anteriores o con la herramienta Exiftool mencionada anteriormente. En ficheros gráficos del tipo JPG, PNG, etc, se puede eliminar algunos de estos datos con Adobe Photoshop o también con Exiftool. Aunque esta herramienta no está orientada precisamente a un usuario final.

Las fotos almacenan esa información en metadatos EXIF, IPTC y otros, los ficheros PDF en XMP, hay muchos más tipos de metadatos en los ficheros, en la web de Exiftool podéis aprender mucho sobre este tema.

Aquí vemos un ejemplo de los datos extraídos de una foto que me han enviado por correo electrónico:

Aquí los metadatos de una presentación en Power Point:

Como veis, en ambos casos hay información muy interesante, en la foto la localización exacta donde se hizo la foto, altitud, el teléfono con el que se hizo la foto, incluso podríamos acceder a la imagen en miniatura si la tuviera (que puede ser algo sorprendente porque puede no ser exactamente igual) y mucha información más. En el fichero PowerPoint podemos ver el usuario que está trabajando actualmente con el fichero, el usuario que lo hizo, fechas de creación, tiempo que se ha tardado en realizar el documento, etc. Toda esta información está muy bien siempre y cuando el usuario quiera que sea pública o que esté disponible, pero generalmente el usuario final no sabe nada de esto ni las consecuencias que puede tener.

Imaginad el impacto que puede tener la publicación de un documento que ha escrito una empresa “amiga” con un RFP y que posteriormente ha publicado otra empresa u organismo, si no se limpian los metadatos se podría demostrar e impugnar una asignación de un proyecto ya que se podría demostrar quien ha escrito el documento y quien lo ha publicado. Eso ocurre y ha ocurrido en muchas ocasiones, por eso esto es muy crítico.

¿Y qué relación tiene todo esto con Alfresco? Gran parte de estos metadatos que residen en múltiples formatos de documentos son utilizados por los extractores de Alfresco para nutrir sus contenidos de información adicional y evitar que el usuario deba rellenar a mano algunos de ellos, esta tarea se hace gracias a las librerías Apache Tika incorporadas en el repositorio. Por lo tanto, si subimos un fichero a Alfresco, se extraen los metadatos más conocidos automáticamente y podemos acceder a ellos en las propiedades de cada contenido, esto no significa que desaparezcan del propio fichero. A efectos de un ECM esto es normal ya que una vez que un fichero está en un ECM éste es el encargado de gestionar la información alrededor del fichero y poder dotar a los contenidos de más información y posibilidades que el propio contenido en si mismo.

En esta captura podemos ver como se muestran las propiedades extraídas (y ahora almacenadas en la BBDD de Alfresco) de una foto:

Entonces ¿qué ocurre si publico mis contenidos en servidores web con acceso público, o si tengo integrado mi portal cuyos contenidos están almacenados en Alfresco? ¿Qué pasa con los metadatos internos de los ficheros que se ponen a disposición de cualquiera en internet pero residen en el repositorio o salen de él?

Eso lo veremos en el próximo artículo, donde explicaré como defendernos de posibles fugas de información mediante metadatos usando Alfresco.

Seguridad en las comunicaciones de Alfresco

En este artículo quiero hablar sobre las comunicaciones en Alfresco. Como buenos administradores debemos saber qué puertos utiliza la aplicación de entrada (tráfico inbound: servicios que publica Alfresco) y de salida (tráfico outbound: servicios externos a los que accede Alfresco). De esa forma podemos configurar apropiadamente el firewall local del servidor y también el firewall perimetral de la organización. Otro aspecto a tener en cuenta es la seguridad de los servicios que publicamos, las comunicaciones tipo cliente-servidor y entre capas de una instalación, es decir, la posibilidad de cifrar el tráfico de los servicios que publicamos y de los servicios que se usan entre las capas o entre nodos en caso de cluster.

Listado de puertos, servicios y origen/destino del tráfico

  • En el listado siguiente podemos ver puertos de servicio que se usan o se pueden usar en Alfresco. Posiblemente veréis alguno más de los que pensábais, cuento con que tenemos Alfresco Repository (alfresco.war) y Alfresco Share (share.war) desplegado en el mismo servidor de aplicaciones y la base de datos, LDAP y almacenamiento en servidores remotos, aunque como sabéis, estos servidores también podrían estar en local en caso de desarrollo o pruebas. Todos estos puertos son los que se establecen por defecto, y como veremos, algunos no están activados por defecto:
Protocolo Puerto TCP/UDP IN/OUT Activo Comentarios
HTTP 8080 TCP IN Si Incluye WebDav
FTP 21 TCP IN Si Modo pasivo
SMTP 25 TCP IN No
CIFS 137,138 UDP IN Si
CIFS 139,445 TCP IN Si
IMAP 143 TCP IN No
Share Point  Protocol 7070 TCP IN Si
Tomcat Admin 8005 TCP IN Si
Tomcat AJP 8009 TCP IN Si
SOLR admin 8443 TCP IN Si Hay que instalar cert en navegador
NFS 111,2049 TCP/UDP IN No
Lotus Quickr 6060 TCP IN No
RMI 50500-50507 TCP IN Si Usado por EHCache entre nodos de cluster y para gestión JMX
JGroups 7800 TCP IN No Cluster discovery entre nodos
JGroups 7801-7802 TCP IN No Comunicación Ehcache RMI entre nodos de cluster
OpenOffice 8100 TCP IN Si Sólo en localhost, no hay que abrirlo
  • Como hemos visto, los puertos indicados anteriormente son todos los que podría utilizar Alfresco en una instalación con todas las funcionalidades activadas y en cluster, en una instalación para producción deberemos arrancar el servidor de aplicaciones con un usuario no privilegiado (en caso de Linux), por lo tanto no podremos levantar los puertos por debajo del 1024, deberemos cambiarlos en la configuración para que sean por encima del puerto 1024 y posteriormente hacer una redirección con el firewall local. Aquí podéis ver un ejemplo.
  • Para controlar el tráfico de salida, es decir, la actividad que genera o sistemas a los que se conecta nuestro servidor, deberíamos crear reglas para controlar el tráfico. En muchos casos no sería necesario limitar la información de salida, pero si quieres realmente controlar todo lo que sale del sistema y tus requisitos de seguridad son elevados, controlar el tráfico de salida es vital:
Protocolo Puerto TCP/UDP IN/OUT Activo Comentarios
SMTP 25 TCP OUT No Configurado hacia tu MTA. Usado para enviar notificaciones.
DB – PostgreSQL 5432 TCP OUT Si* Depende de la BBDD usada
DB – MySQL 3306 TCP OUT Si* Depende de la BBDD usada
DB – MS SQL Server 1433 TCP OUT Si* Depende de la BBDD usada
DB – Oracle 1521 TCP OUT Si* Depende de la BBDD usada
DB – DB2 50000 TCP OUT Si* Depende de la BBDD usada
LDAP 396 TCP OUT No Hay que activar autenticación/sincronización
LDAPS 636 TCP OUT No Hay que activar autenticación/sincronización
docs.google.com 443 TCP OUT No
OpenOffice 8100 TCP OUT No Sólo si se usa OpenOffice externo
JGroups 7800-7802 TCP OUT No Entre nodos del cluster
NFS 111,2049 TCP/UDP OUT No Sólo si se usa un almacenamiento NFS remoto para contentstore
Kerberos 88 TCP/UDP OUT No Sólo si tenemos SSO con Kerberos
DNS 53 UDP OUT Si Si queremos que el servidor resuelva nombre
  • Seguro que hay otros puertos de salida a tener en cuenta, he destacado los necesarios para que funcione el servidor. Por ejemplo, habría que permitir el tráfico a servicios remotos de Facebook, Twitter, LinkedIn, Slideshare, Youtube, Flickr o Blogs, en caso de usar el Publishing Framework. En este caso, y dado que los puertos de salida comentados en el listado anterior pueden variar, lo más rápido sería abrir hacia internet todo el tráfico del servidor, capturar el tráfico y analizarlo. Hecho eso podremos abrir realmente el tráfico saliente que necesitamos. Claro, todo ese control de tráfico de salida habría que hacerlo si estás muy obsesionado con la seguridad, ahí tienes ideas.
  • Si usas autenticación externa, contra un LDAP, procura usar la conexión segura LDAPS (puerto 636 TCP).
  • Otro aspecto a tener en cuenta son las personalizaciones que utilizan o consumen información de otros servidores remotos, como es lógico, no está contemplado en el listado anterior.
  • Tampoco está contemplado en las tablas de arriba otros puertos y tráfico saliente con destino a servidores remotos en caso de usar Transfer/Replication Services de Alfresco, FSR (Alfresco File System Receiver), Liferay, Drupal, etc. En el caso del Replication Service es muy recomendable usar HTTPS y no realizar las transferencias con el usuario admin.
  • Recuerda: tener un firewall (o cuatro firewalls) bien configurado no es sinónimo de seguridad, es sólo un proceso continuo más que debemos llevar a cabo para controlar lo que ocurre en nuestras redes y en nuestros servidores.

Cifrado de la información:

Si no usamos cifrado en las comunicaciones, las contraseñas y los contenidos viajan en sin cifrar, por lo que esa información podría ser interceptada y usada sin nuestro consentimiento, con el grave perjuicio que eso conlleva.

Y de los servicios que publica Alfresco ¿cuales puedo hacer seguros? Vamos a ver los más importantes de cara al usuario y dónde consultar para aprender a configurarlos apropiadamente:

  • HTTP -> HTTPS:

De esta forma cifraríamos la comunicación (http y webdav) entre el navegador del usuario hasta Alfresco o hasta el frontal web que proteja al servidor de aplicaciones.

Para hacer seguro el acceso web a Alfresco Share, Explorer y webdav, podríamos hacerlo de tres formas:

  1. Usando un balanceador que soporte SSL offloading, en cuyo caso no se necesita configurar nada en el servidor web o servidor de aplicaciones.
  2. Activando HTTPS en el frontal web (Apache) y conectando a Alfresco por AJP (mod_proxy_ajp) o mod_Jk, en este caso deberíamos desactivar el acceso al puerto 8080 de Alfresco para evitar accesos no cifrados y obligar a los usuarios de la red local que accedan por el frontal web. Más información sobre los conectores aquí y como activar SSL en Apache aquí aunque hay miles de recurso en Internet disponibles para configuralo.
  3. Activando HTTPS en Tomcat o en el servidor de aplicaciones que tengas, para Tomcat también hay muchos recursos disponibles, por ejemplo aquí, y en este blog (sección CONFIGURING SSL FOR ALFRESCO TOMCAT). Si Alfresco Share está en una capa por delante de Alfresco habría que hacer la tarea en el frontal de Share y opcionalmente en el repositorio y cambiar la configuración de Share para el acceso a los puertos SSL del repositorio. Este artículo te ayudará a entender como separar en capas y su configuración.

Otra recomendación interesante en este punto puede ser el uso en el frontal web del módulo de Apache mod_security, que es un Web Application Firewall que permite filtrar y eliminar cierto tráfico malicioso hacia nuestro servidor como tráfico SQL injection o XSS e infinidad de otros ataques. Aquí un buen recursos para aprender a implementarlo:

http://www.jpereira.net/gestion-documental/alfresco-y-apache-proxy-security

  • FTP -> FTPS:

Permitiremos a los usuarios conectar mediante FTP cifrando la autenticación y la transferencia de contenidos. Es importante que el cliente FTP soporte FTPS, algo que la gran mayoría de clientes lo tienen superado. Es muy sencilla su configuración está bien explicada en la documentación oficial.

  • SharePoint -> SharePoint SSL:

Como comenté en el correspondiente webinar, la implementación Share Point de Alfresco se hace mediante un servidor de aplicaciones embebido en Alfresco llamado Jetty, que escucha por el puerto 7070 TCP. La configuración por defecto no está cifrada, de hecho, eso hace que tengamos que “parchear” el registro de Windows de los clientes para que funcione MS Office correctamente, como vimos en el webinar, o lidiar con la solicitud de contraseña varias veces. Si activamos SSL no es necesario modificar el registro en los clientes. Además, recuerda que se usará SSL en el mismo puerto (7070 TCP) y no estará disponible la comunicación no cifrada.

Aquí se pueden ver los pasos a para su activación:

http://docs.alfresco.com/4.0/index.jsp?topic=%2Fcom.alfresco.enterprise.doc%2Ftasks%2FSharePoint-HTTPS-setup.html

  • SMTP -> SMTP SSL:

Correo saliente (notificaciones):

En este caso si hablamos de la conexión con el MTA de la organización para que Alfresco envíe notificaciones, no hay problema, podemos configurar Alfresco para que se conecte al servidor de correo remoto mediante SMTPS con autenticación y mediante TLS para cifrado. En el blog hablé de esto, puedes ver un ejemplo aquí, aunque en la versión 3.4 y superior es más sencillo, abajo vemos un ejemplo de parámetros para alfresco-global.properties usado con GMail:

[bash]
### Outbound mail SMTP ###
mail.host=smtp.gmail.com
mail.port=465
mail.protocol=smtps
mail.smtps.auth=true
[email protected]
mail.password=Contraseña
mail.encoding=UTF-8
[email protected]
mail.smtp.starttls.enable=true
[/bash]

Correo entrante:

Del correo entrante también hablé aquí. Hasta la versión 4.0 no está soportado SMTP TLS en Alfresco, como puedes ver en este bug reportado en Jira. En la wiki está bien explicado como configurarlo y en docs.alfresco.com también hay información útil.

  • JGroups -> JGroups SSL:

Aunque si usamos interfaces dedicadas para el tráfico entre nodos no sería necesario, JGroups soporta encriptación en el tráfico entre nodos del cluster, aunque en Alfresco no está contemplada esta opción, se podía hacer: http://www.jgroups.org/javadoc/org/jgroups/protocols/ENCRYPT.html

  • IMAP -> IMAPS:

IMAPS (993 TCP) no está soportado por Alfresco, pero se puede poner una capa por delante a modo de proxy e implementarlo. Existen varias soluciones genéricas como stunnel y algunas específicas como PerditionNginx. En este enlace se puede ver más información: https://issues.alfresco.com/jira/browse/ENH-1152

  • SOLR:

En la versión 4.0, que incorpora SOLR, la comunicación entre repositorio y motor de indexación está cifrada y la autenticación también, además es mutua. Todo ese tráfico es HTTPS. Para otro artículo dejo el uso de los keystores por defecto usados para la protección de la comunicación y acceso a SOLR, que este caso usa claves RSA y certificados x.509. Así como para el cifrado de metadatos con la nueva característica de la versión 4.0, el nuevo tipo “d:encrypted” que permite indicar que una propiedad de un nodo se puede cifrar. De cualquier forma podéis encontrar más info aquí.

Persistencia en las credenciales JMX de Alfresco

Aunque esta es una funcionalidad activada y útil sobre todo para Alfresco Enterprise, creo que es una recomendación de seguridad necesaria y a tener muy en cuenta para entornos en producción. Sobre todo si no filtras los puertos con un firewall. Además así evitarás que alguien modifique la configuración de Alfresco.
Vamos a ver cómo cambiar usuarios y contraseñas de acceso JMX por defecto que vienen en Alfresco y que no se sobreescriban cuando actualizamos la versión y siempre tengamos protegido de forma segura el acceso a la consola de configuración y monitorización de Alfresco.
La receta es muy sencilla:
  • Para ello debemos copiar los ficheros alfresco-jmxrmi.access y alfresco-jmxrmi.password que podemos encontrar por defecto en el directorio tomcat/webapps/alfresco/WEB-INF/classes/alfresco/ y los copiamos por ejemplo en tomcat/shared/classes/.
  • Una vez copiados, podemos editarlos y modificarlos a nuestro gusto, los ficheros están muy bien comentados y no dan lugar a dudas.
  • En el fichero alfresco-jmxrmi.access encontramos los nombres de usuario disponibles y el rol asignado:

[bash]
monitorRole   readonly
controlRole   readwrite
[/bash]

  • En el fichero alfresco-jmxrmi.password podemos cambiar la contraseña de cada uno de los usuarios disponibles:

[bash]
monitorRole  mi-nuevo-password1
controlRole  mi-nuevo-password2
[/bash]

  • Por último deberemos añadir la siguiente linea en alfresco-global.properties y reiniciar el servidor de aplicaciones:

[bash]
alfresco.jmx.dir=/directorio/instalacion/tomcat/shared/classes
[/bash]

Por lo tanto, usaríamos el usuario monitorRole para monitorización (aplicaciones externas como Hyperic o Nagios) y el usuario controlRole para acceder mediante jconsole y configurar Alfresco. De eso ya hablé aquí.

Alfresco: configuración de Single Sign On (SSO) con NTLM vía Active Directory. Parte 3 de 3

En este último artículo de la serie veremos como “Activar el SSO en Alfresco CIFS con Active Directory (NTLM)“:

Recuerda activar los logs de DEBUG para CIFS y tener una visión más amplia de lo que pasa en el sistema, para ello debemos descomentar las líneas correspondientes en el archivo log4j.properties que hay en el directorio classes del alfresco.war desplegado (webapps/alfresco/WEB-INF/classes):

# CIFS server debugging
log4j.logger.org.alfresco.smb.protocol=error
log4j.logger.org.alfresco.smb.protocol.auth=debug
log4j.logger.org.alfresco.acegi=debug

Ficheros que intervienen para configurar SSO en Alfresco CIFS:

  • file-servers.xml en <configRoot>
  • file-servers-custom.xml en <extension>

Copia toda la sección <config evaluator=”string-compare” condition=”CIFS Server”> del fichero file-servers.xml a file-servers-custom.xml dentro de la sección “alfresco-config“.

Y también la sección <config evaluator=”string-compare” condition=”Filesystem Security”> del fichero file-servers.xml a file-servers-custom.xml dentro de la sección “alfresco-config“.

Editamos file-servers-custom.xml:

Añada replace=”true” en <config evaluator=”string-compare” condition=”CIFS Server” replace=”true”>

Para mi servidor Alfresco que lo he llamado “alfresco” con dominio “test.tld” pondría esta configuración:

<serverEnable enabled=”true”/>
<host name=”alfresco” domain=”test.tld“/>
<comment>Alfresco CIFS Server</comment>

En <host name=”alfresco” domain=”test.tld”/> elimina la A, este atributo hace que se publique el CIFS con el nombre de la máquina + A en caso de tener otro CIFS en esa máquina, en nuestro caso sólo tenemos uno y la quitamos.

Modificamos <authenticator type=”passthru”/> y descomentamos y/o modificamos la sección siguiente:
<authenticator type=”passthru“>
<Server>TEST.TLD\10.215.253.165, 10.215.253.165</Server> <!– dominio e IP del controlador del dominio –>
<protocolOrder>TCPIP,NetBIOS</protocolOrder>
<offlineCheckInterval>60</offlineCheckInterval>
</authenticator>

Una vez hecho esto ya podremos arrancar Alfresco y acceder, en mi caso, por CIFS a \\alfresco\Alfresco desde un cliente Windows XP del dominio y accederemos directamente sin solicitar usuario y contraseña.

En los logs deberemos ver algo así (usuario toni que está en Active Directory y ha iniciado la sesión) :

00:07:09,486  DEBUG [smb.protocol.auth] Mapped client /10.215.253.168 to domain null
00:07:09,589  DEBUG [smb.protocol.auth] Passthru sessId=15, auth ctx=[NTLM,Challenge=1d9c38e2728fb40a]
00:07:09,594  DEBUG [smb.protocol.auth] Null CIFS logon allowed, sess = T9
00:07:09,607  DEBUG [smb.protocol.auth] Using Write transaction
00:07:09,613 User:toni DEBUG [smb.protocol.auth] Setting current user using person toni (username toni)
00:07:09,613 User:toni DEBUG [smb.protocol.auth] Passthru authenticate user=toni, FULL
00:07:09,619 User:toni DEBUG [smb.protocol.auth] Closed auth session, sessId=15
00:07:09,647  DEBUG [smb.protocol.auth] Null CIFS logon allowed, sess = T9

Por último, para que funcione todo accediendo por FQDN, por ejemplo, hostname.domain.tld hay que configurar los navegadores según el siguiente manual: http://www.nateirwin.net/2007/01/19/enabling-ntlm-authentication-in-firefox-and-internet-explorer/, es decir, en IE configurar la URL como sitio de confianza.

Alfresco: configuración de Single Sign On (SSO) con NTLM vía Active Directory. Parte 2 de 3

En esta segunda parte veremos como “Activar el SSO en Alfresco Share con Active Directory (NTLM)“:

Hasta aquí, hemos conseguido acceder autenticados automáticamente a Alfresco Explorer y Alfresco Webdav, pero ¿qué pasa con Alfresco Share? Si probáis acceder en este momento tras la configuración anterior , veréis que os pide usuario y contraseña para poder acceder de forma normal, por lo que no está el SSO activado, vamos a ver como se configura.

Ficheros que intervienen:

  • web.xml -> dentro de WEB-INF de share.war (ya desplegado)
  • webscript-framework-config-custom.xml -> dentro de web-extension en el shared

En web.xml descomentar las dos secciones filter y filter-mapping que hacen referencia a NTLM.

En el fichero webscript-framework-config-custom.xml añadir dentro de la etiqueta alfresco-config la siguiente configuración:

<config evaluator=”string-compare” condition=”Remote”>
<remote>

<endpoint>
<id>alfresco</id>
<name>Alfresco – user access</name>
<description>Access to Alfresco Repository WebScripts that require user authentication</description>
<connector-id>alfresco</connector-id>
<endpoint-url>http://yourserver:8080/alfresco/wcs</endpoint-url>
<identity>user</identity>
<external-auth>true</external-auth>
</endpoint>

</remote>
</config>


Donde vemos yourserver debemos especificar localhost que es desde donde Share ve a Alfresco (esto es importante, si no sabes qué poner deja localhost). Reiniciamos Alfresco y listo.

Alfresco: configuración de Single Sign On (SSO) con NTLM vía Active Directory. Parte 1 de 3

Para comenzar el año, os dejo aquí el primero de una serie de 3 artículos sobre la configuración de Single Sign On con Alfresco Enterprise 3.1. Las versiones 3.2 de Alfresco requieren una configuración que difiere de la que se cita a continuación. Estos artículos los he podido escribir gracias a la ayuda de Isaías Aranda, Raúl Macián y Fernando Gonzalez, compañeros y expertos en Alfresco de Intecna.

En este artículo veremos como “Activar SSO (Single Sign On) con Alfresco Explorer y Webdav con Active Directory (NTLM)“, en los siguientes artículos de esta serie veremos cómo “Activar el SSO en Alfresco Share con Active Directory (NTLM)” y cómo “Activar el SSO en Alfresco CIFS con Active Directory (NTLM)“.

¿Qué es Single Sign On (SSO)? Según la Wikipedia, que lo explica bastante bien, es un procedimiento de autenticación que habilita al usuario para acceder a varios sistemas con una sola instancia de identificación. Hablando en plata, que introduces tus credenciales una vez y ya accedes a todas las demás aplicaciones configuradas para funcionar como SSO. Más info aquí.

No confundas SSO con autenticar diferentes aplicaciones con el mismo usuario y contraseña, eso no es SSO, eso será autenticación centralizada.

Este procedimiento explica cómo configurar Alfresco Enterprise 3.1SP2 para que detecte las credenciales del usuario que accede a su estación de trabajo Windows XP logueando en un dominio controlado por Active Directory de esa forma, cuando el usuario acceda a Alfresco con Internet Explorer, autenticará dentro del Alfresco Explorer y Webdav automáticamente sin pedir usuario y contraseña, es decir, detectando el usuario que ya se envía en la sesión de Windows.

También se puede hacer esto con Firefox escribiendo “about:config” sin comillas en la URL, buscamos la cadena “network.automatic-ntlm-auth.trusted-uris” y añadimos (doble-click) la URL de Alfresco, en el caso de este artículo sería http://alfresco.test.tld:8080/alfresco

Datos usados para estos artículos:

  • IP del controlador de dominio: 10.215.253.165 (w2003.test.tld)
  • Dominio: TEST.TLD
  • IP servidor Alfresco: 10.215.253.168 (alfresco.test.tld)

Ficheros que intervienen:

  • web.xml -> dentro de WEB-INF de alfresco.war desplegado, directorio alfresco en webapps
  • ntlm-authentication-context.xml -> en <extension>

En el web.xml modificar según se indica en: http://wiki.alfresco.com/wiki/3.0_Configuring_NTLM#Alfresco_Explorer_and_WebDav_SSO_using_NTLM simplemente es descomentar unas cuantas líneas que prefiero obviar aquí, pero no olvides hacerlo para que todo funcione.

En ntlm-authentication-context.xml quitar la extension .sample del nombre de fichero y modificar o añadir el siguiente bean:
<bean id=”authenticationComponent” class=”org.alfresco.repo.security.authentication.ntlm.NTLMAuthenticationComponentImpl” parent=”authenticationComponentBase”>
<property name=”useLocalServer”>
<value>false</value>
</property>
<!– Damain Servers –>
<property name=”servers”>
<value>TEST.TLD\10.215.253.165, 10.215.253.165</value>
</property>
<property name=”personService”>
<ref bean=”personService” />
</property>
<property name=”nodeService”>
<ref bean=”nodeService” />
</property>
<property name=”transactionService”>
<ref bean=”transactionComponent” />
</property>
<property name=”guestAccess”>
<value>false</value>
</property>
</bean>

Importante, hay que controlar los logs mientras estamos configurando estas funcionalidades, para ello debemos descomentar las siguientes líneas en el archivo log4j.properties que hay en el directorio classes del alfresco.war desplegado (webapps/alfresco/WEB-INF/classes):

# NTLM servlet filters
log4j.logger.org.alfresco.web.app.servlet.NTLMAuthenticationFilter=debug
log4j.logger.org.alfresco.repo.webdav.auth.NTLMAuthenticationFilter=debug

Reiniciamos Alfresco y ya podemos probar. Al acceder vía web (Alfresco Explorer) tras iniciar sesión con Windows XP en el dominio, deberemos ver unas trazas como las siguientes (Dominio TEST.TLD, Usuario: toni, Nombre de la máquina cliente: XPAIR, servidor Alfresco MACBOOK-DE-TONI):

20:41:26,223  DEBUG [app.servlet.NTLMAuthenticationFilter] New NTLM auth request from 10.215.253.168 (10.215.253.168:57688) SID:1B5CD1A3F83CE31F0EA27770359574FD
20:41:26,226  DEBUG [app.servlet.NTLMAuthenticationFilter] Received type1 [Type1:0xa2088207,Domain:<NotSet>,Wks:<NotSet>]
20:41:26,227  DEBUG [app.servlet.NTLMAuthenticationFilter] Client domain null
20:41:26,330  DEBUG [app.servlet.NTLMAuthenticationFilter] Sending NTLM type2 to client – [Type2:0x80000203,Target:MACBOOK-DE-TONI,Ch:9e407e94299c1e11]
20:41:26,335  DEBUG [app.servlet.NTLMAuthenticationFilter] Received type3 [Type3:,LM:3ca6bb198992e77cc713341304743f156de9a77061678617,NTLM:239d3b79b323af49d32a77be92842057d65b32af3fb4236b,Dom:TEST,User:toni,Wks:XPAIR]
20:41:26,381 User:toni DEBUG [app.servlet.NTLMAuthenticationFilter] Updated cached NTLM details
20:41:26,381 User:toni DEBUG [app.servlet.NTLMAuthenticationFilter] User logged on via NTLM, [toni,Wks:XPAIR,Dom:TEST,AuthSrv:MACBOOK-DE-TONI,Sun Dec 20 20:41:26 CET 2009]
20:41:27,287 User:toni DEBUG [app.servlet.NTLMAuthenticationFilter] Processing request: /alfresco/wcservice/api/search/keyword/description.xml SID:null
20:41:27,287 User:toni DEBUG [app.servlet.NTLMAuthenticationFilter] Found webscript with no authentication – set NO_AUTH_REQUIRED flag.
20:41:27,288 User:toni DEBUG [app.servlet.NTLMAuthenticationFilter] Authentication not required (filter), chaining …
20:41:29,537 User:toni DEBUG [app.servlet.NTLMAuthenticationFilter] Processing request: /alfresco/wcservice/api/search/keyword/description.xml SID:7784CDFAD8E6B29103D6A2E02FE558F1
20:41:29,540 User:toni DEBUG [app.servlet.NTLMAuthenticationFilter] Found webscript with no authentication – set NO_AUTH_REQUIRED flag.
20:41:29,540 User:toni DEBUG [app.servlet.NTLMAuthenticationFilter] Authentication not required (filter), chaining …

Recuerda añadir el usuario que quieras dotar de permisos administrador en el grupo ALFRESCO_ADMINISTRATOR o añadir el usuario en el authority-services-context.xml, cópialo en <extension> desde el <configRoot> y lo modificas según tus necesidades:

<property name=”adminUsers”>
<set>
<value>${alfresco_user_store.adminusername}</value>
<value>administrator</value>
<value>TU_USUARIO</value>
</set>
</property>

Y listo. Así de fácil.

Monitoring Alfresco: Nagios/Icinga, Hyperic, AuditSurf… JMX rocks!

Si tenemos Alfresco en producción (versión Enterprise), posiblemente queramos tener la aplicación controlada de la mejor forma posible y sobre todo que ese control nos aporte una visión real de lo que está pasando en el servidor y en la aplicación. Una monitorización efectiva nos permite controlar los problemas con el servicio, atisbar problemas futuros de rendimiento, detectar cuellos de botella, anomalías, etc.

Basic RGBnagios hypericauditsurf

La necesidad estaba ahí, necesitamos una solución de monitorización potente para Alfresco. Las versiones 3.X de Alfresco Enterprise permite ver y modificar muchos propiedades de la aplicación en tiempo real, por ejemplo:

  • Cambiar el nivel de log
  • Activar o desactivar FTP, CIFS o NFS
  • Poner el repositorio en solo lectura.
  • Poner el servidor en mono-usuario.
  • Limitar el número máximo de usurios o evitar accesos adicionales.
  • Ver número de sesiones y tickets de usuarios.
  • Ver número de sesiones y tickets no válidos.
  • Y muchos parámetros más.

Todo esto es gracias al soporte de JSR-160 vía JMX.

Vamos a ver qué opciones existen y cómo podemos implementarlas. Haremos un repaso a Hyperic, AuditSurf, cómo conectar a Alfresco con Jconsole y por último cómo implementar este tipo de monitorización con Nagios o Icinga (nuevo fork de Nagios).

ACTUALIZACION: No olvides ver este y este post. A partir de este artículo hice el módulo de Nagios para Alfresco.

Read More

10 consejos básicos de seguridad en Alfresco

¡¡Actualizado el punto 5!!

Si estás empezando a usar Alfresco, en cuanto a seguridad y protección, es recomendable que tengas en cuenta los siguientes consejos básicos:

1. No uses la contraseña de administrador por defecto (admin/admin), debe ser lo primero que cambies al acceder por primera vez a Alfresco. Incluso puedes crear un usuario super administrador diferente a admin. A partir de la versión 3.1 puedes añadir tantos administradores como quieras en el grupo ALFRESCO_ADMINISTRATORS (vía Alfresco Explorer).

2. No uses el usuario y contraseña de base de datos por defecto. Como sabes, se usa usuario alfresco, contraseña alfresco y base de datos alfresco, para tenerlo en local está bien, pero no lo uses en un servidor, la salud de tu Alfresco depende de ello.

3. Nunca ejecutes Alfresco con un super usuario (root). Crea un usuario específico para levantar la aplicación. También recuerda que al repositorio físico (alf_data), índices y a la base de datos sólo debe acceder el usuario que levante la aplicación alfresco o el usuario que conecta a la base de datos, restringe acceso a cualquier otro usuario para evitar inconsistencias en BBDD y/o repositorio.

4. Usa un firewall como IPtables en la máquina donde está instalado Alfresco para hacer portforward de los puertos inferiores al 1024.

5. Usa un Apache y ProxyPass para proteger tu servidor de aplicaciones, no expongas tu servidor de aplicaciones. Esta configuración de Apache te puede servir de ejemplo, yo uso un fichero llamado alfresco.conf en /etc/httpd/conf.d/ (RedHat, CentOS y derivados):

ProxyPreserveHost On
ProxyPass /alfresco http://127.0.0.1:8080/alfresco
ProxyPassReverse /alfresco http://127.0.0.1:8080/alfresco

ProxyPass /share http://127.0.0.1:8080/share
ProxyPassReverse /share http://127.0.0.1:8080/share

ProxyPass /mobile http://127.0.0.1:8080/mobile
ProxyPassReverse /mobile http://127.0.0.1:8080/mobile

ProxyPass /studio http://127.0.0.1:8080/studio
ProxyPassReverse /studio http://127.0.0.1:8080/studio

También podríamos configurarlo con mod_proxy_ajp en lugar de mod_proxy, para más info sobre las virtudes de mod_proxy_ajp leer este artículo.

RewriteEngine on
RewriteRule ^/alfresco(.*) ajp://127.0.0.1:8009/alfresco$1 [P,L]
RewriteRule ^/share(.*) ajp://127.0.0.1:8009/share$1 [P,L]
RewriteRule ^/mobile(.*) ajp://127.0.0.1:8009/mobile$1 [P,L]

Recuerda activar en el server.xml del tomcat la siguiente línea y reiniciar Alfresco:

<Connector port=”8009″ enableLookups=”false” protocol=”AJP/1.3″ redirectPort=”8443″ />

6. Revisa los logs de Apache y del servidor de aplicaciones continuamente (en Apache el access_log y el error_log así como sus variantes SSL). En cuanto a Alfresco, recuerda que existe el log4j.properties y te permite investigar cualquier evento que ocurra en Alfresco.

7. Protege los accesos y autenticaciones con SSL. Esto se consigue, por ejemplo, instalando el módulo de Apache mod_ssl, de esa forma las conexiones serán seguras (independientemente si se accede desde Internet o Intranet). Además también aseguras las conexiones vía Webdav. Recuerda que accediendo por FTP las contraseñas viajan en claro.

8. Cuidado con los permisos y roles heredados en Alfresco, pueden ser un problema. Recuerda que en Alfresco el protagonista es el contenido, es en él donde hay que aplicar los permisos.

9. Aprovecha el encadenamiento (chaining) que soporta Alfresco en la autenticación y deja siempre para el final la autenticación con la BBDD local, sobre todo si no puedes acceder al LDAP de turno y quieres usar el usuario admin.

10. Realiza backup del repositorio y la base de datos todos los días, ya sea en frío (parando Alfresco) o en caliente, haciendo backup de la base de datos e inmediatamente del repositorio (en este orden). También puedes usar la aplicación de copia de seguridad de Intecna (ver repositorio de software libre de la Junta de Andalucía).

Seguro que se puede ampliar esta lista, ¿que consejos recomiendas tu?