Налаштування Fail2Ban: чому перебір паролів доходить до сервісу
Точка входу сервісу відкрита назовні за визначенням — інакше ним не користуються. Щойно сервіс стає доступним ззовні, він стає ціллю: автоматизовані спроби підбору облікових даних ідуть безперервним потоком з розподілених адрес, і кожна залишає запис у журналах доступу.
Перебір паролів не потребує зламу чогось конкретного — достатньо слабких облікових даних і повної відсутності реакції на спроби.
Саме тут і втрачається контроль. Журнали фіксують кожен невдалий вхід, але між появою запису та рішенням заблокувати джерело минає час, за який встигають пройти десятки тисяч запитів.
Ручний розбір журналу не масштабується, а простий поріг «стільки-то спроб з однієї адреси» обходиться: атака розмазує спроби по сотнях джерел, і окремо кожне залишається нижче порога спрацювання.
Для працюючого сервісу це не абстрактна загроза. Навантаження на автентифікацію зростає, журнали роздуваються, легітимні користувачі в години пік отримують уповільнений відгук і відмови входу.
Якщо підбір облікових даних завершується успіхом, зловмисник отримує ту саму сесію, що й звичайний клієнт, і далі діє всередині периметра, не привертаючи уваги.
Fail2Ban закриває цей розрив: він читає журнали в темпі їх появи та блокує джерело на рівні мережевого фільтра, поки спроби тривають.
Але результат дає не встановлення, а налаштування Fail2Ban під конкретну точку входу — власні шаблони фільтрації, окремі строки блокування для різних сервісів, список довірених адрес і відпрацьований порядок зняття бану. Навіть страхувальне блокування власного адміністратора коштує дорожче за саму атаку.
Нижче розбираємо, як це закривається без хибних спрацювань.
Що змінюється після впровадження: класи атак і час реакції
До налаштування основна частина звернень до точки входу — це підбір пароля, сканери та боти, які цілодобово ходять формами входу. Такий потік не ламає сервіс одразу, але з'їдає слоти підключень, забиває журнали й підвищує шанс, що одна з тисяч спроб виявиться вдалою.
Fail2Ban закриває саме цей клас відмов: правило рахує невдалі спроби в заданому вікні, при перевищенні порога блокує джерело й тримає блокування стільки, скільки потрібно.
Час реакції на інцидент змінюється на порядок. Раніше ланцюжок виглядав так: черговий помічає аномалію, розбирає журнали, вручну додає адресу в правила фільтрації — від сплеску до реакції минали години, а вночі й узагалі до ранку.
Тепер спрацювання автоматичне, і інженер отримує сповіщення вже про факт блокування, а не про проблему, яка все ще триває.
За навантаженням ефект теж вимірюваний: сміттєві запити перестають доходити до застосунку, точка входу не впирається в ліміт одночасних підключень, а простій сервісу через вичерпання ресурсів зникає як клас.
Доступність сервісу перестає залежати від того, хто на чергуванні й наскільки швидко він встиг зреагувати.
Порядок робіт тут не менш важливий за результат. Спочатку режим спостереження та білі списки для офісних адрес, вузлів моніторингу й підрядників, потім підбір порога й тривалості вікна під профіль трафіку, і лише потім реальне блокування.
Так налаштування не відрізає своїх, а зібрана статистика показує, яка частка звернень була паразитною — зазвичай вона помітно знижує загальне навантаження на сервіс.
Fail2Ban налаштування: варіанти розміщення та режими блокування
Захист від перебору ставлять на самому сервісі, на прикордонному вузлі або в окремому контурі. Обмежувач один: фільтр бачить лише той трафік, який через нього проходить, тому охоплення схем різниться, і вибір тут роблять за кількістю точок входу, а не за звичкою.
| Варіант розміщення | Коли підходить | Обмеження |
|---|---|---|
| Захист на сервері, поряд із сервісом | Один-два сервіси, сталий список вузлів | Правила дублюються на кожному вузлі, нові вузли залишаються без захисту до ручної правки |
| Захист на периметрі: зворотний проксі, балансувальник | Єдина точка входу, сервіси стоять за проксі | Потрібен коректний розбір вихідної адреси клієнта, інакше блокуються адреси самого проксі |
| Окремий контур збору логів | Десятки вузлів, різнорідні сервіси | Затримка реакції та залежність від доставки логів |
Fail2Ban працює в будь-якій із трьох схем: читає журнали сервісу, застосовує правила й передає блокування на міжмережевий екран, а в контурному варіанті отримує ті самі записи із загальної точки збору.
Режими блокування та строки утримання
Жорсткість режиму вибирають за характером трафіку: м'який — затримка й обмеження частоти звернень, середній — тимчасове блокування адреси на короткий строк, жорсткий — повне блокування джерела з наростаючим строком при повторах.
Строк утримання порушника задається окремо від порога спрацювання. Короткий відсікає випадкові сплески, довгий і наростаючий тримає наполегливий перебір, але потребує дозвільного списку — інакше під блокування потраплять власні інженери й системи моніторингу.
Етапи впровадження: від аудиту журналів до передачі в підтримку
Налаштування Fail2Ban не зводиться до встановлення пакета: правило, поставлене навмання, або блокує легітимних клієнтів, або мовчить на реальній атаці.
Тому йдемо послідовно — від спостереження за журналами до документа, за яким ваша команда зможе супроводжувати захист самостійно.
- Аудит журналів. Знімаємо зріз за період: які сервіси пишуть про невдалі входи, у якому форматі, як часто, чи є нічні сплески й адреси-джерела, що повторюються з дня на день.
- Інвентаризація точок входу. Зводимо в один список сервіси, порти й облікові записи, доступні ззовні, — інакше захист закриє частину входу, а решта залишиться відкритою.
- План впровадження та схема. Фіксуємо, що блокується, на який строк, як задаються винятки для моніторингу, резервного копіювання та службових адрес.
- Налаштування фільтрів. Пишемо шаблони розбору під ваші формати журналів і підбираємо пороги спрацювання так, щоб правило не відсікало живих користувачів.
- Перевірка на тестовому контурі. Відтворюємо сценарій перебору: правило спрацьовує, легітимний вхід проходить, блокування знімається після закінчення строку.
- Вивід у робочий режим. Перший час спостерігаємо, розбираємо спірні спрацювання й коригуємо пороги — і лише потім віддаємо систему в супровід.
- Передача регламенту. Віддаємо документ: які правила діють, чому трапляються хибні спрацювання і що робити під час атаки.
Склад передачі: конфігурації фільтрів, правила та регламенти
Налаштування — це не разова команда, а набір артефактів, який залишається у вас у репозиторії та на серверах. Ми передаємо все разом із розбором: чому вибрано такий поріг, що потрапить під блокування і як це відкотити. Нижче — що саме ви отримуєте на руки.
- Конфігурації фільтрів — окремі набори правил під конкретні сервіси: доступ за SSH, вебсервер, пошту, панель керування. Кожен фільтр перевірено на реальних рядках логів, а не на демонстраційних прикладах.
- Пороги блокування — значення
maxretry,findtimeіbantimeза кожним сервісом з обґрунтуванням: для SSH і для форми входу вони різні, бо ціна хибного спрацювання різниться. - Довірчі списки — адреси офісу, вихідних вузлів захищеного доступу, систем моніторингу та резервного копіювання. Окремим пунктом — як список підтримувати при зміні адрес, щоб не заблокувати власні перевірки.
- Правила винятків — фільтри проти блокування легітимних роботів пошукових систем і внутрішніх сканерів, які інакше регулярно потрапляють у бан і створюють хибні сповіщення.
- Схема взаємодії з міжмережевим екраном — які ланцюжки використовуються, як знімається блокування достроково і як поводиться конфігурація при перезапуску вузла.
- Регламент реакції — хто отримує сповіщення, за який час розбирає, що робить при масовій атаці з сотень адрес і коли ескалує питання.
- Документація — карта конфігурацій, розташування логів, порядок відтворення налаштування на новому вузлі та чек-ліст перевірки після оновлення.
Усе це переживає зміну підрядника: інженер, який відкриє комплект за пів року, зрозуміє логіку рішень без листування з нами.
Кейс: захист відсік перебір без втрати легітимних входів
Що було до
Сервіс авторизації тримав назовні два входи — віддалений доступ адміністраторів і панель керування. У добових журналах осідало 40–60 тисяч невдалих спроб входу, і майже всі доходили до перевірки пароля: єдиним бар'єром залишалася його довжина.
Штатні правила Fail2Ban були увімкнені формально — один набір умов і поріг, за якого блокування спрацьовувало в найкращому разі раз на добу. Перебір забивав журнали, реальні події в них губилися, а на розбір інциденту минали години.
Що змінили
Пройшли по всіх точках входу й завели окремий набір правил для кожної: віддалений доступ, панель, пошта, вебсервіс. Поріг вивели з фактичного розподілу — вікно спостереження 10 хвилин, блокування після п'яти невдач, при повторі з тієї самої адреси строк зростає.
Білий список зібрали з адрес офісу, захищеного каналу та систем моніторингу. Правила фільтрації написали свої, а не шаблонні: частина спроб ішла через проксі, і в журнал потрапляла адреса посередника, а не порушника.
Що вийшло
До сервісу тепер доходить близько двох сотень спроб на добу замість десятків тисяч — решту відсікається на периметрі. Час реакції на реальний інцидент скоротився з годин до хвилин: у журналах залишилися лише осмислені події.
Хибних блокувань за перший місяць — одиниці, і кожне знімалося однією командою без перезапуску служби, тому відновлення доступу займало менше хвилини. Легітимні користувачі змін не помітили: білий список і м'який поріг залишили їм звичний сценарій входу.
Чим відрізняється блокування на периметрі від захисту на самому сервері?
Периметр — це точка застосування захисту до того, як трафік дійде до застосунку: зовнішній фільтр або балансувальник відсікає потік запитів цілком.
Масові атаки він гасить добре, але бачить лише мережевий рівень і не розрізняє підбір пароля до панелі адміністратора та перебір облікових записів через прикладний інтерфейс.
Fail2Ban працює на самому сервері: серія невдалих входів із журналу служби перетворюється на правило файрвола, яке блокує адресу на заданий час. Видно, з яким обліковим записом і як часто намагалися ввійти.
Зворотний бік — потрібно розбирати журнали всіх служб із входом і вести білий список, інакше під бан потраплять свої адреси або перевірки моніторингу.
У кожного варіанта своя межа: периметр не знає про логіку застосунку й пропускає повільний перебір з різних адрес, а серверний захист не масштабується на десятки машин — при додаванні нових вузлів списки блокувань розходяться, і вузол починає з чистого аркуша.
Змішана схема закриває обидві діри: периметр тримає грубі сплески, а на серверах іде точна реакція за журналами. Бани синхронізуються між вузлами через спільне сховище, тому атакувальник не перемикається на сусідній сервер після блокування.
Окремо налаштовується видимість атак: зведення за спробами входу та заблокованими адресами показує, чи працює захист і де поріг варто послабити або посилити. У налаштуванні Fail2Ban цей шар вирішує не менше, ніж самі правила блокування.
Часті сумніви: хибні спрацювання, доступи та сумісність
Більшість сумнівів навколо фільтрації перебору зводиться до одного: чи не заблокує захист своїх. Вузькі місця передбачувані — спільна адреса в офісу або балансувальника, помилкові введення пароля в пікові години, сервіси, що пишуть журнали в нестандартному форматі.
Розбираємо кожне, бо ціна невірного налаштування — не «незручно», а втрата доступу до робочого контуру.
Окрема тема — увімкнення на живому контурі. Правило й фільтр ставлять у режим спостереження, статистика спрацювань збирається кілька діб, і лише потім вмикається блокування. Налаштування йде без зупинки сервісів і вікна простою.
Співробітник кілька разів помилився паролем — його заблокує?
Список довірених адрес знімає цей ризик: офісні підмережі та адреси адміністраторів виключені з блокування. Поріг спрацювання налаштовується під пікові години, а не під середній день.
Доступ іде через проксі або балансувальник — що тоді?
Потрібен розбір ланцюжка адрес і обробка заголовка пересилання: інакше всі запити видно як одну адресу і перший же перебір відсіче весь офіс. Довірені проксі вносяться окремо, перевірка — на реальному трафіку.
Чи сумісно із сервісами, які пишуть журнали інакше?
Так, під нестандартний формат пишеться свій фільтр і шаблон розбору. Логіка перевіряється на справжніх рядках журналу, а не на синтетичних прикладах — інакше правило або не спрацює, або спрацює на нормальному вході.
Що робити із застарілими правилами?
Ревізія перед запуском: знімаються завислі блокування, прибираються фільтри під сервіси, яких уже немає, звіряється карта портів. Накопичене сміття дає хибні спрацювання й заважає розбору інцидентів.
Обговорімо задачу: що потрібно від вас для швидкого старту
Щоб обговорення задачі одразу перейшло в інженерну площину, а не в листування з уточненнями, достатньо мінімального набору відомостей і доступів. Готове технічне завдання не потрібне — опишіть ситуацію своїми словами, решту зберемо самі й повернемося з оцінкою та планом робіт.
- Що захищаємо: перелік серверів і сервісів, де fail2ban уже працює або лише має стати, і яка гілка використовується зараз.
- Точки входу: за якими портами йдуть підключення до SSH, панелей адміністрування та вебсервісів, чи є нестандартні або опубліковані назовні.
- Доступи для старту: обліковий запис із правами на читання конфігурацій і перезапуск служби або підключення через захищений канал із журналюванням сесії.
- Що вже налаштовано: поточні правила блокувань, білі списки, зв'язка з міжмережевим екраном, спосіб доставки конфігурації на вузли.
- Як влаштований вхід зараз: за ключами чи паролем, де зберігаються журнали, як ви відрізняєте своїх від чужих.
- Пріоритети та строки робіт: що критично закрити першим, чи є вікно обслуговування й обмеження на перезапуск сервісів.
- Обмеження: вимоги до безпеки, заборона на встановлення додаткових пакетів, вимоги до зберігання даних про блокування.
Опишіть задачу — повернемося з оцінкою, планом і межами робіт.
