LinuxParty

Lo primero que os recomiendo antes de empezar a leer esta entrada, es dar un vistazo (los asiduos a DaboBlog ya lo conoceréis) a este post sobre el resumen de mi participación junto a Oreixa en el pasado EFIMP (Eset Foro Internet Meeting Point) de Gijón en el que hablo de diferentes tipos de ataques web y control del tráfico en nuestro servidor GNU/Linux con herramientas como Mod Evasive, Apache Status, Mod Security, Medusa, Whatweb, Pentbox, APF Firewall, etc.

Más que nada lo digo porque cuando hablamos de ataques de fuerza bruta, solemos dar prioridad (obviamente) a servicios como ssh con soluciones como fail2ban o DenyHosts tal y como reseño en esa entrada pero ¿qué pasa por ejemplo con el FTP u otros tan sensibles como el correo?

Ahí es donde entra en escena BFD, una herramienta más de los creadores de APF Firewall (que por cierto, su trabajo es impresionante, mirad la lista, tengo que probar LSM, Linux Socket Monitor)

¿Qué es y cómo actúa BFD?

BFD es una aplicación creada por Ryan MacDonald con licencia GPL que una vez instalada, se ejecuta por defecto cada 3 minutos en el cron, buscando en logs relevantes del sistema (/var/log/secure, /var/log/auth.log, /var/log/messages, esto puede variar según la distro) rastros de posibles huellas de ataques de fuerza bruta (fallos de autenticación) en servicios como courier, cpanel, exim, proftpd , pure-ftpd, sshd, etc.

¿Cómo actúa? una vez que localiza el ataque (por defecto el valor que viene en su configuración es “TRIG=”15″, 15 intentos) ejecuta un comando del sistema para bloquear el host que lo ha provocado (por defecto usa el bloqueo de APF Firewall, asumiento, erróneamente a mi modo de ver, que se tiene instalado APF, este es el comando (BAN_COMMAND=”/etc/apf/apf -d $ATTACK_HOST {bfd.$MOD}”)

Aspectos a tener en cuenta. (Probado en Debian Lenny)

Pero en ese valor, (BAN_COMMAND=) podéis usar comandos de iptables, Shorewall, etc, u otro del tipo BAN_COMMAND=”route add -host $ATTACK_HOST reject”. Eso queda a vuestra elección y depende de qué tengáis instalado en el servidor web.

En el fichero de configuración principal que está en; /usr/local/bfd/conf.bfd también se puede definir además de los intentos de bloqueo, comando para rechazar el host atacante y el resto de opciones, que se envíe un e-mail (EMAIL_ADDRESS=”aquí el mail”) avisando del ataque y posterior bloqueo.

Su instalación es muy sencilla, una vez descargado con tipear un ./install.sh es suficiente pero en mi caso, me daba este error en el cron; Error: bad minute; while reading /etc/cron.d/bfd . No era el tiempo de ejecución sino que ahí también va un valor referido al email que hay que rellenar al igual que en /usr/local/bfd/conf.bfd;

MAILTO=aquí el mail, por defecto vacío

SHELL=/bin/bash

*/3 * * * * root /usr/local/sbin/bfd -q

Por lo que además de incluir el mail en la configuración principal; /usr/local/bfd/conf.bfd, también deberéis tener en cuenta este campo a rellenar en el cron; /etc/cron.d/bfd.

Para ver que funciona correctamente, hablando del cron, os recomiendo tener una consola con el siguiente comando;

tail -f /var/log/syslog | grep -i bfd

Y si todo va bien y no os sale el error de “bad minute”, se debería ver cada 3 minutos esto;

Oct 16 21:24:01 server /USR/SBIN/CRON[5017]: (root) CMD (/usr/local/sbin/bfd -q)

Oct 16 21:27:01 server /USR/SBIN/CRON[5468]: (root) CMD (/usr/local/sbin/bfd -q)

Oct 16 21:30:01 server /USR/SBIN/CRON[5468]: (root) CMD (/usr/local/sbin/bfd -q)

También en /var/log hay un fichero que se crea referido a BFD (/var/log/bfd_log).

Lo último que os recomiendo, es que miréis bien tanto la documentación sobre BFD (Brute Force Detection) y como estamos viendo, leer tranquilamente los valores incluidos en el fichero de configuración principal (/usr/local/bfd/conf.bfd).

Este concretamente “syslog auth log path” puede variar, ya que por defecto incluye /var/log/secure y en Debian por ejemplo es /var/log/auth.log. A este tipo de detalles me refiero con mirar bien cada valor.

Además de todo esto, no paséis por alto comprobar las reglas (en /usr/local/bfd/rules) que incluye por defecto para las aplicaciones a proteger, borrando las que no tengáis en el sistema, o cambiando el valor “TRIG” para el bloqueo independiente deseado para cada servicio.

Si se escribe sin ningún parametro bfd en el prompt del sistema, veréis esto;

-s|–standard …….. run standard with output

-q|–quiet ……….. run quiet with output hidden

-a|–attackpool …… list all addresses that have attacked this host

Por defecto si os fijáis en la entrada del cron, se ejecuta con la opción “-q”, para ver la lista de IPs que han sido bloqueadas se usa el parámetro “-a”. Para comprobar su funcionamiento podéis usar Medusa con este comando para atacar una cuenta FTP;

medusa -h ip-host-a-atacar -u usuario_ftp -P passwords.txt -e ns -M ftp

Asumiendo que desde el directorio que estáis tipeando el comando, tenéis una lista de passwords llamada passwords.txt. (Podéis usar esta del proyecto Openwall aunque hay muchas y muy variadas).

Suerte con la instalación y espero que esta entrada os sea de ayuda para que deis menos vueltas que las que he dado yo para configurarlo, ciertamente no es que sea complicado, pero sí un poco farragoso por las conf que trae por defecto.

Vía dadoblog.