Ataque a força bruta no servidor vsftp não mostrando autenticação com falha no log

Question

Meu servidor está executando o Debian 8 com o vsftpd versão 3.0.2-17. Recentemente, meu vsftpd.log preencheu o seguinte:

vsftpd.log

Mon Mar  7 18:13:44 2016 [pid 13499] CONNECT: Client "::ffff:xxx.xxx.xx.xx"
Mon Mar  7 18:13:45 2016 [pid 13501] CONNECT: Client "::ffff:xxx.xxx.xx.xx"
Mon Mar  7 18:13:46 2016 [pid 13503] CONNECT: Client "::ffff:xxx.xxx.xx.xx"
Mon Mar  7 18:13:47 2016 [pid 13505] CONNECT: Client "::ffff:xxx.xxx.xx.xx"
...
...

Isso acontece por mais de 6000 linhas, todas do mesmo endereço IP (ofusquei o IP no fragmento do arquivo de log). Eu tenho um jail fail2ban (versão 0.8.13-1) em execução usando o arquivo vsftpd.conf padrão, mas não há falhas de autenticação que estão sendo registradas, portanto, nenhuma proibição. Aqui está o filtro para referência:

fail2ban regex vsftpd.conf

failregex = ^%(__prefix_line)s%(__pam_re)s\s+authentication failure; logname=\S* uid=\S* euid=\S* t$
        ^ \[pid \d+\] \[.+\] FAIL LOGIN: Client "<HOST>"\s*$

E aqui está o meu arquivo de configuração vsftpd:

vsftpd.conf

listen=NO
listen_ipv6=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=<path to .pem file>
rsa_private_key_file=<path to key file>
ssl_enable=YES
ssl_tlsv1=YES
ssl_ciphers=HIGH
pasv_min_port=XXXX
pasv_max_port=XXXX

Alguém pode me ajudar a entender o que está acontecendo? Por que não há tentativas de login com falha no log? Não consigo encontrar nenhuma outra evidência de que alguém realmente tenha acesso ao sistema.

BTW, minhas intenções eram iniciar e interromper o serviço vsftpd somente quando eu precisasse usá-lo, mas não consegui removê-lo da inicialização, então quando eu reiniciei ele foi iniciado novamente sem que eu percebesse. Eu já corrigi esse problema, mas eu ainda gostaria de entender esse problema e como eu poderia fazer com que o fail2ban trabalhasse com essa situação.

    

Answer 1

Conecte a operação e a operação de login não são as mesmas coisas.

Alguns bots na internet podem apenas verificar se o seu servidor FTP está ativo e desconectar sem sequer tentar logar (algumas vezes no loop como no seu caso). Isso é normal. Não há problema aqui.

Você pode experimentar por conta própria. Basta executar:

$ telnet whatever-domain.com 21
Trying 999.9.9.9...
Connected to whatever-domain.com.
Escape character is '^]'.
220 (vsFTPd 3.0.2)
^]
telnet> Connection closed.

e verifique vsftpd log , deve aparecer apenas a linha onde você está tentando CONNECT e é isso.

    

Answer 2

Brinquei um pouco com sua entrada e fail2ban-regex e consegui combinar essas linhas com esse failregex :

failregex = ^%(__prefix_line)s\s*\[pid\s*\d*\]:\s*CONNECT:\s*Client\s*\"<HOST>\"

Tenho certeza de que você poderia refinar ainda mais, mas o ponto principal é que o padrão __prefix_line é confuso com [pid 13499] em vez de apenas [13499] , então você deve modificar localmente o prefixo ou incluir a parte pid no corpo da regex.

Contanto que você não defina um limite muito baixo, isso deve dar o comportamento que você está procurando: bloquear qualquer pessoa que faça conexões repetidas em um curto período de tempo.