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.

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.