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