мой сервер в настоящее время атакован некоторыми детишками скриптов. Я установил 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 причины:
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"]
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.
Я не уверен, могут ли эти правила привести к проблемам!