Protegiendo el correo con Fail2Ban

21 October 2008 at 17:28

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.

2 Responses to “Protegiendo el correo con Fail2Ban”

  1. Kiko says:

    La versió de Debian sid (Fail2Ban v0.8.3) Si que suporta el multiport:

    A /etc/fail2ban/jail.conf hi vé:

    [couriersmtp]

    enabled = false
    port = smtp,ssmtp
    filter = couriersmtp
    logpath = /var/log/mail.log

    [courierauth]

    enabled = false
    port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
    filter = courierlogin
    logpath = /var/log/mail.log

    I les regles d’iptables que genera tenen aquesta pinta:

    # iptables -vnL
    Chain INPUT (policy ACCEPT 7721K packets, 1659M bytes)
    pkts bytes target prot opt in out source destination
    101K 30M fail2ban-courierauth tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,143,220,993,110,995
    31356 2432K fail2ban-apache tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
    101K 30M fail2ban-sasl tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,143,220,993,110,995
    51913 26M fail2ban-postfix tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465
    205K 17M fail2ban-ssh tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
    31356 2432K fail2ban-apache-overflows tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
    31356 2432K fail2ban-apache-noscript tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443

  2. Eduard says:

    OK, gràcies per confirmar-ho.