Bisher war CrowdSec unser verlässlicher Türsteher: Es hat IPs erkannt, die sich danebenbenehmen (z.B. durch zu viele fehlgeschlagene Logins), und diese dann via Bouncer auf Netzwerkebene blockiert. Das ist effektiv, hat aber eine Schwachstelle: Es ist “nur” Log-Parsing.
CrowdSec musste bisher warten, bis eine Anwendung (bei uns Traefik) einen Fehler in eine Logdatei schreibt, um darauf zu reagieren. Doch was passiert, wenn der Angriff gar keinen Fehler im Log erzeugt, sondern eine Sicherheitslücke in der Anwendung selbst ausnutzt (wie bei Log4Shell oder SQL-Injections)?
| Datum | Änderungen |
|---|---|
| 04.03.2026 | Erstellung dieser Anleitung |
| 20.03.2026 | Doppelte Inhalte zur Traefik Anleitung entfernt, Kapitel 6 angepasst. CHANGELOG |
1. Was ist CrowdSec AppSec?
Mit der Einführung der AppSec-Komponente verwandelt sich CrowdSec von einem reinen Log-Parser in eine vollwertige Web Application Firewall (WAF).
Anstatt nur Logs zu lesen, klinkt sich CrowdSec jetzt direkt in den Datenstrom ein. In unserem Fall sitzt es als Middleware direkt im Traefik Proxy. Jede HTTP-Anfrage wird analysiert, bevor sie überhaupt deine Docker-Container erreicht.
AppSec prüft dabei auf Muster, die wir als “Low Reputation” kennen:
- SQL-Injections (SQLi)
- Cross-Site Scripting (XSS)
- Remote Code Execution (RCE)
- Bekannte Angriffsvektoren (User-Agent Scans, Path Traversal)
2. Der Vorteil: Virtuelles Patchen
Der größte Vorteil ist das sogenannte Virtual Patching. Wenn morgen eine kritische Sicherheitslücke in einer deiner Apps bekannt wird, musst du nicht sofort Panik schieben und Updates einspielen (was man natürlich trotzdem tun sollte). CrowdSec kann die spezifischen Angriffsmuster auf diese Lücke oft schon blockieren, bevor der Patch überhaupt installiert ist. Es kauft dir wertvolle Zeit.
Grundlage dieser Anleitung ist die Anleitung von @psycho0verload zu unserer Traefik CrowdSec Combo (Kapitel 13). Ihr müsst dies bereits erledigt haben, damit ihr mit dieser Anleitung weitermachen könnt.
3. Wichtiger Hinweis für dieses Setup – Nur für Experten
Die hier gezeigte Konfiguration mit CrowdSec AppSec und CRS (Core Rule Sets) bietet eine sehr hohe Sicherheit, ist aber kein Setup für Anfänger!
Die strikten Regeln verursachen in der Praxis unweigerlich False Positives. Ohne tiefgreifendes Verständnis und manuelles Finetuning werden Standardanwendungen wie Nextcloud oder WordPress nicht mehr reibungslos funktionieren. Dies führt ebenfalls dazu, dass ihr auf eurem eigenen Server gebannt werdet.
Setzt diese Anleitung nur um, wenn ihr bereit seid, Logfiles zu analysieren und individuelle Ausnahmeregeln (Exclusions) für eure Dienste zu schreiben. Wer ein einfaches „Install-and-Forget“-System sucht, sollte auf die aggressiven CRS-Regeln verzichten. Diese Anleitung wird zu 100% dafür sorgen, dass initial eure Dienste / Anwendungen irgendwelche Fehler verursachen und nicht mehr korrekt funktionieren.
4. Grundvoraussetzungen
Bei diesem Inhalt handelt es sich um exklusiven Content für Community Plus Mitglieder und Supporter.
Bitte logge dich mit deinem Account ein um den Inhalt zu sehen.
Nun starten wir das Skript:
/opt/containers/traefik-crowdsec-stack/crowdsec-test.shHier solltet ihr nun folgendes sehen, wenn alles korrekt läuft:
==============================================
CrowdSec AppSec (WAF) Test-Skript
==============================================
Bitte gib deine Traefik-Domain ein (z.B. traefik.deinedomain.de): xxxx.de
Ziel-URL festgelegt auf: https://xxxx.de
Bereinige Altlasten (Lösche alle bestehenden Bans)...
[1/4] Zeige initiale AppSec-Metriken...
+-------------------------------------+
| Appsec Metrics |
+---------------+-----------+---------+
| Appsec Engine | Processed | Blocked |
+---------------+-----------+---------+
| 0.0.0.0:7422/ | 34 | 2 |
+---------------+-----------+---------+
+---------------------------------------------+
| Appsec '0.0.0.0:7422/' Rules Metrics |
+---------------------------------+-----------+
| Rule ID | Triggered |
+---------------------------------+-----------+
| 901340 | 2 |
| 930130 | 2 |
| 980170 | 2 |
| crowdsecurity/vpatch-env-access | 1 |
| crowdsecurity/vpatch-git-config | 1 |
+---------------------------------+-----------+
[2/4] Führe simulierte Angriffe gegen https://fatalplayers.de aus...
--- Standard Web-Angriffe (OWASP CRS IDs) ---
-> Teste SQL-Injection (SQLi)... Blockiert (HTTP Code: 403) ✓
-> Teste Cross-Site Scripting (XSS)... Blockiert (HTTP Code: 403) ✓
-> Teste Local File Inclusion (LFI)... Blockiert (HTTP Code: 403) ✓
--- Generische Web-Angriffe (Namen-IDs) ---
-> Teste WP Uploads PHP (generic-wordpress-uploads-php)... Blockiert (HTTP Code: 403) ✓
-> Teste WP Uploads Listing (generic-wordpress-uploads-listing)... Blockiert (HTTP Code: 403) ✓
--- Virtual Patching (CVEs & Exposures) ---
-> Teste PHP CGI RCE (CVE-2024-4577)... Blockiert (HTTP Code: 403) ✓
-> Teste Exposed .env Datei (vpatch-env-access)... Blockiert (HTTP Code: 403) ✓
-> Teste Exposed Git Verzeichnis (vpatch-git-config)... Blockiert (HTTP Code: 403) ✓
[3/4] Warte 4 Sekunden auf die Verarbeitung durch CrowdSec...
[4/4] Zeige aktualisierte AppSec-Metriken...
+-------------------------------------+
| Appsec Metrics |
+---------------+-----------+---------+
| Appsec Engine | Processed | Blocked |
+---------------+-----------+---------+
| 0.0.0.0:7422/ | 42 | 10 |
+---------------+-----------+---------+
+-------------------------------------------------------------+
| Appsec '0.0.0.0:7422/' Rules Metrics |
+-------------------------------------------------+-----------+
| Rule ID | Triggered |
+-------------------------------------------------+-----------+
| 901340 | 10 |
| 930100 | 1 |
| 930110 | 1 |
| 930120 | 1 |
| 930130 | 4 |
| 932160 | 1 |
| 941100 | 1 |
| 941110 | 1 |
| 941160 | 1 |
| 941390 | 1 |
| 942100 | 1 |
| 949110 | 3 |
| 980170 | 7 |
| crowdsecurity/generic-wordpress-uploads-listing | 1 |
| crowdsecurity/generic-wordpress-uploads-php | 1 |
| crowdsecurity/vpatch-CVE-2024-4577 | 1 |
| crowdsecurity/vpatch-env-access | 2 |
| crowdsecurity/vpatch-git-config | 2 |
+-------------------------------------------------+-----------+
==============================================
Test beendet!
Die Metriken ('Processed' und 'Blocked') sollten nun exakt um 8 gestiegen sein.Code-Sprache: PHP (php)
Hi zusammen,
falls jemand von euch – genau wie ich –nach einer Möglichkeit sucht, bestimmte Länder komplett auszusperren, wollte ich hier kurz meine Lösung teilen.
Der Clou dabei: Wir nutzen nicht
DropRequest(was die CPU bei einem Botnetz-Angriff durchgehend belasten würde), sondern triggern über die AppSec-Engine ein echtesSetRemediation('ban'). Dadurch fliegt die IP nach dem allerersten Versuch direkt in die globale Blockliste des Traefik-Bouncers und wird für z.B. 4 Stunden abgewiesen. Das schont die Server-Ressourcen ungemein!Hier ist die Konfiguration, die sich bei mir im Live-Betrieb absolut bewährt hat:
1. Die Konfiguration anlegenErgänze im CrowdSec-Verzeichnis unter
config/appsec-configs/diemrks-config.yamlmit folgendem Inhalt:YAML
description: Custom AppSec configuration with Geoblock for Traefik pre_eval: - filter: IsInBand == true && GeoIPEnrich(req.RemoteAddr)?.Country.IsoCode not in ["DE", "ES", "FR", "CH", ""] apply: - SetRemediation('ban')Wie funktioniert das Ganze?
pre_eval: Die Regel greift ganz am Anfang der WAF-Kette. Wenn ein Bot aus einem gesperrten Land anklopft, wird er sofort blockiert, bevor die WAF überhaupt tiefere (und CPU-intensive) Analysen wie SQL-Injection- oder XSS-Prüfungen startet.not in ["DE", "ES", "FR", "CH", ""]: Das ist eure Whitelist. Alle Länder, die hier nicht drinstehen, fliegen raus.""am Ende ist essenziell! Er sorgt dafür, dass Anfragen aus eurem lokalen Netzwerk (192.168.x.x) oder Docker-interne IPs nicht blockiert werden, da diese logischerweise keinen Länder-ISO-Code besitzen.SetRemediation('ban'): Das ist der Performance-Retter. Die IP wird für die in eurerprofiles.yamldefinierte Zeit (Standard: 4 Stunden) komplett auf Server-Ebene gebannt.2. Bonus-Tipp: Welche Domain wird eigentlich angegriffen? Wenn ihr den Geoblock aktiv habt, tauchen die gebannten IPs in eurer
cscli decisions listunter dem Grundcrowdsecurity/appsec-nativeauf.Weil CrowdSec auf der Konsole standardmäßig nicht anzeigt, welche eurer Subdomains eigentlich das Ziel war, könnt ihr euch mit diesem
jq-Befehl eine wunderschöne Echtzeit-Übersicht basteln, die das JSON der Alarme ausliest:Bash
Die Ausgabe sieht dann so aus:
2026-06-08T07:31:55Z | IP: 8.229.222.230 (US) -> Ziel: https://photos.deinedomain.de/server/.envMan sieht sofort das Herkunftsland, die IP und ob ein Bot gerade versucht, sensible Dateien (wie
.env) auf einer bestimmten Subdomain zu scannen.Vielleicht hilft das dem einen oder anderen, sein Setup noch ein Stück resilienter zu machen.
Hallo,
ich habe eine Verständnisfrage. Gibt es Anwendungen die so programmiert sind dass ich mein System öffnen muss sodass der Live test nicht zu 100% erfolgreich ist. Ich habe als Beispiel Wallebagger. Das bekomme ich als alerts list.
Key | Value |
+—————+————————————————————–+
| ja4h | po11nn17de00_c24cd69737ef_000000000000_000000000000 |
| matched_zones | ARGS.json.content |
| method | POST |
| msg | XSS Attack Detected via libinjection |
| msg | XSS Filter – Category 1: Script Tag Vector |
| msg | NoScript XSS InjectionChecker: HTML Injection |
| msg | Javascript method detected |
| name | native_rule:941100 |
| name | native_rule:941110 |
| name | native_rule:941160 |
| name | native_rule:941390 |
| target_uri | /api/entries.json
Wenn ich die 4 native_rule in die Regelliste aufnehmen erhalten ich im Live Test
-> Teste Cross-Site Scripting (XSS)… Durchgelassen (HTTP Code: 401) ✗ – WAF hat nicht gegriffen!
Gibt es da überhaupt eine Lösung. Vielen Dank
Gruß Andreas