¿Cómo responder a un ataque de fuerza bruta SSH en un solo VPS?

Navega tus respuestas
26

Ingresé a mi VPS esta mañana para encontrar millones de intentos de inicio de sesión fallidos para el usuario root y otros usuarios que ni siquiera existen. Tomé las siguientes medidas para intentar ofuscar los esfuerzos de los atacantes que (han estado ocurriendo durante meses).

Preguntas (s)

  1. ¿Es esta una respuesta apropiada?
  2. ¿Qué más se puede hacer?
  3. ¿Hay algo valioso que pueda hacer con una lista de estas IPs?

Información del sistema para un Centos7 vps 

uname -a
inux vm01 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

paso 1

Creó un script para capturar todas las direcciones IP que no pudieron iniciar sesión desde el registro seguro. ( /var/log/secure ) 

# get_ips.sh
grep "Failed password for" /var/log/secure \
| grep -Po "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" \
| sort \
| uniq -c

paso 2

Escriba un script para crear reglas de firewall para bloquear la dirección IP que se encuentra en el script en el paso 1. Este script es ip_list_to_rules.sh 

#!/bin/bash
# ip_list_to_rules.sh
# script to parse output of get_ips.sh and create firewall rules
# to block ssh requests

if [ -z $1 ]; then
  echo "arg1 must be path to a list of the form <COUNT> <IP>\n"
  exit
fi

LIST=$(readlink -f $1)
SSH_IP=$(echo $SSH_CLIENT | head -n1 | awk '{print $1;}')

echo "Reading IPs from ${LIST}"
echo "SSH Client IP will be ignored (${SSH_IP})"

while read COUNT IP; do

  echo "Creating rule for ${IP}"
  firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -m tcp --source $IP -p tcp --dport 22 -j REJECT
  firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -m tcp --source $IP/24 -p tcp --dport 22 -j REJECT

done<<<"$(cat ${LIST} | grep -v ${SSH_IP})"

paso 3

Ejecutalo todo y guarda las reglas. 

./get_ips.sh > attack_ips.list
./ip_list_to_rules.sh attack_ips.list
firewall-cmd --reload

Actualizar

A continuación se muestran las medidas que tomé de las respuestas.

  1. inicios de sesión de raíz deshabilitados
  2. puerto SSH modificado
  3. instalar & configurado fail2ban
  4. Deshabilitar la autenticación de contraseña & habilitar la clave pública de autenticación

No realicé 4 porque no me conecto a través de cliente de shell seguro / a> y AFAIK no hay soporte de clave pública.

    
pregunta Aage Torleif 01.01.2017 - 02:34
fuente

8 respuestas

54

Sí, este es un enfoque perfectamente razonable y común. Sin embargo, ha reinventado fail2ban . Probablemente desee cambiar a usar eso para no tener que depurar problemas con su script y puede utilizar los filtros existentes para ssh, apache y otros servicios comunes.

Desafortunadamente, no hay mucho que puedas hacer con estas IP. Puede intentar informar la actividad al contacto de abuso que aparece en la lista para su bloqueo de IP, pero realmente no vale la pena dedicarle tiempo a menos que haga algo más serio.

También debes hacer el endurecimiento estándar de ssh, como deshabilitar los inicios de sesión basados en contraseña y root a menos que los necesites absolutamente.

    
respondido por el Xiong Chiamiov 01.01.2017 - 03:05
fuente
23

La forma más efectiva de proteger el sistema SSH es iniciar sesión usando solo la clave privada ssh. Debe deshabilitar la autenticación de contraseña y deshabilitar el inicio de sesión directo de raíz. Después de eso, aún obtendrás muchos intentos de autenticación fallidos, pero no hay ninguna posibilidad de que el atacante de fuerza bruta tenga éxito.

Si desea mantener sus registros limpios después de esto, debe mover su puerto SSH a un número de puerto diferente.

    
respondido por el Lie Ryan 01.01.2017 - 09:04
fuente
6

Puede ser intimidante ver un millón de intentos de inicio de sesión fallidos, pero honestamente, el ancho de banda y el poder de procesamiento que estos intentos están usando ... es trivial.

Así que la verdadera pregunta es: ¿es seguro tu sistema?

  • ¿Deshabilitaste el inicio de sesión de root?
  • ¿Deshabilitó la autenticación de contraseña en favor de la clave de publicación?
  • ¿Cambió el puerto predeterminado del servicio sshd en su VPS?

todos estos cambios se pueden hacer en el archivo / etc / ssh / sshd_config (asegúrate de reiniciar sshd después de hacer los cambios)

Puede usar fail2ban, o alguna secuencia de comandos personalizada para bloquear estas IP en el firewall, pero la autenticación sshd por sí misma es lo suficientemente segura por sí misma ... agregar más complejidad no es necesariamente más seguro y probablemente lo hará accidentalmente bloquearse de la vps.

    
respondido por el CaffeineAddiction 01.01.2017 - 09:33
fuente
3

Como han mencionado otros. Fail2ban con reglas bastante duras (por ejemplo: 3 contraseña incorrecta o intento de inicio de sesión con un usuario inexistente) puede ser muy eficaz.

También sugeriría mover SSH a un puerto no estándar. Por supuesto, esto no ayuda en absoluto contra ningún tipo de ataque inteligente, pero elimina los escáneres automatizados más básicos de los que hay unos cuantos.

Si combinas esto con algo que detecta el escaneo de puertos y lo conectas con fail2ban, puedes incluso proteger una gran parte de los escáneres, redes de bots y otras basura.

    
respondido por el Zeta Two 01.01.2017 - 06:07
fuente
3

Puede establecer tablas de IP que no bloquearán todo su servidor, pero reduce los ataques de fuerza bruta hasta un punto en el que se vuelven ineficaces .

Restringir el acceso SSH por direcciones IP es el método más seguro. Cambiar el puerto SSH puede anular los escaneos de bots pero hace poco contra los ataques dirigidos.

En la terminal, escriba 

/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Esto bloqueará la nueva dirección IP si se conecta más de 3 veces por minuto . Las conexiones establecidas dan como resultado una autenticación exitosa. También puede registrar lo que se está haciendo aquí configurando una regla de registro 

/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j LOGDROP
    
respondido por el Tomáš Pánik 01.01.2017 - 21:28
fuente
1

Puede intentar instalar fail2ban o puede hacer cosas como deshabilitar el inicio de sesión directo en la raíz o cambiar el puerto ssh predeterminado

    
respondido por el Slim-Jay1 01.01.2017 - 05:34
fuente
1
  
  1. Deshabilitar la autenticación de contraseña & habilitar la clave pública de autenticación
    2.   

No realicé 4 porque normalmente me conecto a través de Chrome Secure   shell client y AFAIK no hay soporte de clave pública.

Utilizo el Chrome Secure Shell Client en mi Chromebook, y es compatible con la autenticación de clave pública. He deshabilitado la autenticación de contraseña en todos mis sistemas y no tengo problemas para acceder a ellos desde el Chromebook o desde mi teléfono usando Juice.

    
respondido por el danofsatx 02.01.2017 - 04:22
fuente
-3

Configure ssh para iniciar sesión a través de un puerto diferente.

    
respondido por el Danny Duval 01.01.2017 - 15:32
fuente

Lea otras preguntas en las etiquetas

Otro dominio está usando la dirección IP de nuestra aplicación web. ¿Cómo prevenirlo? [duplicar] ¿Por qué necesitamos HTTPS para contenido estático? Si podemos tener una suma de comprobación al final firmada por la clave privada, ¿eso no prueba la validez?