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 Perdition o Nginx. 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í.