Назад | Перейти на главную страницу

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

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

Мой /etc/fail2ban/jail.local file is (<snip> 'd биты - личные и служебные 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 журналов и никогда не запрещает их. Обычно в течение 10-минутного времени поиска по умолчанию выполняется 8 попыток. Фрагмент использования -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
...

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

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

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

Я надеюсь, что это поможет кому-то еще с аналогичной проблемой.

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

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