Denyhosts vs fail2ban vs iptables: ¿la mejor manera de evitar inicios de sesión de fuerza bruta?

Estoy configurando un servidor LAMP y necesito evitar SSH / FTP / etc. intentos de inicio de sesión de fuerza bruta de éxito. He visto muchas recomendaciones tanto para denyhosts como fail2ban, pero pocas comparaciones de los dos. También leí que una regla de IPTables puede llenar la misma función.

¿Por qué elegiría uno de estos métodos sobre otro? ¿Cómo manejan este problema las personas en serverfault?

IIRC, DenyHosts solo vigilará su servicio SSH. Si también lo necesita para proteger otros servicios, Fail2ban es definitivamente una mejor opción. Es configurable para ver casi cualquier servicio si está dispuesto a modificar su configuración, pero eso no debería ser necesario ya que las versiones más recientes de Fail2ban incluyen conjuntos de reglas que son adecuados para muchos demonios de servidor populares. El uso de fail2ban sobre un límite de velocidad de iptables simple tiene la ventaja de bloquear completamente a un atacante durante un período de tiempo específico, en lugar de simplemente reducir la rapidez con la que puede dañar su servidor. He usado fail2ban con excelentes resultados en varios servidores de producción y nunca he visto uno de esos servidores violado por un ataque de fuerza bruta desde que comencé a usarlo.

¿Cuál es la mejor manera de evitar inicios de sesión de fuerza bruta?

¡No dejes que lleguen a tu máquina en primer lugar! Hay muchas maneras de detener los intentos de fuerza bruta antes de que lleguen a su host, o incluso a nivel SSH.

Dicho esto, proteger su sistema operativo con algo como fail2ban es una gran idea. Fail2ban es ligeramente diferente a DenyHosts, aunque juegan en el mismo espacio. Fail2ban usa iptables.

http://en.wikipedia.org/wiki/Fail2ban

Fail2ban es similar a DenyHosts ... pero a diferencia de DenyHosts que se enfoca en SSH, fail2ban se puede configurar para monitorear cualquier servicio que escriba intentos de inicio de sesión en un archivo de registro, y en lugar de usar /etc/hosts.deny solo para bloquear direcciones IP / hosts , fail2ban puede usar Netfilter / iptables y TCP Wrappers /etc/hosts.deny.

Hay varias técnicas de seguridad importantes que debe considerar para ayudar a prevenir inicios de sesión de fuerza bruta:

SSH:

• No permita que root inicie sesión
• No permita contraseñas ssh (use autenticación de clave privada)
• No escuches en todas las interfaces
• Cree una interfaz de red para SSH (por ejemplo, eth1), que sea diferente de la interfaz desde la que atiende las solicitudes (por ejemplo, eth0)
• No uses nombres de usuario comunes
• Use una lista de permisos y solo permita usuarios que requieran acceso SSH
• Si necesita acceso a Internet ... Restrinja el acceso a un conjunto finito de IP. Una IP estática es ideal, sin embargo, bloquearla a xx0.0 / 16 es mejor que 0.0.0.0/0
• Si es posible, encuentre una manera de conectarse sin acceso a Internet, de esa manera puede denegar todo el tráfico de Internet para SSH (por ejemplo, con AWS puede obtener una conexión directa que omita Internet, se llama Conexión directa)
• Use software como fail2ban para atrapar cualquier ataque de fuerza bruta
• Asegúrese de que el sistema operativo esté siempre actualizado, en particular los paquetes de seguridad y ssh

Solicitud:

• Asegúrese de que su aplicación esté siempre actualizada, en particular los paquetes de seguridad
• Bloquee las páginas de 'administrador' de su aplicación. Muchos de los consejos anteriores se aplican también al área de administración de su aplicación.
• Proteja con contraseña su área de administración, algo como htpasswd para consola web proyectará cualquier vulnerabilidad subyacente de la aplicación y creará una barrera adicional para la entrada
• Bloquee los permisos de archivo. Las "carpetas de carga" son conocidas por ser puntos de entrada de todo tipo de cosas desagradables.
• Considere colocar su aplicación detrás de una red privada y solo exponer su balanceador de carga frontal y un jumpbox (esta es una configuración típica en AWS usando VPC)

Uso las reglas de iptables para limitar las nuevas conexiones desde la misma dirección IP (principalmente SSH, pero también funcionaría bien para FTP). La ventaja, según lo veo, sobre "fail2ban" y otras herramientas similares es que la ruta de iptables ocurre totalmente en modo kernel y no depende de ninguna herramienta de modo de usuario para seguir / analizar archivos de registro.

Cientos de inicios de sesión ssh fallidos

Si puede hacerlo, limitar las direcciones de origen que pueden acceder a los protocolos en cuestión, obviamente, también ayudará.

Con SSH, realmente debería usar la autenticación de certificado y no aceptar contraseñas de todos modos.

OTRA GRAN MANERA DE PROTEGER SSH (lo he usado durante una década o más) es usar las bibliotecas recientes en iptables de forma nativa (dependiendo de su distribución).
Básicamente, se puede usar como puerto que está integrado en iptables. Esto te ahorrará muchos dolores de cabeza. Siempre que pueda tcp connect (telnet es unidireccional. También he usado clientes ssh y los apunté al puerto. Cualquier cosa que haga una conexión tcp a un número de puerto específico. ¡Te estoy mirando Putty!) Desde cliente iniciando la conexión ssh puede usar esto.

A continuación se muestra un ejemplo que hará que iptables abra el puerto 22 a su host cuando realice un telnet desde su host al servidor en el puerto 4103. Luego puede usar un telnet al puerto 4102 o 4104 para cerrar la apertura de sed. La razón para 4102 y 4104 es evitar que un simple escaneo tcp se abra 22. Solo una conexión tcp (telnet) al puerto 4103 le permitirá ingresar.

¡Disfrutar!

Ah, y estoy a favor de Fail2Ban. Más flexibilidad y me gusta que la prohibición ocurra en iptables en lugar de tcpwrappers.

SSH PORTKNOCKING

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP

Otra diferencia entre Fail2ban y Denyhosts es que Denyhosts puede compartir la lista de bloqueo con otros usuarios de Denyhosts. Con Fail2ban, solo puede bloquear las direcciones IP que su servidor ha visto antes; con Denyhosts, un intento de fuerza bruta nunca puede llegar a su servidor, si alguien más lo ha visto, y la lista de bloqueo se descarga a su servidor antes que el atacante llega a tu computadora.

Otra diferencia es que Fail2ban usa iptables, mientras que Denyhosts usa tcpwrappers. Otros han mencionado esta diferencia antes, pero hay un par de notas al margen que vale la pena mencionar.

iptables está limitado en cuántas direcciones IP puede bloquear de manera eficiente. Esa es probablemente una de las razones por las que Fail2ban no tiene un mecanismo para compartir listas de bloqueo.

Otro efecto es que cuando iptables se reemplaza por nftables, Fail2ban probablemente dejará de funcionar o debe reescribirse. Denyhosts probablemente continuará trabajando.

Por lo tanto, ambos tienen ventajas y desventajas. Me gustan ambos; para mí, estoy usando Denyhosts porque generalmente solo quiero proteger SSH, y me gusta compartir la lista de bloqueo.

Una cosa a tener en cuenta sobre Fail2Ban es que parece usar aproximadamente 10 MB más de memoria que DenyHosts. Entonces, si está en un VPS de 128 MB, es posible que desee investigar eso. Además, el fail2ban listo para usar solo se configura en SSH, lo que significa que sin cambios en la configuración, DenyHosts hace lo mismo en menos memoria.

denyhosts es para ssh. fail2ban es más completo (HTTP, FTP, etc.). Ambos usan iptables detrás de escena.

En lugar de jugar con tediosas iptables o fail2ban config, ¿por qué no hacer que la comunidad abierta haga todo el trabajo por usted y utilice CSF / LFD en su lugar? Puedo recomendarlo sobre todas las otras opciones mencionadas. Consulte http://configserver.com/cp/csf.html para saber qué puede hacer por sus servidores. CSF no requiere un panel de control, ofrece una interfaz de usuario simple, para aquellos que no quieren hacerlo por shell. Y es una gran cantidad de scripts de perl no residentes confiables y estables.

fail2ban no parece tener un mecanismo para reconocer un inicio de sesión ssh exitoso y restablecer su conteo de fallas.

El filtro estándar para sshd (al menos en mi instalación de Debian) registra un conteo de fallas para cada clave ssh que el cliente presenta y que el servidor rechaza. Algunos usuarios presentan muchas claves en cada inicio de sesión y se bloquean regularmente, a pesar de que sus inicios de sesión han sido exitosos una vez que se han ingresado algunas claves.

Como resultado de lo anterior, actualmente estoy pensando en alejarme de fail2ban. Al menos a este respecto, denyhosts es mejor. Sin embargo, aparentemente ya no es una buena opción, y ya no se admite en versiones más recientes de debian (alguna discusión en https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with-fail2ban-for- debian / )

No tengo una buena solución aquí.

En realidad, creo que denyHost puede evitar muchos otros servicios además del servicio sshd. En su archivo de configuración /etc/denyhosts.conf, hay algunas líneas de código que se dicen:

# BLOCK_SERVICE: the service name that should be blocked in HOSTS_DENY
#
# man 5 hosts_access for details
#
# eg.   sshd: 127.0.0.1  # will block sshd logins from 127.0.0.1
#
# To block all services for the offending host:  
BLOCK_SERVICE = ALL
# To block only sshd:
# BLOCK_SERVICE  = sshd

así que si configuramos la BLOCK_SERVICEvariable ALLcomo la anterior, podemos ver nuestro servicio ssh.

Denyhosts versión 3.0: cada vez que aparece una dirección IP en un archivo de registro, Denyhosts abre el archivo hosts.deny y lee todo para que coincida con la dirección. Cada vez. Nada se almacena en la memoria caché. Si tiene un gran archivo hosts.deny y está sujeto a muchas pruebas (muchas entradas de archivos de registro), Denyhosts se convierte en un lector de CPU que lee y vuelve a leer el archivo hosts.deny para cada dirección IP que aparece. No está bien.

Si habilita el soporte de iptables, Denyhosts creará listas enormes y lentas de direcciones IP bloqueadas. Denyhosts no usa ipset o nftables para crear mapas IP eficientes.