Mi servidor está siendo constantemente atacado [cerrado]

Soy bastante nuevo en el mundo de la administración de sistemas. He estado trabajando en una aplicación recientemente y cuando reviso los registros de mi servidor de aplicaciones, constantemente obtengo varias direcciones IP que intentan ingresar en mi servidor por fuerza bruta. Aquí hay un ejemplo del registro de mi servidor:

Feb 14 04:07:20 foodwiz3 sshd[1264]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:07:21 foodwiz3 sshd[1264]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:07:21 foodwiz3 sshd[1264]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:07:23 foodwiz3 sshd[1264]: Failed password for root from 23.249.167.223 port 32997 ssh2
Feb 14 04:07:23 foodwiz3 sshd[1264]: Received disconnect from 23.249.167.223: 11: Bye Bye [preauth]
Feb 14 04:13:04 foodwiz3 sshd[1289]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:13:05 foodwiz3 sshd[1289]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:13:05 foodwiz3 sshd[1289]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:13:07 foodwiz3 sshd[1289]: Failed password for root from 23.249.167.223 port 41562 ssh2

¿Es esto algo que es bastante normal, o debería estar preocupado / hacer algo al respecto?

Bienvenido al maravilloso mundo de Internet ... ¿Has:

• poner su servidor detrás de un firewall de hardware?
• activado el firewall del software ? (solo en caso de que el firewall HW falle)
• endurecido su servidor?
• instalado rkhunter antes de ponerlo en línea?
• activadas actualizaciones de seguridad diarias automáticas ?
• cambió el puerto predeterminado de ssh?
• ...

Pero la verdadera respuesta es: Sí, esto es normal : BotNet Maffia siempre puede usar algunos servidores extra mal protegidos ...

Es bastante normal tener pruebas de inicio de sesión suficientes para hacer un registro de inundación.

Cambiar los puertos SSH es más una solución de 'seguridad por oscuridad', pero ayuda con la inundación. Subrayo que no es muy elegante; hay puertos de facto para servicios por una razón.

Como debería estar activado de forma predeterminada, pero asegúrese de que no pueda SSH en su servidor como root. Es el nombre de usuario que es bastante consistente entre los servidores y, por lo tanto, el objetivo principal para los intentos de inicio de sesión de fuerza bruta de contraseña. Aplicar la configuración con la siguiente línea en sshd_config:

PermitRootLogin no

También busque en los fail2banmonitores que registran los registros sshd para delincuentes reincidentes. Por ejemplo, 5 inicios de sesión fallidos en 3 minutos desde una determinada IP obtendrían esa IP bloqueada durante 10 minutos. Aumenté ese tiempo de prohibición a 24 horas para reducir aún más el registro de spam, con éxito. :)

Te sugiero que hagas algunas cosas:

1. Cambie el puerto en el que escucha ssh (a algo muy superior a 1024) y asegúrese de no usar la versión 1 del protocolo:

/ etc / ssh / sshd_config

# What ports, IPs and protocols we listen for
Port 50022
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

2. Instal fail2ban: monitorea los archivos de registro y prohíbe de manera temporal o persistente las direcciones propensas a fallas al actualizar las reglas de firewall existentes ( iptables).

3. Asegúrese de incluir en la lista blanca sus ubicaciones de confianza.

Sí, preocúpate . Es posible que nunca se queme, pero debe seguir las mejores prácticas de TI. Más vale prevenir que curar.

Soy administrador de red en un hospital. Siempre es malo idea conectar una caja directamente a internet. Lo que está viendo son los miles de escáneres automáticos que buscan vulnerabilidades en Internet. Veo estos y todo tipo de cosas (escaneos de puertos, varias pruebas de vulnerabilidad conocidas) para todo tipo de software (ssh, telnet, ftp, etc.) que aparecen en nuestra caja de identificadores. Su máquina debe estar detrás de una solución de firewall / NAT y solo debe reenvíe los puertos requeridos a Internet (80, 443, etc.). Es relativamente fácil de hacer. Tener algo que pueda usar para la administración (SSH telnet) es una mala idea tener que enfrentarse a Internet porque si, por alguna razón, hay un error en el software SSH / telnet en ese servidor, el bot automatizado detectarlo en un abrir y cerrar de ojos y serás jodido. Los errores en el software ocurren todo el tiempo y puede tomar un tiempo para que se lance un parche o para que recuerdes parchearlo.

Si necesita administrar de forma remota, busque configurar algo como una solución VPN o si usa Windows, configure la puerta de enlace de servicios de terminal para el escritorio remoto. Sé que puede usar una caja separada de Linux o Windows con 2 NIC para configurar el enrutamiento y el acceso remoto para VPN y NAT si solo es una pequeña tienda. De lo contrario, los proveedores como Cisco tienen soluciones de firewall / NAT de hardware (Cisco ASA).

En resumen, coloque su máquina detrás de NAT. Solo el puerto reenvía los puertos necesarios para ejecutar el propósito del servicio. No transfiera los servicios utilizados para la administración a Internet, en su lugar, busque VPN para la administración remota.

PS Cambiar los puertos SSH puede ayudar con el volumen de registro, pero en realidad no impide el acceso a SSH. Cualquiera de los miles de buscadores de vulnerabilidades automatizados puede y hará escaneos de puertos para ver qué puertos están escuchando qué servicios. Puede hacerlo usted mismo con una herramienta llamada nmap .

Puede configurar el firewall interno del núcleo mediante iptables . Para que solo unas pocas máquinas puedan enviar ssh a su servidor y dejar caer otros paquetes IP. Ver man iptablespara más información.

Por ejemplo, si 192.168.1.67 es el host desde el que ssh, entonces en el tipo de servidor:

sudo iptables -A INPUT -p tcp --dport ssh -s 192.168.1.67 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport ssh -j DROP
sudo iptables-save

¿Realmente necesitas tu servidor en internet? Si realmente desea tenerlo en Internet, asegúrese de que sea seguro antes de ponerlo allí.

Cambiar el puerto es solo seguridad a través de la oscuridad. Si su atacante es más sofisticado que solo ejecutar scripts, no ayudará.

Algunas cosas ya mencionadas que recomiendo también:

1. Estoy de acuerdo con Fail2Ban, y configurado correctamente mantendrá a raya los scripts y los hackers más sofisticados.
2. Establecer PermitRootLogin en no es imprescindible.
3. Configurar un cortafuegos. Por lo general, simplemente edito las reglas de iptables, pero algo como UFW o firehol también funcionará.

Me acabo de unir a esta comunidad porque hay dos cosas que no creo que se hayan abordado adecuadamente.

• En la configuración del firewall, bloquee / desactive absolutamente todo lo que no sea completamente necesario. Antes de abrir cualquier puerto, pregúntese: "¿Realmente necesito este servicio de Internet?" Cada puerto / servicio que abra se convierte en otro vector potencial que alguien puede explotar. Si hay un error en ese servicio que les permite obtener acceso raíz al servidor, podrían acceder a todo lo que contenga. Su seguridad es tan fuerte como el eslabón más débil.
• Ahora para lo último y posiblemente lo más importante. Los scripts que ha visto intentando acceder a ssh podrían adivinar su contraseña con el tiempo. Fail2Ban los ralentizará mucho, pero aún podrían adivinarlo. Si lo hacen, desea autenticación de 2 factores en los servicios accesibles. Para eso recomiendo una cuenta gratuita con Duo Security. https://www.duosecurity.com/docs/duounix

Otro ejemplo de respuesta @cff, si tiene la intención de prohibir cualquier "intento" sucesivo en su servidor SSH:

sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j DROP
sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
sudo iptables-save

Éste 'etiqueta' los intentos de conexión y si ocurren más de 4 en 600s (10mn), entonces el origen está 'prohibido'. Use esto en lugar de la solución @cff porque es más seguro (si se bloquea, espere 10 minutos y vuelva a intentarlo).