☰

Fail2ban не будет банить postfix/smtps/smtpd

tag-icon • tag-icon postfix syslog fail2ban ubuntu-20.04
Fail2ban не будет банить postfix/smtps/smtpd

У меня есть сервер Ubuntu 20.04, который получает сотни запросов SMTP AUTH на мой сервер postfix каждый день с одного и того же IP. У меня установлен fail2ban, но по иронии судьбы он не может забанить IP.

Мой /etc/fail2ban/jail.localфайл (<вырезанные>фрагменты — это личные и деловые IP-адреса):

[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

Тюрьма, о которой идет речь postfix-flood-attack, взята изв конце этого урока. /etc/fail2ban/filter.d/postfix-flood-attack.confФайл:

[Definition]
failregex = lost connection after AUTH from (.*)\[<HOST>\]
ignoreregex =

Мои сообщения журнала выглядят так

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

Согласно fail2ban-regex, это должно работать, но IP не банится. Вывод команды 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

Таким образом, он находит совпадение для 5356 журналов и никогда не банит ни один. Обычно есть 8 попыток в течение 10 минут поиска по умолчанию. Фрагмент использования опции -vс fail2ban-regexпоказывает следующие совпадения с временными метками:

...
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
...

решение1

Конфигурация выглядит хорошо, но есть одна важная деталь, которую следует отметить в выводе fail2ban-regex: он решил, что даты относятся к 2019 году. Учитывая, как выглядят логи в вопросе, это показалось довольно глупым на первый взгляд. Оказывается, это известная проблема с fail2ban, что-то, что они называютTZ-вопрос. После настройки сервера на использование определенного часового пояса вам нужно либо перезапустить кучу служб, либо перезапустить всю систему, чтобы изменения вступили в силу должным образом. Хотя я не помню, как давно это было, я думаю, что я ни разу не перезапускал свой сервер с тех пор, как настроил на нем часовой пояс.

После перезапуска службы syslog через systemctl restart syslogfail2ban распознал строки журнала в правильном часовом поясе.

Fail2ban немедленно распознал сообщения журнала в настроенном времени поиска и забанил IP, который мучил мой сервер в течение нескольких дней. Я полагаю, Fail2ban запрашивает у syslog информацию о часовом поясе вместо того, чтобы использовать то, что было установлено на машине с момента запуска fail2ban-server.

Надеюсь, это поможет кому-то ещё с похожей проблемой.

решение2

Неоднозначность, из-за которой fail2ban предположил, что эти даты были в 2019 году, не может возникнуть при использовании стандартного форматирования даты. Вы можете полностью избежать этой проблемы,с использованием ISO 8601- в 2020 году у вас может не остаться веских причин придерживаться обратно совместимого форматирования журналов.

Кроме того, в Ubuntu вы, скорее всего, можете полностью пропустить форматирование/анализ даты, указав fail2ban напрямую использовать журнал systemd, который предоставляет простые смещения относительно эпохи без информации о часовом поясе (попробуйте backend = systemdв [DEFAULT]блоке в конфигурации локальной тюрьмы).

Связанный контент