Cientos de inicios de sesión ssh fallidos

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?

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.

fail2ban puede ayudar con esto al bloquear las direcciones IP con demasiados intentos fallidos de inicio de sesión.

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.

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.

Es posible que desee ver también a negones .

FYI: OpenSSH 6.7 elimina el soporte de tcpwrappers , lo que significa que denyhosts probablemente no sea la solución para nuevas instalaciones.

Hazte un favor y deshabilita la contraseña de inicio de sesión. Utilice exclusivamente claves de autenticación (google ssh-keygen por ejemplo - Ejemplo: http://www.puddingonline.com/~dave/publications/SSH-with-Keys-HOWTO/document/html/SSH-with-Keys-HOWTO-4 .html ) Su servidor será más seguro, se conectará a él más cómodamente (verifique ssh-agent, ssh-add, keychain) y ya no será víctima de ataques de fuerza bruta ssh.

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

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

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.

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.

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.

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

He estado usando fail2ban y me ha estado ayudando mucho.

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

Otra opción similar a DenyHosts es sshutout http://www.techfinesse.com/sshutout/sshutout.html