¿Es normal obtener cientos de intentos de intrusión por día?

196

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

Kyle
fuente
2
Hasta que bloqueamos todos los puertos externos innecesarios, recuerdo que no solo tuvimos muchos intentos de pirateo, sino que un día fue tan malo que fuimos pirateados desde dos países diferentes, ¡al mismo tiempo! Entonces sí, cientos de intentos de robo son perfectamente normales.
Django Reinhardt
9191
Tenemos servidores que experimentan una nueva "secuencia" de ataque una vez cada 16 segundos. Una secuencia única suele ser un lote de alrededor de 100 intentos en varios puertos. Solo por diversión, un día encendí un servidor sin parche fuera de nuestro firewall; Se tardó menos de 10 minutos desde el momento en que se encendió para obtener pwnd. El punto es que Internet realmente es una jungla; trata de no ser comido.
NotMe
2
Puedo ver que publiqué mi pregunta en el sitio equivocado: superuser.com/questions/200896/…
Justin C
66
Si bien 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 hacer eso, solo, casi eliminó el 99% de ese tipo de ataque.
Kilo
2
Si va a cambiar su puerto SSH, existen 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:

207

En la Internet de hoy, esto es bastante normal, lamentablemente. Hay hordas de botnets que intentan iniciar sesión en cada servidor que encuentran en redes IP completas. Por lo general, utilizan ataques de diccionario simples en cuentas conocidas (como la raíz o ciertas cuentas de aplicaciones).

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

Por eso es tan importante:

  • no permitir el inicio de sesión raíz en SSH ( howto )
  • 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 autenticación de contraseña por completo ( cómo hacerlo )

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

Además de los ataques SSH, también se está volviendo común escanear su servidor web en busca de aplicaciones web vulnerables (algunas aplicaciones de blogs, CMS, phpmyadmin, etc.). ¡Así que asegúrese de mantenerlos actualizados y configurados de forma segura también!

Holger Just
fuente
21
Las aplicaciones como fail2ban pueden ayudar mucho a evitar 'temporalmente' que esos bots golpeen su servidor en momentos tontos por la mañana :-) Tengo el mío configurado para prohibir 3 intentos incorrectos durante 24 horas.
emtunc
46
Y mueva el puerto de ssh de 22 a 222. Eso funciona bastante bien.
Tom O'Connor
40
+1, solo autenticación de clave pública :)
0xC0000022L
3
@STATUS_ACCESS_DENIED: las acciones que fail2ban toma son solo listas de comandos de shell para ejecutar. Por lo tanto, es realmente flexible y fácil de hacer funcionar correctamente con cualquier configuración personalizada. La mejor referencia es descargarlo y mirarlo action.d/iptables.conf.
mattdm
44
Bloquear atacantes como este es una pérdida de tiempo. Si deshabilita el inicio de sesión de root, existe una buena posibilidad de que nadie adivine su nombre de inicio de sesión correcto, y mucho menos la contraseña. SSH en sí ya está solicitando una contraseña de limitación de velocidad, por lo que incluso si conocen su nombre de usuario (los bots aleatorios no lo sabrán), si tiene una contraseña decente, nunca lo adivinarán.
Brendan Long
58

Unos 100 está bien ... El mes pasado descubrí que uno de mis servidores tenía 40k intentos fallidos. Pasé por la molestia de trazarlos: Mapa

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

Bart De Vos
fuente
2
Buen mapa ¡Me encantaría saber cómo hacer esto!
jftuga
99
@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 ponerlos en un archivo CSV y subirlo a zeemaps.com. He visto mejores mapas que los míos, donde usarían el recuento para colorear el mapa (verde a rojo para la cantidad de intentos por condado), pero no lo he descubierto
Bart De Vos
3
¿Qué quiere decir con 'Knock de puerto implementado'? ¿Hay alguna aplicación que pueda instalar a través de apt-get para hacer esto? El número que cae a 0 suena bien
18
La seguridad a través de la oscuridad tiene una mala envoltura. Está perfectamente bien siempre que sea parte de la estrategia general en lugar de toda la estrategia. Después de todo, ¿qué más es una contraseña que no sea una cadena oscura?
Joel Coel
55
@ Joel Coel, es una cadena secreta , a diferencia de la mayoría de los problemas de seguridad a través de la oscuridad, un proceso oscuro, pero no necesariamente secreto.
tobyodavies
29

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

En netfilterhay un recentmódulo, que se puede utilizar con ( INPUTcadena):

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 recentmódulo con IP y algunas otras cosas bajo el nombre de "tarpit" (si tiene curiosidad, mire /proc/net/xt_recent/tarpit). Obviamente puedes usar otros nombres.

Para enumerar o eliminar IPs, use:

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

Esta tasa limita los intentos a 5 en 300 segundos. Tenga en cuenta que los usuarios con una conexión existente no se ven afectados por ese límite, porque ya tienen una conexión establecida y se les permite 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, al agregarlas, úselas en este orden, al insertarlas en el orden inverso).

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

Todavía puede combinar esto con fail2ban, aunque he estado funcionando bien sin él y solo con las reglas anteriores.

EDITAR:

Es posible bloquearse haciendo esto, por lo que puede agregar algo como lo siguiente que le permite borrar su prohibición tocando un puerto en particular:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove
0xC0000022L
fuente
2
Lo uso y logro bloquearme de vez en cuando, así que me gusta configurar otro puerto que pueda "golpear" para eliminar su prohibición.
benlumley
@benlumley: buen punto. La eliminación de puertos puede ser igualmente útil para cambiar el puerto predeterminado, o incluso ambos en combinación ...
0xC0000022L
@benlumley: vi tu comentario (ahora eliminado por Sam). No me importa si la respuesta se edita / mejora;)
0xC0000022L
15

Puede implementar fail2ban o métodos similares como bloquear SSH a su IP. Lamentablemente, los bots intentan forzar el acceso todo el tiempo, por lo que es bastante normal, debes asegurarte de tener una buena contraseña.

Jacob
fuente
3
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
12

. Es bastante normal hoy en día.

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

$ ssh-keygen -t dsa

Copie el contenido de ~ / .ssh / id_dsa.pub en sus servidores ~ / .ssh / Authorizedkeys (y /root/.ssh/authorized_keys, en caso de que requiera 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 tiene demasiados servidores, puede usar Puppet para ejecutar claves públicas y configuraciones para ellos.

Mire en Denyhosts y fail2ban para bloquear repetidos intentos de inicio de sesión SSH y vea Snort si necesita IDS / IPS completos.

jkj
fuente
2
No recomendaría usar la autenticación de clave pública en SSH para el acceso de shell a su servidor. Si su estación de trabajo se ve comprometida o, peor aún, robada, entonces alguien tiene acceso abierto a sus servidores sin 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 para que no tenga que incrustar contraseñas de texto sin formato en su script / programa.
Usuario registrado
55
@ Cuenta eliminada: puede establecer una frase de contraseña para la clave privada SSH.
Phil Cohen
2
El comentario del "Usuario registrado" está mal dirigido. Solo para aclarar: establezca siempre 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 todos los sistemas que tengan instalada la clave pública, sin tener que volver a ingresar su contraseña. Habilite el reenvío de agente en su cliente ssh para que pueda iniciar sesión de servidor a servidor. Hacer que te roben tu clave privada es malo, pero con una contraseña decente no es tan malo como una contraseña robada.
Martijn Heemels
Bien, ni se te ocurra almacenar las claves privadas del administrador sin cifrar.
yrk
8

use http://denyhosts.sourceforge.net/

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

número 5
fuente
Deshabilitar la autenticación de contraseña no siempre es una solución viable.
Concierto público el
6

Los intentos están 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). Debe seguir los pasos que normalmente debe seguir: 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 .

adamo
fuente
6

Yo diría que solo obtener 500 es un poco bajo.

En un empleador anterior, uno de los investigadores de seguridad informática calificó el flujo constante de intentos de intrusión como "el equivalente en Internet del ruido cósmico ". Lo describió como un flujo normal y continuo de tráfico malicioso que buscaba sistemas en Internet y explotaba automáticamente los scripts para intentar secuestrar el sistema. Las redes de bots y otros sistemas maliciosos explorarían y volverían a explorar constantemente Internet para detectar sistemas vulnerables como SETI.

James Schek
fuente
6

Si,

Esto es común, pero eso no significa que no debas pelear la buena batalla. Aquí hay algunos pasos sobre cómo puede hacer que su servidor sea más seguro.

Evite las direcciones IP asociadas a DNS

Puede reducir en gran medida este número en entornos compartidos o de colocación deshabilitando el acceso SSH en cualquier dirección IP asociada con los nombres de dominio. Las direcciones IP que no son de dominio y que no figuran en la lista recibirán menos de este tipo de tráfico, por lo tanto, compre una IP que no esté en la lista y solo use esta IP para acceso SSH.

Use una VPN para todo el acceso SSH

Si se encuentra en un entorno en el que puede implementar IPsec / VPN en una red privada dentro del entorno de su servidor, esto es ideal. Deshabilite todo el acceso a Internet SSH, asegúrese de tener una solución integrada de luces apagadas. Configure su VPN y solo permita el acceso SSH desde su VPN.

Implemente reglas de dirección IP para acceso SSH

Si la VLAN no es una opción, configure su enrutador o las reglas de firewall para permitir solo conexiones SSH desde un rango de direcciones IP conocido.

Si sigue estos pasos, dormirá mucho más fácilmente por la noche sabiendo que alguien tendría que comprometer la red de su empresa de alojamiento para obtener acceso al servidor a través de SSH.

Ben DeMott
fuente
5

Es bastante normal ver cientos de conexiones SSH fallidas.

Si tiene la opción, simplemente cambio mi puerto SSH a algo no estándar. No necesariamente hace que su servidor sea más seguro, pero sí limpia los registros (¡y le permite ver a cualquiera que intente entrar deliberadamente!)

Adrian Macneil
fuente
5

Además de utilizar un mecanismo de bloqueo automático como fail2ban, tiene una opción más: comunicarse con el ISP de la dirección de abuso del atacante. Puede parecer completamente inútil, pero en el caso del script kiddie, su ISP está más que dispuesto a tomar medidas al respecto.

Para encontrar la dirección de abuso, comience con arin.net y busque la dirección IP usando whois. Puede ser redirigido a otro registro regional, pero eventualmente puede encontrar el ISP responsable del bloqueo de IP que contiene la dirección. Busque la dirección de abuse @ o simplemente envíe un correo electrónico al contacto técnico.

Envíeles un mensaje cortés con las entradas relevantes del archivo de registro (asegúrese de eliminar cualquier información privada) y pídales que tomen medidas contra el host infractor.

JRW
fuente
44
Solíamos hacer esto. Sin embargo, la cantidad de tiempo invertido versus el beneficio recibido fue tan pequeño que no importa.
NotMe
1
Una variante de esta táctica que es más efectiva, pero mucho más riesgosa, es informar el ISP al nodo intermedio. Pero DEBE tener evidencia sólida en su informe. Una vez que hice esto, tuve a un ISP entero en serios problemas porque ignoraban sus informes de abuso.
staticsan
1
Una vez que hice esto, el mensaje de abuso llegó al hacker en lugar de a alguien a cargo de los servidores. Desde entonces, ya no me molesto, solo demasiados problemas.
Wump
Esto realmente no va a ayudar en la mayoría de los casos y puede llevar mucho tiempo
RichVel
4

Recomendaría no usar fail2ban sino ejecutar SSH (y otros) en un puerto no estándar. No creo en la seguridad por la oscuridad, pero creo que esta es una excelente manera de reducir el ruido en sus registros.

Los inicios de sesión fallidos en puertos no estándar serán pocos y distantes entre sí y también pueden indicar ataques más específicos.

Incluso podría ir un paso más allá e instalar un honeypot SSH como Kippo para 'dejar entrar' a los bruteforcers y ver qué harían si tuvieran la oportunidad.

Andy Smith
fuente
Jaja, Kippo se ve muy bien. Lo voy a instalar en un servidor solo para ver qué están tratando de hacer.
wump
4

Si, es normal. Lo que les digo a los clientes en su situación con sitios web pequeños.

Siempre prepárate para ser hackeado.

Tenga una copia de su sitio web en un servidor de desarrollo. Este puede ser su escritorio de Windows usando XAMPP que puede obtener de forma gratuita.

SIEMPRE realice cambios en su servidor de desarrollo y luego cárguelos en su sitio web en vivo. Si es un CMS como Wordpress, haga sus publicaciones en el servidor de desarrollo y luego cópielas y péguelas en el servidor en vivo.

NUNCA descargue nada de su sitio web en vivo a su servidor de desarrollo.

Monitoree sus páginas web regularmente por cualquier cambio que no haya hecho. Específicamente, enlaces ocultos a medicamentos o productos de 'mejora'. Puede encontrar muchos complementos y programas de navegador que lo harán por usted.

Si estás comprometido. Notifique a su host, elimine todo, cambie todas las contraseñas y cargue su servidor dev limpio en el servidor web ahora vacío. Trabaje con su anfitrión para evitar una recurrencia.

No debería necesitar un equipo de seguridad para un sitio pequeño. Eso es lo que se supone que debe proporcionar su host. Si no lo hacen, obtenga otro host, que es mucho más fácil de hacer cuando tiene un servidor de desarrollo en lugar de intentar mover el servidor en vivo.

Espero que esto ayude.

J Litten
fuente
2
+1 para "Siempre prepárate para ser hackeado".
user78940
3

Otra forma de detenerlo (ya que personalmente no me gusta mover el puerto SSH): decida si puede enumerar todas las redes desde las que desea iniciar sesión, luego solo permita que accedan a su puerto SSH.

Las entradas de WHOIS de los ISP locales me ayudaron a reducir los ataques a 1-2 intentos de inicio de sesión al mes (en aquel entonces, era aproximadamente 1k / día). Los detecté al seguir usando denyhosts .

weeheavy
fuente
3

Además de las otras excelentes sugerencias que ya ha recibido, también me gusta usar la directiva AllowUsers si es apropiado para el servidor dado. Esto permite que solo usuarios específicos inicien sesión a través de SSH, lo que reduce en gran medida la posibilidad de obtener acceso a través de una cuenta de invitado / servicio / sistema configurada de forma insegura.

Ejemplo:

AllowUsers admin jsmith jdoe

La opción AllowUsers especifica y controla qué usuarios pueden acceder a los servicios ssh. Se pueden especificar múltiples usuarios, separados por espacios.

Arrendajo
fuente
3

Si, es normal. Usted puede :

  • Reduce la oportunidad de ataque usando fwknop

Fwknop es una de las mejores implementaciones de eliminación de puertos porque no es falsificable y en realidad se autentica en lugar de simplemente autorizar una conexión.

  • Puede cambiar el puerto que usa Openssh, pero en realidad no está mejorando la seguridad.

  • Fortalezca la autenticación ssh utilizando Google-authenticator o wikid

Esto protegerá los ataques basados ​​en contraseña y la posibilidad de que un atacante determinado / ataque dirigido comprometa su máquina de administración y le robe su combinación de clave ssh y contraseña.

Solo mire la última compilación de pwn2own para ver cuán fácil es para un atacante experto comprometer su cuadro de administración completamente parcheado.

Hilton D
fuente
1

Lamentablemente esto es bastante normal. Debería considerar agregar algo como fail2ban a su sistema para detectar y prohibir automáticamente a los atacantes. Si aún no lo ha hecho, también debe considerar usar ssh con claves públicas y no permitir el inicio de sesión raíz a través de ssh. Si usa ftp para transferir archivos al sistema, considere usar scp / sftp en su lugar.

usuario619714
fuente
1

Implementé la eliminación de puertos y tengo algunas sondas por día. No tienen una conexión, así que se van. Registro e informo todo el acceso a los puertos involucrados.

También he ejecutado fail2ban con Shorewall como firewall para poner temporalmente en una lista negra a los atacantes persistentes.

Si no necesita acceso a Internet para SSH, desactívelo. Si tiene algunas direcciones conocidas que necesitan acceso remoto, limite el acceso a esas direcciones.

Limitar el acceso a las claves autorizadas también puede ser útil.

BillThor
fuente
0

Yo uso pam_abla la lista negra temporalmente forzadores bruta, y funciona muy bien. Creo que se siente mejor tener autorización en PAM usando su propia base de datos en lugar de depender de hosts.denyo iptables.

Otra ventaja es que pam_ablno depende del escaneo de archivos de registro.

Christoffer Hammarström
fuente
0

Es completamente normal en estos días.
Puede configurar el límite de "ráfaga" en el firewall para las nuevas conexiones entrantes en el puerto SSH,
o instalar uno de los muchos analizadores de registro a'la fail2ban o cambiar el puerto SSH;).

El último es el más fácil. En máquinas con carga pesada, tales intentos de robo pueden tener una influencia realmente mala en todo el sistema.

-
Saludos,
Robert

Robert
fuente
0

Si es normal

Acabo de cambiar el puerto ssh del estándar 22. Mi servidor, mis reglas :) simplemente edite / etc / ssh / sshd_config, cambie el puerto y reinicie el servicio. El único inconveniente es que debe recordar agregar ese puerto a la configuración a cada cliente ssh que use.

John
fuente
0
  • Deshabilite el inicio de sesión de root (en cada sistema Linux, el usuario root existe para que los bots puedan adivinar fácilmente el nombre de usuario). Después de iniciar sesión como usuario normal, puede cambiar a root por su o sudo.

  • cambiar el puerto predeterminado de 22

  • Permitir acceso ssh solo de ip conocidas

  • Use una contraseña alfanumérica segura para el usuario con acceso ssh

Kevin Parker
fuente