Alternativas a Fail2Ban para servidores Linux modernos

Comprobar la superficie de ataque antes de elegir la herramienta

A Alternativa a Fail2Ban Solo se puede seleccionar de forma adecuada cuando se conocen los servicios a los que realmente se puede acceder. SSH, SMTP, IMAP y una aplicación HTTP tienen procesos de inicio de sesión, fuentes de registro y patrones de daño diferentes. Por el contrario, un servicio de base de datos accesible públicamente no debería, por regla general, tener que protegerse mediante una lista de bloqueo de Internet: su acceso a la red debe limitarse a las aplicaciones necesarias y a las redes de confianza.

En el caso de las altas administrativas, se tiene Restricción de acceso y que las autenticaciones sólidas tengan prioridad sobre los bloqueos automáticos de IP. Un servicio SSH detrás de una VPN, un servidor bastión o redes de administración fijas ofrece a los atacantes una superficie de ataque mucho menor que un puerto abierto a nivel mundial. Las actualizaciones de seguridad recientes, las cuentas con privilegios separadas y un proceso de inicio de sesión con contraseña cuidadosamente sopesado reducen los riesgos que una lista de bloqueo por sí sola no elimina.

Si se permite deliberadamente el acceso público a SSH, los límites y los bloqueos basados en registros pueden reducir los intentos repetidos de introducir la contraseña. Sin embargo, siguen siendo una medida complementaria: las personas que se encuentran detrás de una pasarela NAT compartida pueden utilizar la misma dirección de origen, mientras que los ataques distribuidos emplean muchas direcciones. En el caso de los servicios de correo electrónico, también es importante tener en cuenta qué protocolos están realmente abiertos a los usuarios externos y qué intentos fallidos de inicio de sesión se registran.

En el caso de las aplicaciones web, hay que distinguir entre la accesibilidad del proxy inverso y la de los servicios internos de backend. Un Nginx público puede aceptar solicitudes HTTP sin que sea necesario que la base de datos, la caché o la interfaz de administración sean accesibles desde Internet. El Objetivo de protección Por lo tanto, no se trata de „bloquear direcciones IP“ de forma generalizada, sino de limitar los accesos no autorizados en cada servicio, preservar el uso legítimo y evitar autorizaciones innecesarias.

Antes de realizar cualquier cambio, los responsables deben determinar qué vías de acceso son necesarias en caso de emergencia y qué redes de origen acceden de forma habitual. Este análisis evita que una regla de cortafuegos demasiado restrictiva bloquee el propio acceso de administración o el mantenimiento automatizado. Solo entonces se podrá decidir si lo más adecuado es el análisis de registros, la limitación de conexiones o un enfoque por niveles.

Además, un bloqueo no resuelve la cuestión de si un servicio debe ser público o no. Quien invierte este orden, se centra en las conexiones que llaman la atención, aunque la exposición subyacente permanece inalterada. Especialmente en el caso de las interfaces administrativas que se utilizan con poca frecuencia, una vía de acceso privada suele ser más eficaz y más fácil de gestionar que unas reglas de detección cada vez más complejas.

Cuatro enfoques en lugar de una alternativa a Fail2Ban

En lugar de buscar una única solución alternativa, merece la pena separar la detección de la reacción. CrowdSec Procesa fuentes de registro configurables mediante analizadores sintácticos y escenarios para evaluar secuencias de eventos y generar decisiones. El motor de seguridad no aplica estas decisiones por sí mismo; para ello, es necesario que un componente de corrección independiente esté conectado y en funcionamiento.

Esta distribución resulta adecuada cuando se desea que la misma regla de detección se aplique en distintos puntos. Un componente de cortafuegos puede aplicar decisiones a las conexiones de red, mientras que los componentes para servidores web o proxies inversos se centran en el tráfico HTTP. Sin embargo, esto también aumenta los requisitos: la adquisición de registros, los analizadores sintácticos, la API local, los permisos y la aplicación concreta deben planificarse como una cadena coherente.

SSHGuard está pensado para casos más concretos. Esta herramienta agrupa los registros del sistema y puede bloquear fuentes que repitan comportamientos sospechosos a través de los backends del cortafuegos; su finalidad abarca los ataques de fuerza bruta contra SSH y otros servicios. Por lo tanto, resulta más adecuada para detectar errores de autenticación identificables que para realizar un análisis exhaustivo de las solicitudes web.

Nativos Limitación de velocidad en nftables adopta un enfoque diferente. Los conjuntos dinámicos y los medidores pueden limitar las nuevas conexiones TCP por dirección de origen y gestionar las entradas que han superado el tiempo de espera. Esto frena las secuencias rápidas de conexiones antes de la autenticación, no requiere un analizador de registros y, al mismo tiempo, no evalúa si un inicio de sesión ha fallado o si una solicitud HTTP era maliciosa.

La dirección de la regla es importante en este caso: nftables distingue entre reglas que aceptan tráfico hasta una determinada tasa y expresiones con over, que descartan el tráfico que supera una determinada tasa. Por lo tanto, un límite debe ajustarse al servicio, al comportamiento esperado de los usuarios y a las direcciones de origen compartidas. No se trata de una clasificación fiable de todas las identidades sospechosas.

Para un único servidor con pocos servicios bien definidos, puede bastar con una protección de registros sencilla o un límite de conexiones moderado. La presencia de varios hosts, fuentes de registros centralizadas o la necesidad de distintos puntos de aplicación abogan más bien por una arquitectura modular. Ninguna de estas opciones sustituye a los parches, a un inicio de sesión seguro ni a un acceso a la red restrictivo.

La alternativa adecuada a Fail2Ban depende, por tanto, de qué señales están disponibles y dónde debe producirse la reacción. Los patrones de registro son útiles para los errores de inicio de sesión repetidos; las reglas de paquetes limitan la frecuencia de las conexiones. Ambos métodos solo detectan aquello para lo que están diseñadas su fuente de datos y sus reglas.

Separar claramente el cortafuegos y la protección HTTP

Un servidor Nginx o un proxy inverso conecta dos niveles de protección que no deben confundirse. Un cortafuegos rechaza o permite las conexiones procedentes de una dirección de origen y, por lo tanto, puede afectar simultáneamente a SSH, SMTP o al acceso web. Sin embargo, no evalúa ninguna ruta HTTP concreta, ni los encabezados ni el contenido de las solicitudes; esta información se encuentra en el nivel de aplicación.

En CrowdSec hay Detección y aplicación Funciones independientes. El procesador de registros analiza los datos de registro y las solicitudes HTTP de los servidores web compatibles. AppSec forma parte de este procesador de registros y filtra dichas solicitudes HTTP. Por su parte, los componentes de corrección se encargan de aplicar las decisiones en el nivel seleccionado, por ejemplo, en un cortafuegos, un servidor web o un proxy inverso.

Por lo tanto, un simple componente de cortafuegos no es suficiente para protegerse contra inyecciones SQL, scripts entre sitios u otros contenidos maliciosos en las solicitudes. Se requiere una conexión compatible con el servidor web, así como una configuración adecuada de seguridad de aplicaciones (AppSec) con las reglas correspondientes. La corrección debe mantenerse separada de esto desde el punto de vista técnico: se encarga de aplicar las decisiones en el punto de aplicación seleccionado.

Ambos niveles pueden resultar útiles de forma conjunta. Un bloqueo a nivel de red reduce el tráfico de conexión adicional procedente de una fuente, mientras que un Comprobación HTTP evalúa y filtra los servidores web compatibles con las solicitudes de AppSec. Esto no significa que el bloqueo de una dirección IP proteja automáticamente contra la inyección SQL o el cross-site scripting: sin una comprobación de las solicitudes, el cortafuegos no detecta ni los parámetros ni los datos de carga útil.

Por el contrario, las medidas basadas en la seguridad de las aplicaciones (AppSec) y en la IP también tienen sus limitaciones. Los intentos lentos por debajo de los umbrales, las numerosas direcciones de origen cambiantes o los usuarios legítimos que se encuentran detrás de la misma dirección NAT dificultan la toma de decisiones basadas en la IP de origen. Por lo tanto, las reglas deben tener en cuenta las falsas alarmas y no tratar de forma generalizada como un ataque el acceso a formularios normales, API e integraciones automatizadas.

Para facilitar la planificación, conviene hacer una breve clasificación: La Nivel de cortafuegos controla el tráfico de red en función de direcciones, puertos y características de conexión. AppSec procesa y filtra las solicitudes HTTP de los servidores web compatibles como parte del procesador de registros. Los componentes de corrección aplican las decisiones de forma selectiva en un nivel determinado.

Además, un sistema web público requiere una separación clara de responsabilidades. El proxy inverso solo debe poder acceder a los backends necesarios, y los puntos finales administrativos no deben seguir estando disponibles públicamente solo por el hecho de que haya un filtro situado antes de ellos. De este modo, la segmentación de la red, el inicio de sesión seguro y las reglas específicas se complementan entre sí, sin atribuir a una única técnica de bloqueo más eficacia protectora de la que realmente puede ofrecer.

Comparativa de servidores Linux típicos

No es adecuado elegir una alternativa a Fail2Ban basándose únicamente en el número de bloqueos posibles. Lo decisivo son las señales que se analizan y el lugar donde se aplica la medida. CrowdSec Separa su motor de seguridad del componente que aplica las decisiones en el cortafuegos, el proxy o el servidor web. Por su parte, SSHGuard analiza los registros del sistema en busca de intentos de ataque repetidos; nftables puede limitar las nuevas conexiones directamente en la ruta del paquete.

La tabla no refleja ninguna clasificación. En el caso de un servicio concreto con intentos de inicio de sesión claramente fallidos, un análisis sencillo de los registros es algo distinto a un límite contra las avalanchas de conexiones. En el caso de un proxy inverso, también hay que tener en cuenta si las solicitudes HTTP deben filtrarse mediante AppSec en una conexión compatible. El Punto de aplicación Debe ajustarse al objeto protegido: una regla de cortafuegos no evalúa el contenido de las solicitudes, mientras que los componentes de corrección aplican decisiones en el nivel seleccionado en cada caso.

La gestión centralizada tampoco es un fin en sí misma. Puede unificar la toma de decisiones y el análisis de registros en varios hosts, pero requiere un plan de acceso y de contingencia sólido. En el caso de un servidor pequeño y aislado, esta arquitectura adicional puede suponer, en determinadas circunstancias, más trabajo de mantenimiento que beneficios en materia de seguridad. Por el contrario, los servicios idénticos en varios servidores pueden beneficiarse de una instalación centralizada de CrowdSec planificada cuidadosamente.

Comprobar y clasificar la configuración de forma segura

Antes de activarlo, hay que determinar qué mensajes llegan realmente al servicio. En el caso de una solución basada en registros, comprueba la fuente de los registros, el analizador y el formato concreto de los eventos de SSH, correo electrónico o proxy. En el caso de CrowdSec, no basta con que se detecte la actividad: un componente de corrección registrado y accesible debe transmitir las decisiones a la conexión prevista con el cortafuegos o el proxy.

Los siguientes comandos son únicamente comprobaciones de lectura en un sistema Linux, en el que es posible que las herramientas correspondientes ya estén instaladas. No modifican ninguna regla ni instalan ningún paquete. Sirven para ver el conjunto actual de reglas, los componentes de CrowdSec registrados y los paquetes candidatos disponibles para Debian o Ubuntu.

nft list ruleset
sudo cscli bouncers list
apt-cache policy crowdsec

La salida aún no garantiza ningún efecto de protección. Comprueba en nftables si la cadena de entrada correspondiente tiene el gancho esperado y la política predeterminada adecuada, y si se han definido reglas para las conexiones existentes, el bucle de retorno, IPv4 e IPv6, así como para el puerto de servicio real. Además, un componente registrado puede estar configurado para un punto de aplicación incorrecto. Incluso un paquete candidato visible no garantiza que su versión, configuración y analizador sean compatibles con la distribución y con el propio servicio.

Los umbrales, los periodos de bloqueo y las excepciones no deben incorporarse a la producción sin haber sido comprobados previamente a partir de ejemplos. En particular, las direcciones NAT compartidas, los accesos móviles y las tareas automatizadas pueden provocar falsas alarmas si no se tienen en cuenta. Para el análisis de los eventos de red y el comportamiento del sistema, se puede utilizar además Seguimiento de eBPF para la supervisión de Linux ayuda; sin embargo, no sustituye ni la comprobación de la cadena de registro ni la decisión técnica sobre un bloqueo.

La opción adecuada para cuatro escenarios de funcionamiento

Un único VPS con acceso SSH desde cualquier parte del mundo tiene unas necesidades de protección bien definidas. SSHGuard puede notificar a un backend de cortafuegos los intentos fallidos repetidos, identificables en los registros correspondientes. Un límite moderado de nftables puede limitar además las nuevas conexiones, pero no evalúa los errores de inicio de sesión. Se da prioridad a las vías de administración restringidas y al inicio de sesión seguro; el bloqueo de IP sigue siendo un complemento.

En un servidor de correo, los protocolos SMTP, IMAP y Submission se enfrentan a diferentes vías de autenticación y registro. Una respuesta ágil basada en registros solo tiene sentido si se recogen íntegramente los mensajes relevantes en cada caso. CrowdSec se convierte en una opción cuando es necesario centralizar la toma de decisiones o el análisis de registros de varios sistemas. Sin esta necesidad, la arquitectura centralizada resultaría desproporcionada frente a una solución local claramente delimitada.

En el caso de Nginx o Traefik, situados delante de una aplicación web, no basta con una herramienta orientada exclusivamente a SSH. En este caso, una protección en varias capas Accesos a la red desde comprobaciones HTTP: CrowdSec AppSec forma parte del procesador de registros y puede filtrar las solicitudes de los servidores web compatibles. Por su parte, los componentes de corrección aplican las decisiones en el nivel seleccionado, por ejemplo, en el servidor web o en el proxy inverso. Ambas tareas deben integrarse adecuadamente y revisarse por separado.

Una pequeña flota con registros centralizados o Kubernetes puede beneficiarse de una API local centralizada o de registros centralizados. Esto no simplifica automáticamente el funcionamiento: hay que planificar los permisos, la accesibilidad de las interfaces, la segmentación y el fallo de un componente central. Los aspectos relacionados con el procesamiento de paquetes y el reparto de carga en redes Linux de mayor tamaño también se tratan en el artículo sobre Receive Side Scaling en redes de servidores Linux. En el caso de un número reducido de hosts sin un proceso operativo común, una solución local suele resultar más comprensible.

Supervisar la lógica de bloqueo durante el funcionamiento

La lógica de bloqueo solo resulta comprensible si se controlan por separado tres etapas: la recepción de los datos de registro, la decisión derivada de ellos y su aplicación técnica. En CrowdSec, el motor de seguridad lee las fuentes de registros configuradas y genera decisiones basándose en analizadores sintácticos y escenarios; sin embargo, el bloqueo en sí lo lleva a cabo un componente de corrección independiente.

Comprueba primero si llegan los mensajes esperados. En el caso de un servicio SSH, son relevantes los intentos fallidos de inicio de sesión; en el de un servidor de correo, los protocolos de autenticación correspondientes; y en el de un proxy, sus registros de acceso o de seguridad. Los eventos visibles por sí solos no demuestran aún un efecto defensivo: solo la cadena formada por la recepción del registro, la secuencia detectada, la decisión y la regla efectiva permite un diagnóstico fiable.

A continuación, comprueba por separado las decisiones y el componente registrado. Si CrowdSec detecta eventos sospechosos, pero no hay ningún componente de corrección conectado o operativo, las decisiones no tendrán ningún efecto. La documentación oficial sobre errores señala precisamente este patrón como la causa de que el motor de seguridad funcione, pero no se produzca ningún bloqueo. La detección no es un bloqueo.

En el caso de la protección web, se añade una comprobación adicional. AppSec forma parte del procesador de registros y filtra las solicitudes HTTP de los servidores web compatibles. Los componentes de corrección aplican las decisiones en el nivel seleccionado, por ejemplo, en el servidor web o en el proxy inverso. Por lo tanto, durante el funcionamiento debería quedar claro si un rechazo se debe a la comprobación HTTP o a una decisión ya aplicada, de modo que se puedan investigar de forma específica los errores y las falsas alarmas.

Las falsas alarmas tienen consecuencias especialmente graves cuando muchas personas autorizadas utilizan la misma dirección pública. Las pasarelas NAT, las redes móviles y los sistemas de integración de sistemas (CI) pueden agrupar numerosos intentos de inicio de sesión legítimos bajo una misma dirección IP de origen. Por ello, elige los umbrales, los tiempos de bloqueo y las excepciones en función de las vías de acceso reales, y haz que las decisiones, junto con el motivo y el tiempo de duración, sean comprensibles, en lugar de considerar una larga lista de bloqueos como un éxito.

Prueba primero los cambios con registros históricos anonimizados o en un entorno de prueba. De este modo, se puede comprobar si los analizadores detectan los patrones previstos y si la corrección responde al nivel esperado, sin poner en peligro los accesos de administración. SSHGuard procesa los registros del sistema y puede interactuar con diferentes backends de cortafuegos; por ello, es necesario tener en cuenta conjuntamente la fuente de los registros y el backend en el entorno instalado.

Un proceso controlado no sustituye a una prueba de ataque en el sistema de producción. Documenta los eventos previstos, las decisiones observadas y el efecto resultante de las reglas; a continuación, elimina los datos de prueba o deja que las entradas temporales caduquen de forma natural. De este modo, se puede comprobar la eficacia de la protección y los posibles daños colaterales sin provocar intencionadamente bloqueos reales a los usuarios del entorno productivo.

Resolución de problemas en los registros y las reglas

Empieza siempre la búsqueda de errores por la fuente del registro y ve avanzando hasta llegar a la aplicación. Si faltan los mensajes adecuados, ni un analizador de registros ni una lógica de escenarios o de bloqueo podrán reaccionar de forma fiable. Por lo tanto, comprueba el servicio, el lector de registros y el formato real antes de modificar los umbrales o sospechar de las reglas del cortafuegos.

En CrowdSec, el patrón de error es claro cuando los eventos o las decisiones son visibles, pero sigue siendo posible el acceso: el motor no aplica automáticamente una decisión. Comprueba si hay un componente de corrección adecuado registrado, accesible y realmente conectado al cortafuegos, al servidor web o al proxy. Sin este componente, no se aplica ninguna regla de bloqueo.

En el caso de SSHGuard, la causa suele estar en una etapa anterior. La herramienta agrega los registros del sistema, pero un lector de registros inadecuado o un formato de servicio que se desvíe del patrón esperado no proporcionará resultados útiles. La configuración de ejemplo del repositorio muestra posibles entradas y opciones, pero procede de la rama de desarrollo; compárala con la documentación del paquete y la versión instalada, en lugar de aplicarla tal cual.

En nftables, además, debes comprobar si la regla se encuentra en el gancho esperado de la cadena correspondiente, si detecta el puerto de servicio real y si se aplica a las familias de protocolos necesarias. El conjunto de reglas de ejemplo separa IPv4 e IPv6 mediante cadenas independientes, y permite las conexiones establecidas y asociadas, así como el tráfico de bucle invertido, antes de las autorizaciones de puertos. Una protección formulada exclusivamente para IPv4 no cubre IPv6; del mismo modo, una tasa demasiado restrictiva puede afectar a las conexiones paralelas legítimas.

Un metro limita las nuevas conexiones en función de una tasa definida por fuente y puede gestionar entradas dinámicas con tiempo de espera. Sin embargo, esto no tiene en cuenta los intentos de inicio de sesión fallidos. Por lo tanto, si un ataque se mantiene por debajo de la tasa, el hecho de que no se detecte no tiene por qué ser un fallo de la regla, sino que puede ser un límite del enfoque elegido. Gancho, cadena y punto de medición deben ajustarse al efecto esperado.

Realiza los cambios uno por uno y, tras cada paso, vuelve a comprobar la entrada de registro, la decisión y la aplicación. Antes de realizar ajustes en el cortafuegos, asegúrate de disponer de un acceso de emergencia independiente, por ejemplo, a través de la consola, un host bastión o una red de administración separada. Esto evita que una regla mal configurada o una entrada IPv6 errónea bloquee el único acceso al servidor.

Decisión en función del riesgo y el esfuerzo

La alternativa adecuada a Fail2Ban depende de la superficie de ataque expuesta, no de una clasificación general. Aclara qué servicios son públicos, si procesan inicios de sesión, qué registros están disponibles de forma fiable y quién se encarga de la configuración de forma permanente. Un servicio de base de datos sin acceso público no necesita una lista de bloqueo de Internet; su configuración de acceso a la red sigue siendo la decisión de seguridad más importante.

En el caso de un servidor individual de tamaño reducido en el que se producen errores repetidos de inicio de sesión por SSH o correo electrónico, SSHGuard puede ser una solución sencilla basada en registros. El proyecto está orientado a la protección frente a ataques de fuerza bruta contra SSH y otros servicios, y para ello utiliza los registros del sistema y los backends del cortafuegos. No obstante, la cobertura concreta de los registros y los parámetros de bloqueo deben ajustarse a la distribución instalada y al formato del servicio.

Si se quiere limitar sobre todo las nuevas conexiones rápidas, un límite de velocidad moderado en nftables es un complemento directo. Los medidores pueden limitar las conexiones por dirección de origen; las reglas con over Descarta el tráfico que supere la tasa establecida. Esto ocurre antes de un inicio de sesión, pero no proporciona ninguna información semántica sobre si el inicio de sesión ha fallado o si una solicitud HTTP era maliciosa.

CrowdSec resulta adecuado cuando es necesario coordinar el análisis de registros y la aplicación de políticas en varios niveles o en varios hosts. Su arquitectura separa el motor de los componentes de corrección; son posibles variantes distribuidas con una API local centralizada o registros centralizados. Esta ventaja conlleva requisitos adicionales en materia de permisos, accesibilidad, segmentación y un plan para casos de fallo. Operatividad Por lo tanto, es un criterio de selección, además de la gama de funciones.

En el caso de las aplicaciones web públicas, un bloqueo mediante cortafuegos no es suficiente para evaluar las solicitudes HTTP individuales. Para ello se necesita una integración de AppSec compatible con las reglas adecuadas. AppSec forma parte del procesador de registros y filtra las solicitudes HTTP de los servidores web compatibles; los componentes de corrección aplican las decisiones en el punto de aplicación seleccionado. Lo decisivo es si la necesidad de protección se centra en las conexiones, los eventos de autenticación o los contenidos HTTP.

Las medidas basadas en IP siguen siendo limitadas: las redes de bots distribuyen los intentos entre numerosas fuentes, los ataques lentos pueden mantenerse por debajo de un umbral determinado y, en caso de bloqueo, las direcciones compartidas afectan a usuarios ajenos al problema. Reducen el ruido automatizado, pero no sustituyen a los parches puntuales, a los accesos de administración restringidos ni a la autenticación fuerte. Especialmente en el caso de SSH, el inicio de sesión basado en claves y la accesibilidad limitada tienen prioridad frente a unos umbrales de bloqueo cada vez más agresivos.