CrowdSec: moderne, kollaborative Angriffsabwehr

Fail2ban blockt Brute-Force auf deinen SSH-Zugang – aber was ist mit den Scannern, die den ganzen Tag deine Web-Apps nach Lücken abklopfen? CrowdSec schließt genau diese Lücke: Es erkennt Angriffe in den Zugriffs-Logs von Traefik und sperrt die Angreifer, bevor sie deine Anwendungen überhaupt erreichen.

Was bauen wir?

Am Ende läuft ein CrowdSec-Agent neben deinem Traefik, der die Zugriffs-Logs mitliest, verdächtiges Verhalten anhand von Szenarien erkennt (Port-Scans, Path-Probing, bekannte CVE-Ausnutzung, Login-Brute-Force) und Angreifer-IPs auf eine Sperrliste setzt. Ein Bouncer – hier als Traefik-Plugin – setzt diese Entscheidungen durch: Eine gesperrte IP bekommt bei jeder deiner Apps nur noch 403 Forbidden. Getestet mit CrowdSec v1.7.8, dem Traefik-Bouncer-Plugin v1.7.1 und Traefik v3.7.

So greifen die Teile ineinander:

• Agent + Local API (LAPI): liest die Logs, wertet sie gegen die Szenarien aus und verwaltet die aktiven Sperren („Decisions"). Das ist der Container, den wir aufsetzen.
• Bouncer: fragt die LAPI bei jeder Anfrage „ist diese IP gesperrt?" und blockt bei Ja. Der Traefik-Bouncer läuft als Plugin direkt im Reverse Proxy – kein zusätzlicher Container.
• Community-Blocklist: CrowdSec meldet (anonymisiert) erkannte Angriffe an das zentrale Netzwerk und bekommt dafür eine von allen Nutzern gespeiste Blocklist zurück. IPs, die andernorts schon als bösartig auffielen, sind bei dir dann von vornherein gesperrt. Genau das ist das „kollaborativ" im Titel.

Voraussetzungen

• Ein laufender Reverse Proxy mit Traefik (das proxy-Netz und der Resolver le stammen von dort) mit mindestens einer App dahinter.
• Fail2ban für den SSH-Schutz – CrowdSec kümmert sich hier um die HTTP-Ebene, nicht um SSH.
• Grundwissen zu Docker Compose und ein abgesicherter Server mit aktiver Firewall.

Schritt für Schritt

Schritt 1: Traefiks Zugriffs-Logs einschalten

CrowdSec kann nur erkennen, was es sieht – und es sieht Angriffe über Traefiks Zugriffs-Logs. Die sind standardmäßig aus. Öffne die compose.yaml deines Traefik (aus dem Traefik-Tutorial, Ordner ~/traefik) und ergänze im command-Block diese drei Zeilen:

      - "--accesslog=true"
      - "--accesslog.filepath=/var/log/traefik/access.log"
      - "--accesslog.format=json"

Das JSON-Format ist wichtig – die CrowdSec-Parser erwarten es so. Damit sowohl Traefik (schreibend) als auch CrowdSec (lesend) an dieselbe Datei kommen, legst du sie auf einen festen Host-Pfad. Ergänze im volumes-Block von Traefik:

      - /var/log/traefik:/var/log/traefik

Lege das Verzeichnis auf dem Host an und starte Traefik neu:

sudo mkdir -p /var/log/traefik
cd ~/traefik && docker compose up -d

Ruf einmal eine deiner Apps auf und prüfe, dass Zeilen ankommen:

tail -n 2 /var/log/traefik/access.log

Du solltest JSON-Zeilen mit "ClientHost", "RequestPath" und "DownstreamStatus" sehen. Bleibt die Datei leer, stimmt der Pfad im Volume nicht, oder es kam schlicht noch keine Anfrage.

Diese Kontrolle nicht überspringen: CrowdSec nimmt in Schritt 2 nur Dateien auf, die beim Start schon existieren. Fehlt die access.log in dem Moment, meldet es beim Hochfahren No matching files for pattern /var/log/traefik/access.log und liest sie auch später nicht – dann hilft nur ein Neustart des Containers.

Schritt 2: Den CrowdSec-Container aufsetzen

CrowdSec bekommt einen eigenen Ordner. Erzeuge zuerst einen Bouncer-Schlüssel – mit ihm authentifiziert sich später der Traefik-Bouncer an der LAPI:

mkdir -p ~/crowdsec && cd ~/crowdsec
openssl rand -hex 32

Kopiere die Ausgabe; sie kommt gleich an zwei Stellen zum Einsatz. Lege die Acquisition an – sie sagt CrowdSec, welche Datei mit welchem Log-Typ zu lesen ist:

# ~/crowdsec/acquis.yaml
filenames:
  - /var/log/traefik/access.log
labels:
  type: traefik

Jetzt die compose.yaml. Ersetze DEIN_BOUNCER_KEY durch den erzeugten Schlüssel:

services:
  crowdsec:
    image: crowdsecurity/crowdsec:v1.7.8
    container_name: crowdsec
    environment:
      COLLECTIONS: "crowdsecurity/traefik"
      BOUNCER_KEY_TRAEFIK: "DEIN_BOUNCER_KEY"
      GID: "1000"
    volumes:
      - ./acquis.yaml:/etc/crowdsec/acquis.d/traefik.yaml:ro
      - /var/log/traefik:/var/log/traefik:ro
      - crowdsec-db:/var/lib/crowdsec/data/
      - crowdsec-config:/etc/crowdsec/
    networks: [proxy]
    restart: unless-stopped

volumes:
  crowdsec-db:
  crowdsec-config:

networks:
  proxy:
    external: true

Was hier wichtig ist:

• COLLECTIONS: crowdsecurity/traefik installiert beim ersten Start die passende Sammlung aus Parsern und Szenarien für Traefik-Logs (inklusive der HTTP-Basisszenarien).
• BOUNCER_KEY_TRAEFIK registriert direkt beim Start einen Bouncer namens TRAEFIK mit deinem Schlüssel – das spart den Weg über cscli bouncers add.
• GID: "1000" lässt den CrowdSec-Prozess unter dieser Gruppe laufen. 1000 ist der übliche Default für den ersten Nutzer; läuft Traefik als root, ist die access.log meist world-readable und die GID ohnehin egal. Ist sie enger gesetzt, prüfe mit ls -l /var/log/traefik/access.log und trag die GID der Gruppe der Datei ein.
• Das Log ist nur lesend (:ro) eingebunden. CrowdSec hängt im proxy-Netz, damit der Traefik-Bouncer die LAPI später unter crowdsec:8080 erreicht.

Starte den Container und prüfe, dass alles greift:

docker compose up -d
docker exec crowdsec cscli collections list

Die Traefik-Collection und die HTTP-Szenarien sollten als enabled erscheinen:

 Name                                 📦 Status   Version
 crowdsecurity/base-http-scenarios    ✔️  enabled  1.4
 crowdsecurity/http-cve               ✔️  enabled  3.0
 crowdsecurity/linux                  ✔️  enabled  0.4
 crowdsecurity/sshd                   ✔️  enabled  0.9
 crowdsecurity/traefik                ✔️  enabled  0.2
 crowdsecurity/whitelist-good-actors  ✔️  enabled  0.4

linux, sshd und whitelist-good-actors hast du nicht angefordert – die bringt das Image von Haus aus mit. sshd läuft dabei ins Leere, solange du kein SSH-Log in die Acquisition aufnimmst (das macht bei uns weiter fail2ban); whitelist-good-actors verhindert, dass bekannte gute Bots wie der Googlebot gesperrt werden.

Prüfe, dass die Community-Blocklist aktiv ist – das kostet nichts und ist der halbe Nutzen von CrowdSec:

docker exec crowdsec cscli capi status

You can successfully interact with Central API (CAPI)
Sharing signals is enabled
Pulling community blocklist is enabled
Pulling blocklists from the console is enabled

Pulling community blocklist is enabled bestätigt, dass du die kollektive Sperrliste der CrowdSec-Community beziehst – Angreifer, die anderswo auffällig wurden, sind bei dir schon gesperrt, bevor sie es überhaupt versuchen.

Schritt 3: Den Traefik-Bouncer einbauen

Jetzt der Teil, der die Sperren durchsetzt. Der Bouncer ist ein Traefik-Plugin und besteht aus zwei Ergänzungen an deinem Traefik: das Plugin laden und eine Middleware definieren, die auf alle Apps wirkt.

Lade das Plugin, indem du im command-Block von ~/traefik/compose.yaml ergänzt:

      - "--experimental.plugins.bouncer.modulename=github.com/maxlerebourg/crowdsec-bouncer-traefik-plugin"
      - "--experimental.plugins.bouncer.version=v1.7.1"
      - "--entrypoints.websecure.http.middlewares=crowdsec@file"

Die letzte Zeile hängt die Bouncer-Middleware global an den websecure-Entrypoint – damit läuft jede HTTPS-Anfrage an jede App durch den Bouncer, ohne dass du jede App einzeln anfassen musst.

Der Zusatz @file sagt Traefik, woher die Middleware kommt: aus dem File-Provider, also aus einer YAML-Datei statt aus Container-Labels. Der Traefik-Aufbau aus dem Traefik-Tutorial kommt ohne diesen Provider aus – du schaltest ihn also jetzt mit zwei weiteren Zeilen im command-Block ein:

      - "--providers.file.directory=/dynamic"
      - "--providers.file.watch=true"

Und mountest das Verzeichnis, aus dem er liest, dazu in den volumes-Block:

      - ./dynamic:/dynamic:ro

--providers.file.watch=true lohnt sich hier besonders: Traefik liest Änderungen an der Middleware-Datei damit ohne Neustart ein – im Test hat eine geänderte Bouncer-Konfiguration nach wenigen Sekunden gegriffen.

Lege die Middleware an (Pfad an deinen File-Provider angepasst):

# ~/traefik/dynamic/crowdsec.yaml
http:
  middlewares:
    crowdsec:
      plugin:
        bouncer:
          enabled: true
          crowdsecMode: stream
          crowdsecLapiScheme: http
          crowdsecLapiHost: crowdsec:8080
          crowdsecLapiKey: "DEIN_BOUNCER_KEY"

crowdsecLapiKey ist derselbe Schlüssel wie in Schritt 2 – der Bouncer weist sich damit bei der LAPI aus. Mit crowdsecMode: stream zieht der Bouncer die Sperrliste in einem festen Intervall komplett vor und beantwortet jede Anfrage aus dem lokalen Cache – der vom Plugin empfohlene Modus, weil er die LAPI nicht bei jedem Request belastet.

Starte Traefik neu, damit es das Plugin herunterlädt und die Middleware lädt:

cd ~/traefik && docker compose up -d
docker compose logs -f traefik

Im Log darf kein ERR zum Plugin oder zur Middleware stehen (Traefik v3 loggt bei Standard-Level nur Fehler – eine ruhige Ausgabe ist das gute Zeichen). Prüfe von der CrowdSec-Seite, dass der Bouncer sich verbunden hat:

docker exec crowdsec cscli bouncers list

 Name     IP Address  Valid  Last API pull         Type                             Version  Auth Type
 TRAEFIK  172.18.0.4  ✔️      2026-08-06T23:37:45Z  Crowdsec-Bouncer-Traefik-Plugin  v1.7.1   api-key

Ein gesetztes Last API pull beweist: Das Plugin spricht mit der LAPI. Die Spalte Version meldet dabei die Plugin-Version zurück – ein bequemer Weg, nach einem Update zu prüfen, dass Traefik wirklich die neue Fassung geladen hat und nicht eine gecachte alte.

Schritt 4: Scharf schalten und die Sperre testen

Ruf eine deiner Apps auf – sie sollte ganz normal antworten:

curl -s -o /dev/null -w "%{http_code}\n" https://DEINE_APP.DEINE_DOMAIN/

200

Jetzt sperrst du testweise eine IP von Hand und schaust, ob der Bouncer sie aussperrt. Nimm deine eigene öffentliche IP (curl -s https://ifconfig.me):

docker exec crowdsec cscli decisions add --ip DEINE_TEST_IP --duration 5m --reason "test"

Nach der Wartezeit bekommt die gesperrte IP nur noch:

curl -s -o /dev/null -w "%{http_code}\n" https://DEINE_APP.DEINE_DOMAIN/

403

Heb die Test-Sperre wieder auf:

docker exec crowdsec cscli decisions delete --ip DEINE_TEST_IP

Schritt 5: Echte Angriffe erkennen lassen

Der eigentliche Sinn: CrowdSec sperrt von selbst, ohne dass du Regeln schreibst. Sobald ein Scanner deine Domain nach Pfaden abklopft (viele 404 in kurzer Zeit), greift das Szenario crowdsecurity/http-probing. So sieht eine automatisch erkannte Sperre aus:

docker exec crowdsec cscli alerts list

 ID  value              reason                             country  as                     decisions
 3   Ip:162.142.125.29  crowdsecurity/http-probing         US       398324 CENSYS-ARIN-01  ban:1
 2   Ip:162.142.125.29  crowdsecurity/http-wordpress-scan  US       398324 CENSYS-ARIN-01  ban:1

docker exec crowdsec cscli decisions list

 ID  Source    Scope:Value        Reason                      Action  Country  AS                     Events
 3   crowdsec  Ip:162.142.125.29  crowdsecurity/http-probing  ban     US       398324 CENSYS-ARIN-01  11

Zwei Dinge sind daran lehrreich. Erstens reichert CrowdSec die Sperre automatisch um Land und Provider (AS) an – hier gehört die IP zum Adressbereich des Internet-weiten Scanners Censys, und sie hat gleich zwei Szenarien ausgelöst: das allgemeine Abklopfen von Pfaden und die WordPress-Variante davon. Zweitens kann eine IP zwar mehrere Alerts, aber nur eine aktive Entscheidung haben – cscli decisions list meldet die zweite als duplicated entries skipped.

Neben den selbst erkannten Angriffen tauchen hier mit der Zeit auch Sperren mit der Quelle lists:crowdsecurity/... auf – das ist die Community-Blocklist: IPs, die weltweit schon negativ aufgefallen sind, blockst du, bevor sie dich das erste Mal treffen.

Wer die Sperren lieber grafisch statt in cscli-Tabellen sieht, meldet die Instanz kostenlos in der CrowdSec-Console an (der Enroll-Befehl steht in „Wartung & Backups"). Dort erscheinen dieselben Entscheidungen aufbereitet:

Die mit der Traefik-Collection installierten HTTP-Szenarien decken das ab, was echte Scanner den ganzen Tag versuchen: das Abklopfen nicht existierender Pfade (http-probing), das Suchen nach sensiblen Dateien und Backdoors, Path-Traversal- und SQL-Injection-/ XSS-Sondierungen, verdächtige User-Agents bekannter Scanner sowie die Ausnutzung bekannter CVEs (aus der Collection crowdsecurity/http-cve). Welche Szenarien aktiv sind, zeigt docker exec crowdsec cscli scenarios list.

Ob CrowdSec deine Logs überhaupt liest, zeigt die Metrik-Übersicht. Ein blankes cscli metrics schüttet inzwischen ein Dutzend Tabellen aus – frag deshalb gezielt nur die Acquisition ab:

docker exec crowdsec cscli metrics show acquisition

| Source                           | Lines read | Lines parsed | Lines unparsed | Lines poured to bucket | Lines whitelisted |
| file:/var/log/traefik/access.log | 40         | 40           | -              | -                      | 40                |

Lines read und Lines parsed gleich hoch heißt: CrowdSec liest die Datei und versteht das JSON. Dass hier auch Lines whitelisted bei 40 steht, ist dem Test geschuldet – die Anfragen kamen aus dem Docker-Netz (siehe Kasten oben). Fehlt die Zeile ganz, kommt kein Log an: cscli lässt leere Tabellen weg, du siehst also nicht Lines read: 0, sondern überhaupt keine Acquisition-Zeile – dann zurück zu Schritt 1.

Schritt 6: Dich selbst nicht aussperren

Ein Fehlalarm gegen deine eigene Wartungs-IP ist ärgerlich. Trag deine feste IP als vertrauenswürdig in die Middleware ein – der Bouncer prüft sie dann gar nicht erst. Ergänze in ~/traefik/dynamic/crowdsec.yaml unter bouncer::

          clientTrustedIPs:
            - "DEINE_FESTE_IP/32"

Mit --providers.file.watch=true (Schritt 3) übernimmt Traefik die Änderung ohne Neustart. Nachgeprüft: Eine als vertrauenswürdig eingetragene IP bekommt selbst bei aktiver Sperre weiter 200 – der Bouncer fragt die Sperrliste für sie gar nicht erst ab.

Hast du dich doch einmal selbst gesperrt, hebt ein Befehl die Sperre sofort auf – und im Notfall kommst du über die VNC-Konsole im SCP immer noch auf den Server:

docker exec crowdsec cscli decisions delete --ip DEINE_IP   # eine IP
docker exec crowdsec cscli decisions delete --all           # alle Sperren

Wenn es nicht funktioniert

Wartung & Backups

• Szenarien aktuell halten. CrowdSecs Stärke sind gepflegte Erkennungsregeln – zieh sie regelmäßig nach: docker exec crowdsec cscli hub update && docker exec crowdsec cscli hub upgrade. Das Image (crowdsecurity/crowdsec) und die Plugin-Version (v1.7.1) hebst du bewusst an; lies bei Hauptversionen die Release-Notes. Nach einem Plugin-Update zeigt dir die Spalte Version in cscli bouncers list, ob Traefik die neue Fassung wirklich geladen hat. CrowdSec entwickelt sich zügig – ein guter Kandidat für regelmäßige Versionsprüfung.

• Zugriffs-Log rotieren. Traefiks /var/log/traefik/access.log wächst sonst unbegrenzt. Richte eine logrotate-Regel ein – zwingend mit copytruncate: Diese Variante kopiert die Datei weg und leert das Original an Ort und Stelle, statt es umzubenennen und neu anzulegen. Nur so behält CrowdSecs Tail den Dateizugriff (bei rename/create verlöre es den Handle und läse nichts mehr). Lege /etc/logrotate.d/traefik an:

  Ausgabe

  /var/log/traefik/access.log {
      daily
      rotate 7
      compress
      missingok
      notifempty
      copytruncate
  }

  CrowdSec liest nach dem Truncate an der wieder wachsenden Datei ganz normal weiter – ein Neustart des Containers ist nicht nötig.

• fail2ban bleibt. Nimm fail2ban nicht heraus – es schützt weiter deinen SSH-Zugang auf Host-Ebene, während CrowdSec die Web-Apps abdeckt. Zwei Werkzeuge, zwei Zuständigkeiten.

• Backups. Sichern musst du vor allem deine Konfiguration: den Ordner ~/crowdsec (compose.yaml, acquis.yaml) und ~/traefik/dynamic/crowdsec.yaml mit dem Bouncer-Key. Nimm sie in dein Restic-Backup auf. Die Sperrlisten selbst sind flüchtig und bauen sich von allein wieder auf – kein Backup nötig.

• Optional: das CrowdSec-Dashboard. Wer die Angriffe grafisch sehen will, meldet die Instanz kostenlos in der CrowdSec Console an (docker exec crowdsec cscli console enroll DEIN_ENROLL_KEY). Die Community-Blocklist läuft auch ohne Anmeldung.

• In dein Monitoring einbinden. cscli metrics liefert dir Zahlen fürs Terminal; für Dauerbeobachtung stellt CrowdSec einen Prometheus-Endpunkt bereit (in der Config unter prometheus: aktivieren), den du an deinen Grafana-Stack hängen kannst. Dann siehst du Sperren nach Herkunft und Szenario auf einen Blick:

  

• Ehrlich zum Aufwand: Nach dem Aufsetzen läuft CrowdSec weitgehend allein. Plane einmal im Monat den hub upgrade und einen Blick auf cscli metrics und die Container-Version ein.