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.x
CrowdSec 1.6.x
Език / рантайм
Python 3
Go (single static binary)
Базова памет
~15 MB
~50 MB (агент + LAPI)
Модел на детекция
Regex jail-и
YAML сценарии с временна логика
Съхранение на бановете
Индивидуални firewall правила
nftables/ipset sets за милиони IP-та
Threat intelligence
Няма native
CAPI 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 и сценарии за конкретна услуга. Инсталирайте тези, които отговарят на вашия стек:
За 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, изглежда така:
Инвентаризация на активните jail-и. Изпълнете sudo fail2ban-client status и запишете списъка. За всеки jail открийте съответната CrowdSec колекция в hub. Обикновено има директен еквивалент.
Инсталация на CrowdSec в permissive mode. Инсталирайте агента с колекциите, но не инсталирайте bouncer-а веднага. Оставете агента да parse-ва логове и да генерира decision-и за 24-48 часа, без да блокира.
Одит на генерираните decision-и.sudo cscli decisions list ще покаже какво би било блокирано. Сравнете с активните Fail2ban банове (fail2ban-client status jail_name), за да откриете false positives или пропуски.
Инсталация на firewall bouncer-а. Едва след одита инсталирайте crowdsec-firewall-bouncer-nftables. От този момент двата инструмента блокират паралелно.
Постепенно деактивиране на Fail2ban jail-ите. Деактивирайте по един jail, наблюдавайте CrowdSec alerts 24 часа, продължавайте. Когато всички jail-и са мигрирани, изпълнете sudo systemctl disable --now fail2ban.
Пренасочване на съществуващи 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-и по средата на нощта, беше защото прескочих одита.
Хибридното използване е валидно и разпространено. Двата инструмента работят на различни 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.
Подробно сравнение на Falco и Tetragon за eBPF-базирана runtime сигурност в Linux през 2026 г. — инсталиране, TracingPolicy enforcement, custom правила и комбиниран production стек.
Практическо ръководство за изграждане на трислойна система за откриване на проникване в Linux с auditd, AIDE и Wazuh. Включва реални конфигурации, LOTL детекция и съответствие с CIS/STIG.