Як встановити 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». Ця порада актуальна лише для деяких образів. Стандартний серверний або хмарний образ Ubuntu 24.04 і далі встановлює rsyslog. Його стандартні правила записують auth,authpriv.* до /var/log/auth.log, тому на більшості VPS невдалі спроби входу через SSH потрапляють і до цього файлу, і до журналу systemd. Мінімальні образи (мінімальний хмарний образ Ubuntu 24.04 постачається без rsyslog) і більшість контейнерів записують журнали SSH лише до журналу systemd. У такому разі текстового файлу справді немає. У будь-якому разі пакет Fail2ban для Ubuntu 24.04 уже враховує цю ситуацію. Пакет додає /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 читає журнал systemd, тому не має значення, записує ваш образ auth.log чи ні. banaction = nftables означає, що блокування застосовуються через nftables — саме цей firewall фактично використовує Ubuntu 24.04, а не застарілий iptables. А [sshd] enabled = true означає, що jail увімкнений уже під час першого запуску. Отже, стандартний apt install fail2ban в Ubuntu 24.04 блокує перебір паролів SSH без додаткового налаштування. Переважно потрібно лише перевірити це, налаштувати політику та переконатися, що ви не заблокуєте власний доступ.

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

Крок 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. Не редагуйте цей файл. Оновлення пакета може замінити його, про що попереджає заголовок самого файлу, і ваші зміни буде втрачено. Fail2ban читає файли у фіксованому порядку: спочатку jail.conf, потім jail.d/*.conf в алфавітному порядку, далі jail.local, а потім jail.d/*.local в алфавітному порядку. Перемагає останнє задане значення. Тому jail.local перевизначає встановлений пакетом defaults-debian.conf, але будь-який файл *.local, який ви додасте до jail.d/, буде прочитано після нього й перевизначить це значення; зберігайте власні перевизначення в одному місці, щоб розуміти, яке значення застосовується. Файл .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: Перезапустіть Fail2ban і перевірте, чи читає він журнал

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:   203.0.113.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 203.0.113.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 203.0.113.66

Щоб перевірити весь ланцюжок без очікування, вручну заблокуйте адресу з документації, але ніколи не використовуйте власну адресу. 203.0.113.66 належить до TEST-NET-3 — діапазону, зарезервованого для документації. Тому це не може бути реальною адресою хоста або приватною адресою у мережі вашого провайдера:

sudo fail2ban-client set sshd banip 203.0.113.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, який містить 203.0.113.66, а також ланцюжок f2b-chain, що відхиляє будь-який трафік із джерела в цьому наборі. Якщо fail2ban-client повідомляє, що адресу заблоковано, але в nft list нічого немає, дія блокування не відповідає конфігурації вашого firewall. Див. примітку про nftables/iptables у розділі про типові проблеми.

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

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

sudo fail2ban-client set sshd unbanip 203.0.113.66

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

sudo fail2ban-client unban --all

Не покладайтеся на вже відкритий сеанс SSH: правило nftables відхиляє кожен пакет із заблокованої адреси до порту 22, зокрема пакети для вже встановлених з’єднань. Тому наявний сеанс зависає одразу після застосування блокування. Якщо ви заблокували себе й не маєте запису ignoreip, доступ буде закрито до завершення терміну блокування. Відновіть доступ через вебконсоль провайдера (VNC або serial), яка не використовує 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 вона виникає лише тоді, коли /var/log/auth.log відсутній (в образі немає rsyslog, наприклад у мінімальному образі або контейнері), а журнал не читається: інсталяція pip без defaults-debian.conf, контейнер без journal або зайвий backend = auto, вставлений у jail.local. Якщо використовується файловий backend без /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 і новіші версії), а його journal _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

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

Fail2ban повідомляє, що адресу заблоковано, але вона все одно може підключитися. Лічильник у status sshd збільшується, але адреса все ще досягає порту 22. Це означає, що ban action не узгоджується з 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 action або, якщо ви повністю керуєте firewall через ufw і хочете бачити блокування в ньому, установіть banaction = ufw у [DEFAULT]. Перезапустіть сервіс і перевірте наявність правила за допомогою sudo nft list ruleset | grep f2b.

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

sudo fail2ban-client -t

Команда назве файл і 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 за старим посібником. Це порушує блокування SSH на образі без rsyslog, а отже, і без 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, використайте web-консоль або VNC-консоль свого провайдера й виконайте ту саму команду. Блокування відхиляє кожен пакет із вашої адреси до порту 22, тому перестає працювати навіть уже відкрита сесія. Потім додайте свою адресу до ignoreip, щоб вона не блокувалася знову.

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

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

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

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