CrowdSec Linux 2026: közösségi IPS telepítése és nftables integráció Fail2ban helyett

Frissítve: 2026. augusztus 19.

A CrowdSec egy nyílt forráskódú, közösségi behatolásmegelőző rendszer (IPS) Linuxra, amely a naplófájlokból (SSH, nginx, iptables, systemd) valós időben szűri ki a rosszindulatú viselkedést, majd a döntéseket egy központi közösségi feketelistán osztja meg a több mint 200 ezres CrowdSec Console felhasználói bázissal. Röviden: ez a Fail2ban modern utódja, de sokkal többet tud. Az agent és a bouncer szét van választva, így egyetlen agentből tűzfalat, nginx-et, HAProxy-t vagy akár Cloudflare-t is vezérelhetsz, és 2026-tól már beépített WAF (AppSec) is tartozik hozzá.

• A CrowdSec 1.6.x sorozat 2026-ban a stabil ág; az AppSec (WAF) komponens és a natív nftables bouncer alapfelszereltség.
• A Fail2ban-nel ellentétben a CrowdSec megosztott feketelistával dolgozik: egy támadó IP-je néhány perc alatt globálisan blokkolttá válhat.
• Az agent CPU- és memóriaigénye nagyjából 3–5x-e a Fail2ban-nek, de skálázhatóság és detektálási képesség terén nagyságrendekkel jobb.
• A telepítés Debian/Ubuntu/RHEL rendszereken egyetlen sor: curl alapú repo hozzáadás után apt install crowdsec crowdsec-firewall-bouncer-nftables.
• A közösségi blokklista (CTI) ingyenes napi 500 kérésig; nagyobb környezetben a Premium csomag SOC-szintű riasztásokat és MITRE ATT&CK dúsítást kínál.
• A CrowdSec kompatibilis a nftables, iptables, pf, Cloudflare, AWS WAF és Kubernetes ingress backendekkel.

Mi az a CrowdSec és hogyan működik?

A CrowdSec egy Go nyelven írt behatolásmegelőző rendszer, amely három fő komponensből épül fel: a Local API (LAPI), az agent és a bouncerek. Az agent folyamatosan olvassa a konfigurált naplóforrásokat (journald, egyedi fájlok, Docker socketek, Kubernetes audit log), a beolvasott sorokat parserek normalizálják, majd a scenariók döntik el, melyik viselkedés minősül támadásnak. Például: öt sikertelen SSH-bejelentkezés fél percen belül. A pozitív találatból egy decision keletkezik, ami a LAPI SQLite vagy PostgreSQL adatbázisába kerül.

A blokkolást nem az agent, hanem a bouncerek végzik. Ez az elkülönítés a legnagyobb architekturális különbség a Fail2ban-hez képest. Egyetlen agent képes tűzfal-, HTTP- és felhő-bouncereket párhuzamosan vezérelni, miközben a döntéseket a közösségi CrowdSec Central API (CAPI) globális threat intelligence adatokkal is dúsítja. A hivatalos CrowdSec dokumentáció részletesen leírja a decision engine belső működését, beleértve a whitelistelés és a duráció-számítás logikáját.

A közösségi jelleg praktikus előnye, hogy a rendszered profitál mások tapasztalataiból. Ha egy botnet IP-je Berlinben megpróbál brute-force SSH-t nyomni, néhány percen belül nálad is blokkolt lesz, még mielőtt egyáltalán elérne. Nálam a saját mail-relayen az első hetében pontosan ez történt, két IP percek alatt landolt a listán, még kézzel se kellett hozzányúlnom. Ez különösen erős védelmet ad az nftables tűzfal mesterfokon cikkben tárgyalt statikus szabályok fölé.

CrowdSec vs. Fail2ban: mikor melyiket válaszd?

A CrowdSec és a Fail2ban ugyanazt a problémát oldja meg (automatikus IP-blokkolást naplóelemzés alapján), de teljesen eltérő filozófiával. A Fail2ban Python nyelven íródott, egy szálban dolgozik, és kizárólag iptables vagy nftables szabályokat manipulál a saját hoston. A CrowdSec ezzel szemben elosztott: több bouncer, több szerver, opcionálisan központi konzol köti össze a flottádat. Az alábbi táblázat foglalja össze a főbb különbségeket 2026-os állapot szerint.

Jellemző	CrowdSec 1.6	Fail2ban 1.1
Nyelv és futásidő	Go (fordított bináris)	Python 3
Architektúra	Agent + LAPI + bouncerek szétválasztva	Monolit démon
Közösségi feketelista	Igen (CAPI, ~5M IP)	Nincs, csak lokális
Beépített WAF	Igen (AppSec 2024 óta)	Nincs
Több szerveres deployment	Multi-server LAPI, Kubernetes DaemonSet	Csak lokális
Memóriafogyasztás (idle)	~80–120 MB	~25–40 MB
Metrikák	Prometheus natív endpoint	Csak fail2ban-client status
Licenc	MIT (agent, bouncerek)	GPLv2

Kis, egyszerveres környezetben (VPS, hobbi szerver) a Fail2ban továbbra is védhető választás. Alacsony memóriaigény, kevés függőség, és őszintén szólva bőven elég egy magánblognak. Ha viszont több hoston futtatsz szolgáltatásokat, vagy szeretnéd kihasználni a közösségi threat intelligence-t, a CrowdSec az egyértelmű nyertes. Kifejezetten jól kiegészíti az SSH megerősítés 2026-ban ajánlásait: a kulcs alapú, posztkvantum hitelesítés mellé az IP-szintű blokkolás kiegészítő védelmet ad.

CrowdSec telepítése Ubuntu 24.04 és Debian 12 alatt

A hivatalos APT repo a legmegbízhatóbb telepítési út. Mindig újabb csomagot ad, mint a disztribúció alap repói, és a bouncer csomagok is innen érhetők el frissen. A telepítés két lépésből áll: az agent és a bouncer felrakása. Az agent önmagában csak detektál; aktív blokkoláshoz mindenképpen kell egy bouncer.

# 1) Repo hozzáadása és telepítés
curl -s https://install.crowdsec.net | sudo sh
sudo apt update
sudo apt install -y crowdsec crowdsec-firewall-bouncer-nftables

# 2) Alap kollekciók telepítése (SSH, nginx, systemd, sshd brute-force)
sudo cscli collections install crowdsecurity/linux
sudo cscli collections install crowdsecurity/sshd
sudo cscli collections install crowdsecurity/nginx

# 3) Frissítjük a hub-ot és újraindítjuk az agentet
sudo cscli hub update
sudo systemctl restart crowdsec

# 4) Ellenőrizzük, hogy fut-e minden komponens
sudo cscli metrics
sudo systemctl status crowdsec crowdsec-firewall-bouncer

A telepítő automatikusan generál egy gépi ID-t és bejelentkezési tokent a bouncer számára, majd bejegyzi a LAPI-ba. Ha a bouncer nem jelenik meg a cscli bouncers list kimenetében, valószínűleg a /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml API kulcsa nem lett bejegyezve. Ilyenkor futtasd újra a sudo /usr/lib/crowdsec/scripts/_bouncer.sh add parancsot. (Erre az utolsó Debian 12-es upgrade-em után futottam bele, csendes bug volt, semmi hibaüzenet, csak nem blokkolt.)

Éles környezetben mindig regisztráld a példányt a CrowdSec Console-ra is. Így egyetlen webes felületről látod az összes agent döntését, a MITRE ATT&CK dúsítást és a közösségi jelentéseket. A regisztráció ingyenes egy szerverig; több hoszthoz Team csomag szükséges.

# CrowdSec Console összekapcsolás (opcionális, de ajánlott)
sudo cscli console enroll -e context YOUR-ENROLL-KEY
sudo systemctl reload crowdsec

Kollekciók, forgatókönyvek és a CrowdSec Hub

A CrowdSec detektálási logikáját a Hub tartalmazza: közösségi git-repóban tárolt YAML parserek, scenariók és postoverflowk gyűjteménye. A kollekció (collection) egy előre csomagolt bundle. Például a crowdsecurity/nginx tartalmazza az nginx access.log parsert, az összes jellemző támadási forgatókönyvet (brute-force login, HTTP flood, path traversal), és a hozzájuk tartozó közösségi whitelisteket.

# Elérhető kollekciók böngészése és keresése
cscli hub list
cscli collections list
cscli scenarios list

# Egy scenario testreszabása (pl. SSH brute-force küszöb csökkentése)
sudo mkdir -p /etc/crowdsec/scenarios
cat <<'EOF' | sudo tee /etc/crowdsec/scenarios/ssh-bf-strict.yaml
type: leaky
name: mycompany/ssh-bf-strict
description: "SSH brute-force szigorú küszöbbel"
filter: "evt.Meta.log_type == 'ssh_failed-auth'"
leakspeed: "30s"
capacity: 3
groupby: evt.Meta.source_ip
labels:
  service: ssh
  type: bruteforce
  remediation: true
EOF
sudo systemctl reload crowdsec

A saját scenariók előnye, hogy a leakspeed és capacity paraméterekkel finomhangolhatod. Az alap SSH scenario 5 hibás bejelentkezést enged 30 másodpercen belül, a fenti szigorúbb változat pedig már 3 után is blokkol. Éles környezetben óvatosan használd, mert az adminok SSH ujjhibái is triggerelhetik. (Volt már, hogy magamat lockoltam ki egy pénteki demo előtt, azóta van whitelistem az iroda IP-jére.)

A Hub tartalmazza a postoverflow típusú modulokat is, amelyek a döntés meghozása előtt dúsítják vagy szűrik az eseményt. A crowdsecurity/rdns például visszakérdezi a támadó IP DNS PTR-jét, és ha ismert felhőszolgáltatóhoz tartozik (AWS, GCP, Azure), rákerül a döntésre.

nftables bouncer beállítása és tesztelése

A firewall bouncer a döntéseket egy crowdsec nevű nftables set-be írja, amit külön hook szabály referál. Ez azt jelenti, hogy a bouncer nem módosítja a meglévő tűzfalszabályaidat, csak hozzáad egy új láncot, amit elsőként ellenőriz a rendszer. Az alap konfiguráció a /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml fájlban van, és jellemzően három paramétert érdemes ellenőrizni.

mode: nftables
update_frequency: 10s
log_mode: file
log_level: info
api_url: http://127.0.0.1:8080/
api_key: <automatikusan generált>

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

A set-only: false beállítás azt jelenti, hogy a bouncer maga hozza létre a szükséges nftables táblát és láncot. Ha már meglévő nftables ruleset-ed van (pl. az nftables mesterfok alapján), állítsd set-only: true-ra, és manuálisan hivatkozz a @crowdsec setre az input láncodban:

# Meglévő nftables ruleset-be beillesztendő szabály
table inet filter {
    set crowdsec-blacklists {
        type ipv4_addr
        flags timeout
        size 131072
    }
    chain input {
        type filter hook input priority filter; policy drop;
        ip saddr @crowdsec-blacklists drop
        # ... többi szabály
    }
}

A telepítés után teszteld a bouncert. Adj hozzá kézzel egy döntést, és nézd meg, tényleg megjelenik-e az nftables setben.

# Kézi teszt: 5 perces blokk saját teszt-IP-re
sudo cscli decisions add --ip 203.0.113.42 --duration 5m --reason "teszt"

# Ellenőrizzük a döntéseket
sudo cscli decisions list

# Ellenőrizzük az nftables setet
sudo nft list set inet crowdsec crowdsec-blacklists

# 5 perc múlva automatikusan lejár, vagy manuálisan törölhető
sudo cscli decisions delete --ip 203.0.113.42

AppSec komponens: beépített WAF nginx elé

A 2024 óta stabil AppSec komponens a CrowdSec-et nem csak IP-alapú, hanem HTTP-tartalom-alapú védelmi eszközzé teszi. Az AppSec egy Coraza-alapú WAF motor, amit a bouncer (általában nginx lua-resty-http vagy HAProxy SPOE modul) minden bejövő kérésre lekérdez. Ha a szabálykészlet (pl. OWASP CRS 4.0) egyezést talál, a kérés blokkolódik, mielőtt az alkalmazás felé érne.

# AppSec komponens telepítése és alap virtual patch szabályok
sudo cscli collections install crowdsecurity/appsec-virtual-patching
sudo cscli collections install crowdsecurity/appsec-generic-rules

# nginx bouncer telepítése (Debian/Ubuntu)
sudo apt install crowdsec-nginx-bouncer

# Az AppSec konfig sablonja
sudo tee /etc/crowdsec/acquis.d/appsec.yaml <<'EOF'
appsec_config: crowdsecurity/appsec-default
labels:
  type: appsec
listen_addr: 127.0.0.1:7422
source: appsec
EOF

sudo systemctl restart crowdsec

Az AppSec előnye, hogy a szabályok közösségi forrásból frissülnek. Ha egy új Log4Shell-szerű 0-day megjelenik, a CrowdSec csapat perceken belül publikál virtual patch szabályt, amit a te bouncereid automatikusan letöltenek. Ez az operatív reakcióidő nagyságrenddel gyorsabb, mint kézzel írni egy ModSecurity szabályt vagy alkalmazásfrissítést telepíteni. A Sigstore-alapú ellátási lánc biztosításról az Cosign és Sigstore konténerkép-aláírás cikkben olvashatsz bővebben.

Megfigyelés Prometheus és Grafana segítségével

A CrowdSec agent és a bouncerek natívan exportálnak Prometheus metrikákat a 127.0.0.1:6060/metrics endpointon. Ez lehetővé teszi, hogy pontosan lásd, mely scenariók lőnek, mely IP-ket blokkoltál, és mekkora a CAPI szinkron késése. A Wazuh SIEM és XDR cikkben tárgyalt SIEM mellé a CrowdSec metrikái remekül dashboardolhatók.

# prometheus.yml részlet
scrape_configs:
  - job_name: 'crowdsec'
    static_configs:
      - targets: ['crowdsec-node1:6060', 'crowdsec-node2:6060']
    metrics_path: /metrics

A CrowdSec csapata publikál egy hivatalos Grafana dashboardot (ID: 15168), ami az összes kulcsmetrikát megjeleníti: aktív döntések száma, decision-per-scenario, parser-throughput, CAPI push/pull sikeressége. Éles környezetben állíts be riasztást a cs_appsec_reqs_denied_total gyors emelkedésére, mert ez rendszerint aktív támadás jele.

# Néhány hasznos PromQL példa
# Blokkolt IP-k növekedése az utolsó 5 percben
increase(cs_active_decisions[5m])

# Top 10 scenario, ami tüzelt az elmúlt órában
topk(10, sum by (name) (rate(cs_bucket_overflowed_total[1h])))

# WAF által blokkolt kérések aránya
rate(cs_appsec_reqs_denied_total[5m]) / rate(cs_appsec_reqs_total[5m])

Gyakori hibák és hibaelhárítás

A CrowdSec üzemeltetés során a leggyakoribb hibaosztályok a következők: (1) az agent nem olvassa a naplókat, (2) a bouncer nem tudja frissíteni a döntéseket, (3) a whitelistek nem érvényesülnek. Mindhárom eset a cscli parancsokkal gyorsan diagnosztizálható.

# Milyen fájlokat olvas az agent és milyen parsereket használ?
sudo cscli metrics show acquisition

# Bouncer állapota és utolsó pull időpontja
sudo cscli bouncers list

# Élő log követés
sudo journalctl -u crowdsec -f
sudo tail -f /var/log/crowdsec.log

# Debug módú újraolvasás egy konkrét naplóból
sudo crowdsec -c /etc/crowdsec/config.yaml -type journalctl \
  -dsn 'journalctl://filters=_SYSTEMD_UNIT=ssh.service' \
  -no-api

Ha az agent nem detektál semmit, először ellenőrizd a /etc/crowdsec/acquis.yaml fájlt: itt van felsorolva minden naplóforrás. A journalctl alapú források esetén a _SYSTEMD_UNIT filternek pontosan meg kell egyeznie a valós unit névvel. Az sshd.service és ssh.service különbség például teljesen kikapcsolhatja a detektálást Debian és RHEL között (nekem is ez volt az első nagy fejfájásom a multi-distro rollout során).

A leggyakoribb bouncer-hiba a lejárt vagy elveszett API kulcs. Ilyenkor a bouncer logban 401 Unauthorized jelenik meg. Regeneráld a kulcsot a cscli bouncers add my-bouncer paranccsal, és másold be a bouncer YAML-jébe. A közösségi CTI feed-hez való hozzáférés hibái a cscli capi status paranccsal nézhetők; a CrowdSec GitHub release oldalán érdemes követni a breaking change-eket verziófrissítés előtt.

Gyakran ismételt kérdések

A CrowdSec ingyenes vagy fizetős?

Az agent, a bouncerek és a közösségi Hub 100%-ban MIT licenc alatt ingyenesek. A CrowdSec Console alap csomagja is ingyenes egyetlen géphez; több szerver, MITRE ATT&CK dúsítás és SOC-szintű riasztás fizetős Team vagy Enterprise csomagot igényel.

Futhat a CrowdSec és a Fail2ban egyszerre ugyanazon a szerveren?

Technikailag igen, de nem ajánlott. Mindkettő ugyanazokat a napló-sorokat elemzi, és mindkettő módosítja a tűzfalat, ami versenyhelyzetet és duplikált blokkolást okozhat. Fokozatos migrációnál futtasd párhuzamosan pár napig, majd tiltsd le a Fail2ban-t.

Kell hozzá internetkapcsolat, hogy működjön?

Nem, a CrowdSec teljesen offline is működik, csak a közösségi feketelista (CAPI) szinkronizálásához kell kifelé menő HTTPS kapcsolat. Air-gapped környezetben az agent és a bouncerek helyi LAPI-val teljes értékű IPS-ként dolgoznak.

Támogat a CrowdSec Kubernetes és konténer környezetet?

Igen. Létezik hivatalos Helm chart, ami a CrowdSec-et DaemonSetként telepíti a node-okra, plusz Ingress bouncerek nginx-ingress és Traefik számára. A pod-log és Kubernetes audit log natívan feldolgozható.

Mennyi erőforrást fogyaszt egy átlagos szerveren?

Átlagos webszerveren az agent 80–120 MB RAM-ot és 1–3% CPU-t használ nyugalmi állapotban. A firewall bouncer további 15–25 MB-ot. AppSec komponens bekapcsolása esetén a memóriaigény 200–300 MB-ra emelkedhet, forgalomtól függően.

Mi történik, ha egy jóhiszemű felhasználó IP-je véletlenül blokkolt lesz?

A döntéseket manuálisan törölheted a sudo cscli decisions delete --ip <IP> paranccsal. Ha ismétlődik, adj hozzá whitelistet a /etc/crowdsec/parsers/s02-enrich/whitelists.yaml fájlban, ami CIDR- vagy DNS-alapú kizárást is támogat.