: : blyx.com : : Blog : : Toni de la Fuente : :

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:

• 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:

• 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:

### 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í.

Tags: alfresco, Seguridad

• Seguridad , administración de sistemas
• Comments(0)

Toni Diciembre 20th, 2011

monitorRole   readonly
controlRole   readwrite

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

monitorRole  mi-nuevo-password1
controlRole  mi-nuevo-password2

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

alfresco.jmx.dir=/directorio/instalacion/tomcat/shared/classes

Tags: alfresco, monitorización, Seguridad

• Seguridad , administración de sistemas
• Comments(3)

Toni Enero 4th, 2010

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.

Tags: alfresco, open source, Seguridad

• FLOSS
• Comments(2)

Toni Enero 2nd, 2010

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>

</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.

Tags: alfresco, Seguridad

• FLOSS , Seguridad
• Comments(0)

Toni Enero 1st, 2010

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.

Tags: alfresco, Seguridad, sys admin

• FLOSS
• Comments(0)

Toni Noviembre 19th, 2009

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.

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).

Actualización: No olvides ver este y este post.

Continue Reading »

Tags: alfresco, enterprise applications, monitorización, Seguridad

• Seguridad
• Comments(12)

Toni Noviembre 9th, 2009

¡¡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?

Tags: alfresco, Seguridad

• Seguridad
• Comments(2)

Toni Febrero 16th, 2009

Aquí la otra sobre PKI y herramientas para implementarla.

Tags: conferencias, open source, Seguridad

• FLOSS , Seguridad
• Comments(0)

Toni Febrero 16th, 2009

Lo prometido es deuda. Aquí tenéis la presentación sobre la conferencia que di en La Habana la semana pasada. Saludos a todos los que asistieron.

Más presentaciones mias aqui.

Tags: conferencias, open source, Seguridad

• FLOSS , Seguridad
• Comments(0)

Toni Enero 16th, 2009

[Extraido de mi libro] En este artículo vamos a ver como gestionar un servidor de forma segura si almacena muchas cuentas con acceso a shell, gestión de rotación de contraseñas, privilegios de super usuario (root) y configurar un poco más seguro nuestro servidor SSH.

Continue Reading »

Tags: Linux, Seguridad, sys admin

• administración de sistemas
• Comments(0)