Fail2Ban: вже заборонено?

У мене на сервері Centos працює Fail2Ban. (Налаштування нижче)

У своєму var / log / messages я помітив щось по-справжньому дивне:

Jun 19 12:09:32 localhost fail2ban.actions: INFO   [postfix] 114.43.245.205 already banned

Я налаштував Fail2Ban для додавання забороненого IP до iptables.

Мій jail.conf:

[postfix]

enabled  = true
filter   = postfix
action   = iptables
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/maillog
bantime  = 43200
maxretry = 2

Мій postfix.conf:

[INCLUDES]

before = common.conf

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 550 5.1.1
            reject: RCPT from (.*)\[<HOST>\]: 450 4.7.1
            reject: RCPT from (.*)\[<HOST>\]: 554 5.7.1
            reject: RCPT from (.*)\[<HOST>\]: (.*)@yahoo.com.tw
ignoreregex =

Моє запитання: як можна все, хто вже заблокований, iptablesвсе-таки підключитися до сервера?

Рецидивна в'язниця, рекомендована в іншій відповіді тут, не вирішила для мене питання. Я врешті-решт це виправив, тому ось мій метод на випадок, якщо він допомагає іншим.

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. nano /etc/sysctl.conf

2. Додайте ці два рядки:

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

3. Вийдіть і збережіть файл.
4. Запустіть sysctl -p, щоб зміни вступили в силу.

Після цього запустіть програму fail2ban-client reload, і ви більше не бачите цих "вже заборонених" повідомлень, якщо вас не спамує 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-ForIP-адреси замість реальної адреси джерела, яка в моєму випадку була балансиром навантаження.

У цьому випадку fail2ban не дуже допоможе, оскільки заборона правопорушника може порушити весь трафік.

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

Перш ніж почати, ось моя система:

• Плеск 12
• Centos 7
• Для мене встановлений Plesk-модуль, функціонування та налаштування fail2ban

Коли я встановив OpenVPN на своєму rootserver, я переключив firewalld на iptables. Це могло спричинити для мене цю проблему, але окрім того, що моя система була здебільшого недоторканою та досить свіжо встановленою (Strato rootserver запропонував встановити образ).

Якщо у вас є ця проблема, перевірте /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, але оскільки постфікс, можливо, не закінчив обробку всієї його електронної пошти, 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

дивись /unix//a/525798/22315

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