¿Consejos para hacer frente a una tasa sorprendentemente alta de fallos de inicio de sesión de sshd de "botnets"?

Question

Acabo de configurar 2 nuevos VPS Debian 12 a la vez.

Uno de ellos funcionó bien; con el otro, parecía tener conectividad intermitente. Incluso llegué a escribir la mitad de un ticket de soporte, pensando que debía ser un problema de conectividad en su centro de datos, pero luego investigué más profundamente y descubrí la función "MaxStartups" de sshd: una vez que se han realizado más de un cierto número de conexiones abierto pero aún no autenticado, sshd comenzará a desconectar intencionalmente más conexiones, lo cual es consistente con lo que estaba viendo.

En el VPS que funciona bien, los registros muestran un intento malicioso aproximadamente una vez cada dos minutos, que es lo que esperaba. En el problemático, parece estar alrededor de la una.cada segundoen promedio, por lo que con un LoginGraceTime predeterminado de 2 minutos, tiene mucho sentido por qué tenía dificultades para ingresar. Ya he reducido esto a 5 segundos, lo que prácticamente logra mantener bajo control la cantidad de conexiones abiertas. (Ambos VPS ya están configurados para aceptar solo autenticación de clave pública, por lo que de todos modos no hay forma de que un intento malicioso tenga éxito).

Me sorprende lo rápido que llegan los intentos contra el problemático. Parecen provenir de diferentes IP de origen, por lo que claramente se trata de una botnet y no de algo que pueda bloquear fácilmente. Fail2ban, por ejemplo, no haría nada aquí que yo sepa, ya que funciona completamente en la IP de origen.

Estoy planeando poner un servidor HTTP público en este VPS, por lo que también me preocupa que si ya es el objetivo de un ataque de botnet a través de SSH, mi servidor HTTP podría terminar en DDOS en el olvido incluso antes de comenzar. y/o atraer la atención de alguien o algo que busca vulnerabilidades para explotar. (El otro VPS, que solo ve un intento cada dos minutos, estoy planeando instalar un servidor de correo; ¡no estoy seguro de qué protocolo debería preocuparme más!)

• ¿Qué tasa de intentos maliciosos deboesperarpara ser dirigido a una dirección IPv4 elegida al azar?
• ¿Debo tomar alguna medida en respuesta a esto o simplemente tolerarlo?
  • Pregúntele a mi proveedor de VPS si puede cambiar la IP del servidor, ya que tal vez simplemente tuve mala suerte y este fue el objetivo de un DDOS contra otra persona al azar que desde entonces desasignó su IP y terminó asignándome a mí.
  • ¿Bloquear SSH desde cualquier lugar, excepto otro VPS mío al que pueda acceder, a pesar de eso, en última instancia, ejecutaré un servidor HTTP público en él de todos modos? (parece un poco inútil bloquear SSH cuando HTTP necesita estar abierto, y sería un inconveniente moderado para mí hacer esto)
  • ¿Simplemente silenciar los mensajes de registro por intentos fallidos? (suponiendo que haya opciones para hacer esto; aún no lo he comprobado)
  • ¿Existen paquetes de software de servidor SSH alternativos que pueda usar y que estén más optimizados para manejar una alta tasa de intentos maliciosos? Por ejemplo, sshd crea un nuevo proceso para cada nueva conexión antes de la autenticación, lo que parece una gran sobrecarga innecesaria: idealmente debería consumir la menor cantidad de recursos posible hasta que la autenticación se haya realizado correctamente.
  • ...¿cualquier otra sugerencia?

Answer 1

¿Qué tasa de intentos maliciosos debo esperar que se dirijan a una dirección IPv4 elegida al azar?

El ruido de fondo de Internet: escaneos rutinarios, automatizados y de red (en lugar de dirigidos específicamente a su dirección IPv4) de grandes partes de Internet en busca de hosts y servicios expuestos. Un flujo continuo de sondas, que fácilmente resulta en cientos de intentos de inicio de sesión/abuso por día solo en un sshd expuesto (aunque los números pueden oscilar entre docenas y (muchos) miles, con ciertos rangos de direcciones IP de proveedores siendo atacados más que otros) con fuentes que varían desde:

• proveedores diligentes (que pueden estar ejecutando escáneres de vulnerabilidad porque quieren advertir/desconectar a los clientes cuando operan sistemas inseguros/vulnerables/comprometidos)
• proyectos de investigación (como por ejemploshodan.ioy otros) y otras personas curiosas
• actores maliciosos (que pueden estar usando botnets para ejecutar sus sondas)
• etcétera etcétera.

¿Debo tomar alguna medida en respuesta a esto o simplemente tolerarlo?

En general: cuando expones un servidor y un servicio a Internet, debes esperar conexiones y, lo más importante, abusos (intentos) de todo Internet.

Si un servicio no está destinado a ser un servicio públicoentoncesNo debería estar expuesto a todo Internet.
Cuando puedas: la mejor práctica es aplicar controles de acceso. Esto puede tomar varias formas, pero lo común es limitar el acceso a direcciones IP conocidas y/o rangos de direcciones IP conocidos. O, alternativamente, cuando no conozca exactamente los buenos rangos de direcciones IP, bloquee los rangos que probablemente nunca tengan un requisito de acceso válido.
Aunque vincular direcciones IP (rangos) a ubicaciones geográficas está lejos de ser 100% confiable ni completamente completo, las listas de acceso que utilizan datos Geo-IP pueden ser muy útiles en ese sentido.

Los controles de acceso se pueden configurar fuera del host, con, por ejemplo, grupos de seguridad o un dispositivo de firewall. Entonces el servidor no necesita proporcionar ningún recurso para mantenerlos.

A menudo son más flexibles, pero también requieren recursos del propio host, los controles de acceso basados ​​en host, como un firewall basado en host (en Linux netfilter/iptables/nftables) o controles de acceso en la propia aplicación. Por ejemplo, esta puede ser a menudo la única manera de establecer diferentes restricciones de direcciones IP para diferentes usuarios.

Cuando se pretende un serviciopara un servicio publico, como por ejemplo un servidor web con su sitio web público,normalmente no se aplican controles de acceso, porque los visitantes genuinos del sitio son bienvenidos desde todas partes.
A menudo se adopta el enfoque de estos servicios públicos: permitir el acceso desde cualquier lugar, perodetectar comportamientos maliciosos y (temporalmente) bloquear la dirección IP utilizada por los malos actores. una herramienta comofalla2banes uno de esos enfoques,Sistemas IDS e IPSotro.

_{Ejemplo:Una lista de control de acceso en la página de pedidos de comida para llevar y sistemas de reservas online para un restaurante local en, digamos, Ámsterdam, mi ciudad natal. No configuraría eso para permitir solo el acceso a direcciones IP desde Ámsterdam. Esto probablemente sería demasiado restrictivo y, por ejemplo, rechazaría a visitantes locales válidos que estuvieran utilizando sus teléfonos móviles para acceder al sitio.
Pero, por otro lado, bloquear rangos de direcciones IP que se sabe que están asignados y en uso fuera de Europa y que se utilizan, por ejemplo, en las regiones de África, Asia Pacífico, América del Norte y del Sur, debería reducir en gran medida el número de intentos de abuso y es poco probable. para impactar el número de reservas/pedidos para llevar.
Por el contrario, la lista de control de acceso para el acceso SSH en ese mismo servidor web puede limitarse fácilmente a las direcciones IP estáticas de los administradores del sitio, la puerta de enlace de su oficina y/o cuando no tienen una dirección IP estática o una Servidor VPN, a los rangos utilizados por sus ISP.}

¿Existen paquetes de software de servidor SSH alternativos que pueda usar y que estén más optimizados para manejar una alta tasa de intentos maliciosos? Por ejemplo, sshd crea un nuevo proceso para cada nueva conexión antes de la autenticación, lo que parece una gran sobrecarga innecesaria:

Creo y espero que esté sobreestimando en gran medida los requisitos de recursos reales y el impacto de esos intentos de inicio de sesión. En el esquema de las cosas, la carga que genera un nivel "normal" de intentos de abuso de ssh en los sistemas VPS expuestos que he visto es insignificante en comparación con las cargas de aplicaciones reales.

Parece un poco inútil desactivar SSH cuando HTTP necesita estar abierto

Un enfoque general de la seguridad es elPrincipio de privilegio mínimo; que en las reglas de firewall se traduce en:

• bloquear todo por defecto
• Sólo permitir el acceso a lo necesario a quienes lo necesitan.

Por lo tanto, no tiene sentido permitir el acceso ssh solo desde algunas direcciones IP y en lugar de desde todo el mundo y permitir que todo el mundo acceda a los puertos 80 (para redirigir directamente a https) y 443, el puerto https predeterminado.

Answer 2

Nunca antes había visto ataques de tipo slowloris en ssh. Al observar la documentación, a MaxStartups no parece importarle si son del mismo cliente (es decir, podría estar facilitando el DOS usando esto). Mi primera respuesta (dependiendo del patrón de los ataques) sería usar iptables connlimit (limitar conexiones por IP de cliente).

Fail2ban es la solución obvia para la mayoría de los ataques ssh (también lo he usado para el tráfico HTTP[S]), pero asegúrese de que esté configurado para usar ipset.

Es poco probable que cambiar la dirección IP ayude a largo plazo.

Bloquear SSH desde cualquier lugar excepto otro VPS mío al que pueda acceder

Sí, usar una caja de salto es una práctica bastante común. Nuevamente, esto es algo que puedes hacer tú mismo. Simplemente configure una regla de firewall predeterminada para el puerto 22 y luego incluya en la lista blanca sus jumpbox. Ssh incluso tiene una funcionalidad incorporada que hace que su uso sea transparente, por ejemplo

ssh -J [email protected] [email protected]

o puedes configurar esto en tu ssh_config y simplemente ssh targethost.example.com:

Host jumpbox.example.com
   User: jumpuser
   IdentityFile: ~/.ssh/jumpuser.id_rsa

Host targethost.example.com
   User: user
   ProxyCommand: ssh -q -W %h:%p [email protected]:22 
   IdentityFile: ~/.ssh/user.id_rsa

¿Simplemente silenciar los mensajes de registro por intentos fallidos?

Yo no defendería esto. No dude en ignorarlos si ha tomado medidas razonables para evitar el acceso no autorizado.

Como sugiere pepoluan, también puedes usar un puerto no estándar y un golpe de puerto (por cierto, este último puede serimplementado puramente en iptablessin tener que usar knockd)

Answer 3

Mis sugerencias:

1. Cambie el puerto SSH de 22 a otro.
2. Si los robots aún pueden encontrar su puerto, instale knockdy configure su servidor para implementar la activación de puertos.

Answer 4

Si expone SSH a través de una IP pública, tarde o temprano será escaneado y los actores de amenazas intentarán intentos de autenticación, sin importar el proveedor de VPS o la red.

Reforzaría tu configuración ssh usando un libro de jugadas ansible como este: https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/ssh_hardening

O este libro de jugadas, que fortalece todo el servidor: https://github.com/konstruktoid/ansible-role-hardening

---

Y también recomendaría fail2ban. Fail2Ban: prohíbe los hosts que causan múltiples errores de autenticación. Fail2Ban analiza archivos de registro como /var/log/auth.log y prohíbe las direcciones IP que realizan demasiados intentos fallidos de inicio de sesión. Para ello, actualiza las reglas del firewall del sistema para rechazar nuevas conexiones de esas direcciones IP, durante un período de tiempo configurable.

---

O tal vez pueda crear una conexión VPN a la red de su VPS/crear un servidor VPN en su VPS usando OpenVPN (por ejemplo) y poner SSH detrás de la VPN y no exponerlo a Internet.