Cientos de inicios de sesión ssh fallidos


81

Todas las noches recibo cientos, a veces miles, de inicios de sesión ssh fallidos en mi servidor RedHat 4. Por razones de firewall de sitios remotos, necesito ejecutar en el puerto estándar. ¿Hay algo que deba hacer para bloquear esto? Noto que muchos provienen de la misma dirección IP. ¿No debería detenerlos después de un tiempo?

Respuestas:


67

Puede usar iptables para limitar las nuevas conexiones entrantes al puerto SSH. Tendría que ver toda su configuración de iptables para darle una solución llave en mano, pero básicamente está hablando de agregar reglas como:

iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP 
iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH --rsource -j ACCEPT 

Estas reglas suponen que está aceptando conexiones ESTABLECIDAS anteriormente en la tabla (de modo que solo las conexiones nuevas alcanzarán estas reglas). Las nuevas conexiones SSH alcanzarán estas reglas y se marcarán. En 60 segundos, 5 intentos desde una sola dirección IP provocarán la caída de nuevas conexiones entrantes desde esa IP.

Esto ha funcionado bien para mí.

Editar: prefiero este método a "fail2ban" porque no se instalará ningún software adicional, y ocurre totalmente en modo kernel. No maneja el análisis de archivos de registro como "fail2ban" lo hará, pero si su problema es solo con SSH, no usaría algo en modo de usuario que requiera instalación de software y sea más complejo.


1
Me gusta esta solución y planeo ponerla en práctica esta noche, una vez que apague los incendios de hoy.
MattMcKnight

2
Disminuye la velocidad de los ataques y lo recomiendo, pero debido a que existen botnets de escaneo distribuidas, no es una panacea. Todavía habrá inicios de sesión no válidos de botnets que ejecutan análisis distribuidos en su contra. Realmente no hay mucho que puedas hacer al respecto, salvo algún tipo de esquema de "bloqueo de puertos" para activar remotamente el puerto SSH cuando quieras entrar.
Evan Anderson

1
+1 para la sugerencia de "golpe de puerto" de @ Evan. Alguna información: linux.die.net/man/1/knockd . Pero no lo haga a la manera de la página de manual (es decir, agregando / eliminando reglas de iptables), sino que use -m conditioniptables match en su lugar.
pepoluan

2
¿no necesita --dportar 22 en estas reglas para que solo se apliquen al tráfico ssh?
clima

2
@clime - Sí. ¡Es difícil de creer que esto ha estado aquí 2 años y medio y nadie se dio cuenta! Buena atrapada.
Evan Anderson


25

Recomendaría usar un puerto no estándar para SSH si puede (es decir, el puerto 10222), pero como mencionó que no puede hacerlo, recomendaría usar algo como DenyHosts.

http://denyhosts.sourceforge.net/

Gran paquete, fácil de instalar y configurar.


66
No sé por qué la gente vota esto; SSH está en un puerto estándar 22. Esto significa que cuando estás en una red extranjera, no estás confiando en que hayan abierto un puerto no estándar a través del firewall de salida. La solución real a este problema se documenta anteriormente, ya sea restringir el número de conexiones repetidas a través de su firewall entrante o desconectar los inicios de sesión de contraseña.
Andrew Taylor

1
OpenSSH 6.7 elimina el soporte de tcpwrappers , que es lo que utiliza denyhosts.
Zoredache

15

Si bien puede ser bueno poder ingresar a su sistema mediante ssh desde ubicaciones arbitrarias en Internet, existen sistemas automatizados de ataque con contraseña que se bloquearán en un puerto ssh abierto y aplicarán varios ataques de diccionario y cuenta joe contra su sistema. Esto puede agregarse para leer en su resumen de registro nocturno y es un desperdicio de su ancho de banda.

Si tiene un servidor web en el mismo sistema, puede usar envoltorios php y tcp para restringir el tráfico entrante ssh a los sistemas conocidos, además de darle una clave de puerta trasera para permitirse el acceso desde sistemas arbitrarios en Internet.

Así es como lo haces:

negar todas las conexiones ssh en /etc/hosts.deny:

# /etc/hosts.deny fragment
sshd:  all

Permita sistemas conocidos por IP en /etc/hosts.allow, y agregue un archivo para acceso temporal:

# /etc/hosts.allow fragment
sshd:  10.0.10.2     # some system
sshd:  172.99.99.99  # some other system
sshd:  /etc/hosts.allow.temporary-sshd-access

Cree un archivo php en su servidor web y asígnele un nombre no obvio como my-sshd-access.php:

<?php
function get_ip()
{
    return getenv("REMOTE_ADDR"); 
}

?>

<?php
$out='/etc/hosts.allow.temporary-sshd-access';
$log='/var/log/sshd-access-addition-log';

print "Was:";
readfile($out);
print "<br>";
$ip=get_ip();
$fp=fopen($out,"w");
fputs($fp,$ip);
fclose($fp);

$lfp=fopen($log,"a");
fputs($lfp,$ip);
fputs($lfp,"n");
fclose($lfp);

print "Wrote: ";
readfile($out);
?>

Perdone el código php: lo saqué de otro lugar, por lo que probablemente podría ser limpiado un montón. Todo lo que hace es agregar la dirección IP del sistema que accede al archivo /etc/hosts.allow.temporary-sshd-access, que es leído por sshd (debido a su inclusión por /etc/hosts.allow) en el momento de la conexión .

Ahora, cuando se encuentre en un sistema arbitrario en la web y desee ssh a este sistema, primero use un navegador web y presione este archivo (o use wget o equivilent):

$ wget http://your.system.name/my-sshd-access.php

Ahora debería poder ingresar a su sistema. Si se trata de un lugar desde el que probablemente se encuentre enviando mensajes con frecuencia, sería trivial leer el contenido del archivo /etc/hosts.allow.temporary-sshd-access y agregar permanentemente la dirección IP a / etc / hosts. permitir.


Para hacer esto más seguro, ejecute esta página en https.
Robert Munteanu

Si cambia la secuencia de comandos para que no muestre el contenido del archivo de "dirección IP temporal permitida", no habrá nada para que un aspirante pueda rastrear. Luego puede ejecutarlo en http en lugar de https.
Barry Brown el

La "dirección IP temporal permitida" siempre es la del solicitante (es decir, la suya). No creo que importe de una forma u otra. Https significa que la URL solicitada está encriptada, lo que significa que no es trivial olfatearla.
David Mackintosh

Esto no funcionará si está en una red que representa las conexiones HTTP pero su ruta directa a Internet es a través de una salida diferente.
Andrew Taylor

OpenSSH 6.7 elimina el soporte de tcpwrappers , que es lo que se está utilizando en su respuesta.
Zoredache



2

Otra solución es simplemente mover ssh a otro puerto. Estos gusanos son bastante estúpidos.


3
El póster original decía que necesitaba correr en el puerto estándar.
kbyrd el

1
lo siento, debo leer las preguntas con más cuidado :)
disserman 02 de

1
Tengo que estar de acuerdo ... Tengo mi SSH ejecutándose en puertos "alternativos" y hace un MUNDO de diferencia en los registros. Los gusanos son tan inteligentes como un ladrillo, por lo que funciona bien contra scripts de automatización tontos; No tan bien contra los atacantes humanos. Aún así, los registros tienen el bendito sonido del silencio en ellos ...
Avery Payne

... no es que los bots sean "estúpidos", es que están diseñados para buscar fruta de bajo perfil. Por lo tanto, mover el puerto SSH tiene el estilo de ... mantener la fruta del suelo.
elrobis

2

Otra opción podría ser exigir que todas las conexiones ssh sean verificadas por un certificado y eliminar por completo las contraseñas.

Solía ​​usar Denyhosts, pero descubrí que solo me conectaba regularmente de forma remota desde un puñado de lugares, por lo que bloqueé todas las conexiones del puerto 22, excepto desde cualquier otro lugar, y utilicé el bloqueo de puertos para poder conectarme desde cualquier lugar con mi computadora portátil si tengo que hacerlo. .


1

Cualquier solución que implique el bloqueo automático de IP después de múltiples fallas introduce el riesgo de ataques de denegación de servicio. Mientras exista una buena política de contraseñas para reducir la efectividad de la fuerza bruta o los ataques de diccionario, no me preocuparía demasiado por ellos.

Si limita los usuarios / grupos a solo aquellos a los que se les debe permitir ingresar ssh en primer lugar, y deshabilita el inicio de sesión como root, debe ser lo suficientemente seguro. Y, si eso no es suficiente, siempre hay una autenticación basada en claves.


1

Honestamente, si tiene que ejecutar SSH (y en el puerto 22), no puede evitarlos. Si debe aceptar contraseñas, está en peor forma.

Su mejor opción es configurar su software de análisis de registros para excluir los registros SSH. Luego, ejecute una instancia separada para ver solo los registros SSH y use procmail para filtrar los intentos fallidos. Incluso puede escribir secuencias de comandos para ver los inicios de sesión exitosos desde direcciones IP con múltiples intentos fallidos.

No hay forma de evitar que las personas prueben su servidor SSH. Denyhosts, fail2ban y el ejemplo de iptables funcionarán hasta cierto punto, pero con el peligro adicional de bloquear accidentalmente a usuarios legítimos. El mejor método es absorberlo y tratar de automatizar el proceso de análisis de registro para reducir la cantidad de tiempo que tiene que pensar en ello.


0

Cuando dice que está fallando, intente iniciar sesión en su servidor de red hat, qué tipo de firewall se encuentra detrás y cuántas personas necesitan instalarlo. Sugiero que, si puede, desee limitar los intentos en el firewall antes de que se acerquen a su servidor real.

Si puede restringir el rango de direcciones IP que legítimamente necesitan acceso, debería poder configurar una lista de acceso en el cortafuegos. Si puede restringir el tráfico en el firewall, le sugiero que mire los sistemas de intrusión de red, ya que parece que su servidor está siendo atacado por algo.


0

La mayoría de los servidores web utilizan APF + BFD para bloquear los inicios de sesión SSH fallidos. Hoy en día hay CSF (firewall del servidor de configuración) que incluye una herramienta llamada LFD que hace lo mismo, y más, incluyendo IP bloqueadas de ciertos países a los que no desea acceder a su servidor (por ejemplo, Corea, China, etc., donde el 99% de mis sondas SSH parece originarse de).



0

Si necesita abordar este problema en más de un host, puede consultar OSSEC: http://www.ossec.net/main/ossec-architecture

Esto le permitirá configurar múltiples agentes desde una ubicación centralizada para responder automáticamente a los ataques de fuerza bruta (junto con cualquier otro patrón que pueda extraer de los registros).

Muy buen software :)


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.