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

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!): Die Cloudflare Range IPs Allowlist lässt den Origin-Server direkt erreichbar werden - Firewall am Origin muss daher 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 ist eine 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 je nach Distribution nutzen

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 einen Score - erst bei Überschreitung folgt ein 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

Bewertungslogik:

• 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 ist die Cloud-native WAF für ALB, CloudFront und 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

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 ist die 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)

Beispiele in der Cloudflare Expression Language:

# 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, die bei Penetrationstests bekannt sind:

1. Encoding-Varianten für XSS

WAF blockiert: <script>alert(1)</script>

<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

' /*!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

....//....//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 lassen WAF und Backend unterschiedliche Request-Grenzen sehen:

• WAF: Request endet bei CL-Header
• Backend: Request endet bei TE-Header
• Angreifer kann einen schädlichen Request "hinter" einem legitimen Request schmuggeln

5. Large Payload Bypass

Einige WAFs limitieren die Body-Inspection auf die ersten X KB. Angreifer platziert den Payload nach dieser Grenze (z.B. nach 64 KB). Mitigation: Inspection-Limit erhöhen (Performance sinkt dabei).

6. Desynchronization (Cloudflare/AWS)

Advanced-Technik: 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