En artículos anteriores ya he hecho referencia al excelente artículo de Jaume Sabater sobre la instalación y configuración de un servidor de correo con Postfix. En su artículo hace el razonamiento de que como la autenticación se va a realizar sobre un canal cifrado no hace falta habilitar los métodos de autenticación CRAM-MD5 o DIGEST-MD5, que permiten hacer login sin transmitir la contraseña en plano (como pasa con los métodos PLAIN o LOGIN). Y no le falta razon, pero yo he tomado un camino intermedio: en el servidor SMTP por el puerto 587 (submission) están permitidos todos los métodos de autenticación ya que se fuerza el cifrado de la conexión; pero por el 25 no permito los métodos de autenticación PLAIN o LOGIN para evitar la tentación de hacer login con uno de esos métodos mediante un canal inseguro, pero sí permito CRAM-MD5 o DIGEST-MD5.

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)

Hace bastantes meses escribí un artículo sobre como configurar el SpamAssassin para que verifique las firmas DKIM para luchar contra el Spam y me quedó pendiente explicar como firmar nuestros própios correos. Por aquel entonces era más o menos complicado pero desde la release de Debian Lenny, que incluye el paquete amavisd-new 2.6.1, la tarea se ha simplificado.

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.

DomainKeys Identified Mail, o DKIM, es un sistema de autenticación que permite verificar que el correo realmente proviene de quien dice provenir. Como los spammers suelen falsificar los remitentes de los correos que mandan, también veremos como esa verificación nos puede servir como un método más para luchar contra el correo no deseado.

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.

Recientemente expliqué como Fail2Ban podía ayudarnos a ponérselo más difícil a esos script-kidies que se dedican a intentar entrar por SSH en nuestras máquinas realizando ataques de fuerza bruta.Hoy vamos a ver como usar esa misma herramienta para proteger de esos ataques a los servicios de correo. La configuración que voy a explicar supone que estamos usando Postfix como MTA, Cyrus como servidor POP3 e IMAP y SASL para autenticar a los usuarios.

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.

Hay ocasiones en que el tema del spam me recuerda a una escalada armamentística, en la que las dos partes de un conflicto van evolucionando sus medios y técnicas para obtener ventaja sobre el otro. Un ejemplo de esta escalada en el campo del spam son los filtros bayesianos: hace ya un tiempo los sistemas antispam implementaron filtros bayesianos [Wikipedia], que básicamente son unos algoritmos que son capaces de “leer” los correos y puntuar cuan probable es que ese correo sea spam. Algunos spammers reaccionaron enviando los correos con una imagen en la que incluían el texto de manera que los filtros bayesianos no pudieran leerlo. Para combatir esta técnica, los sistemas antispam implementaron sistemas de reconocimiento de carácteres (OCR) para poder “leer” el texto contenido en las imágenes, a lo que los spammers reaccionaron modificando el fondo de las imágenes para hacer más difícil el reconocimiento. Etc.

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.

(more…)