Oct 16 2010

Bloqueo de ataques de fuerza bruta en servidores GNU/Linux con BFD

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.

Tags: , , , , , , , , , , , , , , , ,

.:: Inicio en DaboBlog::.

Con Creative Commons, difunde la noticia citando la fuente de origen

12 Responses to “Bloqueo de ataques de fuerza bruta en servidores GNU/Linux con BFD”

  1. Tweets that mention DaboBlog - Por David Hernández (Dabo), Cibercultura | GNU/Linux | Mac OS X | Opinión | -- Topsy.com says:

    […] This post was mentioned on Twitter by David Rodriguez and Dabo, Dabo. Dabo said: [Post en DaboBlog]: Bloqueo de ataques de fuerza bruta en servidores GNU/Linux con BFD http://bit.ly/bOzPgn […]

  2. Aguila Rabuda says:

    Gracias por la entrada Dabo, no conocía ese programa. Actualmente estoy usando fail2ban, y con el protejo también servicios como ftp (proftpd), y el correo (postfix) con las correspondiente configuración en /etc/fail2ban/jail.conf . Creo que funciona bastante bien, pero ¿Es realmente efectivo de esta manera o me recomiendas cambiar a BFD?¿O más bien se complementan?

    Un saludo.

  3. OvErCloCK says:

    Grandisimo post, Dabo un pequeño apunte (seguramente lo sepas) es un script en shell y se complementa de manera muy óptima con APF, es un sistema de protección realmente bueno, pues para mi BFD lo uso para indicarle a APF que ip’s debe de bloquear, me parece una herramienta muy potente y óptima para proteger SSH, FTP, EXIM, Apache …

    Además con mod_evasive podemos proteger de manera optima por ejemplo un DoS en Apache, obviamente entran más factores no te deja “blindado” el servidor pero si más seguro, al menos yo probe “afinando” con script en Perl para ver cuando saltaba y como actuaba y fue una prueba muy satisfactoria para mi.

    // Aguila Rabufa

    Yo trabajo con fail2ban, APF y BFD con los tres, una de las cosas que hago siempre es cambiar el puerto SSH (22) por uno más alto, desactivo el usuario root, accedo con otro usuario y escalo privilegios de root, y instalo fail2ban y hago un poco de hardening en ssh.

    Pero vamos que se complementan BFD con fail2ban en realidad utiliza iptables, y en este caso ambos tiran de iptables y es 100% compatible, solo que tienes de modificar un poco (o creo yo que va así) todo suma en seguridad.

    En realidad en algunos casos y mi preferido es usar autentificación por ssh keys (como el PGP clave privada/pública)

    Saludos!

  4. dabo says:

    # Aguila Rabuda

    Hola ;), creo que se complementan, efectivamente con Fail2ban en el directorio /etc/fail2ban/filter.d se puede ver la lista de servicios a proteger , los más importantes vaya, pero quizás haya alguno que no esté incluido en este y BFD lo tenga (no sé Cpanel por citar uno) o quieras definir acciones a llevar a cabo en cada uno. Mi consejo sería que sigas usando Fail2ban y pruebes BFD a ver que tal te va o que veas si cubre alguna necesidad que tengas y que el otro no lo haga. Es una pasada ver lo ligero que es el script y lo que puede llegar a hacer -;)

    OvErCloCK, cierto, son buenos consejos ;), como digo al principio del post, recomiendo ver mi entrada sobre tema del EFIMP para coger otros conceptos.

    Saludos !

  5. Aguila Rabuda says:

    @ OvErCloCK

    Efectivamente, yo también combino las medidas de seguridad que mencionas, además de autentificarme mediante llave pública/privada. Como comentario, para configurar iptables utilizo el script arno-iptables-firewall, que se lleva muy bien con fail2ban y con BFD (adantandolo un pelín). Toda precaución en esto de los servers es poca…

    @ Dabo

    Gracias por contestar. Decirte que aprovechando la entra lo he implementado en mi servidor. La utilidad nueva, que fail2ban nunca me ha terminado de hacer bien, es la protección contra Brute Force para directorios restringidos en Apache.

    Un saludo!

  6. dabo says:

    Me alegro que te haya sido útil ;) Puedes probar APF y ver si te convence más que “arno” (que también va muy fino).

    Suerte con esos bloqueos !

  7. Bloqueo de ataques de fuerza bruta en servidores GNU/Linux con BFD says:

    […] Bloqueo de ataques de fuerza bruta en servidores GNU/Linux con BFD http://www.daboblog.com/2010/10/16/bloqueo-de-ataques-de-fuerza-... por Liamngls hace 4 segundos […]

  8. OvErCloCK says:

    Quiero decir, que fail2ban no suelo usarlo en conjunto con BFD y APF, me parece mejor usar la pareja APF + BFD como seguridad básica en servidores Linux, como normalmente no me acaba de gustar que haya acceso al servidor por SSH lo que hago es usar las ssh keys, pues BFD me lo protege de manera óptima y de paso ya pueden estar intentando que no podrán sin la key, mi opinión es que es la mejor manera de proteger en cuanto a SSH se refiere.

    Además con ssh keys, es muy útil puesto que yo sincronizo servidores al mismo tiempo por scripting o multicopiado de archivos entre servidores y todo sin la necesidad de autentificarse, vamos se puede relamer un coder de shells jejejej

    Otra cosa que me quiero decir, que si por el motivo que sea, no se puede con ssh keys, llamadme “paranoico” es crear un usuario como si fuera una contraseña rollo u$4aRi022% y una clave larga alfanumérica con caracteres, pero con privilegios mínimos solo para usar su/sudo así tengo dos niveles más de protección con el root desactivado y un poco de hardening claro, si llegasen a encontrar ese usuario u$4aRi022% le queda la de root.

    Ya digo es muy paranoico y cuando me autentifico como root normalmente hago que mande un mail avisandome de IP, hora, etc .. todo así estoy más tranquilo.

    Ah quiero compartir con vosotros una web donde hay mucho material muy interesantes para los que administramos servidores, es http://www.dedicated-resources.com yo he encontrado cosas que me han sido de mucha utilidad y agradecido ando, y otra web que me gustaría compartir con incontables scripts, bien sea para aprender o para adaptarse uno a su gusto es http://www.shelldorado.com es interminable … ahora mismo haré un tweet por si algo no los conoces (Dabo espero que no te molesten estos enlaces)

    P.D Me alegra mucho ver este tipo de post y comentarios sabiendo que se cuida la seguridad en los servidores, nos hace un poco más seguro al mundo todos

  9. dabo says:

    Estoy vía móvil pero le daré un vistazo con detalle en casa. Molestarme ? Para nada, encantado de encontrar sitios donde aprender ;)

  10. Bloqueo de ataques de fuerza bruta en servidores GNU/Linux con BFD | Shadow Security says:

    […] Contenido completo en DaboBlog http://www.segu-info.com.ar […]

  11. DaboBlog - Por David Hernández (Dabo), Cibercultura | GNU/Linux | Mac OS X | Opinión | says:

    […] una conexión añadiendo la IP a “hosts.dey” y enviando un mail con la IP del bloqueo. También BFD os puede ayudar hablando de ataques de fuerza […]

  12. DaboBlog - Por David Hernández (Dabo), Cibercultura | GNU/Linux | Mac OS X | Opinión | says:

    […] una conexión añadiendo la IP a “hosts.deny”, enviando un mail con la IP del bloqueo. También BFD os puede ayudar hablando de ataques de fuerza […]