¿Prevenir ataques de fuerza bruta contra ssh?


49

¿Qué herramienta o técnica utiliza para evitar ataques de fuerza bruta contra su puerto ssh? Noté en mis registros de Seguridad, que tengo millones de intentos para iniciar sesión como varios usuarios a través de ssh.

Esto está en un cuadro de FreeBSD, pero imagino que sería aplicable en cualquier lugar.

Respuestas:


25

Aquí hay una buena publicación sobre ese tema de Rainer Wichmann.

Explica los pros y los contras de estos métodos para hacerlo:

  • Contraseñas seguras
  • Autenticación RSA
  • Usando 'iptables' para bloquear el ataque
  • Usando el registro sshd para bloquear ataques
  • Usando tcp_wrappers para bloquear ataques
  • Golpe de puerto

39

Utilizo fail2ban que bloqueará una IP después de varios intentos fallidos durante un período de tiempo configurable.

Combine esto con la prueba de seguridad de la contraseña (con John (John the Ripper)) para garantizar que los ataques de fuerza bruta no tengan éxito.


44
Fail2ban es excelente. Fue sencillo extenderlo para monitorear / var / log / maillog y evitar que los spammers persistentes golpeen mi servidor de correo
Dave Cheney,

Fail2ban se puede combinar con una cadena de iptables que envía tráfico tcp al TARPITdestino, si se siente desagradable (de xtables-addons).
Tobu



15

Una de las formas más fáciles de evitar estos ataques es cambiar el puerto en el que sshd escucha


1
Si, por supuesto, su sistema puede soportarlo.
C. Ross

13
Seguridad a través de la oscuridad, efectiva cada vez.
Chris Ballance

1
No me importaría cambiar mucho el puerto, pero he aprendido que la mayoría de los firewalls (aparte del mío) tienden a bloquear todos los puertos que no sean los comunes (80,22, 443, etc.). Si estoy detrás de esos firewalls, no puedo acceder a mi servidor doméstico en ese puerto no estándar. Para mí eso es un no ir.
duelo

@grieve luego cambia nuestro firewall para dejar salir ese puerto?
Rory el

@ Roy Estoy hablando de firewalls distintos de los que tengo. Por ejemplo, si quiero ingresar a mi máquina doméstica desde Starbucks, su firewall bloquea el puerto de salida. No puedo cambiar eso. (Acabo de usar Starbucks como ejemplo. No tengo idea de qué puertos bloquean o no).
llorar

12

Como señala Chris, use claves de cifrado en lugar de contraseñas.

Añadir a eso:

  • use una lista blanca cuando sea posible.

¿Cuántas personas o ubicaciones (con IP públicas flotantes) realmente necesita para acceder a sus conexiones ssh públicas?

Dependiendo de la cantidad de hosts ssh públicos que esté manteniendo y si puede reducir sus criterios de conexión generales, puede ser una configuración más simple y mantenible para limitar el acceso a unos pocos hosts externos.

Si esto funciona para usted, realmente puede simplificar sus gastos generales de administración.


2
La lista blanca es muy importante si está haciendo algún tipo de lista negra a menos que quiera quedar bloqueado.
Ryaner

2
+1 para la lista blanca proactiva.
Chris Ballance

3
+1 por tener la mejor respuesta absoluta. Esas dos cosas son los únicos pasos razonables, y de hecho son muy efectivas. Cualquiera de los dos vale la pena, y ambos juntos más. Boo en las otras respuestas abogando por la seguridad a través de la oscuridad!
dwc

11

Además de las otras buenas sugerencias, una cosa realmente fácil de hacer es limitar la velocidad de las conexiones entrantes. Límite de 3 conexiones por minuto por IP:

iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Podría estar malinterpretando algo, pero muchos navegadores convencionales se conectan entre 4-6 conexiones a la vez, a pesar de que el estándar HTTP lo establece en 2.
Joshua Enfield

1
Sí, eso sería un problema si intentara limitar el puerto 80 de velocidad. No se está conectando a ssh con su navegador web, y las sesiones ssh son sesiones de larga duración que mantienen el estado, no sesiones sin estado de corta duración como http. Paralelizar sesiones ssh como esa no tiene sentido. Eso no quiere decir que no haya algún uso nicho de ssh que pueda romperse, pero es raro.
Sherbang

Esta solución no es tan buena si, como yo, está sirviendo Subversion a través de ssh. Una sola consulta SVN puede hacer una gran cantidad de conexiones en rápida sucesión. Si proporciona ese servicio, puede usar un segundo servicio sshd en otro puerto o incluir en la lista blanca las direcciones IP conocidas. Estoy pensando en usar fail2ban o sshdfilter para detectar ataques obvios la primera vez, sin castigar a mis usuarios legítimos.
arroz

es bueno saber esta opción también ...
ZEE

6

Use la opción "AllowUsers" en sshd_config para asegurarse de que solo un pequeño grupo de usuarios pueda iniciar sesión. Todos los demás serán rechazados, incluso si su nombre de usuario y contraseña son correctos.

Incluso puede restringir a los usuarios a inicios de sesión desde un host particular.

p.ej,

AllowUsers user1 user2@host.example.com

Esto reducirá el espacio de búsqueda y evitará aquellos usuarios antiguos que accidentalmente se quedaron acostados o habilitados (aunque, por supuesto, estos deberían deshabilitarse de todos modos, esta es una manera fácil de evitar que se usen para una entrada basada en SSH).

Esto no detiene por completo los ataques de fuerza bruta, pero ayuda a reducir el riesgo.


3

Use algo así con PF:

la tabla <ssh-brute> persiste el
bloque en el registro rápido desde la etiqueta ssh_brute
pasa en $ ext_if proto tcp a ($ ext_if) puerto ssh modulate state \
(max-src-conn-rate 3/10, overload flush global)


2

La anulación de puertos es una forma bastante sólida de evitar este tipo de cosas. Ligeramente complicado, a veces molesto, pero definitivamente hace que el problema desaparezca.


He intentado esto y los usuarios lo encuentran molesto. Si solo se trata de una o dos personas, esta podría ser una buena opción, y casi eliminaría los ataques de fuerza bruta
Brent

2

El contexto es importante, pero recomendaría algo así:

  • Como está usando FreeBSD, considere ejecutar el firewall PF y usar sus sólidas funciones de limitación de velocidad de conexión. Esto le permitirá enviar a los fuerza brutas a una lista negra si se conectan con frecuencia.
  • Si se debe acceder a este cuadro desde el mundo exterior, considere utilizar una regla PF rdr para no permitir el tráfico al puerto 22, sino para redirigir algún puerto oscuro hacia él. Es decir, debe conectarse al puerto 9122 en lugar de 22. Es oscuro, pero mantiene alejados a los llamadores.
  • considere la posibilidad de pasar a la autenticación basada en claves solamente, lo que hace que los ataques de diccionario sean inútiles

2

Además de la sugerencia de limitación de velocidad de Sherbang , la duración de la demora es importante. Al aumentar el retraso entre grupos de 3 intentos de inicio de sesión de 2 minutos a 20 minutos, la cantidad de direcciones IP diferentes que hicieron más de tres intentos de inicio de sesión disminuyó, comparando dos períodos de una semana en una máquina mía, de 44 intentos a 3 Ninguna de esas tres direcciones siguió intentándose durante más de 11 horas.

Muy anecdótico, pero auth.log se volvió mucho más legible para mí ...


1

Simplemente no me importa. Déjelos alejarse en el puerto, no van a forzar una llave con fuerza bruta.


-1 ¿Has oído hablar de ataques DoS?
Chris Ballance

8
Sí, porque SSH es el único servicio susceptible a los ataques de fuerza bruta. Si tiene un puerto abierto a Internet, puede usarlo para dejar su máquina en el olvido. Probablemente también
hayas

1

instalar OSSEC. no solo supervisa los inicios de sesión repetidos, sino que ingresará un bloque temporal con iptables para la ip infractora. Y al final le enviará un informe indicando los detalles. registra todo, lo cual es bueno. Somone intentó una vez más de 8000 nombres de inicio de sesión para iniciar sesión. analicé los registros y obtuve una buena lista de usuarios fuera del trato;)

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.