É seguro aplicar fail2ban nos logs sshd "Desconexão recebida/Desconectada ... [preauth]"?

Question

Estou vendo muitos logs como estes no /var/log/auth.log(Debian Buster):

Jan  2 17:10:17 mybox sshd[16304]: Received disconnect from 1.2.3.4 port 37792:11: Bye Bye [preauth]
Jan  2 17:10:17 mybox sshd[16304]: Disconnected from authenticating user root 1.2.3.4 port 37792 [preauth]
Jan  2 17:10:20 mybox sshd[16306]: Received disconnect from 5.6.7.8 port 63061:11: Bye Bye [preauth]
Jan  2 17:10:20 mybox sshd[16306]: Disconnected from authenticating user root 5.6.7.8 port 63061 [preauth]
Jan  2 17:12:38 mybox sshd[16380]: Received disconnect from 9.10.11.12 port 55224:11: Normal Shutdown, Thank you for playing [preauth]
Jan  2 17:12:38 mybox sshd[16380]: Disconnected from authenticating user root 9.10.11.12 port 55224 [preauth]

Eu sei que essas são tentativas de invasão, porque ninguém deveria tentar fazer login naquela máquina (além de mim).

Não há regra correspondente /etc/fail2ban/filter.d/sshd.conf, portanto, essas tentativas não fazem com que o fail2ban proíba o endereço IP incorreto.

Desativei o login por senha, então acho que o que acontece aqui é que essas tentativas são descartadas antes mesmo de tentarem a autenticação e, por esse motivo, o fail2ban não as está captando.

Porém, como sei que são tentativas de quebra, ainda gostaria de banir o IP, para impedi-los de tentar outras coisas e preencher meus logs.

É seguro adicionar um Regexp que corresponda a algumas dessas linhas ou correria o risco de corresponder a tentativas de login legítimas (baseadas em chave)? Quais partes formariam uma combinação segura? A correspondência das palavras "Desconectado" e da tag "[preauth]" indicaria necessariamente uma falha na força bruta baseada em senha?

Answer 1

Não há regra correspondente em /etc/fail2ban/filter.d/sshd.conf, portanto, essas tentativas não fazem com que o fail2ban proíba o endereço IP incorreto.

Qual versão você está usando? Fail2Ban vem com uma regra predefinida sobre isso, incluída no failregex comum usado por todos os modos.

Fail2Ban v0.10.2 em um dos meus sistemas inclui esta regra:

^<F-NOFAIL>Received <F-MLFFORGET>disconnect</F-MLFFORGET></F-NOFAIL> from <HOST>: 11:

E Fail2Ban v0.11.2 inclui este (que é melhor):

^<F-NOFAIL>Received <F-MLFFORGET>disconnect</F-MLFFORGET></F-NOFAIL> from <HOST>%(__on_port_opt)s:\s*11:

Aparentemente, os desenvolvedores pensaram que qualquer uma das seguintes linhas

Received disconnect from <HOST>: 11:
Received disconnect from <HOST> port XXXXX:11:

será suficiente. As palavras-chave relevantes são Received disconnect frome a : 11:parte (em vez do [preauth]sufixo).

Isso <F-NOFAIL>significa que esta linha não é uma falha e esperará outra correspondência sem <F-NOFAIL>banir o IP, então você terá que remover as tags ao redor.

Answer 2

É seguro adicionar um Regexp que corresponda a algumas dessas linhas ou correria o risco de corresponder a tentativas de login legítimas (baseadas em chave)? Quais partes formariam uma combinação segura? A correspondência das palavras "Desconectado" e da tag "[preauth]" indicaria necessariamente uma falha na força bruta baseada em senha?

Uma conexão e autenticação legítimas e bem-sucedidas não acionam essas linhas de log. Essas entradas podem vir de scanners, que não causam danos, mas também podem ser bloqueados. pré-auth significa que esses clientes ainda não iniciaram a autenticação.

Mesmo que você mesmo cause uma falha no login, usando chaves erradas ou digitando a senha incorretamente, usar fail2ban ainda é aceitável. fail2ban bloqueia apenas após um número configurável de linhas de log correspondentes e apenas por um determinado período de tempo.

Você pode usar este trecho (por exemplo, como cmdfailre) no Debian buster:

^Received disconnect from <HOST>%(__on_port_opt)s:11: \s* %(__suff)s$
^Disconnected from authenticating user <F-USER>.*?</F-USER> <HOST>%(__on_port_opt)s %(__suff)s$

Answer 3

Ativei essa funcionalidade definindo mode = agressive em [sshd] em meu arquivo jail.local