Fail2Ban: уже забанен?

Повторная тюрьма, рекомендованная в другом ответе здесь, не устранила проблему для меня. В конце концов я исправил это, поэтому вот мой метод на случай, если он поможет другим.

По умолчанию Fail2ban блокирует только TCP. По крайней мере, с моей настройкой я заметил, что сообщение «уже заблокировано» появлялось, когда боты возвращались, чтобы вместо этого попробовать заблокированный порт через UDP.

Чтобы решить эту проблему, скажите Fail2ban блокировать порт по всем протоколам, а не только по TCP. Вам нужно будет внести это изменение в /etc/fail2ban/jail.conf и в [Init] раздел каждого действия, которое вы используете в /etc/fail2ban/action.d/.

Измените это:

# Default protocol
protocol = tcp

Кому:

# Default protocol
protocol = all

Затем я отключил эхо-запросы ICMP, чтобы заблокированные IP-адреса не могли попасть на сервер:

1. нано /etc/sysctl.conf

2. Добавьте эти две строки:

   net.ipv4.icmp_echo_ignore_all = 1  
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   

3. Выйдите и сохраните файл.
4. Бегать sysctl -p чтобы изменение вступило в силу.

После этого запустите fail2ban-client перезагрузка и вы больше не должны видеть эти «уже заблокированные» сообщения, если только вы не засылаете спамом с IP-адреса, который делает пару попыток доступа до того, как блокировка вступит в силу.

Кроме того, важно заблокировать все порты для каждого нарушителя, а не порт, к которому они пытались получить доступ, с помощью действия iptables-allports в каждом из джейлов. В противном случае они могут запустить еще одну тюрьму и оказаться в журналах как «уже забаненные».

Если вы посмотрите на вывод iptables-save, вы увидите, что fail2ban цепочки настроены так, что они оценивают пакеты в соответствии с правилами, определенными фильтрами, например:

:fail2ban-ssh - [0:0]
-A INPUT -p tcp -A INPUT -p tcp -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh 
-A fail2ban-ssh -j RETURN

Трафик все еще доходит до сервера до того, как будут применены другие правила маршрутизации и трафик будет отклонен. fail2ban по-прежнему видит этот начальный трафик, и поэтому вы видите сообщения «уже заблокированы». Кроме того, для рецидивистов есть специальный фильтр (/etc/fail2ban/filter.d/recidive.conf):

# Fail2Ban filter for repeat bans
#
# This filter monitors the fail2ban log file, and enables you to add long
# time bans for ip addresses that get banned by fail2ban multiple times.
#
# Reasons to use this: block very persistent attackers for a longer time,
# stop receiving email notifications about the same attacker over and
# over again.
#
# This jail is only useful if you set the 'findtime' and 'bantime' parameters
# in jail.conf to a higher value than the other jails. Also, this jail has its
# drawbacks, namely in that it works only with iptables, or if you use a
# different blocking mechanism for this jail versus others (e.g. hostsdeny
# for most jails, and shorewall for this one).

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = fail2ban\.server\.actions

# The name of the jail that this filter is used for. In jail.conf, name the
# jail using this filter 'recidive', or change this line!
_jailname = recidive

failregex = ^(%(__prefix_line)s| %(_daemon)s%(__pid_re)s?:\s+)WARNING\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$

[Init]

journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=4

# Author: Tom Hendrikx, modifications by Amir Caspi

Это произойдет, если заблокированный IP-адрес не фактически IP-адрес клиента, который подключается к серверу. Например. если ваш сервер находится за балансировщиком нагрузки или прокси.

Недавно мне потребовалось довольно много времени, чтобы понять это. Красная сельдь заключалась в том, что журналы были настроены для сбора X-Forwarded-For IP-адрес, а не реальный адрес источника, который в моем случае был балансировщиком нагрузки.

В этом случае fail2ban не сильно поможет, поскольку запрет на неправильный IP приведет к блокировке все трафик.

Я хочу предложить свою проблему и решение с "уже забаненными" сообщениями. Как вы писали, я получил их сотни за считанные минуты, а злоумышленник уже должен был быть забанен.

Прежде чем я начну, вот моя система:

• Plesk 12
• Centos 7
• Plesk-Module установлен, работает и настраивает fail2ban для меня

Когда я установил OpenVPN на свой корневой сервер, я переключил firewalld на iptables. Это могло вызвать у меня эту проблему, но помимо этого моя система была в основном нетронутой и была установлена ​​совсем недавно (корневой сервер Strato предложил установочный образ).

Если у вас возникла эта проблема, проверьте /etc/fail2ban/jail.d/00-firewalld.conf для строки, которая выглядит так:

banaction = firewallcmd-ipset

С тех пор, как я закомментировал это, сохранил файл и перезапустил fail2ban.service, с fail2ban все было хорошо. Больше сообщений нет

Я не эксперт, но надеюсь дать вам правильный ответ. Если это сработает для вас, дайте мне знать!

У меня вопрос: как любой, кто уже был заблокирован в iptables, все еще может подключиться к серверу?

Он подключался к серверу только один раз, но в этом одном подключении он пытался доставить несколько писем в предположительно несуществующие почтовые ящики (например, info@domain.com, sales@domain.com, tech@domain.com и т. Д.)

Вы настроили свой постфиксный фильтр, чтобы запретить эти попытки, поэтому IP будет заблокирован после X попыток. Возможно, клиент уже отключен от postfix, но, поскольку postfix, возможно, не завершил обработку всей своей электронной почты, fail2ban может обнаружить еще одну попытку от того же клиента, когда postfix обрабатывает свою почту, и, таким образом, вы получаете адрес сообщения уже забаненный. Это из-за того, как работает постфиксная очередь.

У меня вопрос: как любой, кто уже был заблокирован в iptables, все еще может подключиться к серверу?

Невероятно хороший вопрос. Я искал, не работают ли мои правила брандмауэра, но iptables --list-rules точно соответствует другому производственному серверу с работающим fail2ban.

Сногсшибательное решение заключалось в добавлении порта 8080 к заблокированным портам, поскольку я все еще заходил на страницу входа через порты разработки.

Итак, исправление в моей ситуации заключается в том, что эта проблема была довольно простой адаптацией моего jail.local:

[JIRA-LOGIN-tcp]
  enabled = true
  port = http,https,8080
  protocol = tcp
  filter = JIRA-LOGIN-ERROR
  logpath = /var/atlassian/application-data/jira/log/atlassian-jira-security.log
  bantime = 600
  maxretry = 1

видеть https://unix.stackexchange.com/a/525798/22315

у вас, вероятно, отсутствует порт 587 в строке "port =", и вы можете проверить файл конфигурации постфикса или выполнить команду "lsof -i: 587", чтобы напрямую узнать, настроен ли postfix для открытия этого порта.

У меня была эта проблема, просто отсутствовали порты в параметре действий

Переход на port = "pop3, imap, imaps, smtp, smtps" решил проблему (см. Файлы в каталоге jail.d)

Если вы используете контейнеры Docker для запуска своего приложения, но fail2ban на хосте, вы можете столкнуться с этой проблемой: https://github.com/fail2ban/fail2ban/issues/2292

Заимствуя там обходные пути, это можно исправить, настроив в файле jail.local строку:

[YOUR-JAIL-NAME]
chain = DOCKER-USER
...

Или для Kubernetes

chain = KUBE-FIREWALL

См. Дополнительную информацию: https://github.com/fail2ban/fail2ban/issues/2292#issuecomment-593216779

В некоторых случаях другим вариантом может быть использование сети хоста вместо сети Docker, см. https://docs.docker.com/network/host/