Begriff
WAF (Web Application Firewall)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Eine normale Firewall (Layer 3/4) ist wie ein Türsteher, der Ausweise kontrolliert.
"IP 1.2.3.4 darf rein." - "Port 80 ist offen."
Sie schaut nicht in das Paket rein.
Eine WAF (Layer 7) ist wie ein Zollbeamter, der deinen Koffer öffnet.
Sie liest den HTTP-Inhalt.
Wenn jemand ?id=1 OR 1=1 (SQL Injection) sendet, sagt die normale Firewall: "Erlaubt (Port 80)".
Die WAF sagt: "Stopp! Das sieht wie ein Angriff aus." Und blockt es.
Sie schützt Webseiten vor Hacker-Tricks (OWASP Top 10).
Merksatz: Eine spezialisierte Firewall, die den HTTP/HTTPS-Verkehr auf Anwendungsebene analysiert, um Angriffe wie SQL-Injections, XSS und Bots abzuwehren.
Cloud WAF: Cloudflare, AWS WAF. Du schaltest sie einfach davor. Klick "Block SQL Injection". Fertig.
Self-Hosted: ModSecurity (Modul für Nginx/Apache). Man lädt Regelsätze ("Core Rule Set"), die böse Muster erkennen.
Beispiel Log:
Blockiert: Pattern match "<script>" at ARGS:comment. (Verhinderter XSS Angriff).
1. Signature vs. Anomaly Detection
- Signatur-basiert: Sucht bekannte Muster (
' OR 1=1,alert()).- Nachteil: False Positives (wenn ein User wirklich über SQL diskutieren will). Und man muss Signaturen täglich updaten.
- Anomalie-basiert (AI): Lernt das "normale" Verhalten. "User X ruft normalerweise 10 Seiten pro Minute auf. Jetzt ruft er 10.000 auf. Block!" (Rate Limiting / Bot Protection).
2. Virtual Patching
Du hast eine Sicherheitslücke im Code (z. B. Log4Shell).
Du kannst den Code nicht sofort updaten (Legacy App).
Du konfigurierst die WAF so, dass sie genau diesen Angriff blockt (${jndi:...}).
Das ist ein "Virtueller Patch". Die Lücke ist noch da, aber niemand kommt durch die WAF, um sie auszunutzen. Kauft Zeit.
3. Bypass Techniken
Hacker versuchen WAFs zu verwirren.
Statt UNION SELECT schreiben sie UnIoN%09SeLeCt.
WAFs müssen decodieren (URL-Decode, Base64-Decode), bevor sie prüfen.
Wenn die WAF und der Webserver unterschiedliche Parsing-Regeln haben (HTTP Parameter Pollution), schlüpft der Angriff durch.
ModSecurity Core Rule Set (CRS) Paranoia
Der Industriestandard für WAF-Regeln ist das OWASP ModSecurity Core Rule Set (CRS).
Das Problem: Wenn du das CRS stumpf aktivierst, blockt es oft 30% des legitimen Traffics. CRS arbeitet in Paranoia Levels (1 bis 4).
Level 1 (Default) fängt nur die banalsten, offenkundig bösartigen Dinge ab und lässt selten False-Positives zu. Level 3 oder 4 zerpflückt jeden Request komplett; es blockt Requests allein schon, wenn Sonderzeichen in einem Cookie vorkommen. In modernen DevOps-Pipelines lässt man die WAF anfangs wochenlang im DetectionOnly-Modus laufen, füttert die Logs in ein SIEM (wie Splunk), und whitelisted legitime, aber fälschlich markierte App-Requests (Regel-Tuning), bevor man sie scharf schaltet (SecRuleEngine On).
WAF-Bypassing durch Fragmentierung
WAFs lesen Regex-Muster im HTTP-Strom. Was, wenn man den Strom zerreißt?
HTTP Parameter Pollution (HPP): Der Client sendet an dasselbe PHP-Script: ?id=1&id=' OR 1=1. Manche WAFs prüfen nur den allerersten Parameter (id=1 -> unbedenklich). Das Backend parst aber den letzten Wert (OR 1=1) und schickt ihn ungeschützt in die DB.
Chunked Transfer Encoding: Wenn der Angreifer den Body "ge-chunked" und extrem verzögert an die WAF sendet, fragmentiert er das Angriffsmuster über etliche TCP-Pakete. Viele WAFs fassen nach 500ms Timeout den Body nicht mehr zusammen, passen den Request unanalysiert durch (Fail Open), um legitime Uploads nicht zu stören – und der Hack gelingt.
WAF als CDN-Edge Compute (Cloudflare Workers)
Früher war die WAF eine physische Appliance im Rack. Heute sitzt sie direkt im CDN (Edge Network).
Der gigantische Vorteil: Die WAF blockt DDoS-Layer-7 Attacks hunderte Meilen vor deinem Rechenzentrum ab. Serverless-Edge-Logiken (Cloudflare Workers) erlauben es dir, dort dynamisch Code auszuführen: "Wenn IP aus Tor-Netzwerk + User-Agent leer + Request an /login -> Löse serverseitig eine Mathe-Puzzle-Challenge aus. Erst wenn gelöst, darf der Request per SSL weiter ans echte Backend." Dein Backend-Server bekommt von den Millionen Bot-Abfragen nicht einen einzigen CPU-Zyklus mit.
Quick-Check
Ersetzt WAF sicheren Code?
Nein! "Defense in Depth". Eine WAF kann umgangen werden. Dein Code sollte trotzdem Injections verhindern (Prepared Statements). Die WAF ist nur der Airbag, nicht die Bremse.DDoS Schutz?
Ja, WAFs sind oft der beste Schutz gegen Layer-7 DDoS (HTTP Floods). Sie können Challenges stellen ("Löse dieses JavaScript-Rätsel"), um Bots von echten Browsern zu trennen.Positiv-Modell?
Die härteste Einstellung. "Alles ist verboten, außer was explizit erlaubt ist." (z. B. "Das Feld ID darf nur Zahlen enthalten"). Sehr sicher, aber extrem aufwendig zu konfigurieren.