☰

Reglas automáticas de IPTables sobre fuerza bruta

tag-icon • tag-icon linux ssh remote-access brute-force-attacks
Reglas automáticas de IPTables sobre fuerza bruta

Soy muy nuevo en la administración de redes, así que tenga en cuenta que todavía no tengo tanta experiencia.

Tengo un servidor raíz de Ubuntu con panel plesk.

Ayer mis amigos y yo notamos que la calidad de la voz en nuestro TS3 empeoró mucho. Envié algunos pings al servidor y hubo una pérdida de paquetes muy alta. Después de eso busqué en Google un poco y descubrí que hay un archivo auth.log. Lo descargué y busqué un poco, luego encontré esto:

May 13 10:01:27 rs204941 sshd[9351]: input_userauth_request: invalid user student [preauth]
May 13 10:01:27 rs204941 sshd[9351]: pam_unix(sshd:auth): check pass; user unknown
May 13 10:01:27 rs204941 sshd[9351]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.220.198.102 
May 13 10:01:29 rs204941 sshd[9351]: Failed password for invalid user student from 112.220.198.102 port 39806 ssh2
May 13 10:01:29 rs204941 sshd[9351]: Received disconnect from 112.220.198.102: 11: Bye Bye [preauth]
May 13 10:01:31 rs204941 sshd[9353]: Invalid user student from 112.220.198.102

Parece que alguien intentó iniciar sesión mediante SSH muchas veces. Me desplacé un poco y vi que alguien intenta usar muchos nombres de usuario diferentes:student, tech, psi, news,...

Cientos de estos inicios de sesión se mostraron en el archivo.

Busqué las estadísticas de tráfico en el sitio web de mi centro de datos. Era sólo de 17 MB por hora. Tengo una red troncal de 100 Mbit, por lo que la transferencia de datos en sí no parece ser el problema.

Por el momento no puedo acceder al servidor de ninguna manera.

Mi pregunta es: ¿cómo puedo obtener acceso nuevamente, cómo puedo suprimir este ataque y evitar los siguientes?

Respuesta1

¿Cómo acceder?

No está claro por qué no puede acceder a su cuenta.

Si su máquina está bajo ataque o tiene una carga alta, debe hablar con su proveedor sobre cómo restringir el acceso (Restricciones de IP) o desconectar el servidor (desconectarse de Internet).

También es posible que necesites acceso fuera de banda, con el que tu proveedor puede ayudarte.

Si alguien ha comprometido su servidor, es posible que deba restaurarlo a partir de copias de seguridad o utilizar una imagen de recuperación.

Cómo prevenir ataques a su servidor, en particular SSH

¿La mejor manera de evitar 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.

Dicho esto, proteger su sistema operativo con algo como fail2ban es una gran idea.http://en.wikipedia.org/wiki/Fail2ban

Fail2ban es similar a DenyHosts... pero a diferencia de DenyHosts que se centra 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 usted debe considerar para ayudar a prevenir inicios de sesión por fuerza bruta:

SSH:

  • No permitir 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 sea diferente a la interfaz desde la que atiende las solicitudes (por ejemplo, eth0)
  • No utilices nombres de usuario comunes
  • Utilice una lista de permitidos y permita solo a los usuarios que requieran acceso SSH
  • Si necesita acceso a Internet... Restrinja el acceso a un conjunto finito de 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 no pasa por Internet, se llama Conexión Directa)
  • Utilice software como fail2ban para detectar ataques 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.
  • Bloquee las páginas de 'administración' de su 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 la consola web proyectará cualquier vulnerabilidad subyacente de la aplicación y creará una barrera de entrada adicional.
  • Bloquee los permisos de archivos. Las 'carpetas de carga' son conocidas por ser puntos de entrada para todo tipo de cosas desagradables.
  • Considere colocar su aplicación detrás de una red privada y exponer solo su balanceador de carga front-end y un jumpbox (esta es una configuración típica en AWS que usa VPC).

Respuesta2

¿Cómo puedo reprimir este ataque y prevenir los siguientes ataques?

Normalmente cambio el puerto ssh predeterminado de 22 a otro como 1122. Esto evita muchos ataques automáticos de bot, pero un simple análisis de puerto puede detectarlo. De todos modos:

vi /etc/ssh/sshd_config

y editarPuerto 22aPuerto 1122, Pero esto no es suficiente.

Reglas automáticas de IPTables sobre fuerza bruta

yo suelolog2iptables https://github.com/theMiddleBlue/log2iptablesen lugar de Fail2ban, porque es un script Bash simple que analiza cualquier archivo de registro con una expresión regular y ejecuta iptables. Por ejemplo, cuando ocurren 5 coincidencias, log2iptables descarta la dirección IP específica. Es genial porque usa la API de Telegram y puede enviarme un mensaje a mi teléfono cuando encuentra un problema :)

¡Espero que esto ayude!

Respuesta3

Acabo de armar esto, ejecutarlo cada 15 minutos como un cronjob, etc.:

for z in `grep Invalid /var/log/auth.log | awk '{ print $NF }' | sort | uniq`
do
  count1=`grep $z /etc/hosts.deny | wc -l`
  count2=`grep Invalid /var/log/auth.log | grep $z | wc -l`
  if [ $count1 -eq 0 -a $count2 -gt 10 ] ; then
    current=`egrep "^ssh" /etc/hosts.deny | sed 's/sshd[ :,]*//'`
    sudo cp /etc/hosts.deny.bak /etc/hosts.deny
    sudo chmod 666 /etc/hosts.deny
    if [ $current ] ; then
      echo "sshd : $current , $z" >> /etc/hosts.deny
    else
      echo "sshd : $z" >> /etc/hosts.deny
    fi
    sudo chmod 644 /etc/hosts.deny
  fi
done

Respuesta4

Esta es mi solución alternativa para ataques SSH. La idea es seguir cerrando el demonio SSH si no se utiliza. Sin puerto abierto no hay ataque. Puedes probarlo. Es de código abierto https://github.com/indy99/nnet_port_guard

información relacionada