Como os ataques de força bruta SSH são irritantes...

8 min

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

Olá, sou um incompetente.
Enquanto observava o /var/log/auth.log do Gitea que estou hospedando com tail -f, notei algumas tentativas suspeitas.
Por exemplo, algo assim:

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

Há tentativas de login SSH do lado do servidor VPN. A razão pela qual isso está acontecendo é porque estou usando o Nginx para fazer um proxy Stream para este servidor Gitea.

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

Dessa forma, os IPs recebidos na porta 2222 são encaminhados para o GiteaSrvIP, mas, sinceramente, ainda não entendo por que a porta 42552 diferente aparece nos logs. É desconfortável ver tantas tentativas de login vindo desse IP que estou usando como um IP interno.
Em termos de mecanismo, no final das contas, quero fazer push para o Gitea via protocolo SSH, mas ao usar o proxy Stream, é necessário fazer o proxy para IP:porta, e acredito que isso esteja acontecendo porque todas as tentativas de SSH na porta 2222 estão sendo encaminhadas para o GiteaSrvIP.

Mesmo eu me explicando, está um pouco confuso, então...

Malfeitor: Vou fazer SSH na porta 2222 de git.domain.tld!
WireGuardSrv: Oh, oh, você está tentando fazer login na porta 2222, é isso?
WireGuardSrv: Então, vou encaminhar todas as requisições para a porta 2222 para o GiteaSrv!
GiteaSrv: Bem, eu só consigo ver o IP do WireGuardSrv, e estou recebendo muitas tentativas de login SSH...

Só consigo imaginar as tentativas de SSH do WireGuardSrvIP nesse tipo de fluxo...
No entanto, o mistério é que, embora eu esteja apenas recebendo na porta 2222 e encaminhando para a porta 2222, não sei como se tornou port 42552. Se fosse uma tentativa de SSH de um IP global para esta porta, usando um endereço IP que só existe na VPN, eu ainda conseguiria entender, mas...
Claro, o login SSH em si proíbe o login de root e usa apenas autenticação por chave pública, então se fosse violado, eu ficaria curioso para saber como foi feito.

Como contramedida

Se o auth.log ficar sujo, será difícil de ler como arquivo de log, e, acima de tudo, o arquivo de log provavelmente inchará muito, então quero bloqueá-lo na fase anterior.
Isso porque, embora eu esteja bloqueando múltiplas tentativas de login SSH com fail2ban, isso também bloquearia o SSH para o GiteaSrvIP via Wireguard, misturando-se com outros logs.
Portanto, quero impedi-lo antes que seja gravado no auth.log.

No lado do FreeBSD (servidor WireGuard)

Vou configurar a política de bloqueio padrão do pf para drop.
PF: Opções de tempo de execução
Então, vou definir Drop como política padrão.

set block-policy drop

Dessa forma, se um pacote for pego pela política de bloqueio do lado do FreeBSD, ele será descartado.

No lado do Debian (cliente WireGuard e servidor Gitea)

Para começar, é estranho que o servidor HTTP do Gitea e as portas 22 e 2222 do SSH estejam recebendo acesso de outros números de porta que claramente vêm do WireGuardSrvIP.
Em particular, portas acima de 2222, como a 3000, funcionam como portas HTTP locais padrão, então elas não deveriam ser abertas. No entanto, como não quero que o Gitea escute na porta 80, estou abrindo a porta 3000 temporariamente durante o período de testes.
Como me enrolei um pouco, limitei as portas com ufw da seguinte forma:

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

Como quero usá-lo como um servidor VPS para brincar, neguei temporariamente o intervalo 2223:65535, mas abri explicitamente a porta 3000/tcp.

As tentativas de SSH sem sentido pararam de aparecer nos logs

Graças a isso, as tentativas de login que estavam aparecendo como loucas no auth.log desapareceram, embora eu não saiba se foi devido à política de bloqueio no lado do FreeBSD ou à negação explícita com ufw, já que fiz as duas coisas ao mesmo tempo.
Provavelmente, como eu já tinha configurado um firewall no lado do FreeBSD até certo ponto, acredito que todos os pacotes bloqueados estão sendo descartados no nível do FreeBSD, em vez de serem REJECTados. Espero que sim.

Reconfigurando o fail2ban

Então, editei /etc/fail2ban/jail.conf e
configurei IPs a serem ignorados nas configurações padrão de monitoramento.

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

Depois disso, alterei as configurações para sshd.

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

Tentei uma configuração mais rigorosa do que a do WireGuardSrv.
As razões para as mudanças são as seguintes:

port    =  all
maxretry = 2

O WireGuardSrv tem a porta explicitamente definida apenas como ssh, então ele monitora apenas as portas usadas para SSH, mas esta configuração monitora tentativas de SSH em todas as portas.
Em relação às tentativas, limitei a um máximo de 2, de forma mais rigorosa.
A razão para a mudança é que estou curioso para saber quantas vezes será acionado, e se for acionado muitas vezes, pretendo configurar o WireGuardSrv no mesmo nível.
Então.
Estou ansioso pelos resultados.

Related Posts