Web Application Firewall und Schutz vor Angriffen

Kurze Zusammenfassung

WAF/WAAP filtert und überwacht den HTTP (S )/WebSocket-Verkehr auf Anwendungsebene: blockiert die Ausnutzung von Schwachstellen (OWASP Top 10), Versuche, die Authentifizierung zu umgehen, Scans, automatisierten Botverkehr und L7 DDoS. Der moderne Stack wird durch Anti-Bot-Engine, API-Schutz, Rate-Limiting, virtuelle Patches sowie eine enge Integration mit CI/CD ergänzt, so dass die Regeln so sicher wie der Code ausgerollt werden.

Rollen und Platz in der Architektur

Edge/CDN WAF (Cloud): geringe Latenz, globale Reputation/Managed Rules, L7 DDoS.
Self-hosted WAF (on-prem/K8s): tiefe Integration mit internen Netzwerken, Feinabstimmung.
WAAP-Ansatz: WAF + API-Gateway-Funktionen (Schema-Validierung, authZ), Anti-Bot, L7 DoS, mTLS.
Einschlussschemata: Reverse-proxy vor der Anwendung; Ingress-Controller in der K8s; Service Mesh-Filter; sidecar.

Sicherheitsmodell

Negative Sicherheit (Signaturen/CRS): schnelle Abdeckung bekannter Techniken (SQLi/XSS/SSRF/RCE).
Positive Sicherheit (allow-list): Wir erlauben nur „gültige“ Abfragen (Methoden/Pfade/Schemata/Inhaltstypen).
Virtual Patching: Sofortige Blockierung des Exploits vor dem Code-Fix.
Kontextualität: verschiedene Richtlinien für statische Inhalte, APIs, Admins, Downloads, Webhooks.

Typische Bedrohungen und Maßnahmen

OWASP Top 10: SQLi, XSS, IDOR/BOLA, SSRF, Injektionen in Templaters, Deserialisierung, Misconfigi.
L7 DDoS: langsame Anfragen/Header, Burst für heiße Endpunkte → Schutz: Rate-Limits, Challenge, Auto-Block.
Bots/Scraper: Verhalten, Frequenz, „nicht-menschliche“ Muster, Device-Fingerprinting, dynamische Token.
Credential Stuffing/ATO: Abfangen/Overkill von Logins → Anomalie durch IP/ASN, Velocity-Regeln, zusätzliche Faktoren.
Downloads: Typ/Größe/Multiskan durch Antivirus, „image-only“ in Medienzonen.
API/GraphQL: Schema-Validierung, 'maxDepth '/' maxCost', Verbot von nicht strafbaren Wildcards, Kontrolle von Methoden und Headern.

Richtlinien und Regelkonstruktoren

1. Transport: TLS 1. 2+/1. 3, HSTS, mTLS auf empfindlichen Backends.

2. Methoden: allow-list ('GET, POST, PUT, DELETE, PATCH, OPTIONS') ist einmalig auf der Ressource.

3. Wege: strenge Masken/Regexes; Admin/Billing - auf ein separates Präfix/Domain.

4. Überschriften: Whitelists, Verbot von gefährlichen ('X-Original-URLs', Nicht-Standard) unnötig.

5. Körper: JSON-nur/Multipart-nur entlang der Route; Limits' Content-Length', Block von Binären zu „Login/Suche“.

6. Rate limits: per-IP/ASN/key/organization; individuelle Limits für „teure“ Anfragen.

7. Anti-Bot: Verhaltensbewertung, „nicht irritierende“ Herausforderungen, Kleben von Identitäten (Cookie-Token, FP- JA3/TLS).

8. CRS/Managed Rules: enthalten, Tuning für FP.

9. Wirth-Patches: Schnelles Blockieren bekannter Parameter/Angriffsmuster.

10. Logs/Metriken: einheitliches Format, Korrelation mit 'trace _ id', FP/TP-Berichte.

Tuning-Praxis: So reduzieren Sie Fehlalarme

Neue Regeln im Detect-only/Count-Modus (Schatten) mit Traffic-Sampling ausführen.
Kontextabhängige Ausnahmen erstellen ('path =/search', 'param = q' Sonderzeichen zulassen).
Teilen Sie die Zone: „öffentliche Seiten“ vs „sensible Operationen“ (die Schwelle der Aggressivität ist unterschiedlich).
Förderband: Regel → Staging → Kanarienvogel (1-5%) → Prod; Rollback nach FP-Metriken.
Führen Sie ein Verzeichnis von „falschen“ payload für Regressionstests.

Integration in DevSecOps

CI: statische Regeln in Git; Tests: Replikation realer Anfragen + Synthetik aus dem Angriffskatalog.
CD: Kanarienbilder, Fichenfahnen; „politische“ Überwachung (Regeländerung = Änderung).
RASP und SAST/DAST: WAF ergänzt, ersetzt aber nicht die Code-Korrektur.

Beobachtbarkeit und SLO

• p95/99 Latenz durch WAF; Anteil der Blockierten/Verpassten; share Managed Rules vs custom; «attack rate».
• Anti-Bot: Anteil Herausforderungen/Übergaben, FP/TP.
• L7 DDoS: burst-rate, auto-mitigation events.

• "Nicht mehr als 0. 5% FP für autorisierte Transaktionen/Tag".
• «p95 overhead WAF ≤ 10 мс».
• Die TTR des virtuellen Patches ≤ 30 Minuten.
• Warnungen: 4xx/5xx Splash nach der Veröffentlichung der Regeln; Wachstum von FP; der Fall der Passage von Captches; Abbau der JWKS/mTLS-Validierung.

Beispiele für Konfigurationen

ModSecurity + OWASP CRS (Nginx)

nginx
Enabling ModSecurity modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main. conf;

apache
SecRuleEngine On
Include /usr/local/owasp-modsecurity-crs/crs-setup. conf
Include /usr/local/owasp-modsecurity-crs/rules/.conf

Example of an exception for a search parameter
SecRule REQUEST_URI "@beginsWith /search" "id:900100,phase:1,pass,nolog,ctl:ruleRemoveByTag=attack-xss"
SecRule REQUEST_URI "@beginsWith /search" "id:900101,phase:2,pass,ctl:ruleRemoveTargetById=942100; ARGS:q"

AWS WAF (JSON, Rate Limit + Länderlistenblock)

json
{
"Name": "prod-web-acl",
"Scope": "CLOUDFRONT",
"DefaultAction": { "Allow": {} },
"Rules": [
{
"Name": "BurstLogin",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": { "ByteMatchStatement": {
"SearchString": "/login",
"FieldToMatch": { "UriPath": {} },
"TextTransformations": [{ "Priority": 0, "Type": "NONE" }],
"PositionalConstraint": "CONTAINS"
}}
}
},
"Action": { "Block": {} },
"VisibilityConfig": { "MetricName": "BurstLogin", "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true }
}
]
}

Cloudflare (Expression Rules)

(http. request. uri. path contains "/admin" and ip. geoip. country ne "UA")
or (http. request. uri. path eq "/login" and cf. threat_score > 10)
or (http. request. uri. path contains "/api" and not http. request. headers["authorization"][0] contains "Bearer ")

NGINX: Eine einfache Regel zu Methoden/Körpern

nginx location /api/withdraw {
limit_except POST { deny all; }
if ($request_method = POST) {
set $cl $http_content_length;
if ($ cl = "") {return 411;} # length is required if ($ cl> 1048576) {return 413;} # ≤ 1MB add_header X-Idempotency-Required "true";
}
}

GraphQL: Begrenzer

„maxDepth = 6“, „maxCost = 1000“, Verbot von „__ Schema“ in der Produktion, Allow-List-Operationen, Validierung von Überschriften („Content-Type: application/json“).

Anti-Bot und menschenfreundliche Prüfungen

Invisible Challenge (JS-Challenges ohne Captcha), Proof-of-Work auf „teuren“ Wegen, Verhaltensanalyse (Bewegungen/Timings).
TLS/JA3-Fingerprinting, IP/ASN-Reputation, Proxy/VPN-Listen (innerhalb angemessener Grenzen).
Traps (Honeypot-Felder) auf Formularen, dynamische Form/Session-Token.
Schutz der Privatsphäre: Minimierung des Tracking, transparente Richtlinien, Opt-out-Optionen.

API-Fokus

Schema-first: OpenAPI/JSON Schema zur Validierung; Verbot von überflüssigen Feldern.
Auth: obligatorisch Bearer JWT oder mTLS; reject без `Authorization`.
Rate/Quota: per-key/per-org; bei Überschreitung „soft block „/slowing.
Webhooks: HMAC-Signatur, 'timestamp + nonce', kurzes Empfangsfenster.
GraphQL: siehe Limiter oben; protokollieren Sie den Namen/die Bezeichnung der Operation.

Downloads und Medien

Größenbeschränkung, Whitelists MIME/Erweiterungen, Umbenennen von Dateien;

AV-Scan (Multi-Engine), ImageMagick-Richtlinie (keine gefährlichen Decoder);

Thumb-Service auf einer separaten Domain, serve-only-images.

Sicherheit von Admins und kritischen Bereichen

Separate Domain/Pfad, mTLS/Verbot mit generischen ASNs/Ländern, enge Rate Limits, JIT-Zugänge, IP-Allow-List.
Zusätzliche Signale (Device Posture, Risk Score) → eine zweite Überprüfung erfordern.

Vorgänge, Vorfälle und virtuelle Patches

Runbook: schnelle Freigabe der Blockregel, TTL-Einschränkung, Benachrichtigung der Befehle.
Rollback-Kriterien: Wachstum 4xx/5xx> Schwelle, FP> Schwelle, p95 latency↑.
Post-mortem: Test zum Regressionsregelsatz hinzufügen, SIGMA-alert in SIEM fixieren.

Compliance und Datenschutz

Minimum protokollieren: Pfad/Methode/Code/Blockursache/IDs; Speichern Sie keine PII/Körpergeheimnisse.
Aufbewahrungsfristen für Richtlinienprotokolle; Zugriff - nach Rollen; Verschlüsselung auf der Festplatte.

Funktionen für iGaming/Fintech

Zahlungen/Auszahlungen/Wallets: Per-Org-Quoten, mTLS zu PSP, strenge Allow-Pfadlisten, HMACs für PSP-Webhooks.
ATO/Bonus-Missbrauch: Velocity-Regeln für Login/Registrierungen/Promo-Codes, Verhaltensgrenzen und Anti-Bot.
Content Provider/Studios: einzelne Domains/Policies, IP/ASN Allow-List, Time-to-Wallet/Conversions Monitoring auf die Auswirkungen der WAF.
Regionale Anforderungen: Geo-Policies (Länder/Regionen), Transparenz der Behandlungen für die DSGVO.

Roadmap für die Implementierung

1. Zonenbestand (öffentlich, API, Admin, Downloads).
2. Basisprofil: TLS, allow-list Methoden/Pfade, Managed Rules/CRS.
3. Rate limits + anti-bot auf empfindliche Wege.

4. Virtuelle Patches und dringender Regelprozess (SLA ≤ 30 Min.)

5. CI/CD für Regeln, Staging/Kanarienvogel/Schattenmodus.
6. Telemetrie, SLO, Regelregressionstests.
7. Regelmäßige Überprüfung der Ausnahmen und „Säuberung“ der Runden.

Typische Fehler

„Alle CRS auf Maximum eingeschaltet“ → FP-Lawine und Team-Burnout.
Regeln ohne Kanarienvögel und Schattenmodus.
Keine Segmentierung: Eine Politik für alles.
API/GraphQL Besonderheiten ignorieren (Schema/Limits).
Logs ohne Korrelation ('trace _ id') und ohne Qualitätsmetriken.

FAQ

Ersetzt WAF den sicheren Code?
Nein. Dies ist eine Weichzeichnungsschicht und ein „virtueller Patch“, aber die technische Pflicht im Code muss unbedingt beseitigt werden.

Wie kann man verstehen, dass es Zeit ist, harte Blöcke einzuschalten?
Wenn ein Shadow-Mode-Bericht einen niedrigen FP zeigt und es Regelregressionstests gibt.

Brauche ich ein separates WAF für die API?
Bessere WAAP/Integration mit API-Gateway: Schema, Limits, Authentifizierung, Webhook-Signaturen.

Summe

Effektives WAF/WAAP ist eine Kombination aus grundlegenden CRS/Managed Rules, positivem Modell, Anti-Bot, Limits und virtuellen Patches, unterstützt durch DevSecOps-Prozesse, Telemetrie und klare SLOs. Dieser Ansatz bietet eine schnelle Reaktion auf Schwachstellen, Widerstandsfähigkeit gegen automatisierte Angriffe und vorhersehbare Auswirkungen auf UX und Leistung.