CrowdSec 1.6: Průvodce pro Linux (2026)

Aktualizováno: 18. července 2026

CrowdSec je open source bezpečnostní engine, který analyzuje logy v reálném čase, detekuje škodlivé chování podle YAML scénářů a blokuje útočníky přes samostatné komponenty zvané bouncery. Ke všemu ještě sdílí IP reputaci s celou komunitou. Ve srovnání s klasickým Fail2Ban jde o distribuovanou kolektivní obranu: každý napadený server obohacuje globální blocklist, který ostatní účastníci mohou stahovat a preventivně nasazovat. V tomhle průvodci projdu instalaci CrowdSec 1.6 na Debianu 12, konfiguraci bouncerů pro nftables a Nginx, tvorbu vlastních scénářů a AppSec komponentu. Píšu to z pohledu člověka, kterého tenhle stack v praxi nejednou zastavil (a několikrát pěkně naštval, taky).

CrowdSec 1.6.x přináší AppSec komponentu (WAF), redistribuovatelné blocklisty a rozšířenou podporu Kubernetes agentů.
Architektura odděluje detekci (agent + LAPI) od akce (bouncery) přes REST API, takže každou vrstvu lze škálovat i vyměnit nezávisle.
Community Blocklist obsahuje přes 6 milionů aktivních škodlivých IP; předběžné blokování odfiltruje 60–80 % běžných botů, než se vůbec dostanou k logu.
Bouncer pro nftables reaguje řádově v sekundách. Nginx bouncer umí captcha challenge místo tvrdého bloku pro sporné IP.
YAML scénáře používají leaky-bucket algoritmus místo pevných počtů, takže pokryjí i pomalé útoky rozprostřené v čase, které Fail2Ban propustí.
Pro produkční nasazení oddělte LAPI od agentů: jeden centrální LAPI slouží více edge serverům bez duplikace databáze.

Co je CrowdSec a jak funguje

CrowdSec je bezpečnostní software napsaný v jazyce Go, který kombinuje lokální detekci útoků s crowdsourcovanou IP reputací. Agent čte logy (z access logů Nginxu, auth.logu SSH, journalu systemd nebo dokonce z Kubernetes audit logu), parsuje z nich strukturovaná data přes grok patterny a nasype je do stateful scénářů. Když scénář vyhodnotí chování jako škodlivé, vytvoří rozhodnutí (decision) uložené v Local API. Bouncery pak polují na tato rozhodnutí a překládají je na blokovací pravidla v konkrétní vrstvě: iptables/nftables, Nginx, HAProxy, Traefik, Cloudflare nebo Kubernetes NetworkPolicy.

Z pohledu útočníka jde o zásadní rozdíl oproti tradičnímu HIDS. Když skenuji nový cíl, obvykle prvních 20 pokusů odhalí, co běží. Proti Fail2Ban se dá tenhle průzkum rozprostřít v čase, řekněme jednou za tři minuty. Proti CrowdSec ale ve chvíli, kdy útočím z rezidenciální IP, která se dva týdny pokoušela někoho jiného hacknout, jsem ještě před prvním requestem v community blocklistu. Prevence běží před detekcí, a to je pro pentestera opravdový problém. Běžný discovery footprint se stává detekovatelným už při prvním TCP handshaku, protože moje IP už není anonymní.

CrowdSec vs Fail2Ban: klíčové rozdíly

Fail2Ban je legendární nástroj, ale byl napsán v roce 2004 pro jinou dobu. Používá Python 2/3 s regex-based filtry, blokuje přes iptables jail a pracuje čistě lokálně. CrowdSec cíleně přebírá jeho use case, ale posouvá ho o generaci dál: kolektivní intelligence, moderní jazyk, modulární architektura a řádově širší rozsah pluginů. Následující tabulka shrnuje klíčové dimenze, ve kterých se rozhodujete při volbě nástroje.

Vlastnost	CrowdSec 1.6	Fail2Ban 1.1
Jazyk implementace	Go (jeden binární soubor)	Python 3
Detekční model	YAML scénáře + leaky-bucket	Regex filtry + počty
Kolektivní blocklist	Ano, přes 6 M IP	Ne (jen lokální jail)
Remediace	Bouncery přes REST API	Vestavěné akce (iptables, nftables)
WAF / Layer 7	AppSec component (Coraza + ModSec pravidla)	Ne
Centrální monitoring	Console (SaaS zdarma)	Ne (třetí strany)
Distribuovaný mód	Nativní (agent → LAPI)	Není
Licence	MIT (agent) + otevřený zdroj	GPLv2

Fail2Ban stále dobře pokrývá jednoduché scénáře, třeba domácí server, kde stačí zablokovat SSH brute force. Ve chvíli, kdy potřebujete pokrýt více protokolů, sdílet stav mezi několika edge servery nebo blokovat útoky, které jste ještě neviděli, přechází výhoda jasně na CrowdSec. Pro srovnání HIDS a runtime přístupu se podívejte i na runtime bezpečnost Linuxu s eBPF, která doplňuje CrowdSec o pohled na chování procesů uvnitř systému. CrowdSec vidí, co jde po síti, Falco to, co se děje syscally.

Architektura: agent, LAPI, bouncery

CrowdSec má tři distinktivní komponenty a je klíčové jim rozumět, protože každou lze škálovat i vyměnit nezávisle. Agent je proces, který sedí na cílovém stroji, čte logy a spouští scénáře. Kdykoli scénář „přeteče" (leaky bucket dosáhne kapacity), agent kontaktuje Local API (LAPI), což je centrální REST server nad SQLite nebo PostgreSQL databází s tabulkou decisions. LAPI drží pravdu: kdo je zablokovaný, jak dlouho a proč.

Bouncery jsou nezávislé procesy (často systemd služby na stejném stroji, nebo pluginy k proxy/firewallu), které se každých pár sekund ptají LAPI přes API klíč: „Máš pro mě nějaká rozhodnutí?" Když LAPI vrátí seznam IP, bouncer je aplikuje do své vrstvy. Kritický důsledek téhle architektury: agent, LAPI ani bouncer nemusí být na stejném stroji. Ve větších setupech běží centrální LAPI a několik edge serverů posílá své detekce dovnitř přes vzájemně důvěryhodný TLS.

Nad tím vším sedí volitelně Console, SaaS dashboard na app.crowdsec.net, kam LAPI push-uje anonymizované signály. Console je zdarma pro až tři stroje a nabízí přehled aktivních incidentů, blocklist manager a alertování na Slack, Discord nebo webhook.

Instalace CrowdSec na Debianu a Ubuntu

Distribuční balíčky jsou zpravidla zastaralé, takže vždy instalujte z oficiálního repozitáře CrowdSec, který drží aktuální 1.6.x. Následující postup platí pro Debian 12 a Ubuntu 22.04/24.04 se systemd:

# Přidání oficiálního repozitáře CrowdSec
curl -s https://install.crowdsec.net | sudo sh

# Instalace agenta a CLI
sudo apt update
sudo apt install -y crowdsec

# Ověření běhu služby a nainstalovaných kolekcí
sudo systemctl status crowdsec
sudo cscli hub list

Instalátor automaticky detekuje běžící služby (SSH, Nginx, Apache) a nainstaluje k nim odpovídající kolekce parserů a scénářů z CrowdSec Hubu. Kolekce jsou balíčky YAML souborů. Třeba crowdsecurity/nginx obsahuje access log parser plus scénáře pro path traversal, brute force a bot detekci.

Po instalaci CrowdSec ještě sám nikoho neblokuje. Pouze detekuje a zapisuje rozhodnutí do LAPI databáze. Pro reálné blokování musíte doinstalovat aspoň jeden bouncer:

# Nejjednodušší volba: firewall bouncer pro nftables/iptables
sudo apt install -y crowdsec-firewall-bouncer-nftables

# Ověření, že bouncer získal API klíč od LAPI
sudo cscli bouncers list

Konfigurace bouncerů pro nftables a Nginx

Firewall bouncer pro nftables je defaultní volba pro L3/L4 blokování. Konfigurace žije v /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Klíčové položky:

mode: nftables
update_frequency: 10s
log_level: info
api_url: http://127.0.0.1:8080/
api_key: ${API_KEY}

nftables:
  ipv4:
    enabled: true
    table: crowdsec
    chain: crowdsec-chain
    priority: -10
  ipv6:
    enabled: true
    table: crowdsec6
    chain: crowdsec6-chain
    priority: -10

deny_action: DROP
deny_log: false

Po restartu bounceru (systemctl restart crowdsec-firewall-bouncer) uvidíte v nft list ruleset nové tabulky crowdsec a crowdsec6. Bouncer je udržuje jako sady (sets) a inkrementálně přidává nebo odebírá IP podle stavu v LAPI. Pokud teprve migrujete z klasického iptables setupu, projděte si nejprve kompletního průvodce nftables. Pomůže vám pochopit prioritní ordering vůči vašim vlastním chainům, aby se pravidla CrowdSec vyhodnocovala dřív než application-layer accept.

Nginx bouncer s captcha challenge

Pro webovou vrstvu je zajímavější Nginx bouncer, který podporuje tři módy remediace: ban (HTTP 403), captcha (výzva před vpuštěním) a custom template. Captcha mód je klíčový pro sporné IP z community blocklistu. Nechcete tvrdě blokovat legitimní uživatele za NATem s dynamickou IP, kterou před vámi zneužil jiný útočník.

# Instalace
sudo apt install -y crowdsec-nginx-bouncer

# Konfigurace v /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf
ENABLED=true
API_URL=http://127.0.0.1:8080/
API_KEY=<automaticky přidělený>
BAN_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/ban.html
CAPTCHA_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/captcha.html
CAPTCHA_PROVIDER=hcaptcha
SITE_KEY=<hcaptcha_site_key>
SECRET_KEY=<hcaptcha_secret>
REDIRECT_LOCATION=/

Aby konkrétní rozhodnutí spustilo captcha místo tvrdého banu, nastavte scénář nebo profil na type: captcha v /etc/crowdsec/profiles.yaml. V produkci obvykle nastavuji captcha pro decisions pocházející z community blocklistu (low confidence) a ban pro decisions z lokálních scénářů (high confidence, viděl jsem chování na vlastní oči).

Scénáře a parsery: jak CrowdSec detekuje útoky

Detekční logika CrowdSec je uložená v YAML souborech pod /etc/crowdsec/scenarios/ a /etc/crowdsec/parsers/. Parser vezme surový log a rozřeže ho na strukturovaná pole (source IP, HTTP metoda, path, status). Scénář nad těmito poli vyhodnocuje leaky-bucket agregaci: kolik událostí kterého typu za jaké okno.

Ukázka vlastního scénáře pro detekci SSH útoku na neplatná username:

type: leaky
name: felix/ssh-invalid-user-bf
description: "Detect SSH brute force on invalid usernames"
filter: |
  evt.Meta.log_type == 'ssh_failed-auth' &&
  evt.Parsed.reason contains 'Invalid user'
groupby: evt.Meta.source_ip
distinct: evt.Meta.target_user
capacity: 5
leakspeed: 30s
blackhole: 5m
labels:
  service: ssh
  type: bruteforce
  remediation: true

Rozklad: bucket se plní každou událostí od stejné source IP proti odlišnému uživatelskému jménu, „vytéká" jedna kapka za 30 sekund a přeteče, když v něm bude 5 rozdílných username během okna. Blackhole zajistí, že stejný scénář nezaloguje duplicitní alert dalších 5 minut. Tenhle model je mnohem odolnější proti pomalému brute force než klasický „5 pokusů za 10 minut", protože rozpouštění probíhá gradientně. Osobně jsem tímhle scénářem zavíral pentesterské username enumeration attacks, které Fail2Ban propouštěl, protože každý pokus byl na jinou kombu. Honestly, když jsem tohle poprvé viděl v akci, chvíli mi trvalo, než jsem si na leaky-bucket paradigma zvykl (Fail2Ban vás vážně kazí).

Pro pochopení, jak scénáře reagují na SSH v kombinaci s hardening opatřeními, doporučuji přečíst průvodce zabezpečením OpenSSH 10. CrowdSec pracuje nejlépe, když už na vstupu odfiltrujete password auth a necháte projít jen key nebo FIDO2. Tím eliminujete třídu false positives, kde legitimní uživatel překlepe heslo pětkrát za sebou.

Community Blocklist a Console

Kolektivní inteligence je vlajkovou vlastností CrowdSec. Ve chvíli, kdy váš agent detekuje útok, LAPI posílá anonymizovaný signál do Central API. Server tam agreguje signály z celé sítě CrowdSec instancí a produkuje kurátorované blocklisty. Vy si je přes cscli můžete stáhnout a nechat aplikovat lokálním bouncerům, a tím preventivně blokujete IP, které jste sami ještě nikdy neviděli.

# Registrace k Console (jednorázově, otevře browser)
sudo cscli console enroll <enrollment_key>

# Přidání community blocklistu (CrowdSec Community Blocklist)
sudo cscli blocklists install crowdsecurity/community-blocklist

# Ruční aktualizace všech blocklistů
sudo cscli blocklists update

V Console pak vidíte nejen vlastní alerty, ale i „edge scenarios", situace, kdy váš stroj přispěl do globálního datasetu. Prakticky to funguje jako feedback loop: čím víc přispíváte, tím preciznější blocklisty dostáváte zpět. Podle statistik z CrowdSec public dashboardu obsahuje community blocklist v polovině roku 2026 přes 6 milionů aktivních záznamů, což předběžně odfiltruje 60–80 % typického bot traffic. Když jsem tenhle blocklist zapnul na testovacím honeypotu, počet log entries za den mi klesl z ~180 000 na ~30 000 během 48 hodin. Rozdíl byl v grafu docela dramatický, málem jsem si myslel, že honeypot spadl.

AppSec Component: WAF integrovaný do CrowdSec

Verze 1.6 zavedla AppSec Component, tedy L7 filter postavený na Coraza WAF enginu, který rozumí OWASP ModSecurity Core Rule Set. Architektonicky sedí AppSec mezi Nginx nebo HAProxy a upstream aplikací jako HTTP mirror: proxy pošle kopii requestu na AppSec endpoint, ten vrátí verdict allow, block nebo log a proxy podle toho rozhodne o requestu.

# Instalace AppSec komponenty
sudo cscli collections install crowdsecurity/appsec-virtual-patching
sudo cscli collections install crowdsecurity/appsec-generic-rules

# AppSec konfigurace v /etc/crowdsec/acquis.d/appsec.yaml
appsec_config: crowdsecurity/appsec-default
labels:
  type: appsec
listen_addr: 127.0.0.1:7422
source: appsec

V Nginxu pak přidáte mirror direktivu, která odesílá subrequest na AppSec endpoint před tím, než pustí request na aplikaci. AppSec detekuje typické Layer 7 útoky (SQLi, XSS, path traversal, log4shell) a rozhodnutí propaguje do LAPI. Tím se blocklist rozšíří o IP, které utíkají klasickým signature-based WAF pravidlům, protože kombinuje behavior scénáře i signature pravidla v jednom rozhodovacím pipeline. Virtual patching kolekce obsahuje CVE-specific pravidla pro nedávné zranitelnosti (Struts, Confluence, Ivanti), takže jde v podstatě o mini-WAF, který dostanete zdarma jako součást stacku.

Ladění, monitoring a troubleshooting

Provoz CrowdSec v produkci vyžaduje pár rutinních kontrol. Nejrychlejší přehled o stavu podává cscli metrics, který ukazuje kolik událostí protéká přes které parsery a scénáře, kolik overflows generují a kolik decisions je aktivních:

sudo cscli metrics
sudo cscli decisions list                       # aktuální blokace
sudo cscli alerts list --since 24h              # nedávné alerty
sudo cscli hub list                             # verze všech pluginů

# Test parseru na konkrétní řádek logu
sudo cscli explain --log "your log line" --type nginx

# Simulace scénáře bez reálného banu (dry run)
sudo cscli scenarios inspect crowdsecurity/ssh-bf --simulate

Pro dlouhodobý monitoring má CrowdSec Prometheus endpoint na 127.0.0.1:6060 s desítkami metrik: počty overflows, latence LAPI odpovědí, věk decisions. Doporučuji doplnit Grafana dashboard s alertem na náhlý pokles počtu bouncer heartbeats. To signalizuje, že bouncer přestal získávat rozhodnutí a firewall se pomalu uvolňuje. Pro shrnutí compliance stopy a auditních záznamů dobře funguje kombinace CrowdSec a auditd pro CIS a PCI DSS compliance, kde auditd zaznamenává změny v pravidlech nftables prováděné bouncerem. Máte tedy nejen záznam, kdo byl zablokován, ale i kdo (jaký proces) blokaci provedl.

Často kladené otázky

Je CrowdSec zdarma pro komerční použití?

Ano. Agent, LAPI, bouncery i community blocklist jsou zdarma pod otevřenou licencí i pro komerční nasazení. Placené jsou pouze prémiové blocklisty (například specializované industry feeds) a Enterprise Console nad tři stroje. Základní community edice Console je také zdarma.

Mohu CrowdSec spustit vedle Fail2Ban?

Technicky ano, ale nedoporučuji to. Oba nástroje spravují vlastní iptables/nftables pravidla a mohou se přepisovat nebo mezi sebou soutěžit o stejnou chain. Vyberte jeden: buďto CrowdSec se všemi bouncery, nebo Fail2Ban. Pro migraci disable Fail2Ban službu předtím, než spustíte crowdsec-firewall-bouncer.

Jak CrowdSec chrání proti false positives z community blocklistu?

CrowdSec používá reputation scoring: každou IP hodnotí podle počtu unikátních signálů, geografické diverzity zdrojů a časového rozložení. Do community blocklistu se dostávají jen IP s vysokou konfidencí. Navíc můžete použít captcha remediation místo tvrdého banu pro sporné případy nebo přidat vlastní whitelist.yaml pro důvěryhodné rozsahy.

Podporuje CrowdSec Kubernetes a Docker?

Ano. Existuje oficiální Helm chart, který nasadí CrowdSec agent jako DaemonSet čtoucí kubelet a audit logy. Pro remediation v clusteru je k dispozici Kubernetes bouncer, který přidává denied IP do NetworkPolicy zdrojů, plus integrace s ingress kontrolery jako Traefik a Nginx.

Jak dlouho CrowdSec drží IP zablokovanou?

Výchozí ban je 4 hodiny, ale konfigurovatelný per profil. Community blocklist má vlastní expiraci, obvykle 24–72 hodin od posledního signálu. V /etc/crowdsec/profiles.yaml můžete nastavit progresivní bany (první porušení hodina, druhé den, třetí týden), což citelně zvyšuje účinnost proti perzistentním útočníkům.