CrowdSec срещу Fail2ban 2026: пълно сравнение, миграция и хибридна защита

CrowdSec срещу Fail2ban през 2026 г.: архитектурно сравнение, миграция стъпка по стъпка и хибридна конфигурация с nftables sets и AppSec WAF.

CrowdSec vs Fail2ban 2026: сравнение и миграция

Актуализирано: 17 юли 2026 г.

CrowdSec срещу Fail2ban през 2026 г. се свежда до един избор: локална, реактивна защита на един сървър (Fail2ban) срещу разпределена, проактивна защита с колективен блоклист (CrowdSec). Fail2ban не е deprecated и остава напълно поддържан, но CrowdSec 1.6.x, с YAML-базирани сценарии, отделни bouncer-и и AppSec WAF, покрива атакови модели (разпределени ботнет-и, layer-7 CVE-та), които log-регекс подходът на Fail2ban не може да види. В тази статия сравнявам двата инструмента архитектурно, показвам как да мигрирате и как да ги стартирате едновременно.

Честно казано, самият аз минах през хибриден setup на около десетина production сървъра миналата година, и опитът промени начина, по който препоръчвам двата инструмента. Не се изключват взаимно.

  • Fail2ban 1.1.x е стабилен log-parser на Python с regex jails; CrowdSec 1.6.x е Go-базиран агент със сценарии, LAPI и отделни bouncer-и. Двата решават IPS задачи по различен архитектурен начин.
  • CrowdSec ползва nftables sets за милиони IP адреси. Fail2ban създава едно правило на IP, така че при повече от няколко хиляди бана започва да генерира забележимо firewall натоварване.
  • Community Central API (CAPI) е ключовото предимство на CrowdSec: получавате блоклист с около 1 милион уникални зловредни IP-та дневно, докато Fail2ban вижда само локални логове.
  • CrowdSec може да работи изцяло офлайн (без CAPI enrollment). Данните, споделяни с общността, са само signal-и за атакуващи IP-та, никога съдържание на вашите логове.
  • Fail2ban остава по-подходящ за минимални VPS-и (под 1 GB RAM) и въздушно изолирани системи; CrowdSec печели за фермерни сетъпове, web front-end-и и мултисървърни fleet-и.
  • Двата инструмента могат да работят паралелно на един хост без конфликт: Fail2ban за SSH jail-и, CrowdSec за web services и колективна интелигентност.

Архитектурни различия: агент, LAPI, bouncer срещу монолитен daemon

Fail2ban е Python daemon (текуща стабилна версия 1.1.0, издадена през 2024 г.), който комбинира три задачи в един процес: чете логове, съпоставя ги с regex филтри, дефинирани в jail-и, и извиква iptables, nftables или firewalld action-и, за да вмъкне DROP правила. Всичко се случва в един системен процес с една конфигурация в /etc/fail2ban/. Този монолитен модел е причината за неговата дълголетна надеждност. За 20 години, откакто съществува, той почти не се е променил.

CrowdSec 1.6.x, напротив, изрично разделя detection от enforcement. Основният агент (Go, около 50 MB residentна памет) прави три неща: parse-ва логове, изпълнява YAML сценарии и записва решения (ban, captcha, throttle) в локална SQLite база, изложена през HTTP Local API (LAPI). Enforcement-ът се случва в отделни програми, наречени bouncer-и, които извикват LAPI на всеки няколко секунди и синхронизират блокировките към firewall, reverse proxy, CDN или WAF.

Практическата разлика: с Fail2ban един процес прави всичко и когато той падне, изчезва и enforcement-ът (макар firewall правилата да остават до restart). С CrowdSec можете да свалите агента за поддръжка и bouncer-ите ще продължат да блокират въз основа на последно синхронизирания decision cache. Обратно, можете да замените bouncer-а с друг (например от nftables към Cloudflare WAF), без да пипате detection логиката. Тази декомпозиция също така отваря вратата към Central API (CAPI), cloud сервис, който агрегира signal-и от всички опериращи инсталации и връща crowd-sourced блоклист.

Сравнителна таблица: CrowdSec срещу Fail2ban 2026

ХарактеристикаFail2ban 1.1.xCrowdSec 1.6.x
Език / рантаймPython 3Go (single static binary)
Базова памет~15 MB~50 MB (агент + LAPI)
Модел на детекцияRegex jail-иYAML сценарии с временна логика
Съхранение на бановетеИндивидуални firewall правилаnftables/ipset sets за милиони IP-та
Threat intelligenceНяма nativeCAPI community blocklist
Layer 7 / WAFНеДа (AppSec компонент)
Офлайн работаДаДа (без CAPI enrollment)
Мултисървър координацияРъчна (custom scripting)Native (споделен LAPI)
ЛицензGPLv2+MIT
Крива на научаванеНискаСредна

Двата инструмента са free & open source. Разликата в лиценза (GPL срещу MIT) рядко има значение за оператори, но може да е фактор, ако вграждате детекция в комерсиален продукт (MIT е по-разрешителен). И двата се обновяват активно: последният release на Fail2ban към момента е 1.1.0 (2024 г.), а CrowdSec публикува minor версии на всеки няколко седмици. Виждате ги на GitHub releases страницата на CrowdSec.

Deprecated ли е Fail2ban през 2026 г.?

Не. Fail2ban не е deprecated и няма индикации да бъде. Проектът продължава да се разпространява във всяко голямо Linux дистро и upstream пуска security fix-ове и bugfix release-и. През 2024 г. излезе версия 1.1.0 с подобрена поддръжка на IPv6, native nftables back-end и по-стриктно парсване на Python 3.12+. Общността около Fail2ban остава активна на GitHub и mailing list-овете.

Различаването между "остаряло" и "непроменящо се" е важно. Fail2ban не се променя много, защото основната му задача, а именно ban-ване на IP-та въз основа на локални лог модели, не изисква нови концепции. Ако имате единичен VPS с 1 GB RAM, SSH и Nginx, Fail2ban с sshd и nginx-limit-req jail-ите остава напълно рационален и надежден избор.

Това, което Fail2ban не може да направи, е следното: да разпознае разпределен ботнет от 10 000 IP-та, всяко от които прави по едно нищо-неказващо probe; да блокира SQL injection или Log4Shell exploit на HTTP ниво преди приложението да го обработи; или да сподели видяните заплахи с другите ви сървъри. Тези сценарии изискват архитектура като CrowdSec, не защото Fail2ban е "лош", а защото решава по-тесен проблем.

Инсталация на CrowdSec на Debian/Ubuntu

CrowdSec се разпространява през official PackageCloud repository. Инсталацията на Ubuntu 24.04 LTS или Debian 12 отнема около 30 секунди:

# Добавяне на CrowdSec repository и подпис
curl -s https://install.crowdsec.net | sudo sh

# Инсталация на агента (Security Engine)
sudo apt install -y crowdsec

# Проверка на версията и статуса
cscli version
sudo systemctl status crowdsec

# Разглеждане на автоматично инсталираните колекции
sudo cscli collections list

По подразбиране инсталаторът разпознава активните услуги (sshd, nginx, apache) и инсталира съответните колекции. Разгледайте състоянието на LAPI и активните scenario-та:

# Health check на локалния API
sudo cscli lapi status

# Списък на активните scenario-та
sudo cscli scenarios list

# Активни decision-и (текущи бановe)
sudo cscli decisions list

# Alerts за последния час
sudo cscli alerts list --since 1h

Ако искате community threat intelligence, регистрирайте инстанцията в CAPI. Enrollment-ът е опционален, но без него губите основното предимство на CrowdSec, а именно глобалния блоклист:

# Създайте акаунт на https://app.crowdsec.net и вземете enrollment key
sudo cscli console enroll YOUR_ENROLLMENT_KEY

# Проверка кои premium blocklist-и са налични
sudo cscli capi status

CrowdSec agent parse-ва логовете изцяло локално. Ако enrollнете инстанцията, тя споделя с CAPI само signal-и за атакуващи IP-та: адрес, задействан сценарий, timestamp. Съдържанието на вашите логове, потребителският трафик и вътрешните IP-та никога не напускат хоста.

Сценарии, колекции и AppSec WAF

Основната единица за детекция в CrowdSec е сценарият, YAML файл, който описва временен модел, а не просто regex match. Например базовият SSH brute-force сценарий брои неуспешните login опити в 10-минутен sliding window и задейства ban при 6 събития. Този expresivност е причината CrowdSec да може да разпознае "5 неуспешни логина от различни usernames за 2 минути", pattern, който Fail2ban не може лесно да формулира.

Колекциите са комбинирани пакети от parser и сценарии за конкретна услуга. Инсталирайте тези, които отговарят на вашия стек:

# SSH brute force (обикновено вече инсталиран)
sudo cscli collections install crowdsecurity/sshd

# Nginx: bad user agents, path traversal, CVE probing
sudo cscli collections install crowdsecurity/nginx

# HTTP базови exploit-и (Log4Shell, CVE-2021-41773, generic CVE-та)
sudo cscli collections install crowdsecurity/base-http-scenarios

# Traefik reverse proxy
sudo cscli collections install crowdsecurity/traefik

# WordPress-specific
sudo cscli collections install crowdsecurity/wordpress

# Zареждане на новите сценарии
sudo systemctl reload crowdsec

За web front-end хостове инсталирайте AppSec компонента, лек WAF, който инспектира живи HTTP заявки на Layer 7 и хваща SQL injection, XSS и CVE експлойти преди приложението да ги види. AppSec-ът се стартира като отделен daemon и се извиква от web bouncer (nginx, traefik, haproxy) като external auth check. Това е ключова функционалност, която Fail2ban няма изобщо: log-базираният подход вижда HTTP exploit-а само след като е записан в access log, което е след като приложението вече го е обработило.

Firewall bouncer с nftables sets

Агентът сам по себе си само взима decision-и и не блокира нищо. За реален enforcement ви трябва bouncer. За infrastructure услуги (SSH, DB, SMTP) най-разумен е firewall bouncer-ът, който създава named nftables set и вмъква DROP правило, което reference-ва този set. Всички банове стават добавяне или премахване на елементи от set-а, операция O(log n) дори при милион IP-та.

# Инсталация на firewall bouncer за nftables
sudo apt install -y crowdsec-firewall-bouncer-nftables

# Автоматична регистрация с локалния LAPI
sudo systemctl status crowdsec-firewall-bouncer

# Проверка на генерирания nftables set
sudo nft list ruleset | grep -A 5 crowdsec

По подразбиране bouncer-ът работи в managed режим: създава chain-а crowdsec-chain, table-а crowdsec и sets crowdsec-blacklists и crowdsec6-blacklists за IPv4 и IPv6. Вмъква DROP правило в table-а inet filter hook input. Ако вече имате изградена nftables конфигурация, например от нашето ръководство за укрепване на Linux защитна стена с nftables, минете bouncer-а в manual режим и добавете хендлването сами.

За web front-end хостове предпочетете web bouncer (nginx, traefik или HAProxy SPOA) вместо, или паралелно с, firewall bouncer-а. Web bouncer-ът връща 403 или CAPTCHA за забранени IP-та, вместо да им затваря TCP връзката. Това дава чиста telemetry в HTTP лог и позволява по-точна реакция от firewall-ниво drop. Пълните инструкции за инсталация са в официалната документация на firewall bouncer-а.

Миграция от Fail2ban към CrowdSec

Пълната замяна на Fail2ban с CrowdSec не изисква downtime, но искате внимателна последователност, за да не оставите хоста незащитен между двете. Работният ред, който използвам на production servers, изглежда така:

  1. Инвентаризация на активните jail-и. Изпълнете sudo fail2ban-client status и запишете списъка. За всеки jail открийте съответната CrowdSec колекция в hub. Обикновено има директен еквивалент.
  2. Инсталация на CrowdSec в permissive mode. Инсталирайте агента с колекциите, но не инсталирайте bouncer-а веднага. Оставете агента да parse-ва логове и да генерира decision-и за 24-48 часа, без да блокира.
  3. Одит на генерираните decision-и. sudo cscli decisions list ще покаже какво би било блокирано. Сравнете с активните Fail2ban банове (fail2ban-client status jail_name), за да откриете false positives или пропуски.
  4. Инсталация на firewall bouncer-а. Едва след одита инсталирайте crowdsec-firewall-bouncer-nftables. От този момент двата инструмента блокират паралелно.
  5. Постепенно деактивиране на Fail2ban jail-ите. Деактивирайте по един jail, наблюдавайте CrowdSec alerts 24 часа, продължавайте. Когато всички jail-и са мигрирани, изпълнете sudo systemctl disable --now fail2ban.
  6. Пренасочване на съществуващи allowlist-и. Ако имате ignoreip списък във Fail2ban, преведете го в CrowdSec whitelist: sudo cscli decisions add --ip 10.0.0.0/8 --type allow, или създайте YAML whitelist parser.

Средно време за миграция на добре документиран сървър с 3-5 активни jail-а: 1-2 работни дни, повечето от които са passive monitoring между стъпките. Не бързайте с последната стъпка, честно казано, единствения път, когато си получих inbox с alert-и по средата на нощта, беше защото прескочих одита.

Хибридна конфигурация: Fail2ban + CrowdSec едновременно

Хибридното използване е валидно и разпространено. Двата инструмента работят на различни nftables chain-и и не си пречат. Разумно разделение на отговорностите:

  • Fail2ban държи SSH jail-а. Двадесет години battle-testing и вградени recidive алгоритми правят Fail2ban ненадминат за прост SSH brute-force use case на изолирани хостове.
  • CrowdSec обработва всички web-facing услуги (nginx, traefik, WordPress) и връща community блоклист от CAPI. Firewall bouncer-ът поддържа огромен nftables set с "known bad" IP-та, дори такива, които локалният агент не е видял.

Единственият координационен въпрос е allowlist-ването. Уверете се, че вашите monitoring и backup IP-та са изключени и в Fail2ban ignoreip, и в CrowdSec whitelist. За допълнителна детекционна дълбочина, комбинирайте CrowdSec с host-based intrusion detection. Вижте нашето ръководство за откриване на проникване в Linux с auditd, AIDE и Wazuh, което покрива kernel audit trail-и и file integrity monitoring, каквито нито Fail2ban, нито CrowdSec предлагат native.

Ако укрепвате самия SSH daemon паралелно, вижте пълния гид за укрепване на SSH през 2026 г. с post-quantum криптография. CrowdSec и Fail2ban са допълнителен слой над правилно конфигуриран OpenSSH, не заместител на него. Проектната документация на Fail2ban е на официалния wiki, референтна за jail и filter синтаксиса.

Често задавани въпроси

Замества ли CrowdSec напълно Fail2ban?

Не напълно. CrowdSec разширява концепцията с колективна интелигентност, YAML сценарии и AppSec WAF, но Fail2ban остава по-лек и достатъчен за single-server SSH сценарии. Много оператори мигрират web услугите към CrowdSec и оставят Fail2ban само за SSH jail-а.

Може ли Fail2ban и CrowdSec да работят едновременно на един хост?

Да. Двата инструмента вмъкват правила в различни nftables chain-и и не си пречат. Разпространеният подход е Fail2ban за SSH и infrastructure услуги, CrowdSec за web front-end и колективна threat intelligence. Единственият риск е двойно ban-ване на легитимни IP-та, така че синхронизирайте allowlist-ите.

Работи ли CrowdSec без интернет връзка?

Да. Ако не enroll-нете инстанцията в Central API, CrowdSec работи изцяло с локално генерирани decision-и. Parse-ва вашите логове, изпълнява сценариите и блокира на база на локална детекция. Губите community blocklist-а, но не и основната IPS функционалност. Това прави CrowdSec подходящ и за въздушно изолирани системи.

Какви ресурси използва CrowdSec в сравнение с Fail2ban?

Базовата residentна памет на CrowdSec агента е около 50 MB, срещу ~15 MB за Fail2ban. Firewall bouncer-ът добавя още 10-15 MB. За single-server сетъп с 512 MB RAM тази разлика може да е чувствителна; за модерни VPS-и с 2 GB+ е незначителна. При висок log throughput Go-базираният CrowdSec parse-ва значително по-бързо от Python-базирания Fail2ban.

Кой е по-подходящ за SSH защита, Fail2ban или CrowdSec?

За чист локален SSH brute-force и на single host, Fail2ban, поради своята простота и десетилетия battle-testing. За фермерни setup-и или когато искате да блокирате известни malicious IP-та преди първия им опит, CrowdSec с колекцията crowdsecurity/sshd и CAPI enrollment. При хибрид, оставете Fail2ban за SSH и ползвайте CrowdSec за web.

Yuki Tanaka
За Автора Yuki Tanaka

Linux kernel security engineer with a background in eBPF and LSM. Likes hardening more than she likes sleeping.