fail2ban: баним brute-force-атакующих по логам

01Идея: охранник, который читает журнал посещений

Представьте охранника клуба, который каждые несколько секунд заглядывает в журнал. Если один и тот же человек пять раз за десять минут назвал неверный пароль, его не пускают час. Это и есть fail2ban. Технически это демон на Python, который следит за лог-файлами или журналом systemd, сопоставляет каждую новую строку с регулярными выражениями, считает совпадения по IP-адресам и при превышении порога выполняет действие — обычно добавляет правило файрвола (nftables, iptables или ufw), которое отбрасывает пакеты атакующего. По истечении времени бана он удаляет правило. Это называется защитой от вторжений на основе логов: сам он трафик не анализирует, а реагирует на то, что уже пишут в лог ваши сервисы. Поэтому он лёгкий и не зависит от конкретного сервиса: защитить можно всё, что логирует неудачи вместе с IP.

02Jail, фильтры и действия

fail2ban состоит из трёх частей. Фильтр (filter.d/*.conf) — набор регулярных выражений, которые распознают неудачу в строке лога и захватывают хост тегом <HOST>. Действие (action.d/*.conf) говорит, что делать при бане и разбане: правила файрвола, вызов API Cloudflare, письмо. Jail связывает их вместе: какой лог читать, какой фильтр и действие использовать и какие пороги. Пороги — это три числа. maxretry — сколько неудач приводит к бану. findtime — окно, в которое эти неудачи должны произойти. bantime — сколько длится бан. С bantime.increment повторные нарушители каждый раз получают более долгий бан. Jail recidive идёт дальше: он следит за собственным логом fail2ban и на дни банит IP, которые раз за разом попадают в бан. Никогда не правьте jail.conf, его перезаписывают обновления; кладите свои настройки в jail.local или jail.d/*.local.

• maxretry = 5, findtime = 10m, bantime = 1h — разумная отправная точка.
• ignoreip гарантирует, что адреса вашего офиса или VPN никогда не будут забанены.
• В Ubuntu 24.04 и новее jail sshd читает журнал systemd (backend = systemd), а не /var/log/auth.log.

03Практичный jail.local для SSH и nginx

Эта конфигурация защищает SSH и типичные случаи nginx с помощью фильтров, которые идут в комплекте с fail2ban. nginx-http-auth ловит неудачные входы через basic auth, nginx-botsearch ловит ботов, запрашивающих известные пути эксплойтов, которые возвращают 404, а nginx-limit-req банит клиентов, раз за разом упирающихся в rate limit nginx (работает, только если вы настроили limit_req). Recidive разбирается с настойчивыми атакующими. В Ubuntu устанавливайте через apt install fail2ban; пакет уже включает jail sshd через jail.d/defaults-debian.conf с действием nftables. После правок выполните fail2ban-client reload и проверьте статус. Если вы используете ufw и предпочитаете видеть баны в ufw status, задайте banaction = ufw.

1# /etc/fail2ban/jail.local
2[DEFAULT]
3bantime  = 1h
4findtime = 10m
5maxretry = 5
6bantime.increment = true
7ignoreip = 127.0.0.1/8 ::1 203.0.113.10
8 
9[sshd]
10enabled  = true
11backend  = systemd
12maxretry = 3
13 
14[nginx-http-auth]
15enabled = true
16[nginx-botsearch]
17enabled = true
18[recidive]
19enabled  = true
20bantime  = 1w
21findtime = 1d

04Пишем собственный фильтр

Защитить можно всё, что логирует неудачи. Частый пример: сайт на Laravel или Next.js, который постоянно прощупывают в поисках страниц входа WordPress и утёкших файлов .env. На сайте без WordPress такие запросы никогда не бывают легитимными, так что даже несколько штук — сильный сигнал. Фильтр ниже находит такие запросы в access-логе nginx (формат combined по умолчанию, где IP клиента — первое поле). Всегда проверяйте новый фильтр через fail2ban-regex на реальном логе, прежде чем включать его: он показывает, сколько строк совпало, и ловит ошибки в регулярках, из-за которых не забанили бы никого — или всех. Если сайт стоит за Cloudflare или другим прокси, сначала настройте модуль real_ip в nginx, иначе в логе будет IP прокси, и вы забаните сам прокси.

1# /etc/fail2ban/filter.d/nginx-probe.conf
2[Definition]
3failregex = ^<HOST> -.*"(GET|POST|HEAD) /(wp-login\.php|xmlrpc\.php|\.env|\.git/)
4ignoreregex =
5 
6# /etc/fail2ban/jail.d/nginx-probe.local
7[nginx-probe]
8enabled  = true
9port     = http,https
10logpath  = /var/log/nginx/access.log
11maxretry = 2
12bantime  = 1d
13 
14# Test before enabling
15sudo fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-probe.conf

05Проверка, разбан и отладка

fail2ban-client — инструмент управления. status показывает активные jail, status с именем jail — текущие неудачи и забаненные IP, а set jail unbanip снимает бан (например, когда коллега слишком часто ошибался в пароле). Лог fail2ban, /var/log/fail2ban.log, фиксирует каждый бан и разбан с именем jail — это первое место, куда смотреть, когда кто-то говорит, что его заблокировало. Если jail никогда никого не банит, проверьте три вещи: jail действительно включён (status его показывает), он читает правильный источник (путь к логу или backend systemd), и фильтр действительно совпадает со строками (fail2ban-regex). Если он банит, а трафик всё равно приходит, возможно, действие не соответствует вашему файрволу или трафик идёт через прокси, IP которого не совпадает с IP атакующего.

1sudo fail2ban-client status                 # list active jails
2sudo fail2ban-client status sshd            # failures and banned IPs for one jail
3sudo fail2ban-client banned                 # all banned IPs, per jail
4sudo fail2ban-client set sshd unbanip 203.0.113.10
5sudo fail2ban-client unban 203.0.113.10     # remove from every jail
6sudo fail2ban-client reload                 # apply config changes
7sudo tail -f /var/log/fail2ban.log
8sudo nft list ruleset | grep -A3 f2b        # see the firewall rules it created

06Ограничения, и fail2ban против CrowdSec

fail2ban видит атаки только после того, как они появились в логе, и оценивает каждый IP отдельно. Распределённая атака с тысяч адресов, каждый из которых пробует один-два раза, никогда не превысит порог. Он ничего не делает против уязвимостей в вашем приложении, а бан в файрволе сервера не помогает, когда трафик приходит через прокси CDN, потому что соединение идёт от CDN; там нужно действие, блокирующее на краю (в fail2ban есть действия для Cloudflare), или собственные правила WAF у CDN. Поэтому относитесь к нему как к снижению шума поверх настоящих мер: SSH только по ключам, файрвол с запретом по умолчанию, rate limits в nginx и WAF вроде Cloudflare впереди. CrowdSec — современная альтернатива: он разбирает логи похожим образом, но отделяет обнаружение от блокировки (bouncers для файрвола, nginx или Cloudflare) и делится сигналами со своим сообществом, так что IP, атакующий других, может быть заблокирован ещё до того, как доберётся до вас. Он мощнее, но в нём больше движущихся частей и есть онлайн-компонент.

07Внутри движка: backend, даты и база банов

У каждого jail есть backend, который доставляет новые строки лога. systemd читает журнал напрямую и фильтрует по юниту — именно это нужно современной Ubuntu для SSH. Для обычных файлов auto пробует pyinotify и при неудаче переходит на polling. Каждая строка должна содержать метку времени, которую fail2ban распознаёт; чтобы решить, попадает ли неудача в findtime, он использует время из лога, а не время чтения строки. Неверный datepattern или несовпадение часовых поясов делают неудачи «старыми», и jail молча никогда не банит. Баны сохраняются в базе SQLite /var/lib/fail2ban/fail2ban.sqlite3, поэтому восстанавливаются после рестарта или перезагрузки. dbpurgeage, по умолчанию один день, определяет, как долго хранится история банов. Это важно для recidive и инкрементальных банов: если findtime у recidive — неделя, а история чистится через день, повторных нарушителей никогда не распознают. Поднимите dbpurgeage в fail2ban.local выше самого длинного findtime.

1# /etc/fail2ban/fail2ban.local
2[Definition]
3dbpurgeage = 8d      # must be longer than recidive findtime
4 
5# Check which date format and lines a filter matches
6sudo fail2ban-regex systemd-journal sshd
7sudo fail2ban-regex --print-all-missed /var/log/nginx/access.log nginx-probe

08Инкрементальные баны: наказание повторных нарушителей

Фиксированный бан на час учит бота возвращаться через шестьдесят одну минуту. С bantime.increment fail2ban смотрит, сколько раз адрес уже банили, и умножает бан. Формула по умолчанию каждый раз удваивает его (время бана, умноженное на два в степени числа банов), так что 1h превращается в 2h, 4h, 8h и так далее; bantime.multipliers позволяет вместо этого задать явную последовательность. bantime.maxtime ограничивает рост, чтобы ошибка не заблокировала реального пользователя на месяцы, а bantime.rndtime добавляет случайную добавку, чтобы боты не могли точно рассчитать момент разбана. bantime.overalljails = true учитывает предыдущие баны из всех jail, а не только текущего: адрес, который вчера сканировал nginx, сегодня получает более длинный бан по SSH. Вместе с постоянной историей это часто делает отдельный jail recidive ненужным, хотя держать оба не вредно.

1# /etc/fail2ban/jail.local
2[DEFAULT]
3bantime  = 1h
4bantime.increment   = true
5bantime.factor      = 1
6bantime.maxtime     = 1w
7bantime.rndtime     = 10m
8bantime.overalljails = true
9# alternative to the formula:
10# bantime.multipliers = 1 2 4 8 16 32 64

09Action на масштабе: наборы nftables, IPv6 и edge

Старые action для iptables добавляли по правилу на каждый забаненный адрес, и каждый пакет проходил весь этот список, что при тысячах банов становится медленным. Action для nftables, которые используют Debian и Ubuntu, кладут адреса в set внутри inet f2b-table — это поиск по хэшу независимо от размера, и он охватывает IPv4 и IPv6 в одной таблице. Вариант allports блокирует все порты, что полезно для recidive, а multiport — только порты jail. IPv6 требует размышлений: fail2ban банит отдельные адреса, но один атакующий может контролировать целую /64 и просто менять адреса. Это ещё одна причина считать настоящей защитой rate limit и SSH только по ключам. Для HTTP за Cloudflare action cloudflare-token создаёт правило доступа в зоне через Cloudflare API с токеном ограниченных прав, так что блокировка происходит на edge, куда трафик на самом деле приходит. Комбинируйте его с локальным action, чтобы SSH и прямые обращения к origin по-прежнему блокировались на сервере.

1# See the nftables sets fail2ban maintains
2sudo nft list table inet f2b-table
3 
4# jail.d/nginx-probe.local: block locally and at Cloudflare
5[nginx-probe]
6action = %(action_)s
7         cloudflare-token[cfzone="your_zone_id", cftoken="your_scoped_token"]

10Фильтры, которыми нельзя злоупотребить

Фильтр превращает недоверенный текст в правила файрвола, так что это граница безопасности. Логи часто содержат поля под контролем атакующего: имя пользователя, URL, User-Agent. Если регулярное выражение не заякорено, атакующий может вписать в такое поле IP-адрес жертвы и заставить вас забанить её — например, вашего платёжного провайдера или сервис мониторинга. Из-за этого риска log injection штатные фильтры якорятся на фиксированной структуре строки и захватывают <HOST> только там, где адрес клиента пишет сам сервис. Правила для собственных фильтров: якорьте через ^ и сопоставляйте точный формат лога, захватывайте хост из поля, которое контролирует ваш сервер, делайте шаблон специфичным для одного смысла неудачи и избегайте вложенных жадных wildcard, которые медленны на длинных строках. Для заведомо нормального трафика, например health check, используйте ignoreregex. Перед включением протестируйте через fail2ban-regex на неделе реальных логов и посмотрите и совпавшие, и пропущенные строки.