Protección de servidores Linux: iptables vs fail2ban

Me gustaría elegir el cerebro de la comunidad con respecto a la seguridad del servidor Linux, específicamente con respecto a los ataques de fuerza bruta y el uso de fail2ban vs iptables personalizadas .

Hay algunas preguntas similares, pero ninguna de ellas aborda el tema a mi entera satisfacción. En resumen, estoy tratando de determinar la mejor solución para proteger los servidores de Linux expuestos a Internet (ejecutando los servicios habituales, ssh, web, correo), de los ataques de fuerza bruta.

Tengo un buen manejo de la seguridad del servidor, es decir, bloquear ssh al no permitir inicios de sesión de root o contraseña, cambiar el puerto predeterminado, garantizar que el software esté actualizado, verificar los archivos de registro, solo permitir que ciertos hosts accedan al servidor y hacer uso de la seguridad herramientas de auditoría como Lynis ( https://cisofy.com/lynis/ ), para el cumplimiento de la seguridad general, por lo que esta pregunta no se refiere necesariamente a eso, aunque las sugerencias y consejos siempre son bienvenidos .

Mi pregunta es qué solución debo usar (fail2ban o iptables), y cómo debo configurarla, o debo usar una combinación de ambas para protegerme contra ataques de fuerza bruta.

Hay una respuesta interesante con respecto al tema ( Denyhosts vs fail2ban vs iptables: ¿la mejor manera de evitar inicios de sesión de fuerza bruta? ). La respuesta más interesante para mí personalmente fue ( https://serverfault.com/a/128964 ), y que el enrutamiento de iptables se produce en el núcleo en lugar de fail2ban, que utiliza herramientas de modo de usuario para analizar archivos de registro. Fail2ban utiliza iptables, por supuesto, pero aún tiene que analizar los archivos de registro y hacer coincidir un patrón hasta que realice una acción.

¿Tiene sentido usar iptables y limitar la velocidad ( https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/ ) para descartar solicitudes de una IP por un período de tiempo que hace demasiados intentos de conexión durante un período específico independientemente del protocolo al que intentaba conectarse? Si es así, entonces hay algunas ideas interesantes sobre el uso de caída versus rechazo para esos paquetes aquí ( http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject ), ¿alguna idea al respecto?

Fail2ban permite una configuración personalizada en la forma de poder escribir ' reglas ' personalizadas para servicios que podrían no abordarse en la configuración predeterminada. Es fácil de instalar y configurar y es potente, pero podría ser una exageración si todo lo que estoy tratando de lograr es ' bloquear ' una IP del servidor si hacen 2 intentos de acceso fallidos en cualquier servicio / protocolo por una cantidad x ¿de tiempo?

El objetivo aquí es abrir informes diarios de logwatch y no tener que desplazarse por las páginas de intentos de conexiones fallidas con el servidor.

Gracias por tomarse el tiempo.

¿Debo usar fail2ban o iptables?

Usted usa fail2ban además de una solución de firewall, para extender a pedido aquellas reglas de firewall existentes con reglas para bloquear las direcciones IP específicas de los sistemas que realizan acciones indeseables en servicios públicos. Trabajan en concierto entre ellos.

Simplificado: un cortafuegos solo ve las conexiones de red y los paquetes y puede comprender los patrones que contiene, pero no tiene el conocimiento de nivel de aplicación para distinguir las solicitudes deseadas y válidas de las solicitudes maliciosas, malformadas e indeseables. Por ejemplo, su firewall no puede diferenciar entre un montón de solicitudes de API HTTP y un número de intentos de inicio de sesión incorrectos causados ​​por adivinar la contraseña de fuerza bruta en su página de administrador de Wordpress, para el firewall ambos son solo conexiones TCP al puerto 80 o 443.

Fail2ban es un enfoque genérico y extensible para proporcionar esa información a nivel de aplicación a su firewall, aunque de manera indirecta.
Con frecuencia, las aplicaciones registrarán y registrarán solicitudes maliciosas, malformadas e indeseables como tales, pero solo en raras ocasiones tendrán la capacidad nativa de evitar nuevos abusos. Aunque está ligeramente desacoplado, Fail2ban puede actuar sobre esos eventos maliciosos registrados y limitar el daño y evitar nuevos abusos, por lo general reconfigurando dinámicamente su firewall para negar acceso adicional. En otras palabras, Fail2ban brinda a sus aplicaciones existentes, sin modificarlas, los medios para defenderse del abuso.

Un método diferente para proporcionar firewalls con información a nivel de aplicación sería mediante un sistema de detección / prevención de intrusos .

Por ejemplo, un servidor web es un servicio público común y en su firewall los puertos TCP 80 y 443 están abiertos para Internet en general.
Por lo general, no tiene ninguna limitación de velocidad en los puertos HTTP / HTTPS porque varios usuarios válidos pueden tener un único origen cuando están, por ejemplo, detrás de una puerta de enlace NAT o un proxy web.

Cuando detecta acciones indeseables y / o maliciosas hacia su servidor web, utiliza fail2ban para automatizar el bloqueo de dicho delincuente (ya sea bloquearlo completamente o solo bloqueando su acceso a los puertos 80 y 443).

Por otro lado, el acceso SSH no es un servicio público, pero si no está en condiciones de restringir el acceso SSH en su firewall a solo los rangos de direcciones IP que figuran en la lista blanca, las conexiones entrantes que limitan la velocidad son una forma de reducir la velocidad bruta -fuerza ataques. Pero su cortafuegos aún no puede distinguir entre el usuario bob que inicia sesión con éxito 5 veces porque está ejecutando libros de jugadas ansibles y 5 intentos fallidos de iniciar sesión como root por un bot.

¿Debo usar fail2ban o iptables?

Esto es algo parecido a preguntar "¿debo usar el cinturón de seguridad o el automóvil?".

En primer lugar, recuerde que fail2ban realmente es solo una herramienta para detectar automáticamente entradas recurrentes en archivos de texto y ejecutar algún comando cuando alcanzan un umbral específico.

A menudo lo usamos para bloquear hosts que violan alguna política como lo demuestran las entradas de registro recurrentes que indican una violación de la política, pero eso no es lo único para lo que puede usarlo.

Usted puede utilizar fail2ban añadir (y eliminar) las reglas iptables bajo demanda. También puede agregar y eliminar reglas de iptables a mano, o puede usar fail2ban para hacer algo completamente diferente en respuesta. Eso se trata de cómo lo configuras.

Debería tener instalado un firewall general independientemente de si está ejecutando fail2ban o no. Tal cortafuegos sería, por ejemplo, bloquear el tráfico (entrante o saliente) que sabe que nunca será legítimo. Por ejemplo, ¿ese servidor de base de datos realmente necesita lidiar con las conexiones entrantes en el puerto 25 desde todo Internet?

Además de eso, hacer que fail2ban responda a las violaciones de las políticas cortando las IPs infractoras por un tiempo no hará mucho para asegurar su servidor per se (una buena explotación solo necesita atravesar su firewall una vez) pero lo hará reducir el nivel de ruido en su sistema, incluidos, entre otros, los registros del sistema. La forma más sencilla de hacerlo es hacer que fail2ban ejecute iptables para configurar el kernel para descartar los paquetes durante un tiempo. Si puede reconfigurar su firewall perimetral en lugar de solo el firewall host, entonces mucho mejor.

En otras palabras, en la medida en que puedan separarse fácilmente en primer lugar, desea ambos.

¿podría ser una exageración si todo lo que intento lograr es 'bloquear' una IP del servidor si hacen 2 intentos de acceso fallidos en cualquier servicio / protocolo durante un período de tiempo de hacha?

Ese es exactamente el caso de uso que fail2ban está diseñado para resolver. Usar una herramienta para su propósito previsto casi nunca es excesivo.

El objetivo aquí es abrir informes diarios de logwatch y no tener que desplazarse por las páginas de intentos de conexiones fallidas con el servidor.

Un comentario aparte, no directamente relacionado con su pregunta: cada vez que filtre registros para su revisión, considere lo que hará con respecto a alguna entrada en particular. Si todo lo que vas a hacer con respecto a una entrada es decir "meh" y seguir adelante, entonces probablemente quieras filtrarla. Asegúrese de guardar los registros completos para su revisión si fuera necesario, pero solo introduzca en su flujo de trabajo de monitoreo regular las cosas con las que realmente va a hacer algo cuando aparezca. Si configura fail2ban para bloquear un host después de algunos intentos fallidos de conexión, es muy probable que no necesite revisarlos manualmente, y puede eliminarlos de sus notificaciones de monitoreo. Si un usuario legítimo se queja de la pérdida de acceso, simplemente extraiga los registros completos y eche un vistazo.

Resolví la misma pregunta hace algunos años. Decidí usar iptables con un módulo reciente debido al rendimiento y la fácil configuración. Tuve que proteger muchos contenedores virtuales en los hosts. Solo tenga en cuenta que no debe abrir ningún vector de DOS con sus reglas. También use ipset para hacer coincidir las listas de red o las listas de ip en las reglas. Lo uso para listas blancas. Todas las redes de un país en una lista son excelentes para un ajuste fino. Y es muy fácil proteger otro servicio con el mismo conjunto de reglas solo agregando un puerto más para que coincida. Por lo tanto, no me gusta cambiar con fail2ban, pero tal vez alguien con otras necesidades esté contento con fail2ban.

Aquí hay alguna muestra:

  #
  # SSH tracking sample
  #
  #################################################################################
  iptables -X IN_SSH
  iptables -N IN_SSH
  iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT
  # filter update
  iptables -A IN_SSH -m recent --name sshbf --set --rsource
  # connlimit
  iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4
  iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT
  # filter
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT
  iptables -A IN_SSH -j ACCEPT

iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH
# iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH

La salida de sus mensajes de registro podría combinarse con fail2ban. También puede usarlo para las reglas de ENTRADA.