Як встановити Fail2ban на Ubuntu 24.04 для SSH

Що насправді робить Fail2ban

Fail2ban — це демон, який читає журнали. Він стежить за повідомленнями про автентифікацію SSH і після кількох невдалих спроб з однієї адреси протягом короткого проміжку часу виконує команду брандмауера, що на певний час блокує цю адресу. У цьому полягає весь принцип роботи. Конфігурація в одному файлі займає приблизно 30 рядків, а в Ubuntu 24.04 встановлення виконується однією командою apt, після чого захист уже активний, навіть якщо ви ще нічого не редагували.

Чітко розумійте, чим є Fail2ban, а чим він не є. Fail2ban не виконує автентифікацію, нічого не шифрує і не зупиняє одну цілеспрямовану спробу входу. Він блокує лише повторні спроби з того самого джерела. Це фільтр шуму й обмежувач частоти запитів, а не блокування доступу. Його завдання — припинити постійне фонове сканування порту 22, щоб воно не витрачало ресурси CPU, мережевий трафік і місце в журналах, а також уповільнити зловмисника, якому доводиться діяти з однієї адреси за раз.

Що Fail2ban не замінює

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

Передумови та реалії Ubuntu 24.04

Вам потрібен VPS під керуванням Ubuntu 24.04 із root або sudo, а також уже налаштованим SSH, бажано з автентифікацією за ключем. Fail2ban споживає мало ресурсів: кілька десятків мегабайт RAM, без потреби налаштовувати ліміти.

Тепер про те, де помиляються майже всі старі посібники. Протягом багатьох років стандартна порада була такою: «встановіть Fail2ban, а потім додайте backend = systemd, тому що Ubuntu припинила записувати /var/log/auth.log». Ця порада описує реальну зміну: сучасні серверні та cloud-образи постачаються без rsyslog, тому SSH записує журнали лише до systemd journal, а цього текстового файла більше немає. Але в Ubuntu 24.04 пакет Fail2ban уже враховує цю зміну. Пакет додає /etc/fail2ban/jail.d/defaults-debian.conf, і саме цей файл, а не стандартні параметри upstream, фактично використовується на сервері:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

Уважно прочитайте цей фрагмент, оскільки він відповідає на два запитання ще до початку налаштування. backend = systemd означає, що jail SSH читає журнал, тому відсутність auth.log не має значення. banaction = nftables означає, що блокування виконуються через nftables — саме цей firewall фактично використовує Ubuntu 24.04, а не застарілий iptables. А [sshd] enabled = true означає, що jail увімкнений уже під час першого завантаження. Отже, стандартний apt install fail2ban в Ubuntu 24.04 блокує SSH-brute-force без додаткового налаштування. Більшість роботи полягає в тому, щоб це підтвердити, налаштувати політику та переконатися, що ви не заблокуєте собі доступ.

Стара проблема з auth.log досі виникає у трьох ситуаціях, і їх варто розпізнавати: ви встановили Fail2ban за допомогою pip замість apt, тому defaults-debian.conf відсутній; ви працюєте всередині непривілейованого контейнера, у якому немає systemd journal для читання; або ви дотримувалися старого посібника й вставили backend = auto у власний jail.local, перевизначивши робочі стандартні параметри. У розділі про типові відмови точно показано, як виглядає кожен із цих випадків.

Крок 1: Встановіть Fail2ban і переконайтеся, що він уже блокує адреси

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 постачається з Fail2ban 1.0.2, а пакет має python3-systemd як жорстку залежність, тому бекенд журналу має все необхідне. Служба автоматично вмикається та запускається:

sudo systemctl status fail2ban

Потрібно отримати active (running). Потім перегляньте jail, який уже працює:

sudo fail2ban-client status sshd

На загальнодоступному VPS, доступному навіть лише кілька хвилин, часто вже видно підраховані невдалі спроби та заблоковані адреси: інтернет безперервно сканує порт 22. Це підтверджує, що стандартна конфігурація працює. Далі ви лише вдосконалюєте її, а не налаштовуєте все з нуля.

Крок 2: Редагуйте jail.local, а не jail.conf

Fail2ban зберігає стандартні налаштування від розробника у /etc/fail2ban/jail.conf. Не редагуйте цей файл. Кожен apt upgrade пакета може замінити його, і ваші зміни зникнуть без попередження. Fail2ban читає файли у фіксованому порядку: спочатку jail.conf, потім усі файли в jail.d/, а далі jail.local; перемагає останнє значення. Файл .local належить вам, і оновлення пакета ніколи його не змінюють. Те саме правило діє для фільтрів: файл *.local замінює поставлений із пакетом filter.d/*.conf.

Тому створіть невеликий jail.local, який перевизначає лише кілька потрібних параметрів, а jail.conf і пакетний jail.d/defaults-debian.conf залиште без змін як довідкові файли.

Крок 3: Створіть /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Додайте цей вміст і замініть адресу в рядку ignoreip на власну публічну IP-адресу:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

Кожен рядок має конкретне призначення:

• bantime, findtime, maxretry — це політика блокування. Стандартне значення bantime, з яким постачається Fail2ban, становить лише десять хвилин; година є розумнішим мінімальним значенням. П’ять невдалих спроб з однієї адреси протягом десяти хвилин призводять до блокування. Звичайний користувач може один або два рази неправильно ввести пароль; п’ять невдалих спроб за десять хвилин свідчать про роботу скрипту.
• ignoreip — це захисний механізм. Додайте сюди публічну адресу, з якої ви підключаєтеся, щоб Fail2ban не заблокував вам доступ до власного сервера. Домашнє підключення зі змінною IP-адресою — це причина наприкінці вибрати підхід із VPN, а не причина пропускати цей рядок.
• bantime.increment = true збільшує тривалість кожного повторного блокування: спочатку до однієї години, потім до двох, далі до чотирьох, але не більше ніж до bantime.maxtime. Адреси, з яких повторно надходять запити, поступово блокуються на довший час.

Знайдіть адресу для додавання до списку дозволених на комп’ютері, з якого ви підключаєтеся через SSH, а не на сервері:

curl -s ifconfig.me

Тут можна згенерувати jail.local, налаштований для ваших портів і політики блокування, а потім вставити його у файл:

Крок 4: Перезапустіть службу та перевірте, чи читає вона журнал

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Команда -t спочатку перевіряє конфігурацію, тому помилка в jail.local одразу проявиться тут, а не залишить службу зупиненою. Стан справного jail має такий вигляд:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

Кількість, яка підтверджує, що Fail2ban справді читає журнал входів, — Total failed. Якщо вона більша за нуль або зростає, коли ви навмисно вводите неправильні облікові дані для входу з іншої машини, журнал читається, і налаштування завершено. Якщо значення залишається рівним 0 незалежно від кількості невдалих спроб, а ви впевнені, що тестуєте не з адреси, зазначеної в ignoreip, перейдіть до наведених нижче сценаріїв несправностей.

Зверніть увагу, що рядок Journal matches і далі містить назву sshd.service. В Ubuntu unit SSH фактично має назву ssh.service, але наданий фільтр також знаходить збіги за _COMM=sshd, а OpenSSH у версії 24.04 записує невдалі спроби від процесу з назвою sshd, тому пошук працює. Це має значення лише для новішої версії OpenSSH (9.8 або пізнішої), де worker для окремого з’єднання має назву sshd-session; цей випадок розглянуто в описі сценаріїв несправностей.

Крок 5: Перегляньте фактичне блокування або примусово створіть його для перевірки

Фактичні блокування самостійно з’являються протягом кількох хвилин на будь-якому публічному VPS. Щоб переглянути одне з них, стежте за журналом:

sudo tail -f /var/log/fail2ban.log

Блокування має такий вигляд:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

Щоб перевірити весь механізм без очікування, вручну заблокуйте адресу для документації, але ніколи не використовуйте власну:

sudo fail2ban-client set sshd banip 10.0.0.66

Команда виведе 1, а адреса з’явиться в Banned IP list у fail2ban-client status sshd. Тепер переконайтеся, що блокування справді додано до firewall. В Ubuntu 24.04 використовується nftables, а не iptables:

sudo nft list table inet f2b-table

Ви побачите набір із назвою addr-set-sshd, що містить 10.0.0.66, і ланцюжок f2b-chain, який відхиляє будь-яке джерело з цього набору. Якщо fail2ban-client повідомляє, що адресу заблоковано, але в nft list нічого немає, дія блокування не відповідає вашому firewall. Див. примітку про nftables/iptables у розділі про типові помилки.

Крок 6: Зніміть блокування для власної адреси та відновіть доступ, якщо вас заблоковано

Якщо ви помилково заблокували адресу, зокрема власну, видаліть її зі списку блокування:

sudo fail2ban-client set sshd unbanip 10.0.0.66

У разі успіху команда повертає 1. Щоб зняти всі блокування в усіх jail:

sudo fail2ban-client unban --all

Не покладайтеся на вже відкрите SSH-сеанс як на спосіб зберегти доступ: блокування nftables відхиляє всі пакети із заблокованої адреси до порту 22, зокрема пакети вже встановлених з’єднань. Тому наявний сеанс зависає одразу після застосування блокування. Якщо ви заблокували власну адресу й не маєте запису ignoreip, доступ буде заблоковано до завершення терміну блокування. Відновіть доступ через вебконсоль вашого провайдера (VNC або послідовну консоль), яка не використовує SSH, а потім дочекайтеся завершення bantime або виконайте там команду для зняття блокування.

Крок 7: Зробіть блокування постійними та поступово посилюйте їх

Fail2ban зберігає активні блокування в невеликій базі даних SQLite у /var/lib/fail2ban/fail2ban.sqlite3, тому вони зберігаються після перезапуску служби або перезавантаження системи. Ви їх не втрачаєте. Додані раніше рядки bantime.increment перетворюють кожне повторне порушення на проблему, наслідки якої для порушника поступово посилюються: тривалість блокування приблизно подвоюється — від однієї години до одного тижня.

Щоб додатково запровадити загальносистемну політику «трьох порушень», Fail2ban постачається з jail recidive. Він відстежує власний /var/log/fail2ban.log і накладає тривалі блокування на будь-яку адресу, яку неодноразово блокували в різних jail. Оскільки ваш [DEFAULT] тепер використовує backend systemd, поверніть для цього jail читання спеціально призначеного для нього файлу журналу:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

backend = auto із явним logpath забезпечує, що recidive читає звичайний fail2ban.log. Саме там фактично з’являються рядки Ban, які він підраховує. Встановлений глобально backend systemd спрямовував би його до journal, де ці рядки відсутні.

Крок 8: Поєднайте його з SSH лише за ключами, а ще краще — з VPN

Fail2ban ефективний лише разом із автентифікацією за ключами. У drop-in-файлі в каталозі /etc/ssh/sshd_config.d/, наприклад у /etc/ssh/sshd_config.d/00-hardening.conf, задайте:

PasswordAuthentication no
KbdInteractiveAuthentication no

Потім виконайте sudo systemctl restart ssh. Якщо вимкнути паролі, brute force взагалі не зможе завершитися успішно. Тоді Fail2ban потрібен для зменшення шуму в журналах і раннього блокування сканерів. Ще надійніше повністю прибрати SSH із публічного інтернету: розмістіть SSH за self-hosted WireGuard VPN і налаштуйте firewall для порту 22 так, щоб він приймав з’єднання лише через тунель. Неможливо виконати brute force для порту, до якого немає доступу. Fail2ban у такій схемі є додатковим захистом, а не першим рубежем.

Fail2ban призначений не лише для SSH. Будь-який сервіс, який записує невдалі спроби входу, можна захистити jail: поштовий сервер, сайт nginx або self-hosted менеджер паролів Vaultwarden, веб-форму входу до якого краще не залишати відкритою для credential stuffing. Коли вебзастосунок працює за сайтом nginx із сертифікатом Let's Encrypt, налаштуйте фільтр Fail2ban для його access log так само, як jail для SSH використовує журнал.

Типові відмови з точними рядками, які ви побачите

"Have not found any log file for sshd jail", і Fail2ban не запускається. Це стара проблема auth.log. В Ubuntu 24.04 вона виникає лише в таких випадках: щось перевизначило стандартне значення пакета, виконано встановлення pip без defaults-debian.conf, контейнер не має журналу або в jail.local випадково вставлено зайвий backend = auto. У файловому бекенді без /var/log/auth.log jail sshd не може знайти журнал, тому весь daemon аварійно завершує роботу. fail2ban.log показує:

ERROR   Failed during configuration: Have not found any log file for sshd jail

Оскільки ця помилка критична, сервіс не запускається. Після цього fail2ban-client status повідомляє про вторинний симптом:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

Рядок про "socket path" не означає, що Fail2ban пошкоджений. Він означає, що Fail2ban не запустився, оскільки один із jail не зміг знайти журнал. Встановлення backend = systemd у [DEFAULT], яке пакет Ubuntu уже виконує за вас, усуває обидва повідомлення.

Jail активний, але Total failed не змінюється. Daemon працює, журнал читається, але реальні невдалі спроби накопичуються в journalctl -u ssh, тоді як лічильник залишається на 0. Спочатку виключіть очевидну причину: ви тестуєте з адреси, зазначеної в ignoreip, тому ваші власні невдалі спроби навмисно ігноруються. Якщо причина не в цьому, ви використовуєте збірку OpenSSH, у якій worker для окремого підключення є sshd-session (9.8 і новіші версії). У її журналі _COMM має значення sshd-session, а не sshd, тому вбудований match не знаходить такі записи. Розширте match у блоці [sshd]:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Перезапустіть сервіс, навмисно виконайте невдалий вхід з адреси, якої немає в ignoreip, і переконайтеся, що Total failed нарешті збільшується.

Ви заблокували себе: Connection refused. Ви не додали власну адресу до ignoreip, виконали кілька невдалих спроб входу, і тепер бачите:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Відмова замість тайм-ауту означає, що стандартний вердикт reject дії nftables спрацював саме проти вас. Виправте це, як описано в кроці 6: скасуйте блокування з сеансу на іншій, не заблокованій адресі або через консоль провайдера. Уже відкритий сеанс із заблокованої адреси також зависне. Потім додайте власну адресу до ignoreip, щоб це не повторилося.

Fail2ban повідомляє, що адресу заблоковано, але вона все одно може підключитися. Лічильник у status sshd збільшується, але адреса все ще досягає порту 22. Це невідповідність між дією блокування та налаштуваннями firewall. В Ubuntu 24.04 це майже завжди означає, що ви перевизначили робочий banaction = nftables значенням banaction = iptables-multiport зі старого посібника на сервері без шару iptables. fail2ban.log показує:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

Видаліть це перевизначення та залиште пакетну дію nftables. Або, якщо ви повністю керуєте firewall через ufw і хочете, щоб блокування відображалися там, встановіть banaction = ufw у [DEFAULT]. Перезапустіть сервіс і перевірте появу правила за допомогою sudo nft list ruleset | grep f2b.

Fail2ban не запускається після редагування jail.local. Через описку, зайвий заголовок або неправильне значення часу сервіс може відмовитися запускатися. Перед запуском попросіть Fail2ban перевірити конфігурацію:

sudo fail2ban-client -t

Fail2ban назве файл і jail із проблемою, наприклад Errors in jail 'sshd'. Skipping.... Так ви виправите джерело проблеми, а не вгадуватимете причину.

FAQ

Чи справді стандартне встановлення Fail2ban в Ubuntu 24.04 блокує атаки на SSH?

Так. Пакет містить /etc/fail2ban/jail.d/defaults-debian.conf, який вмикає jail sshd, задає backend = systemd, щоб читати журнал systemd замість відсутнього /var/log/auth.log, і задає banaction = nftables, щоб блокування застосовувалися через фактичний firewall Ubuntu. Звичайний apt install fail2ban захищає SSH від першого запуску. Перевірте це за допомогою sudo fail2ban-client status sshd і знайдіть ненульове значення Total failed.

Чому Fail2ban нічого не блокує на моєму сервері?

Послідовно виключіть три поширені причини. Можливо, ви тестуєте з адреси, яка входить до ignoreip і навмисно звільнена від блокування. Можливо, ви замінили робоче стандартне налаштування, вставивши backend = auto у jail.local за старим посібником. Це порушує читання журналу в образі без auth.log. Або ви працюєте всередині контейнера, де взагалі немає журналу systemd для читання. Перевірте Total failed у fail2ban-client status sshd: якщо його значення не зростає, тоді як journalctl -u ssh показує реальні невдалі спроби, jail читає не те джерело.

Як розблокувати власну IP-адресу?

Виконайте sudo fail2ban-client set sshd unbanip YOUR.IP.HERE. У разі успіху команда повертає 1. Щоб скасувати всі блокування, виконайте sudo fail2ban-client unban --all. Якщо доступ до SSH заблоковано, скористайтеся веб-консоллю або VNC-консоллю вашого провайдера й виконайте ту саму команду. Заблокована адреса не може надсилати жодних пакетів на порт 22, тому навіть уже відкрите з’єднання перестає працювати. Потім додайте свою адресу до ignoreip, щоб це не повторилося.

У чому різниця між jail.conf і jail.local?

jail.conf містить стандартні налаштування Fail2ban від розробників і перезаписується під час кожного оновлення пакета. Тому будь-які зміни в цьому файлі зрештою буде втрачено. Пакет Debian/Ubuntu накладає власні налаштування через jail.d/defaults-debian.conf. Ваші зміни потрібно зберігати в jail.local. Цей файл читається останнім і має пріоритет над обома іншими файлами. Під час оновлення його вміст не змінюється. Використовуйте jail.conf лише як довідковий файл.

Чи замінює Fail2ban автентифікацію SSH за допомогою ключів?

Ні. Fail2ban обмежує частоту повторних невдалих спроб з однієї адреси. Він не захищає від повільного розподіленого підбору, коли кожна адреса залишається нижче встановленого порога. Автентифікація лише за ключем (PasswordAuthentication no) повністю унеможливлює підбір пароля. Fail2ban після цього зменшує кількість зайвих записів у журналі та рано блокує сканери. Використовуйте обидва механізми. Бажано також повністю не відкривати SSH у публічному інтернеті.