Fail2ban у Linux: повний посібник з налаштування захисту SSH від brute force у 2026 році

Можна подумати, що brute force-атаки на SSH — це вже минуле століття. Але статистика 2025–2026 років каже зовсім інше. За даними Cisco Talos, десь з березня 2024-го спостерігається стрімке зростання кількості атак перебором на SSH-сервіси, і у 2025-му тенденція тільки посилилась. Чесно кажучи, сучасні GPU-кластери зробили підбір паролів швидшим, ніж будь-коли раніше — а дослідження USENIX показало, що Fail2ban зі стандартними налаштуваннями блокує близько 66,1% атак, а при правильному тюнінгу — до 85,2%.

Цей матеріал — практичне керівництво 2026 року з налаштування Fail2ban на Ubuntu 24.04 LTS і Debian 12. Розберемо архітектуру, побудуємо багаторівневий захист SSH з прогресивним банування, підключимо nftables (так, iptables вже пора лишити в минулому), додамо рецидивну клітку, власні фільтри та інтеграцію з SIEM-платформами на кшталт Wazuh.

Що таке Fail2ban і чому він критично важливий у 2026 році

Fail2ban — це фреймворк запобігання вторгненням (IPS), написаний на Python. Він моніторить лог-файли на наявність ознак шкідливої активності й автоматично блокує IP-адреси порушників через правила брандмауера. Працює як демон у фоні та споживає мінімум ресурсів — зазвичай менше 50 МБ RAM. Скромний, але працьовитий.

У контексті сучасної безпеки Linux Fail2ban виконує три критичні функції:

• Активне запобігання перебору паролів — автоматичне блокування IP-адрес після N невдалих спроб;
• Захист від ботнетів — зменшення навантаження на SSH-демон від скриптів, що сканують інтернет без утоми 24/7;
• Автоматична документація атак — журнал усіх спроб і банів для подальшого аналізу в SIEM.

І все ж давайте одразу розставимо крапки над «і»: Fail2ban — це доповнення, а не заміна SSH-ключів, вимкнення root-входу та зміни стандартного порту. Це лише один із шарів оборони в глибину (defense in depth). Важливий, але не єдиний.

Архітектура Fail2ban: три компоненти

Щоб ефективно налаштувати Fail2ban, треба розуміти його будову. Усе тримається на трьох простих речах.

1. Фільтри (Filters)

Фільтри — це регулярні вирази, які шукають у лог-файлах ознаки атак. Зберігаються вони у /etc/fail2ban/filter.d/. Наприклад, фільтр sshd шукає рядки на кшталт Failed password for user у /var/log/auth.log або у systemd journal.

2. Клітки (Jails)

Клітки пов'язують фільтр з конкретним сервісом і визначають, що робити при спрацюванні. Основні параметри клітки:

• maxretry — максимальна кількість невдалих спроб;
• findtime — часове вікно, у якому рахуються спроби;
• bantime — тривалість блокування;
• action — що робити з порушником (зазвичай — додати правило в брандмауер).

3. Дії (Actions)

Дії — це скрипти у /etc/fail2ban/action.d/, які, власне, і виконують блокування. У 2026 році стандартом стало використання nftables замість застарілого iptables. Якщо ви досі на iptables — саме час мігрувати.

Встановлення Fail2ban на Ubuntu 24.04 та Debian 12

На сучасних дистрибутивах встановлення — справа буквально хвилини. З офіційних репозиторіїв:

sudo apt update
sudo apt install -y fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2ban

Перевірте версію — у 2026-му актуальна гілка Fail2ban 1.1.x:

fail2ban-client --version
# Fail2ban v1.1.0

На RHEL/Rocky Linux/AlmaLinux 9 знадобиться EPEL:

sudo dnf install -y epel-release
sudo dnf install -y fail2ban
sudo systemctl enable --now fail2ban

Базова конфігурація: створення jail.local

Ключове правило, яке я повторюю кожному новачку: ніколи не редагуйте /etc/fail2ban/jail.conf. Цей файл перезаписується під час оновлень пакунка, і ваші налаштування просто зникнуть. Замість нього створіть jail.local:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Для зручності краще розбити конфігурацію на окремі файли в /etc/fail2ban/jail.d/. Створіть /etc/fail2ban/jail.d/defaults.local:

[DEFAULT]
# Глобальні налаштування для всіх кліток
bantime  = 1h
findtime = 10m
maxretry = 3

# Прогресивне банування — ключова можливість 2026 року
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w
bantime.rndtime = 300

# Backend — systemd journal (сучасний стандарт)
backend = systemd

# Whitelist локальних адрес
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24

# Використовуємо nftables замість iptables
banaction = nftables-multiport
banaction_allports = nftables-allports

# Email-сповіщення (необов'язково)
destemail = [email protected]
sender = [email protected]
mta = sendmail
action = %(action_mwl)s

Налаштування захисту SSH

Створіть окремий файл для SSH-клітки — /etc/fail2ban/jail.d/sshd.local:

[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = %(sshd_log)s
backend  = systemd
maxretry = 3
findtime = 10m
bantime  = 1h

# Агресивний режим — ловить більше типів атак
mode = aggressive

# Прогресивне банування для цієї клітки
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w

Параметр mode = aggressive активує додаткові регулярні вирази. Вони ловлять не лише невдалі паролі, а й спроби перебору користувачів, слабкі алгоритми шифрування та підозрілі запити KEX. Я особисто завжди вмикаю його на продакшн-серверах — ніколи не пошкодував.

Recidive: другий рівень захисту від рецидивістів

Recidive jail — це метаклітка, яка моніторить сам лог Fail2ban і банує IP-адреси, що вже кілька разів потрапляли в інші клітки. Простий, але дуже ефективний шар проти наполегливих ботів.

Створіть /etc/fail2ban/jail.d/recidive.local:

[recidive]
enabled  = true
filter   = recidive
logpath  = /var/log/fail2ban.log
action   = %(action_)s
bantime  = 1w
findtime = 1d
maxretry = 3

Логіка проста: якщо IP було забанено у будь-якій клітці 3 рази протягом доби — вона блокується на цілий тиждень. Це робить brute force економічно невигідним для атакуючих, бо ресурси бота витрачаються в порожнечу.

Інтеграція з nftables замість iptables

У старих гайдах досі фігурує iptables, але Ubuntu 24.04 та Debian 12 давно перейшли на nftables як основний брандмауер. Добра новина — Fail2ban має вбудовану підтримку nftables через дію nftables-multiport, тож нічого велосипедити не треба.

Переконайтеся, що у вашому jail.local встановлено:

banaction = nftables-multiport
banaction_allports = nftables-allports
chain = INPUT

А потім перевірте, що Fail2ban створив свій набір правил:

sudo nft list ruleset | grep f2b

Ви побачите приблизно таке:

table inet f2b-table {
    set addr-set-sshd {
        type ipv4_addr
        elements = { 185.234.219.77, 192.168.100.13 }
    }
    chain f2b-chain {
        type filter hook input priority -1; policy accept;
        tcp dport 22 ip saddr @addr-set-sshd reject
    }
}

Повсякденне адміністрування: fail2ban-client

Основний інструмент керування — fail2ban-client. Ось найкорисніші команди, які ви будете використовувати щодня:

# Статус всієї служби
sudo fail2ban-client status

# Детальний статус клітки sshd
sudo fail2ban-client status sshd

# Розбанити конкретну IP-адресу
sudo fail2ban-client set sshd unbanip 185.234.219.77

# Заблокувати IP вручну
sudo fail2ban-client set sshd banip 203.0.113.42

# Перезавантажити конфігурацію без перезапуску
sudo fail2ban-client reload

# Перевірити, чи активна клітка
sudo fail2ban-client get sshd bantime

Приклад виводу статусу sshd-клітки:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     847
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 12
   |- Total banned:     156
   `- Banned IP list:   185.234.219.77 203.0.113.42 ...

Створення власного фільтра: приклад захисту nginx

Fail2ban легко розширюється під свої потреби. Припустимо, ви хочете банувати IP, які генерують купу 404-помилок на nginx (типова поведінка сканерів уразливостей). Створіть /etc/fail2ban/filter.d/nginx-404.conf:

[Definition]
failregex = ^<HOST> - .* "(GET|POST|HEAD).*" 404 .*$
ignoreregex =

А тепер додайте клітку в /etc/fail2ban/jail.d/nginx-404.local:

[nginx-404]
enabled  = true
port     = http,https
filter   = nginx-404
logpath  = /var/log/nginx/access.log
maxretry = 20
findtime = 5m
bantime  = 2h

І обов'язково — перед тим, як пускати це в бій, протестуйте фільтр:

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-404.conf

Інтеграція з SIEM: передача подій у Wazuh

Для централізованого моніторингу безпеки події Fail2ban варто пересилати в SIEM-платформу. Wazuh — найпоширеніша open-source альтернатива у 2026 році — має вбудовані правила декодування логів Fail2ban. Тобто, жодної магії налаштовувати не треба.

Якщо агент Wazuh уже встановлено на сервері, достатньо додати моніторинг лог-файлу в /var/ossec/etc/ossec.conf:

<localfile>
    <log_format>syslog</log_format>
    <location>/var/log/fail2ban.log</location>
</localfile>

Після перезапуску агента у дашборді Wazuh з'являться події з правилами групи fail2ban. Що це дає на практиці? Можливість корелювати бани з іншими подіями безпеки — наприклад, зі спрацюваннями auditd, сканами nmap чи змінами файлової системи (FIM). А це вже справжня видимість.

Типові помилки та troubleshooting

Помилка: Fail2ban не бачить невдалих спроб

Найчастіша причина — невідповідність backend. На Ubuntu 24.04 systemd journal за замовчуванням не пише в /var/log/auth.log. Переконайтеся, що backend = systemd встановлено саме в клітці sshd, а не десь поруч.

Помилка: правила nftables не створюються

Перевірте, що пакет nftables встановлено і що немає конфлікту з UFW:

sudo apt install -y nftables
sudo ufw disable  # або налаштуйте сумісність

Помилка: «я заблокував себе»

Класика жанру. Буває з кожним хоча б один раз. Якщо ви випадково забанили свою власну IP, використайте консоль провайдера (наприклад, serial console у VPS) і виконайте:

sudo fail2ban-client unban --all
# або
sudo systemctl stop fail2ban

Щоб подібного більше не траплялось, завжди (без винятків) додавайте свою робочу IP чи мережу в ignoreip. Це правило врятувало мене щонайменше тричі.

Найкращі практики 2026 року

1. Завжди використовуйте прогресивне банування — bantime.increment = true з фактором 2 і максимумом 1 тиждень.
2. Розгортайте recidive-клітку — це суттєво зменшує навантаження від повторюваних атак.
3. Комбінуйте з іншими заходами: SSH-ключі замість паролів, вимкнення PermitRootLogin, зміна стандартного порту, 2FA через Google Authenticator.
4. Моніторте логи Fail2ban — інтегруйте з SIEM або хоча б з Grafana+Loki.
5. Регулярно переглядайте правила — принаймні раз на квартал перевіряйте, чи не застаріли ваші фільтри.
6. Використовуйте nftables, не iptables — це стандарт у сучасних дистрибутивах.
7. Не забувайте про IPv6 — багато адмінів досі фокусуються тільки на IPv4, а атакуючі цим охоче користуються.

Поширені запитання (FAQ)

Чи достатньо самого Fail2ban для захисту SSH?

Коротка відповідь — ні. Fail2ban — це лише один шар захисту. Для повноцінного захисту SSH у 2026 році потрібно: автентифікація за ключами замість паролів, вимкнення входу root, зміна стандартного порту, ввімкнення MFA (multi-factor authentication), обмеження доступу через брандмауер за IP та, за можливості, використання bastion host або SSH-сертифікатів.

Скільки ресурсів споживає Fail2ban?

Дуже мало. На типовому VPS Fail2ban займає 30–60 МБ RAM і менше 1% CPU. Навантаження відчутно зростає хіба що при дуже великих лог-файлах (>10 ГБ) або десятках активних кліток. У таких випадках варто додати usedns = no і точно використовувати systemd backend замість polling.

Чи буде Fail2ban блокувати CloudFlare або reverse proxy?

Так, якщо веб-сервер логує IP проксі, а не оригінального клієнта. І це реально проблема, з якою я стикався не раз. Для nginx/Apache налаштуйте mod_realip або ngx_http_realip_module, щоб у логах відображалися справжні IP-адреси клієнтів. Інакше ризикуєте забанити IP CloudFlare і повністю втратити доступ до свого ж сайту.

Fail2ban vs CrowdSec — що краще у 2026 році?

CrowdSec — новіша альтернатива з краудсорсингом IP-репутації та сучасною архітектурою на Go. Fail2ban перевірений роками, простіший у налаштуванні, вбудований у більшість дистрибутивів. Для типових задач захисту SSH Fail2ban цілком достатньо. CrowdSec варто розглядати для великих інфраструктур з багатьма сервісами, де цінується спільне виявлення загроз.

Як експортувати список заблокованих IP для аналізу?

Використайте команду sudo fail2ban-client banned (доступна з версії 1.0.2) — вона повертає JSON з усіма активними банами по всіх клітках. Для історичних даних парсіть /var/log/fail2ban.log:

grep 'Ban ' /var/log/fail2ban.log | awk '{print $NF}' | sort -u

Висновки

Fail2ban у 2026 році залишається одним з найефективніших і найекономніших інструментів захисту SSH та інших мережевих сервісів від brute force-атак. Кілька хвилин коректного налаштування — прогресивне банування, recidive-клітка, інтеграція з nftables і SIEM — блокують понад 85% спроб перебору паролів. Для безкоштовного інструмента це, чесно кажучи, вражає.

Але не забувайте головне: Fail2ban — це доповнення до SSH-ключів, 2FA й належного хардинга системи. Справжня безпека завжди будується з декількох шарів, і цей інструмент — один з найдешевших і найефективніших серед них.

Наступні кроки: розгляньте інтеграцію Fail2ban з системою аудиту auditd, налаштування централізованого моніторингу через Wazuh або Elastic Stack, і періодичний перегляд правил nftables — усе це разом і створює ту саму глибоку оборону вашої Linux-інфраструктури.