CrowdSec замість Fail2ban: коли краудсорсингова безпека для Linux-сервера справді має сенс

CrowdSec замість Fail2ban – це не просто заміна одного демона іншим, а перехід від локальних банів до моделі, де сервер отримує сигнали про атакувальні IP не лише зі своїх логів. У цьому сценарії головне питання просте: чи дає такий підхід реальну користь на одному Linux-сервері або в невеликому homelab, і чи не додає він більше складності, ніж захисту.

Якщо Fail2ban вже блокує SSH brute force, міграція не завжди виправдана. Але коли на сервері одночасно висять SSH, reverse proxy, self-hosted панелі, веб-додатки й кілька сервісів за публічною адресою, CrowdSec починає виглядати переконливіше. Він бачить більше патернів, а реакція може спрацювати ще до того, як конкретний IP встигне впертися саме у ваш хост.

На практиці crowdsec замість fail2ban має сенс там, де потрібен не просто бан по regex, а нормальна кореляція подій між сервісами. У homelab це особливо помітно на вузлах з Nginx, SSH і адмінками, які постійно отримують фоновий шум з інтернету.

Коли CrowdSec справді кращий за Fail2ban

CrowdSec виграє там, де один журнал уже не дає повної картини. Якщо атака розмазана між SSH, веб-сервером і формами логіну, crowdsec замість fail2ban зазвичай спрацьовує точніше, бо оцінює сценарій, а не окремий збійний рядок у логу.

Fail2ban сильний своєю прямолінійністю. Є лог, є фільтр, є jail, є бан. Для одного сервісу цього часто достатньо. Проблема починається тоді, коли правил стає багато, а поверхня атаки росте. Кожен новий сервіс додає ще один набір шаблонів, ще одну точку відмови і ще один блок, який треба тримати в голові після оновлень.

CrowdSec побудований інакше. Він аналізує журнали, визначає сценарії атаки і передає рішення механізму блокування. Окремо працюють bouncer-компоненти, які застосовують ці рішення на firewall, reverse proxy або прикладному рівні. Цей поділ не завжди простіший на старті, зате краще масштабується, якщо на хості не один SSH і nginx, а кілька публічних сервісів.

Є й неочевидний момент. У маленькому homelab Fail2ban може бути надійнішим саме через меншу кількість рухомих частин. Якщо вузол один, сервіси два, а журнали стандартні, CrowdSec іноді виявляється зайвим шаром. Зате на edge-сервері з постійним фоновим скануванням користь від спільного сигналу про погані IP відчувається значно швидше.

Як працює crowdsec замість fail2ban на Linux-сервері

CrowdSec для Linux-сервера працює як ланцюг із трьох частин: збір логів, розбір сценаріїв і виконання блокувань. Це відрізняє його від Fail2ban, де одна система і читає журнал, і вирішує, кого банити, і часто одразу пише правила у firewall.

Спочатку агент читає журнали сервісів. Далі парсери нормалізують події, а сценарії визначають, чи виглядає потік як brute force, enumeration або інша типова атака. Після цього рішення потрапляє до локального API, звідки його забирає bouncer. Саме bouncer вже блокує IP через nftables, iptables, reverse proxy або іншу точку застосування.

Сильна сторона цієї схеми – розділення логіки виявлення й логіки блокування. Через це легше міняти спосіб реакції без повного перекроювання правил аналізу. Слабка сторона теж очевидна: якщо зламався парсер, API або bouncer, доведеться діагностувати не один процес, а кілька.

Для homelab це важливо з практичної причини. Помилки в CrowdSec частіше з’являються не на рівні самого бану, а на стику журналів і парсерів. Якщо сервіс пише нестандартний лог або проксі ховає реальний IP, система може чесно працювати, але аналізувати не те, що потрібно.

Базове налаштування CrowdSec на Debian або Ubuntu

Для базового запуску потрібно встановити агент, перевірити, які журнали він читає, і підключити firewall bouncer. Якщо мета – замінити Fail2ban на одному сервері, краще спочатку закрити SSH і веб-сервер, а вже потім чіпати інші сервіси.

1. Додати офіційний репозиторій CrowdSec і встановити агент та bouncer. Актуальні пакети й інструкції варто брати з офіційного сайту CrowdSec.

2. Переконатися, що сервер пише журнали SSH і веб-сервера у стандартні шляхи, які агент реально бачить.

3. Увімкнути bouncer для firewall. На сучасних дистрибутивах логічно орієнтуватися на nftables, якщо саме він використовується як основний backend.

4. Подивитися, які парсери та колекції активні, і не тягнути зайве. Для одного вузла надмірний набір сценаріїв лише ускладнює діагностику.

5. Лише після перевірки вимкнути Fail2ban, щоб не отримати подвійні бани й плутанину в правилах firewall.

sudo apt install crowdsec crowdsec-firewall-bouncer-nftables
sudo systemctl enable --now crowdsec
sudo systemctl enable --now crowdsec-firewall-bouncer

Назви пакетів можуть відрізнятися залежно від дистрибутива й способу підключення репозиторію, тому орієнтуватися треба на офіційну інструкцію для конкретної системи. Суть процесу не змінюється: агент окремо, bouncer окремо.

Нормальна тактика міграції така: спочатку запустити CrowdSec паралельно, але не вимикати Fail2ban у той самий момент. Коли видно, що рішення створюються, а блокування доходять до firewall, тоді старі jail вже можна прибирати. Інакше одна помилка в лог-шляху залишить хост без захисту, а помітно це стане лише після чергової хвилі brute force.

Як перевірити, що CrowdSec реально блокує, а не просто крутиться в systemd

Перевірка CrowdSec має включати три речі: чи читаються логи, чи створюються рішення, і чи доходять вони до механізму блокування. Запущений сервіс ще нічого не означає. У реальному житті половина проблем ховається між парсером і bouncer, а не в статусі systemd.

sudo cscli metrics
sudo cscli decisions list
sudo systemctl status crowdsec
sudo systemctl status crowdsec-firewall-bouncer

У метриках має бути видно, що журнали надходять і розбираються. У списку рішень – що з’являються активні decisions. Якщо там порожньо під час очевидного шуму по SSH або nginx, проблема майже напевно в логах, форматі записів або довіреному IP-ланцюжку за reverse proxy.

Далі варто дивитися вже на firewall. Якщо рішення є, а трафік не ріжеться, несправний або неправильно підключений саме bouncer. Це типова пастка після міграції на nftables: агент працює, decisions видно, але backend блокування налаштований не тим способом, який реально використовується на хості.

Ще одна корисна перевірка – подивитися, чи не баниться власна підмережа через проксі або hairpin NAT. У домашній інфраструктурі це трапляється частіше, ніж здається, особливо якщо адмінки відкриваються через той самий reverse proxy, що й зовнішні сервіси.

Де crowdsec замість fail2ban зазвичай ламається

Найчастіше CrowdSec ламається не через сам механізм бану, а через неправильний контекст логів. Якщо reverse proxy не передає коректний клієнтський IP, система починає бачити атаки від локальної адреси проксі. У такій схемі можна швидко заблокувати власний frontend і довго шукати причину.

• Нестандартні журнали сервісів. Парсер не збігається з форматом, події не нормалізуються.

• Подвійна реакція разом із Fail2ban. Обидві системи банять ті самі IP, і відлагодження стає брудним.

• Помилка з trust chain за reverse proxy. Блокується не клієнт, а внутрішній вузол або балансувальник.

• Невідповідний bouncer. Рішення створюється, але конкретний спосіб блокування не працює.

• Занадто широкий набір колекцій. На маленькому сервері це дає шум замість користі.

Є й практичне обмеження, про яке рідко думають на старті. CrowdSec краще відчувається на вузлах із постійним інтернет-шумом. Якщо сервер майже закритий, зовнішнього веба немає, а ззовні доступний лише SSH по ключах і VPN, ефект від краудсорсингової моделі буде скромний. У такій схемі Fail2ban або навіть просто жорстка мережна політика часто дають той самий результат з меншою складністю.

З іншого боку, коли Linux-сервер стоїть на публічному IP і фронтує кілька self-hosted сервісів, crowdsec замість fail2ban починає давати більш осмислену реакцію. Особливо там, де атака виглядає не як грубий brute force, а як серія дрібних проб через різні точки входу.

Що вибрати для homelab: CrowdSec чи Fail2ban

Вибір між CrowdSec і Fail2ban зводиться не до того, який інструмент новіший, а до структури сервісів. Для одного-двох стандартних демонів Fail2ban досі залишається тверезим варіантом. Для кількох публічних сервісів за reverse proxy CrowdSec частіше окупає свою складність.

Для homelab-роутера, VPN-шлюзу або мінімалістичного VPS перевантажувати систему CrowdSec не завжди розумно. Для self-hosted вузла з публічним Nginx, SSH, SSO і кількома адмінками це вже інша історія. Там Fail2ban часто перетворюється на набір латок, а CrowdSec виглядає цілісніше.

Тверезий висновок такий: crowdsec замість fail2ban варто ставити не заради модної назви, а коли локальний бан по логах уже не встигає за реальною поверхнею атаки. Якщо ж інфраструктура проста, найкраща заміна Fail2ban – не CrowdSec, а менша кількість відкритих сервісів назовні.

Що робити після базового запуску

Після старту не треба одразу підключати все підряд. Спочатку варто довести до ладу логи, reverse proxy і firewall backend. Лише потім є сенс додавати нові сценарії або інтеграції для окремих сервісів.

Найкращий наступний крок – перевірити, чи збігається вся схема довіри до реального клієнтського IP. Саме тут CrowdSec або різко підвищує якість блокувань, або починає банити внутрішню інфраструктуру. Межа між цими двома станами проходить не по документації, а по тому, наскільки чисто зібрані журнали на конкретному хості.

Деталі встановлення, пакети та актуальні компоненти варто звіряти на офіційному сайті CrowdSec.