WAF Implementierung: Web Application Firewall konfigurieren und tunen

Eine WAF ist kein “Set and Forget” Tool. Falsch konfiguriert blockiert sie legitime Nutzer (False Positives) oder lässt Angreifer durch (False Negatives). Das richtige WAF-Tuning erfordert Verständnis für die Anwendung, die Angriffsvektoren und die Grenzen der WAF. Und ja - erfahrene Angreifer wissen wie man WAFs umgeht. Deshalb ist eine WAF eine Schicht in Defense-in-Depth, kein vollständiger Schutz.

WAF-Deployment-Modi

Drei Deployment-Optionen:

1. Cloud-WAF (Reverse Proxy / CDN-integriert):
   Anbieter:   Cloudflare, AWS WAF, Azure WAF, Akamai, Fastly
   Funktionsprinzip:
     DNS → Cloudflare IP → Cloudflare WAF prüft → Origin Server
   Vorteile:
     → Kein eigener Server, skaliert automatisch
     → DDoS-Schutz inklusive
     → Globale Präsenz (CDN = weniger Latenz)
     → Einfaches Deployment (DNS-Änderung reicht)
   Nachteile:
     → Traffic geht durch Drittanbieter (Datenschutz!)
     → Echter Origin-Server-IP muss versteckt bleiben (sonst WAF umgehbar!)
     → Weniger Kontrolle über Regelset

   Origin-IP verstecken (kritisch!):
     → Cloudflare Range IPs allowlist → Origin-Server direkt erreichbar!
     → Firewall am Origin: nur Cloudflare-IPs erlauben
     curl https://www.cloudflare.com/ips-v4 > cloudflare-ips.txt
     # Iptables: nur Cloudflare IPs auf Port 443 erlauben!
     iptables -A INPUT -p tcp --dport 443 -j DROP  # Default Drop
     while read ip; do
       iptables -I INPUT -s "$ip" -p tcp --dport 443 -j ACCEPT
     done < cloudflare-ips.txt

2. Hardware/VM-WAF (Reverse Proxy, On-Premise):
   Anbieter:   F5 BIG-IP, Imperva, Barracuda, Fortinet FortiWeb
   Deployment: WAF vor Web-Server (Reverse Proxy)
     Client → WAF (Port 443) → Web Server (intern, Port 80/443)
   Vorteile:
     → Vollständige Datenkontrolle (kein Drittanbieter)
     → Detailliertere Konfiguration
     → SSL-Termination an WAF (kein CDN sieht Traffic)
   Nachteile:
     → Eigenständiger Betrieb erforderlich
     → Kosten (Lizenz + Hardware)
     → Single Point of Failure (HA nötig!)

3. Integrierte WAF (Web-Server-Modul):
   Anbieter:   ModSecurity (NGINX/Apache), NAXSI
   Deployment: Modul im Web-Server
   Vorteile:
     → Keine separate Infrastruktur
     → Kostengünstig (Open Source)
     → Tight Integration mit Web-Server-Logs
   Nachteile:
     → Kein DDoS-Schutz
     → Performance-Impact (CPU des Web-Servers)
     → False-Positive-Management aufwändig

ModSecurity + OWASP Core Rule Set (CRS)

ModSecurity - Open-Source WAF für NGINX/Apache:

Installation (Ubuntu, NGINX):
  # ModSecurity-nginx Connector:
  apt install libmodsecurity3 libmodsecurity-dev
  # Build NGINX mit ModSecurity:
  # Oder: fertiges Paket nutzen (je nach Distribution)

  # NGINX Konfiguration:
  # /etc/nginx/modsec/main.conf
  modsecurity on;
  modsecurity_rules_file /etc/nginx/modsec/main.conf;

OWASP Core Rule Set (CRS) v4.0:
  git clone https://github.com/coreruleset/coreruleset.git /etc/nginx/modsec/crs
  cp /etc/nginx/modsec/crs/crs-setup.conf.example \
     /etc/nginx/modsec/crs/crs-setup.conf

  # Hauptkonfiguration:
  # /etc/nginx/modsec/main.conf
  Include /etc/nginx/modsec/modsecurity.conf
  Include /etc/nginx/modsec/crs/crs-setup.conf
  Include /etc/nginx/modsec/crs/rules/*.conf

Anomaly Scoring Mode (empfohlen statt Block-Mode):
  # CRS Anomaly Threshold: Requests werden nicht sofort geblockt
  # sondern akkumulieren Score - erst bei Überschreitung: Block

  # /etc/nginx/modsec/crs/crs-setup.conf:
  SecDefaultAction "phase:1,log,auditlog,pass"  # Pass statt Deny!
  # Anomaly Score Thresholds:
  setvar:'tx.inbound_anomaly_score_threshold=5'   # 5+ = Block
  setvar:'tx.outbound_anomaly_score_threshold=4'  # Antwort-Block

  Erklärung:
    1 Treffer auf Critical Rule (SQLi): Score +5 → sofort Block!
    1 Treffer auf Warning Rule:         Score +3 → noch kein Block
    2 Warning Rules getroffen:          Score +6 → Block!

    Vorteil: Einzelne False Positives blockieren nicht sofort
    Vorteil: Mehrere verdächtige Signale → Block (korrekt)

WAF-Modi (Empfehlung für Rollout):
  Phase 1 (Detection Only):
    SecDefaultAction "phase:1,log,auditlog,pass"  # Nur Logging, kein Block
    → Produktionsverkehr beobachten
    → False Positives identifizieren (2 Wochen)

  Phase 2 (Block mit Whitelist):
    → False Positives als Ausnahmen konfigurieren
    → Dann: auf Block schalten

  Phase 3 (Block):
    SecDefaultAction "phase:1,log,auditlog,deny,status:403"

AWS WAF Konfiguration

AWS WAF v2 - Cloud-native WAF für ALB, CloudFront, API Gateway:

Basis-Konfiguration (Terraform):
  resource "aws_wafv2_web_acl" "main" {
    name  = "prod-waf"
    scope = "REGIONAL"  # oder CLOUDFRONT für global

    default_action {
      allow {}  # Alles erlauben außer explizit blockiert
    }

    rule {
      name     = "AWS-AWSManagedRulesCommonRuleSet"
      priority = 1
      override_action { none {} }  # Managed Rule Set Aktion nutzen

      statement {
        managed_rule_group_statement {
          vendor_name = "AWS"
          name        = "AWSManagedRulesCommonRuleSet"
        }
      }
      visibility_config {
        sampled_requests_enabled   = true
        cloudwatch_metrics_enabled = true
        metric_name                = "CommonRuleSet"
      }
    }

    rule {
      name     = "RateLimiting"
      priority = 5
      action { block {} }

      statement {
        rate_based_statement {
          limit              = 2000  # Max 2000 Requests/5 Minuten pro IP
          aggregate_key_type = "IP"
        }
      }
      visibility_config {
        sampled_requests_enabled   = true
        cloudwatch_metrics_enabled = true
        metric_name                = "RateLimiting"
      }
    }
  }

AWS Managed Rule Groups (verfügbare Sets):
  AWSManagedRulesCommonRuleSet:    OWASP Top 10 Grundschutz
  AWSManagedRulesSQLiRuleSet:      SQL Injection spezifisch
  AWSManagedRulesKnownBadInputsRuleSet: Log4Shell, Spring4Shell etc.
  AWSManagedRulesAnonymousIpList:  Tor, VPN, Proxy-IPs blockieren
  AWSManagedRulesBotControlRuleSet: Bot-Erkennung (kostenpflichtig)
  AWSManagedRulesATPRuleSet:       Account Takeover Protection (ATP)

False Positive Handling:
  # Einzelne Regel für spezifischen Pfad ausschalten:
  rule {
    name     = "ExcludeAdminPath"
    priority = 0  # Höchste Priorität = zuerst ausgeführt

    statement {
      and_statement {
        statements = [
          { byte_match_statement { ... field: URI_PATH, value: "/admin" } },
          { managed_rule_group_statement {
            vendor_name = "AWS"
            name        = "AWSManagedRulesCommonRuleSet"
            excluded_rules = ["CrossSiteScripting_BODY"]  # Diese Regel ignorieren
          }}
        ]
      }
    }
    action { allow {} }  # /admin Requests immer erlauben
  }

AWS WAF Logging:
  # CloudWatch Logs + Kinesis Firehose:
  resource "aws_wafv2_web_acl_logging_configuration" "main" {
    resource_arn            = aws_wafv2_web_acl.main.arn
    log_destination_configs = [aws_kinesis_firehose_delivery_stream.waf.arn]
  }

Cloudflare WAF

Cloudflare WAF - einfachste Deployment-Option:

Kostenloser Free Plan:
  → Managed Ruleset für OWASP Top 10 (begrenzt)
  → DDoS-Schutz
  → 5 Custom Rules
  → Bot Fight Mode

Pro/Business Plan:
  → Vollständiger OWASP Managed Ruleset
  → 100+ Custom Rules (Pro) / Unbegrenzt (Business)
  → Rate Limiting granular
  → Firewall Analytics

Cloudflare Firewall Rules (Custom):
  # Expression Language Beispiele:
  # IP-Blocklist:
  (ip.src in {185.220.0.0/16}) → Block

  # Country-Block:
  (ip.geoip.country in {"KP" "IR" "SY"}) → Block

  # User-Agent-Check:
  (http.user_agent contains "sqlmap" or
   http.user_agent contains "nikto" or
   http.user_agent contains "ZAP") → Block

  # Login-Rate-Limiting:
  (http.request.uri.path eq "/api/login" and
   http.request.method eq "POST") →
   Rate Limit: 10 Requests/Minute pro IP → Challenge

  # Kombinierte Regel:
  (http.request.uri contains "wp-admin" and
   not ip.src in $allowlist) → Block

Page Shield (XSS-Schutz):
  → Überwacht JavaScript-Ressourcen auf Injection
  → Supply-Chain-XSS: 3rd-Party-Scripts auf Veränderung monitoren
  → Alert wenn neues Script auftaucht

Bot-Management (Enterprise):
  → Statische + verhaltensbasierte Bot-Erkennung
  → CAPTCHAs nur für verdächtige Bots
  → "Bot Score": 1-99 (1=Bot, 99=Mensch)

WAF-Bypässe - Grenzen einer WAF

WAF-Bypass Techniken (bekannt bei Penetrationstests):

1. Encoding-Varianten für XSS:
  # WAF blockiert: <script>alert(1)</script>
  # Bypass:
  <scr\u0069pt>alert(1)</sc\u0072ipt>       # Unicode Encoding
  <img src=x onerror=alert(1)>               # Event-Handler statt <script>
  <svg onload=alert(1)>                      # SVG Vektor
  <iframe src="javascript:alert(1)">        # JavaScript URI
  %3Cscript%3Ealert(1)%3C/script%3E        # URL Encoding (im Body)
  <!--<img src="--><img src=x onerror=alert(1)> # Comment Confusion

2. SQL Injection Bypässe:
  # WAF blockiert: ' OR '1'='1
  # Bypässe:
  ' /*!50000OR*/ '1'='1              # MySQL Version Comment
  ' OR 0x312='1                      # Hex Encoding
  '||'1'='1                          # Oracle Syntax statt OR
  ' OR/**/1=1--                      # Comment als Leerzeichen
  1 UNION%09SELECT 1,2,3--          # Tab statt Leerzeichen

3. Path Traversal:
  # WAF blockiert: ../../../etc/passwd
  # Bypässe:
  ....//....//etc/passwd             # Double Encoding
  ..%2F..%2F..%2Fetc%2Fpasswd       # URL Encoding
  ..%252F..%252F../etc/passwd        # Double URL Encoding

4. HTTP Request Smuggling:
  # Inkonsistente Content-Length + Transfer-Encoding Header
  # WAF sieht anderen Request als Backend!
  → WAF: Request endet bei CL-Header
  → Backend: Request endet bei TE-Header
  → Angreifer kann bösen Request "hinter" legitimem Request schmuggeln

5. Large Payload Bypass:
  # Einige WAFs limitieren Body-Inspection auf erste X KB
  # Angreifer: schickt Payload nach Grenze (z.B. nach 64KB)
  # Mitigation: Inspection-Limit erhöhen (Performance ↓)

6. Desynchronization (Cloudflare/AWS):
  # Advanced: HTTP/2 zu HTTP/1.1 Downgrade-Confusion
  # Nur für sehr erfahrene Angreifer

WAF ist keine vollständige Lösung:
  ✓ WAF schützt vor: bekannten Angriffen, Script-Kiddies, automatisierten Scans
  ✗ WAF schützt NICHT vor: gezielten Angriffen durch Bypass, Business Logic,
    Authentication-Schwächen, IDOR, serverseitigen Fehlern ohne HTTP-Signatur

Defense in Depth: WAF + SAST/DAST + Secure Development + Pentest

Eine WAF ist eine wichtige Sicherheitsschicht - aber kein Ersatz für sichere Entwicklungspraktiken. AWARE7 überprüft im Rahmen von Web-Application-Penetrationstests explizit WAF-Konfigurationen und Bypass-Möglichkeiten, um die tatsächliche Schutzwirkung zu validieren.

Web Application Pentest anfragen | Penetrationstest Web-Applikationen