Eu tenho um servidor Ubuntu 20.04 que recebe centenas de solicitações SMTP AUTH em meu servidor postfix todos os dias do mesmo IP. Tenho o fail2ban instalado, mas ironicamente não está conseguindo banir o IP.
Meu /etc/fail2ban/jail.localarquivo é (<snip>'d bits são IPs pessoais e comerciais):
[postfix-flood-attack]
enabled = true
bantime = 1h
filter = postfix-flood-attack
action = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp]
logpath = /var/log/mail.log
ignoreip = <snip> 127.0.0.1/8
maxretry = 3
[postfix]
enabled = true
maxretry = 3
bantime = 1h
filter = postfix[mode=aggressive]
logpath = /var/log/mail.log
ignoreip = <snip> 127.0.0.1/8
[dovecot]
enabled = true
port = pop3,pop3s,imap,imaps
filter = dovecot
logpath = /var/log/mail.log
maxretry = 3
ignoreip = <snip> 127.0.01/8
A prisão em questão é postfix-flood-attack, retirada departe inferior deste tutorial. O /etc/fail2ban/filter.d/postfix-flood-attack.confarquivo é:
[Definition]
failregex = lost connection after AUTH from (.*)\[<HOST>\]
ignoreregex =
Minhas mensagens de log se parecem
Aug 15 13:54:45 ikana postfix/smtps/smtpd[268729]: connect from unknown[193.35.48.18]
Aug 15 13:54:46 ikana postfix/smtps/smtpd[268729]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: warning: unknown[193.35.48.18]: SASL PLAIN authentication failed:
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: connect from unknown[193.35.48.18]
Aug 15 13:54:51 ikana postfix/smtps/smtpd[268729]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:54:57 ikana postfix/smtps/smtpd[268729]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:54:57 ikana postfix/smtps/smtpd[268729]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Aug 15 13:54:57 ikana postfix/smtps/smtpd[268729]: connect from unknown[193.35.48.18]
Aug 15 13:54:58 ikana postfix/smtps/smtpd[268729]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:55:04 ikana postfix/smtps/smtpd[268729]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:55:04 ikana postfix/smtps/smtpd[268729]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Aug 15 13:55:04 ikana postfix/smtps/smtpd[268734]: connect from unknown[193.35.48.18]
Aug 15 13:55:05 ikana postfix/smtps/smtpd[268734]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:55:09 ikana postfix/smtps/smtpd[268734]: warning: unknown[193.35.48.18]: SASL PLAIN authentication failed:
Aug 15 13:55:09 ikana postfix/smtps/smtpd[268734]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:55:09 ikana postfix/smtps/smtpd[268734]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Segundo fail2ban-regex, isso deveria funcionar, mas o IP não está sendo banido. A saída do comando fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/postfix-flood-attack.confé:
Running tests
=============
Use failregex filter file : postfix-flood-attack, basedir: /etc/fail2ban
Use log file : /var/log/mail.log
Use encoding : UTF-8
Results
=======
Failregex: 5356 total
|- #) [# of hits] regular expression
| 1) [5356] lost connection after AUTH from (.*)\[<HOST>\]
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [37949] {^LN-BEG}(?:DAY )?MON Day %k:Minute:Second(?:\.Microseconds)?(?: ExYear)?
`-
Lines: 37949 lines, 0 ignored, 5356 matched, 32593 missed
[processed in 1.43 sec]
Missed line(s): too many to print. Use --print-all-missed to print all 32593 lines
Portanto, ele encontra uma correspondência para 5.356 registros e nunca proíbe nenhum. Geralmente há 8 tentativas dentro do tempo de pesquisa padrão de 10 minutos. Um trecho do uso da -vopção with fail2ban-regexmostra as seguintes correspondências com carimbos de data/hora:
...
193.35.48.18 Thu Aug 15 13:50:55 2019
193.35.48.18 Thu Aug 15 13:51:02 2019
193.35.48.18 Thu Aug 15 13:51:10 2019
193.35.48.18 Thu Aug 15 13:51:15 2019
193.35.48.18 Thu Aug 15 13:54:50 2019
193.35.48.18 Thu Aug 15 13:54:57 2019
193.35.48.18 Thu Aug 15 13:55:04 2019
193.35.48.18 Thu Aug 15 13:55:09 2019
193.35.48.18 Thu Aug 15 13:58:40 2019
193.35.48.18 Thu Aug 15 13:58:48 2019
193.35.48.18 Thu Aug 15 13:58:54 2019
193.35.48.18 Thu Aug 15 13:58:59 2019
...
Responder1
A configuração parece boa, mas há um detalhe importante a ser observado no resultado de fail2ban-regex: Foi decidido que as datas são de 2019. Dada a aparência dos logs na pergunta, isso pareceu um tanto estúpido a princípio. Acontece que este é um problema conhecido com o fail2ban, algo que eles chamam dea questão TZ. Depois de configurar seu servidor para usar um fuso horário específico, você precisa reiniciar vários serviços ou reiniciar todo o sistema para que ele tenha efeito adequado. Embora não me lembre quanto tempo faz, acho que nunca reiniciei meu servidor desde que configurei o fuso horário nele.
Depois de reiniciar o serviço syslog via systemctl restart syslog, o fail2ban reconheceu as linhas de log no fuso horário correto.
O Fail2ban reconheceu imediatamente as mensagens de log no horário de localização configurado e baniu o IP que assola meu servidor há dias. Acho que o Fail2ban pede ao syslog as informações de fuso horário em vez de usar o que foi definido na máquina desde que o servidor fail2ban foi iniciado.
Espero que isso possa ajudar alguém com um problema semelhante.
Responder2
A ambigüidade que fez com que o fail2ban assumisse que essas datas eram em 2019 não pode ocorrer quando você usa a formatação de data padrão. Você pode evitar o problema completamente,usando ISO 8601- talvez você não tenha nenhum bom motivo para manter a formatação de log compatível com versões anteriores em 2020.
Além disso, no Ubuntu, você provavelmente pode pular completamente a formatação/análise da data, instruindo o fail2ban a consumir o diário do systemd diretamente, o que fornece compensações simples da época sem informações de fuso horário (tente backend = systemdno [DEFAULT]bloco na configuração da prisão local).