Debido a los molestos ataques de fuerza bruta a SSH...

8 min

sshdebianvpsfail2ban
language: ja bn en es hi pt ru zh-cn zh-tw

Hola, soy un inútil.
Mientras observaba /var/log/auth.log en el servidor de Gitea con tail -f, noté algunos intentos sospechosos.
Por ejemplo, algo así:

2024-12-07T16:57:39.486624+00:00 hostname sshd[392231]: Received disconnect from WireGuardSrvIP port 42552:11: Bye Bye [preauth]

Hay intentos de inicio de sesión SSH desde el lado del servidor VPN. La razón por la que esto está sucediendo es porque estoy usando Nginx para hacer un proxy Stream a este servidor Gitea.

stream {
    server {
        listen 2222; 
        proxy_pass GiteaSrvIP:2222; 
        proxy_timeout 1m;
        proxy_connect_timeout 1s;
    }
}

De esta manera, las IPs que se reciben en el puerto 2222 se reenvían a GiteaSrvIP. Honestamente, todavía no entiendo por qué el log muestra un puerto diferente, 42552, pero me resulta inquietante que haya tantos intentos de inicio de sesión desde esta IP, que se supone que es una IP interna.
En cuanto al mecanismo, creo que esto sucede porque, en última instancia, quiero hacer un 'push' a Gitea con el protocolo SSH, pero al hacer un proxy con Stream, es necesario hacer un proxy a IP:puerto, y todos los intentos de SSH en el puerto 2222 se están reenviando a GiteaSrvIP.

Incluso para mí, esto se está volviendo confuso, así que...

Malhechor: ¡Voy a hacer SSH al puerto 2222 de git.domain.tld!
WireGuardSrv: Oh, oh, ¿estás intentando iniciar sesión en el puerto 2222?
WireGuardSrv: ¡Entonces, todas las solicitudes al puerto 2222 se reenviarán a GiteaSrv!
GiteaSrv: Pero, de alguna manera, solo veo la IP de WireGuardSrv, y están llegando muchos intentos de inicio de sesión SSH...

Solo puedo imaginar los intentos de SSH desde WireGuardSrvIP de esta manera...
Sin embargo, lo que es un misterio es cómo se convierte en port 42552, cuando solo he configurado para recibir en el puerto 2222 y reenviar al puerto 2222. Si fuera un intento de SSH a este puerto desde una IP global, utilizando una dirección IP que solo existe en la VPN, aún podría entenderlo...
Por supuesto, el inicio de sesión SSH en sí tiene el inicio de sesión de root deshabilitado y solo permite la autenticación con clave pública, así que si logran romperlo, me interesaría saber cómo lo hicieron.

Como contramedida

Si se mantiene un auth.log 'sucio', es difícil de leer como archivo de registro, y lo que es más importante, el archivo de registro probablemente se hinchará enormemente, así que quiero bloquearlo en una etapa anterior.
Esto se debe a que, aunque estoy bloqueando múltiples intentos de inicio de sesión SSH con fail2ban, esto también bloquearía los intentos de SSH a GiteaSrvIP a través de Wireguard, mezclándose con otros registros.
Por lo tanto, quiero detenerlo antes de que se escriba en auth.log.

Lado de FreeBSD (servidor WireGuard)

Configuraré la política de bloqueo predeterminada de pf para que sea drop.
PF: Opciones de tiempo de ejecución
Así que, estableceré Drop como política predeterminada.

set block-policy drop

De esta manera, si un paquete es atrapado por la política de bloqueo de FreeBSD, será descartado directamente.

Lado de Debian (cliente WireGuard y servidor Gitea)

En primer lugar, es extraño que haya algún tipo de acceso desde otros números de puerto que provienen claramente de WireGuardSrvIP, hacia el servidor HTTP de Gitea y los puertos SSH 22 y 2222.
Especialmente los puertos superiores a 2222, como el 3000, funcionan como puertos HTTP locales predeterminados, por lo que tampoco deberían estar abiertos. Sin embargo, como no quiero que Gitea escuche en el puerto 80, lo he abierto en el puerto 3000 por ahora, durante el período de prueba.
Como me he liado un poco, he restringido los puertos con ufw de la siguiente manera:

ufw deny proto tcp from WireGuardSrvIP to any port 2223:65535
ufw reload

Aunque quiero usarlo como un servidor VPS de prueba, he denegado temporalmente el rango 2223:65535, y he abierto explícitamente 3000/tcp por separado.

Los registros de intentos de SSH sin sentido han desaparecido con éxito

Gracias a esto, los intentos de inicio de sesión que aparecían como locos en auth.log han desaparecido con éxito. No sé si fue por la política de bloqueo en el lado de FreeBSD o por la denegación explícita con ufw, ya que lo hice al mismo tiempo.
Probablemente, como ya tenía configurado un firewall en el lado de FreeBSD hasta cierto punto, creo que los paquetes bloqueados se están descartando (drop) en lugar de rechazarse (REJECT) en el propio FreeBSD. Espero que sea así.

Reconfiguración de fail2ban

Así que, edité /etc/fail2ban/jail.conf y configuré las IPs a ignorar en la configuración predeterminada de monitoreo.

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 WireGuardSrvIP

Después de eso, cambié la configuración de sshd.

[sshd]
enabled = true
port    = all
logpath = /var/log/auth.log
bantime = 10w  
findtime = 1d  
maxretry = 2

He intentado una configuración más estricta que la de WireGuardSrv.
Las razones de los cambios son las siguientes:

port    =  all
maxretry = 2

En WireGuardSrv, el puerto está explícitamente establecido solo como ssh, por lo que solo monitorea los puertos utilizados para SSH, pero esto monitorea los intentos de SSH en todos los puertos.
En cuanto a los reintentos, es un máximo de 2, lo cual es estricto.
La razón del cambio es que me interesa ver cuántos intentos serán atrapados, y si son muchos, tengo la intención de aplicar una configuración similar a WireGuardSrv.
Eso es todo.
Estoy deseando ver los resultados.

Related Posts