Archive for the ‘Informática’ Category

h1

Alfresco quiere sentirse seguro con SSL (¡por fin!)

septiembre 17, 2015

¡Está chupado!!, pásate por este enlace:

http://docs.alfresco.com/5.0/tasks/configure-ssl-prod.html

¿Ya estás aquí de nuevo?, ¿no te has enterado?… lo suponía 😉

Cuando hace ya dos años y medio implanté el gestor documental “Alfresco Community” en mi empresa lo hice con la intención de cubrir las necesidades de archivo y versionado de la ISO 27001 que acabábamos de implantar con éxito, de ese modo evitábamos pagar por un servicio de archivo en la nube. Digan lo que digan la nube sigue siendo excesivamente cara como medio de almacenamiento y un servidor físico es hoy día más competitivo para estas lides.

Muchos de los que podáis llegar aquí estaréis familiarizados con la sencillez que tiene Apache para utilizar el protocolo SSL donde la simple adquisición o autoemisión de certificados SSL (mediante OpenSSL o PKI de dominio por ejemplo) permite en pocos minutos traspasar a “https” las comunicaciones entre servidor y cliente. Sin embargo, en Alfresco cuando intenté localizar la manera de hacerlo llegue a un infierno información inconexa, así que de forma muy resumida os daré los pasos para que lo tengáis chupado.

ssl_mierd

  • Comenzamos solicitando el certificado correspondiente al dominio de nuestro servidor con el procedimiento habitual.
  • Dado que la plataforma Alfresco tiene una contraseña por defecto generada en varios ficheros, os recomiendo que establezcáis esa misma contraseña para la llave privada (revisad el fichero server.xml).
  • Si deseas cambiar esa contraseña deberás editar los ficheros *password.properties para también modificarlo en los diferentes submódulos de la suite Alfresco.
  • El certificado deberá utilizar el formato PKCS12 con nombre alfresco.p12 (así aprovecharemos los .bat incluidos para incorporar a los “keystore” las diferentes claves). Deberá incluir la CA correspondiente de ser necesario.

¿No sabes hacerlo y tienes OpenSSL?, pues toma nota porque te doy los parámetros para que lo exportes desde tu PKI de dominio con el nombre “alfresco.pfx” si vas a utilizar un servidor en la red local, recuerda que deberás tener una plantilla de servidor en la que la clave privada sea exportable:

openssl pkcs12 -in alfresco.pfx -clcerts -out ssl.crt
openssl pkcs12 -in alfresco.pfx -nocerts -out ssl.key
@rem openssl pkcs12 -export -in ssl.crt -certfile midominio.crt -inkey ssl.key -out alfresco.p12 -name ssl.repo
@rem Descomentar lo de arriba y comentar lo de abajo si queremos integrar en la clave privada la pública del CA
openssl pkcs12 -export -in ssl.crt -inkey ssl.key -out alfresco.p12 -name ssl.repo
ren ssl.crt alfresco.cer
del ssl.key

En el caso de una PKI de dominio no es necesario incluir el certificado público pues el servidor estará integrado y ya confiará en esa CA, tampoco debería ser necesario en una CA pública de confianza, pero usando un certificado autofirmado (nada recomendable) deberemos crear un certificado de CA e incluirlo en el “alfresco.p12”.

Os estoy ahorrando bastante trabajo de investigación con este pequeño .bat  ^_^

Copiaros el fichero alfresco.cer (formato x509) y alfresco.p12 generados por OpenSSL al servidor Alfresco que, no lo olvidéis, os recomiendo que uséis la contraseña que tengáis por defecto en vuestra instancia de Alfresco a la hora de fijar la de la clave privada. También necesitareis el certificado público de vuestro dominio o CA correspondiente.

Y aquí llega lo gordo, os dejo la adaptación del generate_keystores_domain.bat

Adaptar este fichero .bat a vuestros parámetros (ruta origen de certificados, nombre de vuestro certificado de CA…) y, naturalmente, entiendo que ya habéis configurado vuestro servidor Alfresco y se han desplegado los ficheros “war” de Alfresco y Share en sus respectivas ubicaciones y todo funciona perfectamente en el puerto 8080.

Si todo va bien no veréis error alguno y los ficheros estarán en sus lugares correspondientes. Estoy presuponiendo que tenéis unos conocimientos mínimos acerca de que es el “Common Name” de un certificado, de cómo se solicitan, gestionan las plantillas en un PKI, cómo funciona un DNS, etc.

¿Creías que ya podías arrancar Alfresco con SSL sin más?, ¡¡alto insensato!!, no actives el servicio/demonio de Apache Tomcat todavía o vivirás la experiencia de ver un terrible “log” repleto de errores.

Te falta reconfigurar los ficheros solcore.properties ;  alfresco-global.properties ; server.xml y tomcat-users.xml

En el caso del server.xml deberás revisar el SSLEnlable (a true) y configurar en todos los sitios tu puerto de preferencia, en mi caso utilicé el estándar por tener un servidor virtualizado dedicado expresamente a este servicio.

Prestad atención a estas líneas:

<Connector port=”8080″ URIEncoding=”UTF-8″ protocol=”HTTP/1.1″
connectionTimeout=”20000″
redirectPort=”8443” maxHttpHeaderSize=”32768″ />

Para que el servidor redirija las peticiones al puerto seguro, en mi caso el 443.
Y os tocará descomentar las líneas adecuadas.

En el caso del fichero “tomcat-users.xml” es el que me hizo tener dolores de cabeza cuando puse en marcha SSL pues por ningún lado vi referencia al fichero de marras. Finalmente, no recuerdo bien donde demonios localicé estas líneas salvadoras, pero las encontré: “# Note : if you change the following variables, they will also need to be changed in the repo/solr configuration : # REPO_DN and REPO_CLIENT_DN are reflected in tomcat-users.xml.
# KEYSTORES_PASSWORD is reflected in keystores configuration (on both sides : repo and solr (for each core)).
# BROWSER_PASSWORD (password protecting the pkcs12 certificate) is not referenced in the configuration, so can be changed without further action.”

Pues eso, que si no queréis sufrir debéis agregar vuestro:  <user username=”CN=miservidor.midominio.local” roles=”repoclient” password=”null”/>

Me volví loco en mis primeros intentos al haber introducido OU y otros campos en el certificado, pero finalmente desistí porque no funcionaban por razones que desconozco, así que os recomiendo que solamente introduzcáis el CN en vuestro certificado con el FQDN de vuestro servidor Alfresco.

No borréis los “<user username=…>” incluidos pues como habéis visto anteriormente, el solr mantiene el certificado que viene integrado por defecto con la instalación y que caduca en 2113, creo que tenemos tiempo todavía 😉

Recientemente por la obsolescencia de los certificados con firma SHA1 he actualizado mi PKI a SHA256 y he actualizado el certificado de CA de dominio y de inmediato para que los Chrome dejarán de dar el molesto aviso actualicé todos mis servidores web a nuevos certificados con firma SHA256 y gracias a eso mirad que bonito color verde…

httpsporfin

h1

Drupal 6 y los puñeteros “strict warnings” (¡ya hay módulo!)

febrero 19, 2015

No existe nada más coñazo que llegar a la web que administras tras estrenar nuevo VPS, un Debian reluciente como los chorros del oro, un PHP moderno y de repente te encuentras con esto …

strictodrupal

Se puede decir sin lugar a dudas que el mundo de los CMS es una nueva forma de “esclavismo interversional” donde a la que te descuidas puedes encontrarte en un oscuro lugar repleto de errores y advertencias sin haber hecho nada más que mantener un sitio web anclado a cierta versión por motivos diversos.

Tuve la santa paciencia de migrar esa misma web a Drupal 7 sin tener ni idea de CSS o de plantillas de Drupal, pero esa misma maqueta es la que (esta vez profesionales de maquetación web) han rediseñado para la futura web corporativa, así que he preferido mantener la web actual bajo Drupal 6, lo cual la ha salvado de cierto follón que hubo en torno a la versión 7 del popular CMS. No hay web más segura que una no publicada 😉

A lo que iba: ese coñazo tiene fácil solución y consiste en modificar… atentos ….  ¡una puñetera línea de código! del fichero “core”: includes/common.inc

A la línea 668  le añadís simplemente el E_STRICT y así filtrará también esta clase de errores:

if ($errno & (E_STRICT ^ E_ALL ^ E_DEPRECATED ^ E_NOTICE)) {

Con esto vuestro registro en la base de datos pasará a estar esplendoroso y verde.

¿Tan complicado es poner las cosas así de sencillas en Internet?… parece que no porque he leído tratados de filosofía de docenas de “expertos” administradores sobre la vida y milagros de PHP, sin embargo para la cosa más simple que es trucar esa simple línea de código nadie es capaz de dar las instrucciones, como si hacer las cosas sencillas a los demás fuera un pecado 😛

La referencia que me sirvió para resolver el puzzle: http://goo.gl/v6WIdL

PD. Evidentemente si actualizas el núcleo te tocará volver a editar el fichero de marras…


Al final una de las últimas actualizaciones del núcleo hicieron que esta solución no sirva…

Afortunadamente un alma caritativa nos proporciona la solución mediante un simple módulo:

https://www.drupal.org/project/___drupal_php_strict_suppress

¡¡GRACIAS!! (aunque me sorprende que tan sólo tenga 43 descargas, muchos han migrado a Drupal 7 supongo)

h1

Actualizando Alfresco cuando no es posible actualizarlo

octubre 3, 2014

Lo se, estoy comenzando al revés por una razón, y es que la memoria es tan vaga como el administrador de sistemas cuando decide documentar un proceso que probablemente jamás volverá  a necesitar. Internet está lleno de foros y saber extraer la información adecuada no es un proceso sencillo.

No se si alguna vez os he comentado que por razones laborales he pasado de la era pre-Google a otra completamente distinta donde Google parece la fuente del saber. Entre medias estuve trabajando en el sector de la electro-medicina, un campo muy interesante pero menos amplio que el de sistemas, para ejemplo sirve el que los ecógrafos por entonces no usaban (y quizás siga siendo así) bases de datos relacionales y el indexado de las pruebas se convierte en un caos cuando crece el número de pacientes.

A más de uno os habrá pasado que ante una migración se extiende una sensación de miedo ante lo desconocido, especialmente si estamos hablando de sistemas en producción con decenas de personalizaciones que a saber si funcionarán en el nuevo motor del producto que sea, pero es inevitable, tarde o temprano es necesario migrar a una nueva versión que no sólo ofrece mayor rendimiento o funcionalidad, si no que también actualiza los componentes que garantizan la seguridad y estabilidad necesarios para toda empresa que se precie.

El pasado mes de agosto sufrí lo indecible para migrar Alfresco Community de la 4.2c a la 5.0a, saltándome varias versiones por en medio. Ha sido una decisión sabia pues la 4.2c daba bastantes problemas con Kerberos y la integración con Google Docs era pésima.

El escenario en el que me muevo es un servidor físico (Windows 2008 Server R2) con Hyper-V y una máquina virtual que hemos llamado ALFRESCO.
No se si lo sabéis, pero hay un método muy majo para crear una nueva máquina virtual a partir de la copia de seguridad de un VHD existente que consiste en simplemente haber exportado previamente una máquina virtual, lo cual es un proceso largo y tedioso pero, una vez que lo hagamos, ya dispondremos de una fichero .exp que contiene en formato XML todos los parámetros necesarios para poner en funcionamiento la misma máquina virtual en un entorno de pruebas.

Es muy sencillo: a partir de la última copia de seguridad del servidor virtual (porque me imagino que haréis copia… ¿verdad?) extraeremos el VHD y sustituiremos el VHD obtenido en la exportación que en su día hicimos. Con esto hecho importamos la máquina con el nuevo VHD y listo. Así la máquina de producción la mantendremos en funcionamiento constante hasta que tengamos una de pruebas con el nuevo Alfresco operativo 100% . Para evitar la piratería Microsoft genera un identificador único, no lo mováis porque eso supone mover la licencia de un servidor a otro.

Como la máquina importada es “gemela” de ALFRESCO tendrás que iniciarla aislada de la red para según arranque sacarla del dominio y modificar su nombre. En mi caso le puse ALFRESCOTEST y tan contentos.

Con esto ya tenemos una nueva máquina de pruebas a la que sólo queda reconfigurar cualquier fichero de propiedades o XML en donde haya alguna URL o nombre de host de la máquina que tenemos en producción. Un consejo evidente es que siempre que modifiquéis cualquier fichero de configuración hagáis de inmediato una copia del mismo para mantenerlo a salvo de cualquier incidente y que os permita reconfigurar fácilmente Alfresco en caso de migraciones, porque así sabréis que ficheros habéis personalizado. Si tenéis la suerte de tener la versión “enterprise” supongo que podréis trabajar directamente en la GUI vía web.

http://docs.alfresco.com/4.0/concepts/ch-upgrade.html

Bien, aquí tenemos la teoría, parece hasta sencilla, pero a la hora de la verdad es improbable que desde ciertas versiones podáis migrar a otras debido a los cambios de estructura de la base de datos, ya que Google Docs 1.0 introduce ciertos aspectos no compatibles con versiones posteriores: https://issues.alfresco.com/jira/browse/ALF-20086 , todo está documentado y aún así no existe parche, al menos para Community.

Con este panorama y un Alfresco totalmente funcional con SSL, certificado de dominio, Kerberos operativo, sincronización con directorio activo, varios sitios activos y un sistema de reglas para el envío automatizado de nóminas me sentía con pocas ganas de cambiar de versión pero, el mundo no es de los cobardes, así que me puse en marcha:

captura_compare

Lo primero es comprobar que el servidor de pruebas funciona. Alfresco permite que coexistan dos versiones sin mayor problema que renombrar el “dir.root”, este en una instalación normal es: C:\Alfresco, así que basta con renombrar C:\Alfresco a C:\Alfresco.old  e instalar la versión a la que queremos migrar, con esto la “suite” completa se instalará sin mayor problema. Lo segundo que os recomiendo es ir poco a poco editando todos los ficheros personalizados, para mi la herramienta fundamental es Notepad++ y el “plugin” Compare, ya que nos permite ver las diferencias entre el fichero original y el que hemos personalizado en la vieja instalación de Alfresco, dicho lo cual nos ponemos a reconfigurar nuestro nuevo Alfresco hasta que funcionen las características que personalizamos (https, AD, Kerberos…)

Para esta tarea de personalización nos servirán los tutoriales que prepararé de aquí a diciembre según me quede tiempo (más bien poco), pero si quieres migrar es que ya tienes una instalación, así que de momento puedes ir tirando con lo que ya tienes instalado.

Cuando la base de datos no es posible migrarla y parchearla para la nueva versión de Alfresco, lo mejor es partir de cero y utilizar los ficheros “.ACP”, que son los que me salvaron la vida. Básicamente son el “copia/pega” de Alfresco. Entrando como administrador en nuestro servidor iremos a la Consola de Administración donde tenemos las herramientas de exportación. No es excesivamente complicado pero si poco intuitivo porque hemos de ir primero a lo que queremos exportar y luego pinchar el icono de la consola. Si lo hacemos bien veremos por ejemplo:

captura_exportar_sitiosDesde ahí cuando pulsemos en exportar veremos que tenemos la opción de “Exportar ‘Sitios’ “, y si, es así de sencillo porque podremos marcar que exporte desde el espacio actual incluyendo los hijos, con lo que el ACP tendrá todo el contenido empaquetado y listo para importar en la nueva instalación. No olvides seleccionar un destino que es el lugar del repositorio donde el fichero ACP será situado para que luego puedas rescatarlo vía interfaz web, WebDAV o CIFS.

Todo este proceso sólo tiene un “pequeño” defecto, o al menos yo no di con la tecla adecuada, y es que perdí el versionado de los ficheros y sólo se copió la última versión de cada fichero en la biblioteca de documentos de los respectivos sitios. Sin embargo las reglas se conservaron (con matices) y me supuso muchísimo menos trabajo que haber tenido que regenerar todo el árbol de sitios y ficheros. Eso si, si alguien ha pasado por esta experiencia y ha logrado una migración satisfactoria cuando esa migración no es posible mediante el proceso de “upgrade”, somos todo oídos.

Tengo muy claro que para empresas que estén hasta arriba de sitios, espacios personales y demás, pues puede ser un infierno, pero si has tenido la suerte de que la instalación que tenías se ha usado para cuatro cosas mal contadas, al menos podrás disfrutar de tu nueva versión de Alfresco en un plazo razonable. Sólo una curiosidad: pregunté a un consultor experto en Alfresco el coste normal de una migración en una mediana empresa con la versión “Enterprise”, y, os sorprenderá saber (o no) que cobran del orden de 10.000 €. Os garantizo que por mucho menos podemos ir poco a poco trasladando por esta vía todo los espacios de datos.

Respecto a los permisos y demás… pues bien, también perdí los usuarios, pero tampoco me preocupaba mucho porque a cambio Kerberos funcionaba a la perfección en el “Share” ¡sin haber tocado nada!, simplemente trasladé la configuración desde una instalación a otra y me sorprendí cuando de repente probando por probar vi que “Share” cogía automáticamente las credenciales (utilizamos Chrome Bussiness). Bastó con mandar una circular interna para que pincharan el enlace (aproveché para utilizar el puerto https estándar ya que no lo tenemos publicado en Internet) y enseguida tuve a todos los usuarios con sus respectivos espacios personales a los que les pude trasladar los datos con facilidad desde el viejo Alfresco.

Para otra ocasión hablaremos del necesario “keystore” y https. Existen varios detalles muy mal documentados a la hora de añadir https, procuraré en una sola entrada resumiros los puntos críticos del proceso, para el resto de cosas ya existe múltiple y variada documentación.

h1

¡Alfresco! (mientras puedas)

agosto 11, 2014

Hace poco más de un año decidí implantar en mi empresa un servidor de Alfresco en su versión Community (4.2c) y desde entonces mi vida ya no es la misma.

Es cierto que el comienzo es fácil: el instalador desempaqueta los componentes de Alfresco (Apache Tomcat, Java, Openoffice, Solr…) y te deja lista una configuración que te puede servir si tu aspiración es muy básica, pero… ¿qué ocurre cuando quieres ir un poco más lejos en su versión gratuita?, es entonces cuando ante ti se despliega un pequeño infierno en el cual tareas que, en otros entornos son relativamente sencillas, en Alfresco “Community” parecen una novela negra para el administrador de sistemas.

Este año me he enfrentado a múltiples y variadas pruebas que me han hecho dudar de mi mismo como administrador de sistemas, sin embargo la fe y la perseverancia ha terminado por dar sus frutos y he logrado tener una instalación con buen rendimiento, estable, integrada en el dominio, segura y eficaz. Así que para que no sufráis demasiado os iré detallando de forma cronológica algunos de los pasos que fui dando desde la 4.2c a la 5.0a, versión que actualmente tenemos en producción.

alfresco_logo

Bueno, no es exactamente comida italiana lo que nos ofrece Alfresco, aunque bien podría servirnos como símil ya que Alfresco viene a ser una especie de espagueti que enlaza de manera formidable la documentación empresarial mediante una serie de motores que operan entre ellos para ofrecer trazabilidad, indexado, etiquetado, versionado y soporte para flujos de trabajo sobre dichos documentos, sin olvidar por supuesto que con los protocolos CIFS y Webdav nos permite disponer de un sistema de almacenamiento.

El problema de Alfresco reside en que sus grandísimas capacidades a su vez requieren ingentes cantidades de documentos que permitan siquiera poder administrarlo. A añadir que su versión gratuita no dispone de una consola de administración, con lo cual el administrador debe navegar en un ecosistema de ficheros .properties y xml algo farragoso.

Quiero con mi modesta contribución ofreceros algunos recursos, páginas que consulté y, sobre todo, problemas a los que me enfrenté más sólo que la una para lograr que Alfresco fuera un lugar seguro en el que depositar la documentación vital de una empresa.

Estos serán los puntos que detallaré y que considero más útiles:

h1

¿Kerberizamos un poco?

enero 22, 2014

Ser administrador de sistemas requiere una gran dosis de paciencia.

En estos días he necesitado mucha para enfrentarme al “todopoderoso” Kerberos, sistema introducido por el M.I.T. a principios de los años 80 tras haber utilizado con éxito el protocolo a nivel interno.

El gran problema a la hora de trabajar con Kerberos es la grandísima cantidad de módulos e implementaciones que tiene. En la actualidad se utiliza la versión 5 (la 4 fue la primera en distribuirse para uso general) asociada a un montón de RFCs que describen en detalle la operativa. Si a esto le añadimos las variaciones que pueden tener los diferentes despliegues en las decenas de sistemas operativos que lo soportan, pues ya la tenemos liada.

El escenario en el que me he movido estos días era un poco atípico: necesitaba aprovechar un servidor NAS (FreeNAS 9.2) algo infrautilizado para que los usuarios de otra sede de mi empresa tuvieran un repositorio de Subversion que rindiera, sin estar sujeto a la lentitud y latencia de un túnel IPsec. Así que paso a paso os cuento lo que hice y las locuras a las que me enfrente con estos elementos:

  • Servidor Windows 2008 R2 Server
  • Servidor FreeNAS 9.2 integrado en el directorio activo.
  • Jail de FreeBSD con los “ports” disponibles.

Mi objetivo era no hacer una chapuza, intentando que el cliente SVN se conectase al repositorio de forma segura (SSL) y sin necesidad de transmitir usuario/contraseña.

En primer lugar puse en marcha un precioso “jail” con la plantilla “pluginjail” de FreeBSD que FreeNAS incluye en el GUI, esta plantilla es genial porque tiene lo justito y necesario para desplegar con facilidad un servidor SVN publicado por Apache y los elementos necesarios para gestionar Kerberos.

Aunque es realmente sencillo desplegar un FreeBSD con esta plantilla, detecté la aparición de bastantes errores en el “syslog” relativos al Netbios, ya que FreeNAS monta un alias IP para el “bridge” con el “jail”, generando una duplicidad de “host” para las dos IPs, para evitarlo os recomiendo activar VIMAGE y eliminar la IP alias, esto virtualiza la pila TCP/IP y, aunque es una característica algo experimental, lo cierto es que funciona bastante bien.

Una vez tengáis una IP asignada al “jail” de FreeBSD y acceso al “shell”, tendréis que modificar bastantes parámetros, en concreto en /etc/hosts conviene que el FQDN del “jail” esté reflejado en la 127.0.0.1

Ejemplo:  127.0.0.1                 localhost serversvn.dominio.local

Aunque en muchas guías se ponen pesados con la resolución inversa en el DNS del FQDN, realmente no es necesario. 

Haremos un “cd /usr/ports” y procederemos a instalar los paquetes que necesitamos. Por si acaso no estáis familiarizados:

[cmd] cd /usr/ports/www/apache22 ; make install [/cmd]
(usamos Apache 2.2 por no disponer de Kerberos el port del 2.4)

Con ello saldrá la pantalla de configuración. No olvidéis activar el módulo SSL y el “rewrite” que siempre vienen bien para por ejemplo forzar https de forma trasparente para el usuario. También para SVN harán falta el DAV y DAV_FS. Y mediante el mismo procedimiento instalaremos en /usr/ports/www/mod_auth_kerb2 el módulo de Kerberos para Apache.

Para terminar ya solamente nos hace falta Subversion, en /usr/ports/devel/subversion dispondremos de la última versión (siempre es recomendable hacer un [cmd] portsnap fetch ; portsnap update [/cmd] por si las moscas. No olvidemos en la pantalla de configuración activar el MOD_DAV_SVN que instalará y activará el módulo DAV necesario para los clientes.

Tocaría ahora configurar el fichero /etc/krb5.conf para configurar el KDC. Es realmente sencillo si, lógicamente, tenemos algo de idea respecto a la configuración para por ejemplo la integración de Samba en un directorio activo. Por si acaso os paso un ejemplo con unos parámetros revisados y comprobados:

[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24000
clockskew = 300
default_realm = DOMINIO.LOCAL [realms]
DOMINIO.LOCAL = {
kdc = kdc.dominio.local:88
} [domain_realm]
dominio.local = DOMINIO.LOCAL
.dominio.local = DOMINIO.LOCAL
DOMINIO.LOCAL = DOMINIO.LOCAL
.DOMINIO.LOCAL = DOMINIO.LOCAL [appdefaults]
kinit = {
renewable = true
krb4_convert = false
forwardable = true
}

Y con esto pasamos a la chicha, que es la parte que más se me ha complicado debido a a los tipos de cifrado soportados. Inicialmente Microsoft en este enlace nos dice alegremente que pasemos de verificar el KDC con la opción “KrbVerifyKDC Off”, lo cual abre una brecha de seguridad que posibilita a un atacante meternos un servidor maligno que Apache no se preocupe de comprobar. Entiendo que es complicado que alguien se preocupe de venir a nuestra oficina con un servidor malo maloso, pero nunca se sabe, especialmente en grandes empresas 🙂

Si hubiera decidido hacer caso a M$ estaría todo listo en un par de horas, pero preferí complicarme la vida a sabiendas de que no hay buena documentación y, los foros, a veces más que ayudar nos complican la vida. Eso si, reconozco que en los tiempos pretéritos buscarse la vida entre miles de fotocopias, libros y apuntes era mucho peor.

Lo primero de todo es crear una cuenta en el directorio activo para que la pueda utilizar el servicio Apache. La contraseña la podemos definir ahora o luego (cuando generemos el “keytab” con el comando “ktpass”). Como nombre de inicio de sesión de usuario indicaremos el servicio y el FQDN, es decir: HTTP/serversvn.dominio.local y como nombre de cuenta (anterior a Windows 2000) lo que queramos. Anotamos los datos y esa será la cuenta que hará de enlace con el directorio activo para autenticar a los usuarios de Apache.

Una vez hecho esto vamos a la línea de comandos del servidor de dominio y generamos el fichero “keytab” que viene a ser una forma segura de validar al servidor  Apache contra el KDC. El comando es un poco engorroso, así que os paso los parámetros que funcionan a la perfección en mi escenario:

[cmd] C:\>ktpass -princ HTTP/serversvn.dominio.local@DOMINIO.LOCAL -mapuser usuariosvn@DOMINIO.LOCAL -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password -out fichero.keytab [/cmd]

Parece algo lioso, pero no lo es. Básicamente lo parametrizamos como servicio HTTP, la / actua de separador, luego va el FQDN del servidor que utilicemos (a estas alturas supongo ya has registrado una entrada DNS estática apuntando al “serversvn”) y lo mapeamos como el usuario (anterior a Windows 2000) que acabamos de crear. Indicamos la versión y tipo de servicio Kerberos y el cifrado, finalmente indicamos el nombre del fichero keytab que copiaremos posteriormente en /usr/local/etc/apache22/keytab o una ruta a la que tenga acceso Apache.

Ahora vamos al directorio activo y en el usuario que hemos creado marcamos en “Opciones de cuenta” que la contraseña nunca expire, también marcamos “No pedir la autenticación de Kerberos previa” y, finalmente, el detalle que me complicó la vida enormemente, que aunque no parezca necesario es imprescindible: marcad también “Esta cuenta admite cifrado AES de Kerberos de 256 bits” porque parece que por defecto el KDC basado en Windows 2008 Server utiliza otro cifrado (y esto por más que he mirado, no lo he visto en ningún lado, de hecho M$ afirma tenerlo activo por defecto).

Esta cuenta recomiendo que sea miembro de “Invitados del dominio”, no precisamos que tenga acceso a más recursos que el simple intercambio de “tickets Kerberos”.

Con esto queda lo más sencillo. En primer lugar conviene poner unos permisos restrictivos al “keytab” y lo haremos legible a Apache cambiando el propietario. Una vez tenemos el fichero “keytab” en el “jail” de FreeBSD hacemos:

[cmd] chmod 640 /usr/local/etc/apache22/keytab/fichero.keytab ; chown www:www /usr/local/etc/apache22/keytab/fichero.keytab [/cmd]

Y probamos que el “keytab” funciona bien: ” kinit -k -t fichero.keytab HTTP/serversvn.dominio.local” . Si tenemos la suerte de no recibir ningún error, con el comando “klist” veremos que tenemos un “ticket kerberos” emitido para nuestro servidor, comprobad que el SPN es completo, incluyendo el @DOMINIO.LOCAL

Si hay error tendremos que verificar que hay conectividad al KDC y que los pasos anteriores han sido correctamente realizados.

Y para finalizar queda configurar Apache, donde tan sólo toca personalizar en el fichero /usr/local/etc/apache22/httpd.conf los siguientes parámetros:

  1. servername serversvn.dominio.local  (FQDN)
  2. Listen 443 (o el puerto que queramos utilizar para https)
  3. Revisamos que los módulos “mod_auth_kerb.so”, “mod_rewrite.so”, “mod_dav.so”, “mod_dav_fs.so”, “mod_ssl.so”, “mod_dav_svn.so” y “mod_authz_svn.so” están sin comentar.
  4. Personalizamos el DocumentRoot a donde publicaremos los repositorios SVN.
  5. En el <Directory “/usr/local/www…> indicamos el DocumentRoot que acabamos de definir y dejamos sin comentar solamente AllowOverride All (para permitir autenticación kerberos) y listo. Esto también podríamos definirlo posteriormente en el Virtual Host, pero en ocasiones hay gente a la que le da problemas.

Entiendo en este punto que sabéis generar los certificados necesarios para https ya sea con OpenSSL, PKI de dominio o comprando un certificado a una entidad certificadora. Una vez tengamos los certificados crearemos la ruta /usr/local/etc/apache22/Includes un fichero.conf con el siguiente contenido:

# Forzamos https
<VirtualHost *:80>
RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
</VirtualHost>
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile etc/apache22/ssl/serversvn.crt
SSLCertificateKeyFile etc/apache22/ssl/serversvn.key
SSLCACertificateFile etc/apache22/ssl/CA.crt
<Location />
DAV svn
SVNParentPath /usr/local/www/subversion/
SVNListParentPath On
SVNAutoVersioning On
AuthName “SVN SERVER
AuthType Kerberos
KrbMethodNegotiate On
KrbVerifyKDC On
KrbSaveCredentials On
KrbMethodK5Passwd Off   (esto es opcional pero recomendable como medida de seguridad)
KrbAuthRealms DOMINIO.LOCAL
Krb5KeyTab /usr/local/etc/apache22/keytab/fichero.keytab
KrbServiceName HTTP/serversvn.dominio.local
SSLRequireSSL
Require valid-user
</Location>
<Location /repo1>
AuthzSVNAccessFile /usr/local/www/subversion/repo1/conf/auth.conf
</Location>
</VirtualHost>

Con esto ya estamos cerca de terminar, y ya me gustaría a mi que alguien me hubiese preparado todos los pasos así tan sencillos 🙂

Vamos a crear el repositorio y el fichero de autenticación de usuarios de dominio autorizados para el “repo1”. Presupongo que en la ruta “DocumentRoot” antes definida habéis creado el directorio “subversion” o como lo queráis llamar. Hacéis un “cd” a la ruta de subversion y con el comando “svnadmin create repo1” generamos la estructura.

Entraremos en repo1/conf/ y crearemos el fichero auth.conf y dentro establecemos los permisos tal como viene definido en la ayuda de ejemplo que tenemos en el fichero “authz”, con la salvedad de que a todos los usuarios debemos agregarles @DOMINIO.LOCAL 

Siempre mucho cuidadín con las rutas, no es raro despistarse y que se produzcan errores por este motivo.

Hacemos un buen “apachectl restart” tras crear el repositorio SVN, así nos aseguramos de que no hay errores de sintaxis en los ficheros de configuración de Apache y ya sólo queda lo fácil, que es ir a cualquier cliente de SVN en un equipo que esté en el dominio para probar, aunque también podemos utilizar Internet Explorer que por defecto reconoce como zona Intranet a cualquier equipo con FQDN de nuestro dominio: https://serversvn.dominio.local/repo1 y a ver qué pasa. ¡Suerte!

h1

Una de sistemas… seguros

agosto 13, 2013

No se me había ocurrido hasta ahora incluir en este “blog” una entrada relacionada con mi perfil profesional, pero lo cierto es que llevo desde 1984 embelesado con la que yo denomino “ciencia de las ciencias”, así que creo que va tocando 🙂

Para mi la informática más que una afición es toda una pasión. Por más años que lleve dedicándome de forma profesional a esto, parece que nunca dejo de disfrutar con cada nuevo descubrimiento. En lo relativo a esta entrada quiero hablar un poco del sistema FreeNAS en su última versión que incorpora el maravilloso sistema de ficheros ZFS versión 28, una gozada para todos los que tengáis experiencia en sistemas Solaris y derivados. Tras una pequeña pelea en su actualización desde la “release” 8.3.1, conseguí poner en marcha de nuevo el servicio de “directorio activo”, ya que ahora es necesario seleccionar el servicio de directorio en la pestaña de “settings”, de no hacerlo jamás podrás activar el servicio:

settings_freenas

En esta nueva versión disponemos de segregación de roles en la configuración avanzada del directorio activo, de modo que podemos apuntar a diferentes servidores para balancear mejor la distribución de la carga de trabajo. Hasta ahora lo más que podías hacer era apuntar a un servidor de dominio. Un buen truco era apuntar al nombre del dominio (en formato DNS) y así los registros SRV que son dinámicos asignaban en cada momento la IP al servidor con menos carga de trabajo. Ahora con estos nuevos campos avanzados podremos personalizar algo más la configuración. Además para redes que tienen cierta latencia podemos aumentar el “timeout” tanto para DNS como para directorio activo, lo cual nos vendrá muy bien si por ejemplo tenemos un túnel IPSec con otra sede.

A lo que iba, si algo me ha mosqueado en esta nueva “release” de FreeNAS es la escasez de información, dando por supuesto que todos sabemos de todo y que por tanto averiguaremos cosas como que ahora hay que seleccionar el servicio de directorio y no como antaño, que simple y llanamente configurabas el servicio de directorio que te interesaba y lo activabas en la pestaña de servicios. Supongo que la razón es que algún que otro cafre debió configurar varios servicios LDAP y ello pudo causar un conflicto a Samba. Ahora hay que elegir y activar forzosamente un sólo servicio. Sea como sea me gusta y tan sólo he encontrado varios problemillas de fácil resolución:

  • El NTP por motivos desconocidos ha fallado en dos ocasiones con la configuración por defecto, así que he optado por seguir las recomendaciones y sincronizar contra el servidor de dominio.
  • No olvides añadir una entrada estática en el DNS que apunte al servidor NAS.
  • FreeNAS  no lleva demasiado bien eso de que activemos los requisitos de firma LDAP en las políticas de dominio. Tengo pendiente experimentar con esta nueva versión. En la 8.3.1 funcionaba bien a nivel Samba, pero el interfaz web no permitía seleccionar usuarios de dominio para los “datasets” ZFS, dando un error de un “script” de Python.

Además ¡por fin!, permiten desde la interfaz web incluir “scripts” “pre init” y “post init”, muy cómodos para personalizar cosillas como por ejemplo el Syslog, ya que es un coñazo que por defecto FreeNAS tenga un nivel “info” y no te permita ajustarlo desde la interfaz web.

Finalizaré con un detalle muy importante: la seguridad…
No mola nada que la aplicación web no sea capaz de interactuar con los usuarios de dominio si se activan los requisitos de firma LDAP. Pero lo peor no es eso, si no que te pidan alegremente que almacenes la contraseña de un usuario “administrador de dominio” para simple y llanamente enlazar con el dominio y validar sus usuarios/grupos. Esto es especialmente grave ya que el sistema utiliza “Kerberos” como protocolo de autenticación de clientes y realmente no debería precisar de una cuenta con semejante nivel de privilegio. Ante esta tesitura y siendo como soy responsable de seguridad en mi empresa, me he planteado la política de “mínimo privilegio” para la cuenta que utilice FreeNAS para enlazar con el dominio y sincronizar usuarios/grupos. Tras experimentar sin éxito la “delegación de control”, opté por emplear un grupo “BuiltIn” que nos ofrecen los servidores de dominio: “Operadores de cuenta”. Haciendo que la cuenta que utilice FreeNAS sea simplemente “Invitado de dominio” y agregando la misma al grupo “Operadores de cuenta”, restringiremos bastante el potencial destructivo de un posible atacante que pudiera acceder al dominio con los permisos de este usuario.  En seguridad es siempre mejor pecar de paranoico que lamentar las consecuencias de una brecha de seguridad causada por un “0day”. Ale, espero que no sea la última entrada de esta temática 🙂

(Actualización 17/09/2015) A fecha de hoy la versión 9.3 de FreeNAS ha mejorado muchísimo todos estos aspectos, a los cuales en parte hemos contribuido usuarios que como yo lucharon “manualmente” activando SSL desde la configuración de Samba y forzando vía GPO la conexión segura a los servidores de dominio.

El nuevo configurador del servicio de directorio requiere:

  • Certificado público de la CA de tu dominio en “System / CAs”.
  • Seleccionar dicho certificado en el apartado “Directory / Active Directory”.
  • Utilizar la cuenta “invitada de dominio” miembro de “operadores de cuentas” que designéis para el “bind”.
  • Especificar “seal” que es la modalidad más segura de comunicación con los controladores de dominio.
  • Encryption SSL.

En la última actualización ya se han resuelto muchos problemas como el “timeout” que siempre daba problemas ya que el “script” de enlace al dominio es tremendamente complejo y cualquier mínimo retardo en las comunicaciones daba al traste con el enlace al dominio. Por lo demás, una vez unido al dominio el servidor NAS irá de maravilla con todos los usuarios y ACLs de Windows bajo Samba, que cada vez hacen más integrable el servidor con redes Windows.