Ansible Fail2ban: Automatiza Protección contra Fuerza Bruta 2026

Ansible Fail2ban permite automatizar la instalación y configuración de Fail2ban en muchos servidores: protección contra fuerza bruta en SSH, Nginx y otros servicios con un solo playbook. En esta guía verás cómo desplegar Fail2ban con Ansible, definir jails, tiempos de baneo y listas de IP de confianza, de forma repetible y versionada. Si ya automatizas seguridad, revisa Ansible Security Hardening y nuestra categoría Ansible.

¿Qué es Ansible Fail2ban?

Fail2ban monitoriza los logs de servicios como SSH, Nginx, Apache o correo, detecta intentos de acceso fallidos (fuerza bruta, escaneos) y aplica baneos temporales mediante reglas de firewall (iptables o nftables). Con Ansible Fail2ban centralizas esa configuración en código y la aplicas a decenas o cientos de nodos sin tocar cada servidor a mano. La documentación de Ansible y roles como buluma.fail2ban en Ansible Galaxy o buluma/ansible-role-fail2ban en GitHub te permiten empezar rápido. Comparado con instalar Fail2ban manualmente en cada host, usar Ansible Fail2ban garantiza la misma política de seguridad en todos los entornos y permite versionar cambios en Git.

Casos de uso típicos: proteger SSH en granjas de servidores, limitar intentos de login en paneles web (Nginx HTTP auth, Nginx limit-req), proteger servicios de correo o bases de datos expuestas. Con un solo playbook puedes desplegar jails distintos por grupo de hosts (por ejemplo, solo SSH en unos y SSH más Nginx en otros). Fail2ban funciona con expresiones regulares sobre los logs: cuando detecta un patrón de fallo (por ejemplo un mensaje de «Failed password» en el log de SSH), ejecuta una acción (añadir una regla iptables para bloquear esa IP durante un tiempo). Ansible Fail2ban lleva esa lógica a escala: la misma política en todos los servidores, con la posibilidad de diferenciar por entorno mediante variables.

Arquitectura de la solución Ansible Fail2ban

En un despliegue con Ansible Fail2ban tienes un nodo de control (donde ejecutas ansible-playbook) y los nodos gestionados (servidores donde se instalará Fail2ban). Ansible se conecta por SSH, no requiere agente en los nodos. El flujo es: inventario con los hosts, variables por grupo o por host (jails, bantime, ignoreip), y un playbook que aplica un rol de Galaxy o tareas propias. Los módulos de Ansible utilizados suelen ser apt/yum para instalar el paquete, template para generar jail.local y filters, y systemd para reiniciar el servicio. La estructura de inventario puede separar, por ejemplo, [webservers] con jails SSH + Nginx y [bastion] solo con SSH. El rol descarga e instala Fail2ban, escribe los ficheros de configuración según las variables y deja el servicio listo para monitorear los jails activos; cualquier cambio posterior en variables se refleja en la siguiente ejecución del playbook.

Requisitos previos para Ansible Fail2ban

Necesitas un nodo de control con Ansible instalado (2.9 o 2.14+ recomendado), Python en control node y en los managed nodes, y acceso SSH a los servidores objetivo con privilegios sudo. Fail2ban se instala desde los repositorios del sistema (apt en Debian/Ubuntu, yum/dnf en RHEL/CentOS). Un inventario Ansible con los hosts donde quieres desplegar Fail2ban es suficiente; no hace falta agente en los nodos más allá de SSH. Conocimientos básicos de YAML y de la estructura de un playbook Ansible ayudan. Para gestionar secretos (por ejemplo listas de IP en Vault) conviene conocer Ansible Vault. En entornos con muchos nodos, asegúrate de que el inventario está bien agrupado y de que las variables por grupo no sobrescriben por error configuraciones que deban ser distintas por host (por ejemplo, jails específicos para un servidor de correo frente a un front web).

Pasos de implementación con Ansible Fail2ban

Paso 1: Instalar el rol desde Galaxy en tu proyecto (o usar un playbook que instale Fail2ban sin rol). Ejemplo con el rol buluma.fail2ban:

ansible-galaxy install buluma.fail2ban

El rol se descargará en ~/.ansible/roles/ o en roles/ si usas un ansible.cfg con roles_path. Verifica con ansible-galaxy list que aparece buluma.fail2ban.

Paso 2: Crear el inventario con el grupo de servidores donde desplegar Ansible Fail2ban. Por ejemplo inventory/hosts.yml con un grupo servers y las IP o nombres de tus hosts. Si tienes varios entornos, define grupos como webservers, bastion y asigna variables por grupo para activar jails distintos (por ejemplo solo SSH en bastion y SSH más Nginx en webservers).

Paso 3: Definir variables. Puedes usar group_vars/servers.yml o vars dentro del playbook. Variables típicas: fail2ban_bantime (segundos de baneo, ej. 3600 para una hora), fail2ban_findtime (ventana en segundos para contar fallos, ej. 600 para diez minutos), fail2ban_maxretry (número de fallos antes de banear, ej. 5), fail2ban_jails (lista: sshd, nginx-http-auth, nginx-limit-req, etc.), fail2ban_ignoreip (localhost y redes de confianza para no bloquear a administradores). Consulta la documentación del rol en Ansible Galaxy para opciones avanzadas como tiempos por jail o rutas de log personalizadas.

Paso 4: Crear el playbook principal que aplique el rol. El playbook debe ejecutarse con become: yes porque la instalación y la configuración de Fail2ban requieren root. Incluye el rol en la sección roles: y, si lo deseas, tareas previas (por ejemplo comprobar que el host está en el inventario correcto) o posteriores (notificar a un canal si se aplicaron cambios).

Paso 5: Ejecutar con ansible-playbook -i inventory playbook.yml. Revisa el output de Ansible para confirmar que no hubo fallos. En los nodos, comprueba que el servicio Fail2ban está activo (systemctl status fail2ban) y que los jails configurados aparecen con fail2ban-client status y fail2ban-client status sshd. Si un jail no lista ningún ban, es normal si aún no ha habido intentos fallidos; puedes simular con intentos de SSH fallidos (otro terminal) y ver cómo se añade la IP baneada. Con estos pasos tienes Ansible Fail2ban operativo en todos los hosts del inventario.

Playbook Ansible Fail2ban completo

- name: Desplegar Fail2ban en servidores
  hosts: servers
  become: yes
  vars:
    fail2ban_bantime: 3600
    fail2ban_findtime: 600
    fail2ban_maxretry: 5
    fail2ban_ignoreip:
      - 127.0.0.1/8
      - 10.0.0.0/8
    fail2ban_jails:
      - sshd
      - nginx-http-auth
  roles:
    - role: buluma.fail2ban
      # Instalación previa: ansible-galaxy install buluma.fail2ban

Ajusta fail2ban_bantime, fail2ban_findtime y fail2ban_maxretry según tu política. Con Ansible Fail2ban puedes usar group_vars por entorno (desarrollo con bantime corto, producción más largo) o host_vars para excepciones. Para Nginx con autenticación básica, asegúrate de que el jail nginx-http-auth esté habilitado y que la ruta del log en el rol coincida con tu configuración de Nginx. Documentación oficial de Fail2ban en fail2ban.org.

Variables y jails típicos en Ansible Fail2ban

Incluye en fail2ban_ignoreip siempre localhost (127.0.0.1/8) y las redes de confianza (VPN, oficina, CI) para no bloquear a administradores. Jails habituales: sshd (SSH), nginx-http-auth, nginx-limit-req, apache-auth, dovecot, postfix-sasl. Cada jail puede tener su propio bantime, findtime y maxretry si tu rol lo permite. Para secretos (por ejemplo una lista de IPs en un vault), usa Ansible Vault y no guardes datos sensibles en texto plano en el repositorio. En entornos con firewalld en lugar de iptables, el rol o la configuración de Fail2ban deben usar la acción adecuada (por ejemplo firewallcmd-ipset); la documentación del rol en Galaxy suele indicar las opciones soportadas para cada distro.

Optimización y buenas prácticas con Ansible Fail2ban

Seguridad: Usa Ansible Vault para cualquier variable sensible (listas de IP, datos que no quieras en texto plano). Aplica el principio de permisos mínimos: el usuario con el que Ansible se conecta solo necesita sudo para instalar paquetes y gestionar el servicio Fail2ban. Mantén SSH hardening (autenticación por clave, desactivar root login si procede) y documenta qué IPs o redes están en fail2ban_ignoreip para auditorías. No expongas el playbook con secretos sin cifrar en repositorios públicos.

Rendimiento: En playbooks con muchos hosts, ajusta forks en ansible.cfg o con -f para paralelizar; valores entre 10 y 20 suelen ser razonables. Considera strategy: free si no hay dependencias entre hosts para que cada uno termine sin esperar al más lento. Si el fact gathering no es necesario para este playbook, desactívalo con gather_facts: no para acelerar.

Mantenimiento: Estructura el proyecto con roles en roles/, variables en group_vars y host_vars, y versiona todo en Git. Fija la versión del rol en un requirements.yml (galaxy) para no romper el playbook al actualizar. Ejecuta en modo check (ansible-playbook ... --check) cuando quieras ver cambios sin aplicarlos. Documenta las variables en un README para que el equipo sepa cómo adaptar Ansible Fail2ban a nuevos entornos o añadir jails. Herramientas como Molecule permiten testear roles en contenedores antes de aplicar en producción.

Troubleshooting Ansible Fail2ban

Error de conexión SSH o permisos: Verifica que el usuario tenga acceso sudo sin contraseña o que esté configurado el become. Prueba con ansible servers -m ping y ansible servers -m shell -a "sudo fail2ban-client status". El jail no aparece o no banea: Revisa que el nombre del jail coincida con los disponibles en el nodo (fail2ban-client status) y que la ruta del log en la configuración del jail sea correcta. Me baneo yo mismo: Añade tu IP o red en fail2ban_ignoreip y vuelve a aplicar el playbook; en el nodo puedes desbanear con fail2ban-client set sshd unbanip <tu_ip>. Cambios no se aplican: Algunos roles solo copian ficheros si cambian; forzar reinicio del servicio con un handler o systemd con state: restarted. Revisa los logs de Fail2ban en /var/log/fail2ban.log y los del servicio con journalctl -u fail2ban.

Conclusión

Con Ansible Fail2ban tienes protección contra fuerza bruta automatizada y consistente en todos tus servidores: un solo playbook para instalar y configurar Fail2ban, jails y listas de confianza. Versionando la configuración en Git y aplicando los mismos criterios en desarrollo y producción reduces errores y tiempo de administración. Como próximos pasos puedes integrar notificaciones (por ejemplo cuando se banea una IP), combinar con otras automatizaciones como Ansible Nginx y seguir explorando la categoría Ansible del blog.

FAQ sobre Ansible Fail2ban

¿Puedo usar Ansible Fail2ban con Nginx y Apache?
Sí. Fail2ban tiene jails para ambos; configura el jail correspondiente (nginx-http-auth, nginx-limit-req, apache-auth, etc.) y la ruta del log en las variables del rol que uses.

¿Cómo evito banearme yo?
Añade tu IP o red de confianza en fail2ban_ignoreip (o el equivalente en tu rol) y vuelve a ejecutar el playbook. En emergencia puedes desbanear desde el servidor con fail2ban-client set <jail> unbanip <ip>.

¿Funciona con firewalld o solo iptables?
Depende del backend que use Fail2ban en tu distro (action en el jail); la mayoría de roles soportan la configuración estándar. Revisa la documentación del rol y de fail2ban.org.

¿Qué versión de Ansible necesito?
Ansible 2.9 o superior; 2.14+ es recomendable. Los roles de Galaxy suelen indicar compatibilidad en su README.

¿Es idempotente el playbook?
Sí. Instalar el paquete, copiar configuración y reiniciar el servicio son operaciones idempotentes; puedes ejecutar el playbook varias veces sin efectos secundarios no deseados.

¿Puedo usar roles de Galaxy además de buluma.fail2ban?
Sí. Hay otros roles para Fail2ban en Ansible Galaxy; elige uno mantenido y con documentación clara. Asegúrate de que las variables (nombres de jails, rutas) coincidan con lo que espera el rol.