Pregunta ¿Es normal obtener cientos de intentos de robo por día?


Acabo de comprobar mi servidor /var/log/auth.log ¡y descubrí que recibo más de 500 notificaciones fallidas de intento de ingreso / contraseña por día! Mi sitio es pequeño, y su URL es oscura. ¿Esto es normal? ¿Debo tomar alguna medida?


196
2018-03-08 11:26


origen


Hasta que bloqueamos todos los puertos externos innecesarios, recuerdo que no solo tuvimos muchos intentos de piratear, sino que un día fue tan malo que nos estaban hackeando desde dos países diferentes, ¡al mismo tiempo! Así que sí, 100s de intentos de robo es perfectamente normal. - Django Reinhardt
Tenemos servidores que experimentan una nueva "secuencia" de ataques una vez cada 16 segundos. Una secuencia única suele ser un lote de alrededor de 100 intentos en varios puertos. Sólo por un día, encendí un servidor sin parches fuera de nuestro firewall; Tardó menos de 10 minutos desde el momento en que se encendió para que se activara. El punto es que Internet es verdaderamente una jungla; tratar de no ser comido - NotMe
Puedo ver que publiqué mi pregunta en el sitio incorrecto: superuser.com/questions/200896/… - Justin C
aunque estoy de acuerdo con otros, esto es normal en los puertos comunes requeridos (80, 443). Prácticamente eliminé estos intentos contra mi puerto SSH simplemente cambiando el puerto predeterminado de 22 a algo oscuro como 6022, por ejemplo. Solo haciendo eso, solo, casi eliminamos el 99% de ese tipo de ataque. - Kilo
Si va a cambiar su puerto SSH, hay razones de seguridad para mantenerlo por debajo del puerto 1024 (solo la raíz puede abrir puertos <1024, por lo que lo protege de otros usuarios que secuestran SSH). - Brendan Long


Respuestas:


En internet de hoy esto es bastante normal por desgracia. Hay hordas de botnets que intentan iniciar sesión en cada servidor que encuentran en redes IP completas. Por lo general, usan ataques de diccionario simple en cuentas conocidas (como cuentas de root o de ciertas aplicaciones).

Los objetivos de ataque no se encuentran a través de las entradas de Google o DNS, pero los atacantes simplemente intentan cada dirección IP en una subred determinada (por ejemplo, de compañías de hospedaje de servidores raíz conocidos). Por lo tanto, no importa que su URL (por lo tanto, la entrada de DNS) sea bastante oscura.

Por eso es tan importante:

  • no permitir root-login en SSH (cómo)
  • use contraseñas seguras en todas partes (también en sus aplicaciones web)
  • para SSH, use la autenticación de clave pública si es posible y deshabilite la contraseña por completo (cómo)

Además, puede instalar fail2ban que escaneará el authlog y si encuentra una cierta cantidad de intentos fallidos de inicio de sesión desde una IP, procederá a agregar esa IP a /etc/hosts.deny o iptables / netfilter para bloquear al atacante durante unos minutos.

Además de los ataques SSH, también es cada vez más común analizar su servidor web en busca de aplicaciones web vulnerables (algunas aplicaciones de blogs, CMS, phpmyadmin, etc.). ¡Así que asegúrate de mantenerlos actualizados y configurados de forma segura también!


207
2018-03-08 11:35



Las aplicaciones como fail2ban pueden ayudar mucho a evitar que esos bots lleguen a tu servidor a la hora de la mañana :-) Tengo el mío configurado para prohibir 3 intentos incorrectos durante 24 horas. - emtunc
Y mueva el puerto de ssh de 22 a 222. Eso funciona bastante bien. - Tom O'Connor
+1, solo autenticación de clave pública :) - 0xC0000022L
@STATUS_ACCESS_DENIED: las acciones fail2ban son solo listas de comandos de shell para ejecutar. Así que es realmente flexible y fácil de hacer funcionar correctamente con cualquier configuración personalizada. La mejor referencia es descargarlo y verlo. action.d/iptables.conf. - mattdm
Bloquear a los atacantes como esto es una pérdida de tiempo. Si deshabilita el inicio de sesión de root, es muy probable que nadie adivine su nombre de inicio de sesión correcto, y mucho menos la contraseña. SSH ya tiene solicitudes de contraseña con límite de velocidad, por lo que incluso si saben su nombre de usuario (los robots aleatorios no lo harán), si tiene una contraseña decente, nunca lo adivinarán. - Brendan Long


Unos pocos 100 están bien ... El mes pasado encontré que uno de mis servidores tuvo 40k intentos fallidos. Me tomé la molestia de trazarlos: Mapa

Una vez que cambié el puerto ssh e implementé Port Knocking, el número bajó a 0 :-)


58
2018-03-08 11:36



Buen mapa Me encantaría saber cómo hacer esto! - jftuga
@jftuga Primero obtuve todas las IP de los registros. grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(elimine el | uniq al final si desea permitir duplicados). Luego, puede colocarlos en un CSV y subirlos a zeemaps.com. He visto mejores mapas que los míos, donde usarían el recuento para colorear el mapa (de verde a rojo para el número de intentos por condado), pero no me he dado cuenta de eso. - Bart De Vos
¿Qué quiere decir con 'Port Knocking implementado'? ¿Hay alguna aplicación que pueda instalar a través de apt-get para hacer esto? El número bajando a 0 suena bien
La seguridad a través de la oscuridad recibe una mala envoltura. Está perfectamente bien mientras sea parte de la estrategia general en lugar de toda la estrategia. Después de todo, ¿qué otra cosa es una contraseña que no sea una cadena oscura? - Joel Coel
@Joel Coel, es un secreto cadena, a diferencia de la mayoría de la seguridad a través de problemas de oscuridad - un proceso oscuro, pero no necesariamente secreto. - tobyodavies


Por mi parte, uso un "tarpit" además de permitir solo la autenticación de clave pública y deshabilitar los inicios de sesión de raíz.

En netfilter hay un recent módulo, que puede utilizar con (INPUT cadena):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Lo que eso hace es que cada intento de conectarse al puerto 22 está listado por el recent módulo con IP y algunas otras cosas bajo el nombre "tarpit" (si tiene curiosidad, mire /proc/net/xt_recent/tarpit). Obviamente puedes usar otros nombres.

Para listar o eliminar el uso de IPs:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Esta velocidad limita los intentos a 5 en 300 segundos. Tenga en cuenta que a los usuarios con una conexión existente no les molesta ese límite, porque ya tienen una conexión establecida y pueden crear más (incluso por encima del límite de velocidad).

Ajuste las reglas a su gusto, pero asegúrese de que se agreguen en ese orden (es decir, cuando las agregue, úselas en este orden, cuando las inserte en el orden inverso).

Esto reduce el ruido inmensamente. También proporciona seguridad real (contra el uso de fuerza bruta) a diferencia de la seguridad percibida de cambiar el puerto. Sin embargo, todavía recomendaría cambiar el puerto si es posible en su entorno. También reducirá mucho el nivel de ruido ...

Aún puedes combinar esto con fail2ban, aunque he estado funcionando bien sin él y solo con las reglas anteriores.

EDITAR:

Es posible bloquear su auto haciendo esto, por lo que puede agregar algo como lo siguiente que le permite eliminar su prohibición al golpear en un puerto en particular:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

29
2018-03-08 14:24



Uso esto y logro bloquearme de vez en cuando, por lo que me gustaría configurar otro puerto para que pueda "golpear" y eliminar su prohibición. - benlumley
@benlumley: buen punto. La detonación de puertos puede ser igualmente útil para cambiar el puerto predeterminado, o incluso ambos combinados ... - 0xC0000022L
@benlumley: vio tu comentario (ahora eliminado por Sam). No me importa si la respuesta se edita / mejora;) - 0xC0000022L


Usted podría implementar fail2ban, o métodos similares como bloquear SSH a su IP. Lamentablemente, los bots intentan acceder a la fuerza bruta todo el tiempo, por lo que es bastante normal, debes asegurarte de tener una buena contraseña.


15
2018-03-08 11:32



Si está utilizando SSH, considere la autenticación de clave pública. Esto es un poco más seguro que la autenticación de contraseña. - Piskvor


. Es bastante normal hoy en día.

Utilice solo la autenticación de clave pública para fines administrativos si es posible. Genera una clave privada en tu estación de trabajo:

$ ssh-keygen -t dsa

Copypaste los contenidos de ~ / .ssh / id_dsa.pub a ustedes servidores ~ / .ssh / authorized_keys (y /root/.ssh/authorized_keys, si necesita un inicio de sesión directo).

Configure sus servidores / etc / ssh / sshd_config Para aceptar solo la autenticación de clave pública:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Si tienes demasiados servidores, puedes usar Marioneta Para ejecutar claves públicas y configuraciones para ellos.

Examinar Denyhosts y fail2ban para bloquear repetidos intentos de inicio de sesión SSH y ver Bufido Si necesita IDS / IPS completos.


12
2018-03-09 23:32



No recomendaría el uso de la autenticación de clave pública en SSH para el acceso de shell a su servidor. Si su estación de trabajo está comprometida o, aún peor, es robada, entonces alguien ahora tiene acceso abierto a sus servidores sin la necesidad de una contraseña. La autenticación de clave pública es más para situaciones en las que necesita algo como un script o programa para poder tener acceso SSH a otro sistema sin necesidad de una contraseña, por lo que no tiene que insertar contraseñas de texto sin formato en su script / programa. - Registered User
@Deleted Account: puede establecer una frase de contraseña para la clave privada SSH. - Phil Cohen
El comentario del "Usuario registrado" está mal dirigido. Solo para aclarar: siempre establezca una buena contraseña en su clave privada, y no almacene la clave privada en ningún servidor. Mantenga la clave privada en su propia estación de trabajo. Una vez que agregue la clave a un programa ssh-agent e ingrese su contraseña, puede iniciar sesión en cada sistema que tenga instalada la clave pública, sin tener que volver a ingresar su contraseña. Habilite el reenvío de agentes en su cliente ssh para que pueda iniciar sesión de servidor a servidor. Robar su clave privada es malo, pero con una contraseña decente no es tan malo como una contraseña robada. - Martijn Heemels
Correcto, ni siquiera pienses en almacenar las claves privadas de los administradores sin cifrar. - yarek


utilizar http://denyhosts.sourceforge.net/

y sí, debe usar la autenticación de clave pública y deshabilitar la autenticación de contraseña.


8
2018-03-09 09:37



Deshabilitar la autenticación con contraseña no siempre es una solución viable. - Publiccert


Los intentos son mecanizados, por lo que los números parecen estar bien (sí, son altos en comparación con algunos sitios y bajos en comparación con otros). Debería seguir los pasos que normalmente debe: considera sus sitios como objetivos de ataque todos los días, incluso cuando no detecta un ataque; No detectar un ataque, no significa que no exista..


6
2018-03-08 11:33