Seguridad en las comunicaciones de Alfresco
Toni Enero 24th, 2012
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:
- Usando un balanceador que soporte SSL offloading, en cuyo caso no se necesita configurar nada en el servidor web o servidor de aplicaciones.
- 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.
- 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:
- 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:
### Outbound mail SMTP ### mail.host=smtp.gmail.com mail.port=465 mail.protocol=smtps mail.smtps.auth=true mail.username=correo@gmail.com mail.password=Contraseña mail.encoding=UTF-8 mail.from.default=correo@gmail.com mail.smtp.starttls.enable=true
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í.
