Fail2ban en una puerta de enlace VPN: qué arregla y qué no

Todo servicio expuesto recibe el mismo consejo: ponle fail2ban. Para una puerta de enlace VPN ese consejo ni es erróneo ni es suficiente, y tratarlo como una casilla de endurecimiento es justo cómo la gente acaba con una jaula (jail) que no bloquea nada útil. Fail2ban lee los registros de fallos a los que lo diriges y pide a un backend de aplicación que prohíba las fuentes coincidentes. Todo su valor depende de qué superficie de autenticación produjo el registro, de si la dirección que contiene es el cliente real y de qué ocurre con todos los demás detrás de esa dirección.

Qué es fail2ban, mecánicamente

Un filtro hace coincidir líneas de un registro, una jaula cuenta coincidencias por fuente y una acción aplica una prohibición mediante un backend de cortafuegos. Tres piezas móviles, y cada una puede estar equivocada de forma independiente.

Ninguna de las tres toca la ruta de autenticación: fail2ban reacciona a la evidencia después del hecho y nunca valida por sí mismo una credencial. Por eso una jaula puede funcionar limpiamente mientras la superficie que nombra sigue exactamente igual de expuesta que antes.

El oyente del túnel no es un formulario de inicio de sesión

Un oyente OpenVPN protegido con tls-auth o tls-crypt descarta los paquetes sin la protección del canal de control antes de que empiece el procesamiento normal de TLS. Un escáner que nunca tiene la clave no genera nada que tu filtro pueda contar. La autenticación por certificado añade otra puerta, porque no hay contraseña que adivinar. El proyecto Fail2ban documenta un modelo general basado en registros, y un filtro VPN genérico no convierte un paquete no autenticado en un evento de fallo significativo.

Si la puerta de enlace solo acepta certificados, puede que la historia de fuerza bruta contra la que te defiendes no exista en ese puerto.

Entonces, ¿qué superficie proteges?

El mismo host suele exponer tres cosas distintas: el oyente del túnel, un portal de perfiles de cliente o de autoservicio y una página de administración. El portal y la página de administración tienen formularios de contraseña y producen líneas de registro que un filtro puede contar. El túnel puede producir solo errores de apretón de manos que significan algo completamente distinto. Haz coincidir la jaula con la superficie, no con el nombre del producto.

Una jaula que vigila el registro equivocado es peor que ninguna, porque crea confianza sin cobertura. Apunta un filtro de inicio de sesión a los errores de apretón de manos del túnel y el contador saltará con escáneres que nunca tuvieron una clave, mientras que un ataque de contraseña contra el portal quedará sin contar. Lee la línea de registro que hace coincidir el filtro antes de fiarte del número de la jaula.

La atribución de la fuente es el eslabón débil

Una prohibición vale lo que vale la dirección a la que apunta. Cuando el servicio está detrás de un proxy inverso local, la dirección del cliente en el registro puede ser la del proxy, y prohibirla elimina a todos. Confiar en una cabecera reenviada de una fuente no fiable da a un atacante la capacidad de prohibir direcciones arbitrarias. En UDP las direcciones de origen se pueden falsificar, así que contarlas merece más cuidado que contar un inicio de sesión TCP completado.

Anota el método de atribución de la fuente en el README de la jaula, porque una cabecera reenviada desde un salto no fiable convierte una prohibición en un arma.

El coste colateral son los demás

Varios empleados detrás de un NAT de oficina comparten una dirección, así que una sola contraseña guardada y obsoleta puede bloquear toda la oficina en cuanto se cruza el umbral. El registro muestra una fuente y una cuenta que fallaron, no una caída de toda la oficina.

Las prohibiciones cortas y los umbrales moderados reducen eso, y una ruta documentada para levantar la prohibición reduce la carga de soporte cuando ocurre igualmente. La dirección es una señal burda en lugar de una identidad, y quien abra el tique describirá la caída, no el umbral.

Cuándo adoptarlo y cuándo arreglar otra cosa

Adóptalo cuando haya un fallo de inicio de sesión en línea real, atribuible y repetido en una superficie que controles, y cuando el backend de aplicación cubra de verdad esa superficie. Arregla otra cosa cuando el problema sea una política de credenciales débil, una página de administración expuesta a internet o una cuenta que inicia sesión con éxito porque ha sido comprometida. Una prohibición no puede reparar nada de eso y no puede absorber el tráfico que ya ha saturado tu enlace ascendente. Ese último problema pertenece aguas arriba, a alguien que pueda filtrar antes de que los paquetes te lleguen.

Mantén cada jaula ligada a una superficie, revisa los falsos positivos y mide el trabajo de autenticación evitado en lugar del número de direcciones prohibidas.