La mayoría de las afirmaciones sobre seguridad perimetral son declaraciones de nivel 1: lo que dice el fabricante en su hoja de datos. Para saber si una configuración específica realmente detiene un ataque, no hay atajo — hay que intentar vencerla.
Eso hicimos. Desde una MacBook Pro conectada a una red móvil externa (fuera de nuestra red corporativa), lanzamos un ataque de fuerza bruta SSH real contra un servicio expuesto de nuestra propia infraestructura, con el objetivo de validar si la combinación de FortiGate IPS + fail2ban detenía el ataque en un tiempo razonable, o si la protección era solo teórica.
El montaje de la prueba
Antes de lanzar el ataque, configuramos fail2ban en modo agresivo sobre el servicio SSH expuesto, con los siguientes parámetros:
- maxretry: 3 intentos fallidos
- findtime: 5 minutos
- bantime: 7 días
- Jail adicional "recidive": bloqueo de 30 días para IPs que reinciden repetidamente
Esto se combina con el IPS de FortiGate operando en la capa de red, antes de que el tráfico siquiera llegue al servicio SSH.
Resultado: bloqueo en menos de 3 intentos
El origen del ataque —una dirección de un pool de Telcel, confirmado por resolución DNS inversa— fue bloqueado en menos de 3 intentos de autenticación fallidos. El tiempo entre el inicio del ataque y el bloqueo efectivo se midió en segundos, no en minutos.
fail2ban-client status sshd en el servidor afectadoStatus for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 45
| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
|- Currently banned: 10
|- Total banned: 11
`- Banned IP list: 193.46.255.86 2.57.121.25 2.57.122.150 107.172.57.42 31.56.229.221 20.124.91.101 176.53.159.197 176.53.159.198 61.28.144.154 64.225.17.153Nótese que la lista de baneados no es solo el origen de nuestra prueba: son 11 direcciones distintas bloqueadas, incluyendo 193.46.255.86 — el bot que ya estaba atacando antes de que empezáramos. Los otros orígenes en la lista corresponden a tráfico malicioso real que fail2ban siguió bloqueando de forma continua, no solo durante la ventana de nuestra prueba.
El hallazgo que no esperábamos
Al revisar los logs de FortiAnalyzer durante la prueba, encontramos que ya había un bot real intentando acceder al mismo servicio, sin relación con nuestra prueba. Ese origen también fue bloqueado por la misma configuración, confirmando que el sistema no solo funciona bajo condiciones controladas — ya estaba funcionando contra tráfico malicioso real antes de que empezáramos.
| Fecha/Hora | Severidad | Origen | Acción | Nombre del ataque |
|---|---|---|---|---|
| 2026-07-01 14:28 | Alta | 138.197.87.21 | dropped | Multiple.Routers.GPON.formLogin.Remote.Command... |
| 2026-07-01 11:22 | Alta | 196.188.141.17 | dropped | Mirai.Botnet |
| 2026-07-01 10:25 | Alta | 221.159.119.6 | dropped | TP-Link.Archer.AX21.luci.stok.Command.Injection |
| 2026-07-01 01:11 | Crítica | 66.240.205.34 | dropped | Bladabindi.Botnet |
| 2026-06-30 20:30 | Alta | 20.210.131.207 | dropped | ALFA.TEaM.Web.Shell |
Muestra parcial de un registro más extenso. No corresponde al momento exacto de nuestra prueba de fuerza bruta — se incluye como evidencia de que el IPS de FortiGate bloquea tráfico malicioso real de forma continua, no solo durante pruebas controladas.
Por qué esto importa para su infraestructura
Muchas configuraciones de seguridad perimetral se dan por buenas simplemente porque "están instaladas". La diferencia entre un control de seguridad que existe y uno que funciona solo se puede confirmar con una prueba real, documentada, con evidencia verificable — no con la palabra del fabricante ni con una auditoría de configuración en papel.
Si su organización nunca ha validado en la práctica qué tan rápido responde su firewall ante un ataque de fuerza bruta real, es una brecha de visibilidad que vale la pena cerrar antes de que un atacante real la encuentre primero.