Pero hoy, tras actualizar a la versión 2.8.1, por casualidad he lanzado un grep en un directorio que no tocaba y he descubierto el fichero wp-admin/includes/class-wp-filesystem-ssh2.php. Resulta que WordPress también puede usar SSH para realizar esas actualizaciones. Normalmente esa opción no aparece por que no disponemos de todo el software necesario para que funcione, pero es bastante sencillo conseguirlo. Veamos como hacerlo en una Debian:

$ sudo aptitude install libssh2-1 libssh2-1-dev php5-dev
$ sudo pecl install -f ssh2
$ sudo vi /etc/php5/conf.d/ssh2.ini
    extension=ssh2.so
$ sudo /etc/init.d/apache2 restart

Una vez tenemos instalada la extensión ssh2.so de PHP, podemos desinstalar los paquetes de desarrollo que instalamos en el primer paso.

$ sudo aptitude remove libssh2-1 libssh2-1-dev php5-dev

Listo, ya podemos actualizar los plugins desde la comodidad de nuestro navegador sin necesidad de tener un servidor FTP o FTPS. Seguramente también se puede usar para actualizar el propio WordPress, aunque no lo puedo confirmar ya que yo lo actualizo usando subversión.

Como se puede ver es bastante sencillo. De todas formas, os dejo un screencast que he hecho sobre la instalación (inaugurando mi cuenta de YouTube).

Voy a dar por sentado que tenemos un Postfix instalado y configurado para que use el Amavis para las funciones de anti-virus y anti-spam. Si no es así, te recomiendo que leas el excelente artículo de Jaume Sabater.

El primer problema lo tenemos si el mismo servidor está actuando como MX y como servidor SMTP para nuestros usuarios: Amavis firmaría tanto los correos de nuestros usuarios como los que le llegan en su función de MX, y no es lo que queremos. Por tanto, lo primero es separar esas dos funciones (MX y submission) en el Postfix añadiendo las siguientes líneas en /etc/postfix/master.cf (seguramente ya haya algo parecido pero comentado)

1
2
3
4
5

submission inet n       -       n       -       -       smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o content_filter=smtp-amavis:[127.0.0.1]:10026

Con estas líneas estamos indicándole al Postfix que también escuche por el puerto de submission (587/tcp), que por ese puerto sólo acepte correo de conexiones autentificadas y cifradas por TLS, y que debe enviar los correos recibidos al Amavis usando el puerto 10026 (mientras que el resto se seguirá enviando por el puerto 10024). Con esto conseguiremos que Amavis distinga y trate de forma diferente los correos de los usuarios.

Lo siguiente es hacer que Amavis también escuche por el puerto 10026 y hacer que firme los correos que le lleguen por ese puerto. Lo haremos añadiendo al fichero /etc/amavis/conf.d/50-user:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$inet_socket_port = [10024, 10026];
 
$interface_policy{'10026'} = 'AUTH';
 
$policy_bank{'AUTH'}   = {           # Authenticated clients
os_fingerprint_method   => undef, # don't fingerprint authenticated clients
bypass_spam_checks_maps => [1],   # don't spam check authenticated clients
originating => 1,
#
# force MTA to convert mail to 7-bit before DKIM signing
# to avoid later conversions which could destroy signature:
smtpd_discard_ehlo_keywords => ['8BITMIME'],
};
 
$enable_dkim_signing = 1;
dkim_key('llull.net', 'personal', '/etc/dkim/llull.net.key.pem');

En la última línea le indicamos que para el dominio ‘llull.net‘ y el selector ‘personal‘ debe firmar los correos con la clave privada contenida en el fichero /etc/dkim/llull.net.key.pem. Para generar ese fichero ejecutaremos como root el comando

server:~# amavisd-new genrsa /etc/dkim/llull.net.key.pem
Private RSA key successfully written to file "/etc/dkim/llull.net.key.pem" (1024 bits, PEM format)

Ya sólo falta obtener y configurar en nuestro servidor DNS la clave pública y para ello disponemos de otro comando:

server:~# amavisd-new showkeys
personal._domainkey.llull.net.  3600 TXT (
"v=DKIM1; p="
"MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDoTaWXxsXpNi100Flp7fIKJSlZ"
"ptMP4aCCZjUFgT7TsWokWQJhnGUNnxexEqqPtCDbCUAvEg3iieMRrKwZoHAUDqCf"
"fvW9dcYR7+NdnaxAXCBpOh8Wg5GFJeIid9Gsx3ByBObBQnRGSMOxdBRBO4VXwGb2"
"hKAIOiBMPxaFghdDZQIDAQAB")

Y ya sólo falta añadir la salida del anterior comando a la zona de nuestro dominio en el servidor DNS. La salida está en formato Bind por lo que si usamos ese servidor DNS no tendremos más que añadir  ese texto en el fichero correspondiente.

Acordaos de reiniciar el Postfix, Amavis y Bind para que apliquen las nuevas configuraciones. Para comprobar que todo está funcionando correctamente, podemos enviar un correo a uno de los reflectores existentes.

Ahora ya no tenéis escusa para que vuestro servidor de correo no firme los correos salientes. Si os surge alguna duda, usad los comentarios. Aunque creo que me he acordado de todo, han pasado algunos meses desde que lo configuré y es posible que haya pasado algo por alto.

Artículo basado en la documentación oficial de Amavis.

Desgraciadamente, las webs seguras nunca han podido beneficiarse de esta mejora por la forma en que funciona el protocolo HTTPS (HTTP sobre SSL). La cabecera Host que permite al servidor discernir el host virtual al que va dirigida la petición del usuario está a nivel HTTP, debajo del cual tenemos SSL y su negociación. En esa negociación es cuando el servidor envía al cliente su certificado X.509 y el navegador comprueba la validez del certificado comparando el campo CN del certificado con el nombre del dominio al que se está conectando. Por tanto, el servidor debe enviar el certificado correcto, y por tanto del host virtual correcto, al navegador antes que este le pueda indicar mediante la cabecera Host el dominio al que se quiere conectar. La única solución es usar VirtualHosts basados en dirección IP.

Sin embargo, si los diferentes dominios que tenemos en el servidor son subdominios que comparten el second-level domain, o SLD, podemos conseguir que todos ellos dispongan de web segura usando una única dirección IP. Por ejemplo www.example.com y mail.example.com tienen el SLD example.com en común.

Para conseguirlo, también es imprescindible el uso de un Wildcard SSL Certificate (he decidido no traducirlo porque ninguna de las tradicciones que se me han ocurrido me acababa de gustar), que es un certificado SSL en el que el nombre del dominio contiene un comodín. Por ejemplo: *.example.com. De esta manera, indicamos al navegador que este certificado es válido para cualquier subdominio de example.com. No voy a explicar como se generan los certificados SSL ya que buscando un poco por google se encuentran multitud de páginas al respecto. Si le vamos a dar un uso personal, podéis crear un self signed certificate. La única diferencia con los tutoriales que podáis encontrar es que como dominio introduciremos “*.<dominio>” (Por ejemplo: *.example.com).

Configuración del servidor web de Apache

Voy a suponer que en nuestro servidor tenemos configurado un servidor web Apache2 con varios host virtuales (www.example.com, mail.example.com y un servidor WebDAV para el Subversion en svn.example.com), y que el servidor sólo dispone de una dirección IP.

Lo primero que hay que hacer es poner el servidor web a escuchar en el puerto 443 (puerto estándar de HTTPS) y configurar un host virtual sobre ese puerto:

Listen 443
<VirtualHost *:443>
  ServerName *.example.com
  ErrorLog /var/log/apache2/https-error.log
 
  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg.
  LogLevel warn
 
  CustomLog /var/log/apache2/https-access.log combined
  ServerSignature Off
 
  SSLEngine On
  SSLCertificateFile /path/to/certs/example.com.pem
  SSLCertificateKeyFile /path/to/private-keys/example.com.key
</VirtualHost>

Con esto ya tenemos la capa SSL configurada. El certificado indicado en el parámetro SSLCertificateFile es el Widlcard SSL Certificate que hemos creado anteriormente. A partir de aquí, el “truco” está en el uso creativo del mod_proxy, que conseguiremos añadiendo la siguiente configuración dentro del hosts virtual que acabamos de crear:

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>
 
  # Proxy requests to ourselves preserving the Host header
  ProxyPass / http://localhost/
  ProxyPassReverse / http://localhost/
  ProxyPreserveHost on

Con esta configuración estamos reenviando todas las peticiones que nos lleguen a este host virtual por HTTPS hacia el propio servidor, pero cambiando el protocolo de HTTPS a HTTP. Es importante destacar la última línea, que le indica al servidor web que debe mantener la cabecera Host al hacerse la petición a sí mismo, gracias a la cual no tendrá ningún problema a la hora de determinar que página quiere ver el usuario.

Para que las aplicaciones web puedan distinguir si la petición que les llega a entrado por HTTP o HTTPS, configuraremos el host virtual para que añada la cabecera X_FORWARDED_PROTO a las peticiones que se hace a sí mismo:

  # Add the X_FORWARDED_PROTO=https to allow applications to identify
  # proxyed https connections
  RequestHeader set X_FORWARDED_PROTO https

Ya sólo queda un detalle, necesario únicamente si vamos a usar esta configuración para proteger un WebDAV. El problema de esta configuración con WebDAV viene a la hora de intentar hacer un ‘svn mv‘, por ejemplo. Este comando indica el destino en la cabecera HTTP Destination. Como el cliente se esta conectando a https://svn.example.com/repo/etc, la cabecera tendrá ese valor. Pero el host virtual que tiene la configuración de WebDAV sólo está configurado para HTTP por lo que espera que la cabecera Destination empiece por http://svn… Para solucionar la inconsistencia entre la cabecera esperada y la recibida echaremos mano del mod_rewrite:

  # Workarrounf for WebDAV Destination header
  RewriteEngine on
  RewriteCond %{HTTP:Destination} ^https://(.*)$
  RewriteRule . - [env=DESTINATION:http://%1,PT]
  RequestHeader set Destination %{DESTINATION}e env=DESTINATION

Resumen de la configuración

Una vez explicadas las diferentes partes de la configuración, os pongo toda la configuración tal cual se debe escribir en los ficheros de configuración del servidor web para que no haya problemas de “¿y esto donde va?, ¿dentro o fuera del virtualhost?” :

Listen 443
<VirtualHost *:443>
  ServerName *.example.com
  ErrorLog /var/log/apache2/https-error.log
 
  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg.
  LogLevel warn
 
  CustomLog /var/log/apache2/https-access.log combined
  ServerSignature Off
 
  SSLEngine On
  SSLCertificateFile /path/to/certs/example.com.pem
  SSLCertificateKeyFile /path/to/private-keys/example.com.key
 
  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>
 
  # Workarrounf for WebDAV Destination header
  RewriteEngine on
  RewriteCond %{HTTP:Destination} ^https://(.*)$
  RewriteRule . - [env=DESTINATION:http://%1,PT]
  RequestHeader set Destination %{DESTINATION}e env=DESTINATION
 
  # Add the X_FORWARDED_PROTO=https to allow applications to identify
  # proxyed https connections
  RequestHeader set X_FORWARDED_PROTO https
 
  # Proxy requests to ourselves preserving the Host header
  ProxyPass / http://localhost/
  ProxyPassReverse / http://localhost/
  ProxyPreserveHost on
</VirtualHost>

Conclusiones

Personalmente veo está configuración como una solución válida para servidores personales en los que se suelen usar self signed certificates o de CAcert. Para pequeñas empresas (con unos pocos dominios) puede ser una solución, pero los Widlcard SSL Certificates de autoridades certificadoras comerciales (cuyos certificados raíz vienen en los navegadores) no son baratos. Dependiendo del hosting creo que saldría más barato contratar IPs adicionales para el servidor y certificados individuales que no usar el Widlcard SSL Certificate en un servidor con una sóla IP.

En empresas medianas o grandes, puede justificarse el uso de Widlcard SSL Certificates si tienen un gran número de subdominios que quieren asegurar ya que puede suponer un ahorro, pero no veo el motivo de tenerlo todo sobre una sóla dirección IP. Por tanto, no veo que la configuración aquí explicada sea aplicable en este tipo de empresas.

A mi, esta solución me está funcionando muy bien y de momento no he encontrado ningún problema.

Notas adicionales

[1] Para los nostálgicos, ¿os acordáis de la guerra de navegadores?

DKIM recuerda bastante al Sender Policy Framework, o SPF, cuya finalidad es que los servidores puedan verificar que el servidor que les está entregando un correo está autorizado a hacerlo. Es decir, si el servidor mx.example.org está intentando entregar un correo con remitente user@example.com a mi servidor, este usará SPF para verificar si mx.example.org está autorizado a gestionar el correo de ese dominio. La idea es buena pero, por la forma en que se hace, tiene problemas cuando hay redirecciones o forwards. Para más información, podéis leer la introducción a SPF del proyecto OpenSPF o el artículo de la Wikipedia [en inglés].

Quería introducir un poco SPF para poder compararlo con DKIM ya que ambos tienen finalidades similares y usan el sistema de DNS para publicar la información necesaria. Pero así como SPF publica en DNS qué servidores pueden o no enviar correo de un dominio, DKIM publica una clave pública que se usará para verificar que el correo se originó desde un servidor legítimo, evitando el problema de los forwards. Pero nos estamos avanzando un poco…

¿Cómo funciona?

Simplificando bastante: a la hora de enviar, el remitente firma el mensaje y añade esa firma al correo. Entonces, cualquiera de los servidores por los que pasa el correo, puede comprobar su autenticidad verificando la firma. Aunque cualquiera de los servidores puede, la comprobación normalmente se realiza en el servidor destinatario.

Profundizando algo más, DKIM se basa en sistemas muy usados y conocidos como son la criptografía asimétrica, las funciones de hash y, como ya habíamos anticipado, DNS. Para entender mejor su funcionamiento, vemos la infraestructura que hay que configurar para que pueda funcionar:

1. El administrador del dominio de correo debe generar un par de claves asímetricas.
2. Seguidamente, configurará la clave privada en sus servidores de correo, que la usaran para firmar los mensajes.
3. Finalmente, publica la clave pública como un registro TXT en la zona DNS de su dominio para que los servidores que quieran comprobar la autenticidad de los correos puedan obtenerla.

Ahora ya podemos ver el proceso con más detalle: el servidor remitente calcula el hash del correo teniendo en cuenta el cuerpo y algunas cabeceras, y cifra ese hash con la clave privada generando la firma que se añade al correo. Cuando un servidor quiera verificarlo, como necesitará la clave pública para hacerlo, consultará al sistema DNS para obtenerla y poder realizar la comprobación. Si el correo se originara desde un servidor ilegítimo, como no tendría la clave privada adecuada, la comprobación de la firma fallaría poniendo en evidencia al servidor como posible spammer o phisher.

Como la comprobación no se basa en quién nos está entregando el mensaje sino en quién lo originó, este esquema no sufre de los problemas de SPF con los forwards. Sin embargo, al estar basado en firma digital, tiene problemas con las modificaciones que pueda sufrir el correo durante su transmisión. Por ejemplo, si se añade un disclaimer después de que se haya firmado, la verificación fallará.

Para más información sobre DKIM os remito su web, donde encontrareis multitud de documentación, y, como nó, a la Wikipedia.

Como referencias, decir que tanto Yahoo! como Gmail son dos grandes ejemplos de ISPs que usan DKIM en sus servidores.

DKIM en SpamAssassin

Finalmente, veamos como podemos configurar SpamAssassin para sacar provecho de este sistema. Estoy dando por supuesto que usamos Debian Etch y que ya tenéis el MTA (Postfix o similar) y el SpamAssassin instalados y configurados. Sólo mostraré la configuración a realizar para que se empiecen a comprobar las firmas de DKIM. Desgraciadamente, la versión que viene con Etch no es del todo adecuada por lo que deberemos añadir el repositorio de backports a nuestro source.list. Una vez añadido, actualizaremos la lista de paquetes e instalaremos libmail-dkim-perl, con todas sus dependencias, desde backports:

  server:~# aptitude update
  server:~# aptitude -t etch-backports install libmail-dkim-perl

Ahora sólo falta habilitar el plugin Mail::SpamAssassin::Plugin::DKIM descomentando la correspondiente línea en el fichero /etc/spamassassin/v312.pre. Recordad reiniciar spamd, amavisd-new o el content-filter que uséis para que se aplique la nueva configuración.

Como ejemplo, veamos las cabeceras de un correo enviado desde gmail:

X-Spam-Status: No, score=-0.124 required=4.5 tests=[AWL=-0.185,
	BAYES_20=-0.74, DKIM_SIGNED=0.001, DKIM_VERIFIED=-0.001,
	DNS_FROM_SECURITYSAGE=0.001, HTML_MESSAGE=0.001, P0F_Unknown=0.8,
	SPF_PASS=-0.001]
...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:mime-version:content-type;
        bh=JvMz4j1uNftb2YwcCYFAjZF73T5HtaC0paeyk3KqFao=;
        b=s2/id2fqmQMef9gWIvn6jhs09lz9nnyOrwepQtQQdzd6Bj8iB/7b2G3PN+bLcOW0k1
         kTs7ew+y8P1rROBlA+T8CpsYirWL0gSp6YZidyhN2SHJVg9ZXQ7oWq6czAcqs/y3871n
         l4Wnm53EqPPNn4Tqos6ruDghAfyJ/deBxFY3Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type;
        b=U6s9wCp2Q5U7DC0WcQGJ6S6hNwTNmPUiklMd0RtMgB+pJzvP8T/NaqT43Q4QyaukPz
         ig4b3S0/QF3B6uOctVvYQE9YAlgbilx+QxthVzhtc9xvyfePgF63RoebvK28hNlL5VUn
         +0cdEBbEOqkPzo1d1j5XaDGDUV6W/0xHRZb2o=
Received: by 10.210.65.2 with SMTP id n2mr4808273eba.65.1224441206376;
        Sun, 19 Oct 2008 11:33:26 -0700 (PDT)
Received: by 10.210.113.2 with HTTP; Sun, 19 Oct 2008 11:33:26 -0700 (PDT)
Message-ID: <57e22bd310j416695a2d215d0810191133h6297c2b8a@mail.gmail.com>
Date: Sun, 19 Oct 2008 20:33:26 +0200
From: "Gmail user" <user@gmail.com>
To: user@example.com
Subject: DKIM test
MIME-Version: 1.0
Content-Type: multipart/alternative;

Como podéis ver, con la puntuación que le dá SpamAssassin por defecto no mejoramos la discriminación de spam: +0.001 por venir firmado que se compensa con -0.001 porque la firma es correcta. En la lista de correo de spamassassin-users podemos encontrar algunas sugerencias (y sus actualizaciones).

Conclusiones

DomainKeys Identified Mail es otro sistema pensado para verificar el origen del correo que, como el resto de alternativas, tiene sus ventajas e inconvenientes. Y hemos dado unas pinceladas sobre como se puede usar para ayudar a nuestro sistema anti-spam. En un futuro post, explicaré como configurar nuestro Postfix y Bind para que nuestro correo use DKIM.

Yo, personalmente, pienso que más que intentar parchear el protocolo SMTP, debería tomarse la decisión de hacer “borron y cuenta nueva” y diseñar un nuevo protocolo de transmisión de correo teniendo en cuenta todo lo aprendido hasta ahora y especialmente pensado para no permitir el spam.

Servidor SMTP

Como ya he comentado, lo que queremos es proteger el MTA de ataques de fuerza bruta: si alguien consiguiera averiguar unas credenciales correctas podría usar nuestro servidor para hacer relay. Dentro del paquete de fail2ban en Debian tenemos casí toda la configuración que nos hace falta. De hecho, se define el filtro sasl, pero la expresión regular no es del todo correcta. Para solucionarlo, crearemos el fichero /etc/fail2ban/filter.d/sasl.local (tal y como se recomienda en /usr/share/doc/fail2ban/README.Debian.gz<(code>) con el siguiente contenido.

[Definition]
failregex = : warning: .*+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed

Es la misma línea que en sasl.conf pero con ligeras modificaciones, como la eliminación de la marca de final de línea ($) en la expresión regular.

Activaremos la regla sasl modificando/creando el fichero /etc/fail2ban/jail.local:

[sasl]
enabled  = true

Para que se aplique la nueva regla, debemos recargar la configuración:

 server:~# fail2ban-client reload
 <pueden salir unos warnings>

 server:~# fail2ban-client status
 Status
 |- Number of jail:      2
 `- Jail list:           sasl, ssh

Si alguno de los comandos da un error de “Could not find server“, es que el servidor de fail2ban no está arrancado.

Servidores POP3 e IMAP

Por coherencia, si protegemos el servidor SMTP debemos hacer lo propio con los servidores de POP3 e IMAP. Si no, como los tres servicios comparten la base de datos de usuarios, podrían usar uno de los servicios desprotegidos para averiguar la contraseña por fuerza bruta. Como los mensajes de error de autenticación no indican el servicio que ha usado el usuario para conectarse, vamos a tratar los servidores POP3 e IMAP en conjunto. Esto es, al detectarse errores de autanticación se bloquearan todos los servicios.

Para realizar esta configuración, empezaremos creando el filtro en /etc/fail2ban/filter.d/cyrus.local con el siguiente contenido:

[Definition]
failregex = : badlogin: .*\[<HOST>\] (?:plaintext|LOGIN|(?:CRAM|DIGEST)-MD5|NTLM) .*SASL\(-13\): authentication failure
ignoreregex =

Y acabamos añadiendo las reglas necesarias al final del fichero /etc/fail2ban/jail.local:

[pop3]
enabled  = true
port     = pop3
filter   = cyrus
logpath  = /var/log/mail.log

[pop3s]
enabled  = true
port     = pop3s
filter   = cyrus
logpath  = /var/log/mail.log

[imap2]
enabled  = true
port     = imap2
filter   = cyrus
logpath  = /var/log/mail.log

[imaps]
enabled  = true
port     = imaps
filter   = cyrus
logpath  = /var/log/mail.log

Debemos definir una regla por puerto porque la versión 0.7.5 de fail2ban (la que tenemos en Etch) no soporta que se indique más de un puerto por regla. Versiones más recientes, como la versión 0.8, parece que si lo soportan (Si alguien lo comprueba, que me lo comente.  Gracias).

Como siempre, recargad la configuración y comprobad que se estén usando las reglas recién definidas.

Conclusiones

Fail2Ban es una gran medida disuasoria y con estas configuraciones conseguimos frenar en gran medida los ataques de fuerza bruta contra los servicios autenticados de correo: con la configuración por defecto, el servidor no aceptará conexiones de ese cliente durante diez minutos tras tres intentos fallidos.

Aunque la seguridad es necesaria, suele ser incómoda. Pensad en el usuario que intenta configurar su Outlook Expres en casa pero se le ha olvidado la contraseña (como si la hubiera recordado durante más de diez segundos… cuanto daño ha hecho la opción “Recordar contraseña”…) y tras varios intentos os llama. Como el servidor le ha bloqueado el acceso por un tiempo, aunque le podáis dar la contraseña correcta, deberá esperar. Dependiendo de como sean vuestros usuarios, es posible que debáis jugar un poco con los parámetros bantime y maxretry.

Como véis, no resulta muy complicado dotar de algo más de seguridad a nuestros servidores si conocemos las herramientas adecuadas y como usarlas.

Entendemos por entorno como el conjunto de servidores necesarios para que nuestras aplicaciones funcionen. Es decir, en una aplicación web de tres capas, cada entorno lo formarían el servidor de base de datos, el servidor de aplicaciones y el servidor web.

Los sistemas medianamente complejos suelen disponer de vários. Típicamente, tres:

• Desarrollo: sobre el que los programadores realizan los cambios.
• Preproducción: que suele usarse para la integración de los cambios de los diferentes equipos, pero puede usarse también para pruebas de despliegue (deployment) y para pruebas de QA.
• Producción: al que los usuarios se conectan para usar las aplicaciones. Este es el entorno en el que se produce el negocio y por tanto el más crítico.

Al disponer de estos entornos, cualquier cambio suele pasar por los tres: se programa en desarrollo, se comprueba en preproducción y finalmente se despliega en el productivo para ponerlo a disposición de los usuarios.

Una vez introducidos los conceptos, mi opinión es que si los desarrolladores tienen acceso al entorno productivo, es posible que puedan sentirse tentados a realizar cambios directamente en él, saltándose el ciclo normal del cambio, debido a la presión de los usuarios y es posible que pueda provocar problemas  en un entorno que debería ser, por encima de ninguna otra cosa, estable. Estoy seguro que si un cambio provocara un problema, sería de forma involuntaria, pero errar es humano.

Por otra parte, es cierto que el proceso de resolución de incidencias puede complicarse ya que el desarrollador no puede monitorizar el sistema mientras reproduce la incidencia. Pero creo que los entornos de preproducción, correctamente mantenidos, se podrían usar para esto. Además, soy de la opinión de que los ficheros de log, correctamente usados, pueden ser de gran ayuda para la resolución de incidencias. Lo complicado está en determinar qué es necesario registrar: si loggueamos de más, el seguimiento y estudio puede complicarse por la cantidad de “ruido” que hay; y si nos quedamos cortos no dispondremos de la información suficiente para diagnosticar el problema.

He aquí el dilema: por la estabilidad del entorno productivo es mejor que no tengan acceso, pero esto puede dificultar la resolución de incidencias. Personalmente opino que las ventajas de que no tengan acceso superan con creces los inconvenientes, pero soy consciente de que por mi trabajo como administrador de sistemas puedo tener una visión sesgada del problema.

Y vosotros, ¿que opináis? ¿Deben o no tener los equipos de desarrollo acceso a producción?

Como se puede sobreentender de su nombre, los sistemas de One-Time-Password son sistemas de autenticación en los que cada contraseña se utiliza una única vez. Esto nos puede resultar útil en el caso de que debamos hacer login en situaciones comprometidas: usando un protocolo con el que las credenciales viajan en claro (sin cifrar) por la red, desde un equipo del que no podemos asegurar su integridad (que no tenga keyloggers instalados, por ejemplo), etc.

Aunque existen tres formas de implementar sistemas OTP, desde un punto de vista práctico existen dos tipos:

• Basados en secuencia: cada vez que usamos una contraseña esta deja de ser válida y el sistema nos pedirá la siguiente en el proximo login. Mientras no hagamos login, el sistema nos seguirá pidiendo la misma.
• Basados en relojes sincronizados: la contraseña va cambiando con el tiempo, se use o no. El principal requisito de estos sistemas es que el servidor y el generador de la contraseña deben estar sincronizados en el tiempo.

El sistema que os presento es OPIE, que está basado en secuencia, es una implementación de S/Key. Si elegí este fué por sencillez de implementación ya que todo el software necesario esta disponible desde los repositorios oficiales de Debian. Pero le he encontrado dos “problemas”: la página del proyecto no funciona (al menos mientras estoy escribiendo este post) y que no hay desarrollos nuevos desde 1998.

Las contraseñas de OPIE son independientes de las del sistema operativo, cosa necesaria ya que sino de poco nos serviría si a partir de la contraseña de OPIE se pudiera averiguar la del sistema operativo. Para funcionar, OPIE se basa en tres datos: un número de secuencia, una semilla y una passphrase (donde reside la fortaleza del sistema frente a ataques de fuerza bruta).

La forma que tiene de generar la contraseña de un sólo uso es concatenando la semilla y la passphrase, y aplicando la función de hash MD5 tantas veces como le indique el número de secuencia. El resultado se convierte en seis palabras inglesas. Todo este cálculo se realiza desde el cliente. La passphrase nunca se almacena en el servidor.

Para poder validar la contraseña, el servidor necesita almacenar la última contraseña que se usó y el número de secuencia y semilla para podérselo indicar al usuario al hacer login (para los curiosos, esta información se almacena en /etc/opiekeys, que es un fichero que sólo puede leer el usuario root). El sistema dará por buena la contraseña si el MD5 de la contraseña proporcionada por el usuario coincide con la contraseña que tenía almacenada. Una vez se ha verificado la contraseña el número de secuencia se decrementa y cuando este llega a 1 es necesario reinicializar el contador con una nueva semilla (si no, las contraseñas se repetirían) Como el MD5 es una función unidireccional, es imposible encontrar la nueva contraseña a partir de la anterior.

Instalación y configuración

Cómo siempre, empezaremos instalando el software necesario. En este caso deberemos instalar paquetes tanto en el servidor como en un equipo de confianza que nos hará de cliente. Para distinguir los comandos que debemos ejecutar en uno u otro equipo, usare los prompts server:~# y client:~# para el servidor y el cliente respectivamente.

  server:~# aptitude install libpam-opie opie-server opie-client
  client:~# aptitude install opie-client

Una vez instalado el software, cada usuario que quiera usar este sistema de autenticación debe inicializarlo. Hay dos formas de hacerlo, en una se supone que el acceso que tenemos al servidor es seguro y en la otra esta suposición no es necesaria. Si estamos implementando este sistema significa que la seguridad nos preocupa (algunos dirían que somos paranoicos ) y por eso sólo explicaré el segundo método, que no es mucho más complicado y si es más seguro. En este proceso hay que ejecutar comandos tanto en el servidor como en el equipo de confianza (cliente). Supongamos que el usuario username quisiera inicializarlo:

• Debería empezar por usar opiepasswd en el servidor.

  username@server:~$ opiepasswd
  Adding username:
  You need the response from an OTP generator.
  New secret pass phrase:
          otp-md5 499 se4569
          Response:

• En este momento vamos a un terminal del cliente (máquina de confianza) y ejecutamos opiekey pasándole como parámetros los valores del número de secuencia y semilla que aparecen al lado de otp-md5. Cuando nos lo pida, le introduciremos la passphrase que queremos configurar. Recordad que cuanto más complicada sea la passphrase, mejor.

  client:~$ opiekey 499 se4569
  Using the MD5 algorithm to compute response.
  Reminder: Don't use opiekey from telnet or dial-in sessions.
  Enter secret pass phrase: <introducimos la passphrase>
  WOOL ARTY FUM SNUG WARN WICK

• Volvemos a la consola que tenemos en el servidor y pegamos la última línea que obtuvimos con  opiekey en el cliente. Lo remarcado en cursiva es lo que ya teníamos en pantalla.

  username@server:~$ opiepasswd
  Adding username:
  You need the response from an OTP generator.
  New secret pass phrase:
          otp-md5 499 se4569
          Response: WOOL ARTY FUM SNUG WARN WICK
  
  ID username OTP key is 499 se4569
  WOOL ARTY FUM SNUG WARN WICK

Con esto, el usuario username dispone de 499 contraseñas de un sólo uso.

Para hacer que el sistema empiece a usar OPIE como sistema de autenticación debemos indicárselo al PAM. La forma más sencilla es sobreescribir el fichero /etc/pam.d/common-auth con el que podemos encontrar en /usr/share/doc/libpam-opie/examples/pam.d/common-auth (recomiendo hacer una copia de seguridad del antiguo) en el que se indica que el primer método de autenticación seguirá siendo la contraseña del sistema operativo pero si este fallá se usará OPIE:

server:~$ cat /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
auth    sufficient      pam_unix.so
auth    sufficient      pam_opie.so
auth    required        pam_deny.so

Si lo hacemos de esta forma, cualquier servicio que autentique por PAM se podrá beneficiar del sistema de One Time Password: ssh, su, etc. De nada serviría poder usar OTP para hacer login desde un equipo del que no nos fiamos y luego tecleamos la clave de root en la misma máquina. En el caso de usarlo también para obtener permisos de administrador, aconsejo usar sudo antes que su por la sencilla razón que para usar el primero se pide la contraseña del usuario que pide los privilegios (que ya está usando OTP) mientras que el segundo pide la contraseña de root.

En el caso de SSH debemos realizar una pequeña comprobación en la configuración del servidor de sshd (fichero /etc/ssh/sshd_config): el parámetro ChallengeResponseAuthentication debe estar a yes. Si no estuviera así, el sistema no le indicaría al usuario el número de secuencia y semilla al intentar hacer login.

Ejemplo de uso

Ya lo tenemos todo listo. Veamos un ejemplo de conexión SSH usando OPIE:

• Desde la máquina de dudosa seguridad nos conectamos como normalmente:

  unsecure:~$ ssh username@example.com
  Password:

• El sistema nos pide la contraseña como siempre, ya que así lo hemos configurado en las PAM. Pero como no nos fiamos de la seguridad de esa máquina no introducimos la contraseña:

  unsecure:~$ ssh username@example.com
  Password: <enter>
  otp-md5 498 se4569 ext, Response:

• Como la autenticación por contraseña a fallado, ha entrado en acción OPIE que nos indica el siguiente número de secuencia (498) y la semilla (se4569). Desde un equipo de confianza usamos opiekey para obtener el OTP, pasándole el secuencial y la semilla:

  secure:~$ opiekey 498 se4569
  Using the MD5 algorithm to compute response.
  Reminder: Don't use opiekey from telnet or dial-in sessions.
  Enter secret pass phrase: <introducimos la passphrase que usamos al configurarlo>
  GWYN OAF HIRE ALOE CASK CERN

• Una vez tenemos la contraseña, se la indicamos al servidor y si todo ha ido bien, ya estamos dentro (lo remarcado en cursiva es lo que ya teníamos en pantalla):

  unsecure:~$ ssh username@example.com
  Password:
  otp-md5 498 se4569 ext, Response: <introducimos la contraseña generada (no se ve)>
  Last login: Mon Apr  9 10:01:18 2008 from 192.168.0.10
  username@server:~$

• Si nos intentamos conectar de nuevo, veremos como el número de secuencia se ha decrementado:

  unsecure:~$ ssh username@example.com
  Password: <enter>
  otp-md5 497 se4569 ext, Response:

Generadores de claves

Me imagino que os deberéis estar preguntando que ventaja tiene este sistema si de todas formas necesitas un equipo de confianza para generar la contraseña. Es decir, ¿si tengo un portátil para ejecutar opiekey, por que no lo uso para conectarme directamente desde él? Entre otros motivos se me ocurre que ese portátil no pueda tener conexión a Internet porque, por política de seguridad, la red en la que estás no permita que equipos externos tengan acceso al exterior. Pero yo nunca he dicho que necesitemos un PC para generar la contraseña. Existen, como mínimo, dos alternativas:

Podemos imprimir una lista de contraseñas y llevarlas bien cerca de nosotros. Para hacerlo, en el cliente de confianza ejecutaremos:

client:~$ opiekey -n 5 499 se4569
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: <introducimos la passphrase que usamos al configurarlo>
495: CRAB YEAR MAO JAG BEAD KUDO
496: CLOD REED BOND COMA DELL HEFT
497: ERIC WEE WISE TOLD NINA DIVE
498: GWYN OAF HIRE ALOE CASK CERN
499: WOOL ARTY FUM SNUG WARN WICK

Donde en la opción -n se le indica el número de contraseñas que queremos que nos imprima y el 499 es el número de secuencia más alto que queremos que aparezca en la lista.

Y si no queremos llevar las contraseñas por escrito, podemos usar nuestro móvil o PDA para calcular la contraseña instalando el equivalente al opiekey. Para hacerlo necesitaremos que el dispositivo pueda ejecutar código Java. Yo he encontrado tres aplicaciones GPL: j2me-otp, otp-j2me (sí, no son muy originales con los nombres) y otpgen. No voy a explicar como se instalan, ya que depende mucho del móvil que tengáis.

De los tres, el que más me gusta es el tercero pues es más cómodo: te permite definir cuentas en las que mantiene el seed y el número de secuencia, que se va decrementando a medida que obtienes contraseñas. Además estoy seguro de que no hace cosas raras ya que lo he auditado (lo que os dará igual si no os fiáis de mí ) y al que he hecho dos pequeñas aportaciones: el número de secuencia sólo se decrementa cuando aceptamos la contraseña que nos ha proporcionado y he añadido una opción de configuración para que se muestren o no asteriscos al escribir la passphrase.

A pesar de haber mandado el parche al desarrollador, la verdad es que me animé tanto con esta aplicación que he terminado reescribiéndola casi por completo y podéis ver el resultado en la página del proyecto.

Mantenimiento

Como a medida que vamos usando contraseñas el número de secuencia va decrementando, debemos reinicializarlo cuando este se acerque a uno. Para hacerlo usaremos las mismas herramientas que usamos para inicializarlo (opiekey y opiepasswd) y el proceso es casi el mismo. La única diferencia es que en esta ocasión opiepasswd nos solicitará la actual contraseña antes de solicitarnos la nueva:

username@server:~$ opiepasswd
Updating username:
You need the response from an OTP generator.
Old secret pass phrase:
        otp-md5 495 se4569 ext
        Response: CRAB YEAR MAO JAG BEAD KUDO <contraseña actual obtenida con opiekey>
New secret pass phrase:
        otp-md5 499 se1984
        Response: NINA TOLD ALIA LAKE LARK THIS <contraseña nueva obtenida con opiekey>

ID username OTP key is 499 se1984
NINA TOLD ALIA LAKE LARK THIS

Es muy importante no repetir nunca la misma semilla, si mantenemos la passphrase, ya que las contraseñas se calculan a partir de estos dos datos y si en alguna ocasión repitiéramos, las contraseñas que se generarían serían repetidas y ya no serían de un sólo uso.

Seguridad del sistema

Las contraseñas de este sistema son generadas mediante algoritmos de hashing, por lo que empezaremos estudiando la seguridad o robustez del sistema a partir de estos algoritmos y en concreto de la dificultad de averiguar el texto a partir del resultado de la función. Por la forma en que se generan las contraseñas, significa revisar lo dificultad de averiguar la siguiente contraseña a partir de la actual. Aunque en 1996 se descubrió una vulnerabilidad en el algoritmo MD5, que es el que usa OPIE, esta vulnerabilidad no afecta al aspecto que nos preocupa. (para los curiosos, dicha vulnerabilidad es un problema de colisiones: resulta más o menos fácil encontrar dos textos que den el mismo resultado, pero esto no significa que, dado un resultado, se pueda calcular un texto que lo genere). Por lo tanto, no debemos preocuparnos en este aspecto. La robustez del sistema dependerá de la robustez de las contraseñas generadas, que es el siguiente punto a considerar.

OPIE genera contraseñas de 64 bits de longitud a partir de los 128 bits resultantes del MD5 haciendo una XOR entre los 64 primeros bits y los 64 últimos. Consideraremos que los 64 bits son aleatorios ya que se calculan mediante funciones de hashing. Eso significa que estas contraseñas tienen una robustez de 64 bits. Para poder comparar, según la Wikipedia, una contraseña de la misma longitud (ocho carácteres) generada por un usuario tiene la robustez equivalente de entre 18 y 30 bits. Por lo tanto, en este aspecto es mejor que las contraseñas que usamos habitualmente: distributed.net necesitó 4 años, 9 meses y 23 días para romper una clave de 64 bits mientras que, también según la Wikipedia, sólo se necesitarían 16 minutos para averiguar una contraseña creara por un usuario.

Por lo tanto, parece que el sistema es seguro. Si véis algun error en mi razonamiento, por favor, indicádmelo mediante los comentarios.

Por otro lado, ya que estamos hablando de seguridad y si habéis llegado hasta aquí posiblemente signifique que os interesa poderos conectar por SSH a un servidor vuestro desde una red potencialmente insegura, dejadme que os dé un consejo: llevad con vosotros, y a buen recaudo, el figerprint de la clave de vuestro servidor y verificad que coincida con el que se os indica al iniciar la conexión por primera vez. De esta manera os aseguraréis que no estáis siendo sujetos de un ataque man-in-the-middle. Puede que muchos de vosotros ya lo estéis haciendo, pero seguro que hay otros muchos que no.

Conclusiones

Aunque el post es bastante largo (a veces pienso que me enrollo demasiado) este sistema es bastante sencillo de implementar, la seguridad que ofrece es adecuada y, si lo configuráis como os he indicado, no tiene impacto en el día a día ya que podéis usar vuestras contraseñas de siempre cuando trabajáis desde entornos seguros, pero dispondréis de esta alternativa en casos donde la seguridad no esté tan clara. Además, ¿sabéis la cara que pone la gente cuando usas el móvil para calcular una contraseña al intentar hacer login en un sistema?

Si tenéis algo que decir sobre el post o si encontráis alguna burrada (cosa posible ya que dada la longitud del post lo he escrito en varias tandas), no dudéis en usar los comentarios.

Fail2ban es un servicio que vigila una serie de ficheros de log y cuando detecta intentos fallidos bloquea la dirección IPdesde la que se han realizado añadiendo una regla de iptables.

Para instalarlo, en Debian basta con un "aptitude install fail2ban". La configuración por defecto trae activada la protección de SSH y a parte de bloquear la IP infractora envía un correo a root. A parte de la protección de SSH, trae configuraciones para apache, postfix, qmail, vsftpd, etc. y soporte para otros sistemas de firewall a parte de iptables.

Fail2ban no nos asegura una protección total, es sólo una medida más para ponérselo más difícil a los que intentan entrar de forma no autorizada en nuestro servidor, principalmente contra script-kiddies.

En este post os voy a explicar una técnica para luchar contra el spam que he descubierto recientemente y como configurarlo.

Introducción

Esta técnica antispam sólo es útil si se implementa a nivel de servidor de correo, y se fundamenta en dos pilares:

1. Como se puede suponer del título del post, uno de los pilares es la detección de la versión del sistema operativo del servidor remoto que está intentando entregar un correo a una de las direcciones que alojamos.
2. El otro pilar es el hecho de que nadie en su sano juicio instalaría un servidor de correo sobre un Windows XP, ya que está destinado a estaciones de trabajo y no a servidores. Pero incluso así, la gran mayoría de spam proviene de Windows XP, que seguramente tendrán instalado un virus que los convierte en relayers.

Es decir, si somos capaces de determinar que correos entrantes nos los está enviando un Windows XP, lo podremos usar para diferenciar mejor el correo legítimo del spam.

Descripción técnica

El núcleo de esta técnica lo forman amavis, spamassassin y p0f. Seguramente el único que no os debe sonar es p0f y me imagino que la mayoría ya conoceréis el amavis, sistema de filtrado de correo, y el spamassassin, el sistema antispam por excelencia. p0f es un sistema de O.S. fingerprining pasivo. Básicamente es un sniffer que es capaz de identificar la versión del sistema operativo a partir de los paquetes TCP/IP que vé. Es decir, es similar a la opción -O del nmap, pero de forma pasiva.

La idéa es que cuando amavis vaya a filtrar un nuevo correo entrante, consulte de alguna manera al p0f para saber la versión del sistema operativo de la máquina remota y el spamassassin pueda tener en cuenta esa información para determinar si el correo es spam o no.

Instalación y configuración

Los prerequisitos son tener un servidor de correo que use amavisd-new y spamassassin. No voy a explicar como se instalan y configuran ya que depende del MTA que uséis y existen muchos how-tos (como este de Jaume Sabater [copia en Bulma]). En cuanto a la distribución, me centraré en una Debian que es lo que tengo por mano.

Instalación de P0F

Lo primero es instalar el p0f: aptitude install p0f (o apt-get install p0f, me da igual )

Para la comunicación entre p0f y amavis, usaremos un programilla en perl que viene dentro del paquete de amavisd-new: p0f-analyzer (que se instala en /usr/sbin). Este programa espera recibir los datos del p0f por su entrada estandar y abre un puerto por el que el amavis le hace las consultas. Por defecto, p0f-analyzer escucha en todas las interfaces del servidor aunque implementa unas ACLs muy simples por las que sólo contesta a peticiones que le lleguen del localhost (127.0.0.1). Como a mi no me gusta tener servicios internos escuchando en todas las interfaces, cambie la línea 79 de


  bind(S, sockaddr_in($port,INADDR_ANY)) or die "bind: $!";

a

  bind(S, sockaddr_in($port,INADDR_LOOPBACK)) or die "bind: $!";

Las ACLs se controlan mediante el array @inet_acl que se define en la línea 70.

Si ejecutas /usr/sbin/p0f-analyzer sin parámetros, te da un ejemplo de uso que es el que yo utilicé:

  /usr/sbin/p0f -l 'tcp dst port 25' 2>&1 | /usr/sbin/p0f-analyzer.pl 2345

De esta manera, el p0f identificará las conexiones destinadas al puerto 25/tcp y el p0f-analyzer abre el puerto 2345 para recibir las consultas del amavis. Primera parte resuelta.

Configuración de amavis

El siguiente paso es configurar el amavis para que consulte al p0f-analyzer. Para ello debemos usar el parámetro de configuración $os_fingerprint_method. En el caso de Debian, modifiqué el fichero /etc/amavis/conf.d/50-user e incluí las dos líneas siguientes:

  $os_fingerprint_method = 'p0f:127.0.0.1:2345';
  $policy_bank{'MYNETS'}{os_fingerprint_method} = undef;

En la primera línea le indicamos donde puede consultar al p0f-analyzer y en la segunda que no use el p0f-analyzer para las máquinas de la red interna.

Finalmente reiniciamos el amavisd-new. Si hemos realizado los cambios en la configuración de forma correcta, en /var/log/mail.log deberíamos encontrar la línea que nos indica que ha activado la opción de OS_Fingerprinting:

  Oct  3 12:23:14 server amavis[29216]: OS_Fingerprint code  loaded

Ahora ya sólo falta que el spamassassin use la información que nos proporciona p0f.

Configuración de spamassassin

La forma que tiene el amavis para pasar la información que ha recibido del p0f al spamassassin es añadiendo la cabecera X-Amavis-OS-Fingerprint al correo. Esta cabecera no se añade al correo que recibirá el usuario, sólo se usa internamente entre el amavis y el spamassassin.

Como a mi me interesaba que todos los usuarios se beneficiaran de esta nueva técnica, modifiqué el fichero /etc/spamassassin/local.cf para que incluyera la siguiente configuración:

  #   Set score for different client OS
  #   Needs p0f-analyzer up and running
  header P0F_WindowsXP X-Amavis-OS-Fingerprint =~ /^Windows XP/
  header P0F_Windows   X-Amavis-OS-Fingerprint =~ /^Windows(?! XP)/
  header P0F_Unknown   X-Amavis-OS-Fingerprint =~ /^UNKNOWN/
  header P0F_Unix      X-Amavis-OS-Fingerprint =~ /^Linux|((Free|Open|Net)BSD)|Solaris|HP-UX|Tru64/

  score  P0F_WindowsXP 3.5
  score  P0F_Windows   1.7
  score  P0F_Unknown   0.8
  score  P0F_Unix     -0.5

Definimos cinco tests y les damos puntuaciones. Las puntuaciones de los tests no son aleatorias, me basé en las que se indican aquí pero las modifiqué un poco a mi gusto. Con estas puntuaciones le estamos indicando al spamassassin que es muy probable que los correos que le lleguen desde máquinas Windows XP sean spam, ya que le damos una puntuación de 3.5, mientras que los que le lleguen desde Unixes tienen una menor probabilidad de serlo y por eso le damos una puntuación de -0.5.

Para que se empiecen a aplicar los nuevos tests, si estamos ejecutando el spamassassin en modo daemon (spamd) deberemos reiniciarlo y si se ejecuta de forma interna al amavis, deberemos reiniciar este último.

A partir de ahora, el spamassassin debería tener en cuenta el sistema operativo de la maquina remota para puntuar los correos. Si tenéis configurado el amavis para que incluya en las cabeceras los tests del spamassassin, podéis buscarlo allí. Por ejemplo:

X-Spam-Status: Yes, score=9.25 required=4.5 tests=[BAYES_99=3.5,
    HTML_MESSAGE=0.001, P0F_Unix=-0.5, RCVD_IN_BL_SPAMCOP_NET=1.96,
    URIBL_AB_SURBL=1.86, URIBL_BLACK=1.955, URIBL_SC_SURBL=0.474]

Conclusión

La técnica de O.S. fingerprinting no es la panacea en la lucha contra el spam, pero es un complemento al resto de tests, un aspecto más que nuestro sistema antispam puede tener en cuenta para clasificar mejor los mensajes. Y por el trabajo que lleva configurarlo, creo que merece la pena.

Recientemente se me ocurrió la idea de si sería posible que si un equipo no registrado se conectara a una red privada (un consultor que llega a una empresa, por ejemplo) se le presentara una página web indicando que debe ponerse en contacto con el soporte técnico para que le den acceso. Vaya, una especie de portal captivo pero mucho más simple.

Después de darle unas pocas vueltas llegué a una posible solución, que es la que voy a exponer a continuación. Mi intención no es dar una configuración detallada al 100%, básicamente porque no dispongo de un entorno donde poderlo probar todo. Lo que quiero es dar las ideas y poner parte de las configuraciones necesarias para conseguirlo.

La idea es la siguiente:

1. Tenemos el DHCP configurado de tal manera que a los equipos de la red se les asigna siempre la misma dirección IP de un determinado rango a partir de su dirección MAC. A las MACs no registradas les asignamos una dirección IP de un pool formado por direcciones de una rango totalmente diferente al de la red que se le asigna a las MACs conocidas y que no está enrutada (por tanto no tiene salida fuera de la red local). El pool “captivo” estará configurado para que el servidor DNS que se asignará a esos dispositivos sea uno que estará en el mismo segmento de red y dentro de la misma red IP que las direcciones (recordad que la red del pool no esta enrutada).
2. Configuraremos el servidor DNS que usaran esos equipos no registrados de manera que resuelva todos los nombres de dominio con una misma dirección IP, la de un servidor local que también estará dentro de la misma red IP que el pool (que es la única red que pueden ver).
3. Y el servidor Web siempre devolverá la misma página independientemente de la URL que se le solicite. En esa página se le indicará al usuario que el equipo desde el que está accediendo no esta autorizado, que se ha registrado su acceso y que se ponga en contacto con el soporte técnico para que le den acceso.

Por ejemplo, supongamos que en nuestra red usamos las direcciones 192.168.0.0/24, que el DNS “bueno” está en la dirección 192.168.0.1 y el default gateway también es el 192.168.0.1. Para las MACs no registradas, el pool tendrá direcciones de la red 172.16.0.0/24, de la 172.16.0.16 a la 172.16.0.254, el servidor DNS para los equipos no registrados será la 172.16.0.1 y el servidor web estará en la misma máquina.

De esta forma, cuando alguien enchufe un PC a la red y no lo haya notificado previamente, cuando intente acceder a alguna web le saldrá la página que le indicará que debe registrar su equipo.

Configuración

Vamos a ver como debemos configurar los diferentes servicios que intervienen para implementar esta funcionalidad.

DHCP

La configuración del servidor de DHCP no tiene mucho misterio. Básicamente es traducir los requisitos a nivel de DHCP a configuración. Pego la parte relevante de la configuración.

/etc/dhcp.conf

shared-network LAN {
  subnet 172.16.0.0 netmask 255.255.255.0 {
    allow unknown-clients;
    option routers 172.16.0.1;
    option domain-name-servers 172.16.0.1;
    range   172.16.0.16 172.16.0.254;
    max-lease-time 30;
    default-lease-time 30;
  }

  subnet 192.168.0.0 netmask 255.255.255.0 {
    option routers 192.168.0.1;
    option domain-name-servers 192.168.0.1;
    option subnet-mask 255.255.255.0;
    max-lease-time 86400;
    default-lease-time 86400;
  }
}

# Equipos registrados
group {
  host PC1 {
    hardware ethernet 00:01:02:e7:ef:15;
    fixed-address 192.168.17;
  }

  host PC2 {
    hardware ethernet 00:00:21:cb:22:fa;
    fixed-address 192.168.18;
  }
}

Bind

Como servidor DNS usaremos el Bind y tal y como he comentado anteriormente, debemos configurarlo de manera que resuelva cualquier nombre de dominio que le solicitemos con la dirección IP del servidor en el que configuraremos el Apache. Por suerte, Bind tiene soporte de wildcards.

Importante: poner el TTL de esas resoluciones muy bajo, varios segundos a lo sumo. Si no, tras registrar el PC, seguiría sin ver las páginas a las que hubiera intentado acceder mientras tenÍa configurado el DNS del portal captivo ya que la cache de DNS de su S.O. seguiría “resolviendo” el nombre de dominio como la IP de la web del portal captivo.

/etc/bind/named.conf

options {
  directory "/var/cache/bind";
  listen-on { 172.16.0.1; };
  version "Captive Portal DNS Server";
  recursion no;
};

zone "." {
  type master;
  file "/etc/bind/db.captive";
};

/etc/bind/db.captive

$TTL    1
@       IN      SOA     captive.local. netmaster.local. (
                        0000001         ; Serial
                        604800         ; Refresh
                        86400         ; Retry
                        2419200         ; Expire
                        1 )       ; Negative Cache TTL
;
@       IN      NS      captive.local.
*.      IN      A       172.16.0.1

Apache

Partiremos de una instalación estándar de Apache2 de Debian y configuraremos el host virtual por defecto de manera que la web tendrá simplemente una página HTML y como mucho unas cuantas imágenes (por ejemplo, el logo de la empresa). También configuraremos unas reglas de rewrite para que pidan la URL que pidan salga la misma página.

Importante: para evitar problemas con las caches de los navegadores, la página debería tener una cabecera de Cache-Control forzando que el navegador siempre se la descargue en cada consulta.

/etc/apache2/sites-available

<Directory /var/www/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride FileInfo
  Order allow,deny
  allow from all
</Directory>

Pondremos el index.html que queramos mostrar en /var/www/index.html y crearemos el fichero .htaccess con las reglas de reescritura y de no-cache:

/var/www/.htaccess

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.html [L]
</IfModule>

<IfModule mod_headers.c>
  Header set Cache-Control "no-cache"
</IfModule>

No debemos olvidarnos de habilitar los modulos de rewrite y header:

a2enmod rewrite
a2enmod headers

Y con esto ya tendríamos nuestro portal captivo.

Mejoras

Si no quisiéramos/pudiéramos tener un servidor dedicado al portal captivo, podríamos poner la configuración necesaria de DNS en una vista y configurar el Bind para que las IPs del rango captivo fueran a esa vista en particular, y a nivel de Apache podríamos usar un Virtual Host basado en dirección IP. Si alguien no supiera como hacerlo, le debería ser bastante fácil encontrar documentación en Internet sobre somo hacerlo.

Si lo que nos interesa es que los equipos no registrados no tengan ningún tipo de conectividad, escenario mucho más seguro, deberemos pensar en una solución basada en 802.1x. Pero para ello, tanto la electrónica de red como los equipos deben soportar ese protocolo.