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

¡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?

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!

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 :-)

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

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.

Sí . 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.

use http://denyhosts.sourceforge.net/

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

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 .

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.

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.

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!)

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.

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.

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.

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 .

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.

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.

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.

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.

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.

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

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.

• 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