Solución:
Solución 1:
IIRC, DenyHosts solo observará 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 nuevas 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 martillar 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.
Solucion 2:
¿Cuál es la mejor forma de evitar los inicios de sesión por fuerza bruta?
¡No dejes que lleguen a tu máquina en primer lugar! Hay muchas formas de detener los intentos de fuerza bruta antes de que lleguen a su host, o incluso a nivel SSH.
Habiendo dicho eso, 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 utiliza 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 una serie de técnicas de seguridad importantes que debe considerar para ayudar a evitar los inicios de sesión por 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 es diferente a la interfaz desde la que atiende las solicitudes (por ejemplo, eth0)
- No use nombres de usuario comunes
- Use una lista de permitidos y solo permita a los usuarios que requieran acceso SSH
- Si necesita acceso a Internet … Restrinja el acceso a un conjunto finito de direcciones IP. Una IP estática es ideal, sin embargo, bloquearla en 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 elude Internet, se llama Direct Connect)
- Utilice software como fail2ban para detectar 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
- Bloquea las páginas de “administración” de tu aplicación. Muchos de los consejos anteriores también se aplican 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 de entrada adicional.
- Bloquea los permisos de los archivos. 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 de front-end y un jumpbox (esta es una configuración típica en AWS que usa VPC)
Solución 3:
OTRA GRAN FORMA DE PROTEGER SSH (He usado esto 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 golpe de puerto que está integrado en iptables. Esto le evitará muchos dolores de cabeza. Siempre que pueda conectarse tcp (telnet es una forma. También he usado clientes ssh y los he apuntado al puerto. Cualquier cosa que haga una conexión tcp a un número de puerto específico. ¡Te estoy mirando Putty!) Desde el 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 haga telnet desde su host al servidor en el puerto 4103. Luego, puede usar un telnet al puerto 4102 o 4104 para cerrar la apertura sed. La razón para 4102 y 4104 es evitar que un simple escaneo tcp abra 22. Solo un tcp connect (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.
PORTKNOCKING SSH
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
Solución 4:
Utilizo las reglas de iptables para limitar la velocidad de las nuevas conexiones desde la misma dirección IP (SSH principalmente, pero también funcionaría bien para FTP). La ventaja, como yo 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 analizar / 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 autenticación de certificado y no aceptar contraseñas de todos modos.
Solución 5:
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 haya visto antes; con Denyhosts, un intento de fuerza bruta puede que nunca llegue a su servidor, si alguien más lo ha visto, y la lista de bloqueo se descarga en su servidor antes que el atacante. llega a su computadora.
Otra diferencia más 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 la cantidad de direcciones IP que 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 con nftables, Fail2ban probablemente dejará de funcionar o necesitará ser reescrito. Es probable que Denyhosts continúe funcionando.
Entonces, ambos tienen ventajas e inconvenientes. Me gustan ambos; para mí, estoy usando Denyhosts porque normalmente solo quiero proteger SSH y me gusta compartir la lista de bloqueo.