CrowdSec у Linux: сучасна альтернатива Fail2ban з колаборативним захистом у 2026 році

Оновлено: 2 червня 2026

CrowdSec — це безкоштовний open-source IDS/IPS для Linux, який аналізує логи у реальному часі, блокує зловмисні IP-адреси та обмінюється сигнатурами атак між мільйонами інсталяцій через краудсорсингову мережу. На відміну від Fail2ban, CrowdSec розділяє детекцію (агент) і реагування (bouncers), підтримує колаборативні блоклисти CTI та масштабується від одного хоста до тисяч серверів. Чесно кажучи, я довго сидів на Fail2ban і відкладав міграцію, але після третьої скан-хвилі з ботнету за один тиждень здався. У цьому посібнику покажу повний шлях: установлення на Ubuntu 24.04 та RHEL 9, налаштування bouncer для nftables і nginx, інтеграцію з консоллю CrowdSec, а також міграцію з Fail2ban у 2026 році.

• CrowdSec 1.6.x використовує модель «агент + LAPI + bouncers», що дозволяє рознести детекцію і блокування на різні машини.
• Краудсорсингова мережа Central API (CAPI) надає безкоштовні блоклисти найактивніших атакуючих IP, оновлені кожні 2 години.
• Сценарії (scenarios) і парсери (parsers) встановлюються з Hub командою cscli hub upgrade, що знімає потребу писати regex вручну, як у Fail2ban.
• Bouncer для nftables створює окремий set і використовує його у chain INPUT. Це безпечніше, ніж модифікація глобальних правил iptables.
• На відміну від Fail2ban, CrowdSec не вимагає привілеїв root для агента детекції, що зменшує поверхню атаки.
• Безкоштовна підписка CrowdSec Console додає веб-дашборд, історичні алерти та інтеграцію з SIEM (Splunk, Elastic, Datadog).

Що таке CrowdSec і як він працює

CrowdSec, це поведінковий механізм виявлення вторгнень, написаний на Go. Він читає логи системних служб (SSH, nginx, Apache, Postfix тощо), застосовує до них парсери для нормалізації, передає у сценарії (statistical leaky-bucket алгоритм) і породжує рішення (decisions) при перевищенні порогу. Цей розподілений дизайн дозволяє вивчати тисячі логів за секунду навіть на скромному VPS.

Архітектура складається з чотирьох компонентів:

• Agent: фоновий процес crowdsec, який тільки читає логи і генерує алерти. Нічого не блокує самостійно.
• Local API (LAPI): REST-сервіс на localhost:8080, де зберігаються рішення у SQLite або PostgreSQL.
• Bouncers: окремі плагіни (cs-firewall-bouncer, cs-nginx-bouncer, cs-cloudflare-bouncer), які запитують LAPI і застосовують рішення на своєму рівні (фаєрвол, веб-сервер, CDN).
• Central API (CAPI): глобальна мережа CrowdSec, куди агенти анонімно надсилають сигнали і отримують крауд-блоклисти найактивніших атакуючих.

Саме така архітектура й дала йому прізвисько «Fail2ban на стероїдах». Можна запустити агент на одній машині (наприклад, на лог-сервері), а bouncers поставити на десятках edge-серверів, які тільки виконують блокування. Згідно з офіційною документацією CrowdSec, типова інсталяція обробляє до 50 000 рядків логу на секунду на одному vCPU.

Чим CrowdSec відрізняється від Fail2ban?

Я перевів кілька продакшн-серверів з Fail2ban на CrowdSec у 2025 році і можу впевнено сказати: для будь-якого парку машин понад 5 хостів виграш CrowdSec у спостережуваності та колаборативному захисті виправдовує день на міграцію. Ось як інструменти порівнюються за ключовими параметрами.

Характеристика	CrowdSec 1.6	Fail2ban 1.1
Мова реалізації	Go (компільований бінарник)	Python (інтерпретатор)
Споживання RAM (idle)	~50 МБ	~30 МБ
Пропускна здатність логів	До 50 000 рядків/с	~2 000 рядків/с
Архітектура	Розділена: agent + LAPI + bouncers	Монолітна: один процес
Крауд-блоклисти	Так, безкоштовно через CAPI	Ні (потрібен ipset зовнішніх списків)
Підтримка nftables	Нативна, окремий set	Через iptables-translate, повільніше
Web-дашборд	Так (CrowdSec Console, безкоштовно до 3 хостів)	Ні (тільки CLI)
Готові сценарії	200+ у Hub (брутфорс, скани, web-атаки)	~30 jail.local прикладів
Привілеї агента	Може працювати від non-root	Root обов'язковий
SIEM-інтеграція	Через Console (Splunk, Elastic, Datadog)	Тільки логи в syslog

Якщо ви захищаєте один VPS з SSH, Fail2ban досі цілком прийнятний (див. наш повний посібник із Fail2ban для захисту SSH). Але для веб-серверів, мульти-хост-середовищ і всього, що дивиться у публічний інтернет більше ніж 22-м портом, CrowdSec пропонує значно більшу глибину захисту.

Встановлення CrowdSec на Ubuntu 24.04 та RHEL 9

Офіційний скрипт інсталяції автоматично визначає дистрибутив, додає GPG-ключ і репозиторій. Я завжди читаю скрипт перед запуском (звичка з 2020 року, після випадку зі скомпрометованим npm-пакетом).

Ubuntu 24.04 / Debian 12

# Перевірити, що curl присутній
sudo apt update && sudo apt install -y curl gnupg

# Завантажити і переглянути офіційний скрипт
curl -fsSL https://install.crowdsec.net -o /tmp/cs-install.sh
less /tmp/cs-install.sh   # читаємо що буде виконано
sudo bash /tmp/cs-install.sh

# Встановити агент і CLI
sudo apt install -y crowdsec

# Перевірити статус
sudo systemctl status crowdsec
sudo cscli version

RHEL 9 / AlmaLinux 9 / Rocky Linux 9

# Додати репозиторій
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash

# Встановити
sudo dnf install -y crowdsec

# Увімкнути і запустити сервіс
sudo systemctl enable --now crowdsec

# SELinux: дозволити агенту читати логи
sudo setsebool -P logrotate_use_nfs 1   # якщо логи на NFS

Після встановлення агент уже захищає SSH «з коробки»: парсер crowdsecurity/sshd-logs і сценарій crowdsecurity/ssh-bf підключаються автоматично. Перевірити можна так: sudo cscli parsers list і sudo cscli scenarios list.

Налаштування агента: парсери, сценарії, acquis.yaml

Серце конфігурації CrowdSec, файл /etc/crowdsec/acquis.yaml, описує, які джерела логів читати і як їх тегувати. Тег type: повинен збігатися з префіксом парсера у Hub.

# /etc/crowdsec/acquis.yaml
---
filenames:
  - /var/log/auth.log
  - /var/log/secure
labels:
  type: syslog
---
filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/*-access.log
labels:
  type: nginx
---
source: journalctl
journalctl_filter:
  - "_SYSTEMD_UNIT=ssh.service"
labels:
  type: syslog

Після зміни acquis.yaml завжди валідуйте конфіг перед рестартом:

# Перевірити синтаксис без зупинки сервісу
sudo crowdsec -c /etc/crowdsec/config.yaml -t

# Застосувати зміни
sudo systemctl reload crowdsec

# Подивитися метрики обробки логів
sudo cscli metrics

Хаб CrowdSec, це Git-репозиторій з готовими парсерами і сценаріями для більш ніж 80 застосунків. Встановлення колекції одним рядком:

# Подивитися доступні колекції
sudo cscli collections list -a

# Встановити захист nginx (парсер + сценарії web-атак)
sudo cscli collections install crowdsecurity/nginx

# Встановити захист WordPress
sudo cscli collections install crowdsecurity/wordpress

# Оновити Hub до останніх версій
sudo cscli hub update && sudo cscli hub upgrade

Bouncer для nftables: блокування на рівні ядра

Сам по собі агент CrowdSec нічого не блокує, він лише записує рішення у LAPI. Щоб ці рішення перетворити на реальні DROP-правила, потрібен bouncer. На сучасних Linux я рекомендую cs-firewall-bouncer-nftables, який створює окремий nftables set і не торкається існуючих правил.

# Встановити firewall bouncer
sudo apt install -y crowdsec-firewall-bouncer-nftables

# Bouncer автоматично реєструється у LAPI під час post-install.
# Перевірити:
sudo cscli bouncers list

Конфіг знаходиться у /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Основні параметри для продакшну:

mode: nftables
update_frequency: 10s
log_mode: file
log_level: info
api_url: http://127.0.0.1:8080/
api_key: ${API_KEY}   # створюється автоматично

nftables:
  ipv4:
    enabled: true
    set-only: false     # bouncer створить і chain, і set
    table: crowdsec
    chain: crowdsec-chain
    priority: -10       # вище за filter (0), нижче за raw (-300)
  ipv6:
    enabled: true
    table: crowdsec6
    chain: crowdsec6-chain

Після рестарту bouncer додає правила:

sudo systemctl restart crowdsec-firewall-bouncer
sudo nft list ruleset | grep -A5 crowdsec

# Очікувано: chain crowdsec-chain { type filter hook input priority -10; ip saddr @crowdsec-blacklists drop }
sudo nft list set inet crowdsec crowdsec-blacklists

Якщо ви вже використовуєте nftables для основного фаєрвола, ознайомтеся з нашим посібником з nftables і міграції з iptables. Там розписана структура таблиць, з якою bouncer інтегрується без конфліктів.

Захист веб-додатків з nginx bouncer

Firewall bouncer обриває з'єднання на 4-му рівні OSI. Для веб-атак (SQLi, XSS, scrapers) корисніше блокувати у самому nginx, щоб мати можливість віддавати captcha або 403 з кастомним повідомленням замість «зависання» TCP. Для цього є cs-nginx-bouncer:

# Встановити nginx bouncer (Lua-модуль)
sudo apt install -y crowdsec-nginx-bouncer

# Залежність: lua-resty-http
sudo apt install -y lua-resty-http

# Конфіг bouncer
sudo nano /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf

Базовий конфіг для режиму «livemode» (запит до LAPI на кожен HTTP-запит) і з кешем на 30 секунд:

ENABLED=true
API_URL=http://127.0.0.1:8080
API_KEY=${API_KEY}
BOUNCING_ON_TYPE=ban
MODE=stream            # stream економніший: повний список раз на хвилину
UPDATE_FREQUENCY=60
FALLBACK_REMEDIATION=ban
REDIRECT_LOCATION=/blocked.html
RET_CODE=403
EXCLUDE_LOCATION=/health,/metrics

Підключити модуль у /etc/nginx/conf.d/crowdsec_nginx.conf (створюється автоматично), перевірити синтаксис і перезавантажити nginx:

sudo nginx -t && sudo systemctl reload nginx
sudo tail -f /var/log/nginx/error.log | grep -i crowdsec

Stream-режим (рекомендований для прод) кешує блоклист у пам'яті Lua і не робить мережевий виклик на кожен запит. Це знижує latency до <0.5 мс додатково на запит.

CTI та крауд-блоклисти: колективна оборона

Найсильніша риса CrowdSec, на мою думку, це обмін сигналами між учасниками. Коли ваш агент бачить атаку, він анонімно (тільки SHA-256 від IP + час + сценарій) надсилає сигнал у CAPI. Якщо той самий IP за 24 години помічений ≥3 незалежними учасниками, він потрапляє у безкоштовний краудсорсинговий блоклист, який ви автоматично завантажуєте.

# Зареєструватися у Central API (один раз)
sudo cscli capi register

# Подивитися, скільки IP у крауд-блоклисті
sudo cscli decisions list --origin CAPI | wc -l

# Підписатися на додаткові тематичні блоклисти у Console:
# free-proxies, vpn-tor-exit, ssh-brute, etc.
sudo cscli console enroll <your-enrollment-key>

Згідно зі звітом CrowdSec CTI Report за 2025 рік, мережа щодоби спостерігає понад 3.2 млн унікальних IP-атакувальників, і середній член спільноти отримує ~85 000 «гарячих» IP у крауд-листі, які блокуються ще до того, як вони доторкнуться вашого сервера.

Міграція з Fail2ban на CrowdSec

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

1. Запустити CrowdSec у режимі «спостереження», без bouncer. Агент тільки логуватиме рішення, але нічого не блокуватиме.
2. Порівняти алерти з Fail2ban за 48 годин: sudo cscli decisions list --since 48h vs sudo fail2ban-client status sshd.
3. Імпортувати існуючі бани з Fail2ban у LAPI:

   sudo fail2ban-client banned | jq -r '.[]|.[]|keys[]' \
     | xargs -I{} sudo cscli decisions add --ip {} --duration 168h --reason "migrated from fail2ban"

4. Увімкнути firewall bouncer. Тепер блокування виконує CrowdSec.
5. Зупинити Fail2ban після 24 годин стабільної роботи:

   sudo systemctl disable --now fail2ban
   sudo apt purge -y fail2ban  # тільки після підтвердження що CrowdSec блокує

Не залишайте обидва інструменти запущеними довго. Вони конкуруватимуть за читання auth.log і можуть створювати дубльовані бани з різним TTL.

Моніторинг через CrowdSec Console

CrowdSec Console, це SaaS-дашборд, безкоштовний до 3 хостів. Він показує мапу атак у реальному часі, історичні алерти, інтегрується зі Slack, PagerDuty і SIEM (Splunk, Elastic). Реєстрація проста:

# 1. Зареєструватися на app.crowdsec.net, створити enrollment key
# 2. Підключити агент
sudo cscli console enroll YOUR_KEY_HERE

# 3. На Console натиснути "Accept" для нового хоста
# 4. Увімкнути потрібні модулі (alerts, decisions, metrics)
sudo cscli console enable alerts decisions metrics

Для команд, які вже мають SIEM, корисний модуль Notifications: CrowdSec надсилатиме webhook-події у Slack або у HTTP-endpoint вашого SIEM. У поєднанні з нашим посібником із налаштування auditd і MITRE ATT&CK ви отримаєте повну картину: auditd показує, що зловмисник зробив всередині системи, а CrowdSec, звідки він прийшов і хто ще атакує тим самим методом.

Поширені помилки і як їх уникнути

За два роки роботи з CrowdSec у різних інсталяціях я зібрав короткий список «footguns», які з'їдають час навіть досвідчених адмінів:

• Парсер не читає лог. Найчастіше через SELinux або AppArmor. Перевірити: sudo aa-status | grep crowdsec або sudo ausearch -m AVC -ts recent | grep crowdsec.
• Bouncer не отримує рішення. Перевірте API-ключ: sudo cscli bouncers list. Якщо ключ протух, видаліть і перереєструйте: sudo cscli bouncers add new-fw-bouncer.
• Whitelist не працює. Пам'ятайте, що whitelist у CrowdSec діє на рівні парсера (до того, як алерт потрапить у LAPI), а не на рівні bouncer. Шаблон: /etc/crowdsec/parsers/s02-enrich/whitelists.yaml.
• Помилкові бани власної IP. Обов'язково додайте свої офісні/VPN IP у whitelist перед увімкненням bouncer. Класична помилка, забанити себе через SSH-сесію з мобільного інтернету.
• Перевищена квота LAPI на маленькому VPS. Переходьте з SQLite на PostgreSQL, коли decisions stable >100k. SQLite починає блокувати при write-contention.

Часті запитання

Чи безкоштовний CrowdSec?

Так, ядро CrowdSec (агент, LAPI, bouncers, CTI краудсорсингові блоклисти) повністю open-source під ліцензією MIT. Платні рівні (Console Premium, CTI Premium з геолокацією, Managed SaaS) опціональні і потрібні переважно для enterprise-розгортань на 10+ хостів.

Чи може CrowdSec замінити WAF?

Частково. CrowdSec блокує IP-адреси на основі поведінкових сценаріїв і добре закриває рідкісні автоматизовані атаки (брутфорс, скани, scrapers, ботнети). Для глибокого аналізу payload (SQLi, XSS у складних формах) використовуйте справжній WAF на кшталт ModSecurity або CrowdSec у парі з ним. Вони добре доповнюють одне одного.

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

Виконайте sudo cscli decisions list, і побачите активні бани. Перевірте, що bouncer їх застосував: sudo nft list set inet crowdsec crowdsec-blacklists (для nftables). Для end-to-end тесту з іншої машини: nmap -p 22 your-server після зловмисної активності, порт виглядатиме як filtered.

Чи можна використовувати CrowdSec у Docker і Kubernetes?

Так. Офіційний образ crowdsecurity/crowdsec доступний у Docker Hub, Helm chart для Kubernetes у репозиторії crowdsecurity/helm-charts. У K8s агент розгортається як DaemonSet, читає логи нод і pod-логи через journalctl або файлові маунти, а bouncer для ingress-nginx розгортається як sidecar або окремий Deployment.

Чи відправляє CrowdSec мої логи у хмару?

Ні. У CAPI відправляється лише SHA-256-хеш від IP-адреси, ім'я сценарію (наприклад, crowdsecurity/ssh-bf) і часова мітка. Сирі логи, користувацькі дані, payload запитів. Нічого з цього не залишає вашого сервера. Якщо ви ввімкнете Console, додатково надсилаються агреговані метрики (кількість алертів, типи), але також без сирих логів.