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

UFW + fail2ban не работает с `nginx` для блокировки сценариев атаки

мой сервер в настоящее время атакован некоторыми детишками скриптов. Я установил fail2ban который правильно запрещает IP.

2020-01-07 05:51:45,639 fail2ban.actions        [1656]: WARNING [nginx-botsearch] 123.207.92.128 already banned
2020-01-07 05:51:47,802 fail2ban.filter         [1656]: INFO    [nginx-botsearch] Found 123.207.92.128 - 2020-01-07 05:51:47
2020-01-07 05:51:48,026 fail2ban.filter         [1656]: INFO    [nginx-botsearch] Found 123.207.92.128 - 2020-01-07 05:51:48
2020-01-07 05:51:48,242 fail2ban.actions        [1656]: WARNING [nginx-botsearch] 123.207.92.128 already banned
2020-01-07 05:51:49,228 fail2ban.filter         [1656]: INFO    [nginx-botsearch] Found 123.207.92.128 - 2020-01-07 05:51:49

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
Anywhere                   DENY IN     123.207.92.128            

Какой первый правило

2020-01-07 05:51:45,639 fail2ban.actions        [1656]: WARNING [nginx-botsearch] 123.207.92.128 already banned
2020-01-07 05:51:47,802 fail2ban.filter         [1656]: INFO    [nginx-botsearch] Found 123.207.92.128 - 2020-01-07 05:51:47
2020-01-07 05:51:48,026 fail2ban.filter         [1656]: INFO    [nginx-botsearch] Found 123.207.92.128 - 2020-01-07 05:51:48
2020-01-07 05:51:48,242 fail2ban.actions        [1656]: WARNING [nginx-botsearch] 123.207.92.128 already banned
2020-01-07 05:51:49,228 fail2ban.filter         [1656]: INFO    [nginx-botsearch] Found 123.207.92.128 - 2020-01-07 05:51:49

Но, как видите, IP-адрес уже заблокирован, и злоумышленник все еще может получить к нему доступ.

Интересно, как такое возможно?

Я протестировал это в своей локальной сети и обнаружил, что все еще могу получить доступ к домен но не IP. Я думаю, это потому, что тогда он использует IPv6. Но почему тогда я не получаю запись в журнале IPv6?

Мой домен настроен с использованием CNAME. Это правда? Я не знаю, знает ли злоумышленник домен, но он может быть перенаправлен на него.

Но, как видите, IP-адрес уже заблокирован, и злоумышленник все еще может получить к нему доступ.

Эта проблема похожа https://github.com/fail2ban/fail2ban/issues/2545

Вкратце: keep-alive против ufw (поэтому я предлагаю не использовать его или расширить действие, чтобы убить соединение).

Но почему тогда я не получаю запись в журнале IPv6?

На то есть 2 причины:

  • либо ваша версия fail2ban <= 0.9 (поддержка IPv6 впервые реализована в 0.10);
  • или зарегистрированное сообщение выглядит немного по-другому для IPv6, поэтому failregex больше не соответствует этому (перепишите failregex, совместимый для обоих семейств);

UPD 1:

  • либо (лучше) поместите правило для установленных соединений после цепочки с правилами fail2ban, либо просто удалите правило, заносящее в белый список установленное соединение;
  • или вы можете использовать что-то вроде этого, чтобы убить все установленное соединение с IP-адреса на оба локальных порта http / https:
ss -o state established -K dst $ip 'sport = 80 or sport = 443'

Обратите внимание на это ожидаемое современное ядро ​​(я полагаю, версия> = 4.9).
Вы также можете добавить его прямо в jail.local (без создания нового конфигурационного файла локального действия):

[some-nginx-jail]
_killstmt = ss -o state established -K dst <ip> 'sport = 80 or sport = 443'
banaction = %(known/banaction)s[actionban="<known/actionban><br>%(_killstmt)s"]
  • или заставить nginx закрыть соединение из-за неудачной аутентификации (например, использовать собственное местоположение 40x с keepalive_timeout 0;, который также может записывать ошибку в другой лог-файл, чтобы избежать «паразитного» трафика в смысле fail2ban, см. fail2ban / wiki / Лучшая практика # сокращение-паразит-журнал-трафик для получения дополнительной информации);
    или просто сделать return 444; в соответствующем месте, что приведет к закрытию соединения (см. http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return для документации)

Как заметил @sebres в своем ответе, это поведение должно быть вызвано HTTP Keep-Alive. Если вы хотите fail2ban для немедленной блокировки запросов от удаленного клиента можно добавить определяемую пользователем цепочку (например, before-established) в iptables и поместите его непосредственно перед ESTABLISHED,RELATED правило по цепочке ufw-before-input (бегать iptables -nv --line-numbers ufw-before-input чтобы перечислить их):

iptables -N before-established
iptables -I ufw-before-input <desired_position> -p tcp --dport 80 -j before-established

и сделай то же самое для ip6tables. Если вы остановите UFW, правила останутся в /etc/ufw/before.rules и будет восстановлен между перезапусками UFW. В противном случае добавьте две строки вручную (iptables-save -t ufw-before-input для синтаксиса).

Чтобы использовать новую цепь с fail2ban вы можете создать новый файл действия в /etc/fail2ban/action.d (назовем это before-established.conf) со следующим содержанием:

[INCLUDES]

before = iptables-common.conf

[Definition]

blocktype = DROP

actionflush = <iptables> -F before-established

actionstart = <actionflush>

actionstop = <actionflush>

actioncheck = <iptables> -n -L before-established >/dev/null

actionban = <iptables> -I before-established 1 -s <ip> -j DROP

actionunban = <iptables> -D before-established -s <ip> -j DROP

[Init]

и используйте это действие вместо ufw один.

Как отметил @sebres (большое спасибо !!), причиной такого поведения являются поддерживающие соединения.

Вы можете ограничить количество запросов keepalive в nginx.

редактировать /etc/nginx/nginx.conf и добавить

keepalive_timeout 20; # this was already here but set to 65. 
keepalive_requests 20;

в http раздел.

Это должно ограничить соединения keepalive до 20 и 20 запросов на соединение.

Аналогичные правила должны быть и для Apache.

Дополнительно, вы также можете добавить эти правила в ufw. Преимущество в том, что вы можете использовать эти правила на любом порте, который хотите. Но большинство этих сценариев атаки используют порты 80 и 443.

Я не уверен, могут ли эти правила привести к проблемам!