Entonces me planteé la pregunta de como podía asegurarme de que el próximo “inquilino” del servidor viejo no pudiera recuperar ninguno de mis ficheros. Ya conocía las utilidades wipe o shred pero me faltaba encontrar una forma de poder ejecutarlas borrando todo el disco duro. Por suerte, los servidores dedicados de OVH disponen del “modo rescate” que arranca una mini-distribución por red en nuestro servidor a la que nos podremos conectar por SSH tras recibir el correo con la contraseña de root y que, afortunadamente, dispone de shred.

Así que, los pasos para devolver el servidor de forma segura serían:

1. En el manager de OVH vamos a la sección ‘Servicios’ y vamos a ‘Netboot’
2. De los netboot disponibles seleccionaremos ‘rescue-pro‘
3. Ahora reiniciaremos el servidor para que arranque la distribución de rescate. Una vez haya arrancado, recibiremos un mail con la contraseña del usuario root.
4. Ya sólo nos queda conectarnos por SSH al servidor usando la contraseña recibida y ejecutar 

   root@rescue:~# nohup shred -fvz /dev/sda&

Ese comando sobrescribirá todo el disco duro 25 veces (valor por defecto) con varios patrones y finalmente lo sobrescribirá con ceros para, según la página de man, ocultar el hecho de que se ha ejecutado. Dependiendo del tamaño del disco, el borrado seguro puede tardar bastantes horas, incluso días. Por eso aconsejo ejecutarlo con nohup y ponerlo en background. Así podremos desconectarnos y el proceso seguirá ejecutándose. Siempre podremos verificar el progreso leyendo el fichero nohup.out.

Una vez haya terminado, reiniciamos el servidor y ya estará listo para regresar a manos del proveedor sin que debamos temer por nuestros datos.

Para conseguir este efecto, nos aseguraremos que el siguiente parametro este definido en el fichero /etc/postfix/main.cf
smtpd_sasl_security_options = noplaintext, noanonymous

Con esto conseguiremos que por defecto no se permita ni PLAIN ni LOGIN. Para habilitarlos por el puerto de submission, modificaremos la definición del servicio submission en el fichero /etc/postfix/master.cf añadiendo la línea:
-o smtpd_sasl_security_options=noanonymous

El problema viene a la hora de comprobar que podemos hacer login mediante, por ejemplo, CRAM-MD5 ya que el cliente debe calcular el HMAC-MD5 de un string generado por el servidor, siendo la clave del algoritmo la contraseña del usuario, para realizar la autenticación sin que el usuario deba revelar su contraseña. Pero no es nada que unas cuantas lineas de Perl no puedan resolver:

#!/usr/bin/perl
use MIME::Base64
use Digest::HMAC_MD5 qw(hmac_md5_hex);
print encode_base64($ARGV[1] . " " . hmac_md5_hex(decode_base64($ARGV[0]), $ARGV[2]));

Los argumentos a pasarle son:

1. el challenge generado por el servidor
2. el nombre de usuario
3. la contraseña

Pero nada mejor que un ejemplo para ver como funciona.

S: 220 mail.example.com ESMTP Postfix (Debian/GNU)
C: ehlo client.example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-ETRN
S: 250-STARTTLS
S: 250-AUTH DIGEST-MD5 NTLM CRAM-MD5
S: 250-AUTH=DIGEST-MD5 NTLM CRAM-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250 DSN
C: AUTH CRAM-MD5
S: 334 PDQwMTc3NTY4MTAuODMzNzFAb3ZoMjAxMC5sbHVsbC5uZXQ+

Al indicarle que queremos autenticarnos mediante CRAM-MD5 el servidor nos proporciona el challenge que pasaremos al script en Perl junto con el nombre de usuario y la contraseña en otra consola.

$ ./cram-md5.pl PDQwMTc3NTY4MTAuODMzNzFAb3ZoMjAxMC5sbHVsbC5uZXQ+ user password
dXNlciA3MTUxODVjYTRkMzMxOGRkMzYxZTg2NDg4M2ZkNmE3NA==

Para autenticarnos, le enviaremos el string obtenido al servidor.

C: dXNlciA3MTUxODVjYTRkMzMxOGRkMzYxZTg2NDg4M2ZkNmE3NA==
S: 235 2.7.0 Authentication successful
C: quit
S: 221 2.0.0 Bye

(‘$’ denota el promt de la shell, ‘S’ una línea recibida del servidor y ‘C’ una línea enviada por el cliente)

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.