Firewall- und WAF-Grundlagen für Web-Anwendungen

1. Netzwerk-Firewall vs. Web Application Firewall: Schutzumfang im Vergleich

Eine klassische Netzwerk-Firewall arbeitet auf OSI-Schicht 3 und 4 und trifft ihre Entscheidungen ausschließlich anhand von IP-Adresse, Port und Protokoll. Ein iptables- oder ufw-Regelwerk erlaubt typischerweise eingehenden Verkehr auf Port 443 und 80, blockiert alles andere und begrenzt SSH-Zugriffe per Rate-Limiting. Diese Filterung ist stateful, das heißt, sie kennt den Verbindungszustand (NEW, ESTABLISHED, RELATED) und lässt nur Antwortpakete zu bestehenden Verbindungen durch. Für die Abwehr von Portscans, unautorisierten Diensten und Netzwerk-Floods ist das die richtige und notwendige erste Verteidigungslinie.

Eine Netzwerk-Firewall sieht jedoch nicht, was innerhalb einer erlaubten HTTPS-Verbindung tatsächlich übertragen wird. Ein POST-Request mit einer SQL-Injection im Anfrageparameter passiert Port 443 genauso problemlos wie ein legitimer Login. Genau hier setzt die Web Application Firewall (WAF) an: Sie arbeitet auf OSI-Schicht 7, terminiert oder inspiziert die HTTP-Anfrage und bewertet Methode, Header, Query-String und Body inhaltlich. Eine WAF wird entweder als Modul im Webserver (ModSecurity), als Reverse-Proxy vor der Applikation oder als Edge-Service beim CDN-Anbieter betrieben. Netzwerk-Firewall und WAF ergänzen sich, sie ersetzen sich nicht.

#!/bin/bash
# Basic network firewall rules: allow HTTP/HTTPS, deny everything else,
# rate-limit SSH to slow down brute-force attempts

# Using ufw (Uncomplicated Firewall)
ufw default deny incoming
ufw default allow outgoing

# Allow web traffic
ufw allow 80/tcp
ufw allow 443/tcp

# Rate-limit SSH: max 6 connection attempts within 30 seconds per IP
ufw limit 22/tcp

ufw enable

# Equivalent raw iptables rules for the same policy
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# SSH rate limiting: allow max 4 new connections per minute per source IP
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

2. Signaturbasierte vs. anomaliebasierte Erkennung in WAF-Regeln

WAF-Regeln lassen sich grob in zwei Erkennungsstrategien einteilen. Signaturbasierte Regeln vergleichen eingehende Anfragen mit bekannten Angriffsmustern, etwa typischen SQL-Injection-Syntaxelementen wie UNION SELECT oder Cross-Site-Scripting-Payloads wie <script>-Tags in Formularfeldern. Das OWASP Core Rule Set (CRS) ist das bekannteste signaturbasierte Regelwerk und deckt die OWASP Top 10 mit mehreren hundert vordefinierten Regeln ab. Signaturbasierte Erkennung ist präzise bei bekannten Mustern, versagt aber bei neuartigen oder geschickt verschleierten Angriffen, die keiner bekannten Signatur entsprechen.

Anomalie- beziehungsweise verhaltensbasierte Erkennung geht anders vor: Sie lernt ein Normalprofil des Traffics, etwa typische Parameterlängen, Zeichensätze oder Request-Frequenzen, und schlägt bei Abweichungen Alarm. Das erkennt auch unbekannte Angriffsvarianten, produziert aber tendenziell mehr False Positives, weil legitime, aber ungewöhnliche Nutzereingaben ebenfalls als Anomalie auffallen können. Moderne WAFs wie AWS WAF oder Cloudflare kombinieren beide Ansätze: signaturbasierte Regeln für bekannte Muster plus ein Anomaly-Scoring-System, das mehrere kleinere Verdachtsmomente zu einer Gesamtbewertung addiert, bevor eine Anfrage tatsächlich blockiert wird.

3. False-Positive-Management und Regel-Tuning im Produktivbetrieb

Jede neu aktivierte WAF-Regel blockiert in der Praxis zunächst auch legitimen Traffic, etwa wenn ein Kunde in ein Freitextfeld ein Zeichen wie ein Apostroph oder ein -- eingibt, das zufällig einem SQLi-Muster ähnelt. Der professionelle Rollout-Prozess läuft deshalb nie mit sofortigem Blocking: Neue Regeln laufen zunächst im Detection-only- beziehungsweise Log-Modus, alle Treffer werden mehrere Tage bis Wochen gesammelt und ausgewertet, bevor auf Block-Modus umgeschaltet wird. Ohne diese Phase riskiert man, den Checkout-Prozess eines Magento-Shops für echte Kunden zu blockieren, weil eine Adresse mit Sonderzeichen fälschlich als Angriff eingestuft wird.

Beim eigentlichen Tuning gilt die Regel, so spezifisch wie möglich auszunehmen: Statt eine ganze Regel-ID global zu deaktivieren, wird die Ausnahme auf eine konkrete URL, einen konkreten Parameter oder eine konkrete Kombination aus beidem beschränkt. ModSecurity bietet dafür SecRuleRemoveTargetById, mit dem sich einzelne Parameter von einer Regel ausnehmen lassen, ohne die Regel insgesamt zu deaktivieren. Jede Ausnahme sollte dokumentiert und mit einem Ablaufdatum versehen werden, da sich Formulare und Applikationslogik über die Zeit ändern und eine vergessene Ausnahme Jahre später zur unbemerkten Sicherheitslücke wird.

4. WAF als Defense-in-Depth: kein Ersatz für Code-Fixes

Eine WAF ist eine kompensierende Kontrolle, kein Ersatz für sichere Anwendungsentwicklung. Wird eine SQL-Injection-Schwachstelle im Code durch eine WAF-Regel blockiert, bleibt die eigentliche Schwachstelle bestehen: Ein Bypass der Regel, ein neuer Angriffsvektor über einen anderen Parameter oder eine Fehlkonfiguration der WAF selbst öffnet die Lücke sofort wieder. Die einzig nachhaltige Lösung bleibt Prepared Statements statt String-Konkatenation in SQL-Queries und konsequentes Output-Encoding gegen XSS, unabhängig davon, ob eine WAF davor steht oder nicht.

In der Praxis kauft eine WAF vor allem Zeit: Zwischen dem Bekanntwerden einer Schwachstelle und einem ausgerollten Patch liegen oft Tage bis Wochen, in denen eine gezielte virtuelle Patch-Regel in der WAF das Ausnutzungsfenster schließt. Diese Regel gehört danach aber konsequent wieder entfernt, sobald der eigentliche Code-Fix produktiv ist, sonst sammeln sich über Jahre veraltete, unwartbare Ausnahmen an. Das folgende PHP-Beispiel zeigt saubere serverseitige Validierung und Escaping, die unabhängig vom Vorhandensein einer WAF gelten muss.

<?php

declare(strict_types=1);

namespace Mironsoft\Security\ViewModel;

use Magento\Framework\Escaper;
use Magento\Framework\View\Element\Block\ArgumentInterface;
use InvalidArgumentException;

/**
 * View model that validates and escapes free-text customer input server-side.
 *
 * A WAF may block obvious SQL injection or XSS payloads at the edge, but the
 * application must never rely on that as its only line of defense. This
 * class enforces strict input validation and output escaping regardless of
 * whether a WAF is present in front of the store.
 */
final class CommentInputViewModel implements ArgumentInterface
{
    private const int MAX_COMMENT_LENGTH = 500;

    /**
     * @param Escaper $escaper Magento's HTML escaper used for safe output rendering.
     */
    public function __construct(
        private readonly Escaper $escaper,
    ) {
    }

    /**
     * Validates a raw comment string and returns it escaped for safe HTML output.
     *
     * @param string $rawComment Unvalidated input, e.g. from a product review form.
     * @return string The validated and HTML-escaped comment.
     * @throws InvalidArgumentException If the input fails length or character validation.
     */
    public function sanitizeComment(string $rawComment): string
    {
        $trimmed = trim($rawComment);

        if ($trimmed === '' || mb_strlen($trimmed) > self::MAX_COMMENT_LENGTH) {
            throw new InvalidArgumentException('Comment length is invalid.');
        }

        // Reject control characters and null bytes regardless of WAF filtering upstream
        if (preg_match('/[\x00-\x08\x0B\x0C\x0E-\x1F]/', $trimmed) === 1) {
            throw new InvalidArgumentException('Comment contains invalid control characters.');
        }

        // Escape for HTML output; never trust that upstream WAF layers already did this
        return $this->escaper->escapeHtml($trimmed);
    }
}

5. ModSecurity und OWASP Core Rule Set: Konfigurationsgrundlagen

ModSecurity ist die verbreitetste Open-Source-WAF-Engine für Apache, nginx und IIS und wird meist zusammen mit dem OWASP Core Rule Set betrieben. Nach der Installation definiert die Kernkonfiguration den Detection-Modus (SecRuleEngine DetectionOnly für die Testphase, später On für aktives Blocking), die maximale Request-Body-Größe und das Anomaly-Scoring-Modell des CRS. Jede CRS-Regel vergibt bei einem Treffer Punkte auf ein Anomaly-Scoring-Konto; erst wenn die Gesamtpunktzahl einer Anfrage einen konfigurierten Schwellenwert überschreitet, wird tatsächlich geblockt, statt bei jedem einzelnen Treffer sofort zu reagieren.

Diese Schwellenwert-Logik reduziert False Positives spürbar, weil eine einzelne harmlose Auffälligkeit selten ausreicht, um die Anfrage zu blockieren, während eine Kombination mehrerer verdächtiger Merkmale den Schwellenwert überschreitet. Die Paranoia-Level des CRS (1 bis 4) steuern zusätzlich, wie aggressiv die Regeln greifen: Level 1 ist produktionstauglich mit wenigen False Positives, Level 4 maximiert die Erkennungsrate zulasten deutlich mehr manueller Tuning-Arbeit. Für die meisten Magento-Shops ist Paranoia-Level 1 mit gezielten Ausnahmen für bekannte Admin-Workflows der praktikable Startpunkt.

# ModSecurity + OWASP CRS: example rule blocking a SQL injection pattern
# via anomaly scoring instead of an immediate hard block

# Detection-only mode during the initial tuning phase (log but don't block)
SecRuleEngine DetectionOnly

# Custom rule: flag a classic UNION-based SQLi pattern in any request argument
SecRule ARGS "@rx (?i:union\s+select|sleep\(\d+\)|benchmark\()" \
    "id:100001,\
    phase:2,\
    deny,\
    log,\
    msg:'Possible SQL Injection pattern detected',\
    severity:'CRITICAL',\
    tag:'attack-sqli',\
    setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}',\
    setvar:'tx.anomaly_score=+%{tx.critical_anomaly_score}'"

# Block only once the cumulative anomaly score crosses the threshold,
# not on every single rule hit
SecAction "id:100002,phase:1,pass,nolog,setvar:tx.inbound_anomaly_score_threshold=5"

SecRule TX:ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_threshold}" \
    "id:100003,\
    phase:5,\
    deny,\
    status:403,\
    msg:'Inbound anomaly score exceeded threshold'"

6. Cloud- und Edge-WAF konfigurieren: Cloudflare, AWS WAF und Rate Limiting

Cloud- und Edge-WAFs wie Cloudflare oder AWS WAF verlagern die Filterung vor die eigentliche Infrastruktur, meist als Teil eines CDN, sodass bösartiger Traffic gar nicht erst den Origin-Server erreicht. Die Konfiguration erfolgt heute überwiegend als Infrastructure-as-Code, etwa über Terraform oder CloudFormation, mit Managed-Rule-Groups für bekannte Angriffsklassen (SQLi, XSS, bekannte CVEs) sowie eigenen Custom Rules für applikationsspezifische Muster. Diese Regelgruppen lassen sich pro Route oder Pfad unterschiedlich scharf schalten, etwa strenger für den Checkout als für statische Assets.

Rate-Based Rules sind ein zentraler Baustein von Cloud-WAFs und ergänzen die klassische Signaturerkennung um eine Frequenz-Dimension: Überschreitet eine IP-Adresse innerhalb eines Zeitfensters eine definierte Anzahl Requests auf einen sensiblen Endpunkt wie den Login, greift automatisch ein Block oder ein CAPTCHA-Challenge, unabhängig davon, ob die einzelnen Requests inhaltlich unauffällig sind. Das ist die wirksamste Verteidigung gegen Credential-Stuffing und Brute-Force-Versuche, die inhaltlich völlig legitim aussehende Login-Requests in großer Zahl senden und daher von reiner Signaturerkennung nicht erfasst würden.

# AWS WAFv2 Web ACL: managed rule groups plus a custom rate-based rule
Resources:
  ShopWebAcl:
    Type: AWS::WAFv2::WebACL
    Properties:
      Name: magento-shop-waf
      Scope: CLOUDFRONT
      DefaultAction:
        Allow: {}
      VisibilityConfig:
        SampledRequestsEnabled: true
        CloudWatchMetricsEnabled: true
        MetricName: magento-shop-waf
      Rules:
        - Name: AWS-AWSManagedRulesSQLiRuleSet
          Priority: 0
          OverrideAction:
            None: {}
          Statement:
            ManagedRuleGroupStatement:
              VendorName: AWS
              Name: AWSManagedRulesSQLiRuleSet
          VisibilityConfig:
            SampledRequestsEnabled: true
            CloudWatchMetricsEnabled: true
            MetricName: sqli-managed-rules

        - Name: AWS-AWSManagedRulesCommonRuleSet
          Priority: 1
          OverrideAction:
            None: {}
          Statement:
            ManagedRuleGroupStatement:
              VendorName: AWS
              Name: AWSManagedRulesCommonRuleSet
          VisibilityConfig:
            SampledRequestsEnabled: true
            CloudWatchMetricsEnabled: true
            MetricName: common-managed-rules

        - Name: login-rate-limit
          Priority: 2
          Action:
            Block: {}
          Statement:
            RateBasedStatement:
              Limit: 300
              AggregateKeyType: IP
              ScopeDownStatement:
                ByteMatchStatement:
                  SearchString: /customer/account/loginPost
                  FieldToMatch:
                    UriPath: {}
                  TextTransformations:
                    - Priority: 0
                      Type: LOWERCASE
                  PositionalConstraint: STARTS_WITH
          VisibilityConfig:
            SampledRequestsEnabled: true
            CloudWatchMetricsEnabled: true
            MetricName: login-rate-limit

7. WAF-Bypass-Techniken und die Grenzen des Schutzes

WAF-Bypass-Techniken nutzen typischerweise Unterschiede zwischen der Interpretation der WAF und der Zielanwendung aus, etwa durch alternative Kodierungen (doppeltes URL-Encoding, Unicode-Normalisierung), Case-Variation innerhalb von SQL-Keywords oder das Aufsplitten eines Angriffsstrings über mehrere HTTP-Parameter, die die Anwendung serverseitig wieder zusammenfügt. Auch HTTP-Parameter-Pollution, also das mehrfache Senden desselben Parameternamens mit unterschiedlichen Werten, wird ausgenutzt, weil WAF und Anwendung diese Fälle manchmal unterschiedlich auswerten.

Diese Techniken sind kein Grund, auf eine WAF zu verzichten, sondern der zentrale Beleg dafür, warum eine WAF niemals die einzige Schutzschicht sein darf. Ein aktuelles, regelmäßig gepatchtes CRS-Regelwerk, kombiniert mit striktem Anomaly-Scoring und einer sauber implementierten Anwendung, die selbst bei einem erfolgreichen Bypass durch Prepared Statements und Output-Encoding standhält, reduziert das reale Risiko auf ein Minimum. Sicherheitsteams sollten WAF-Bypässe regelmäßig im Rahmen von Penetrationstests gezielt prüfen, statt sich allein auf die Herstellerangaben der WAF zu verlassen.

8. Logging und Alerting für WAF-Ereignisse

Jede geblockte und jede im Detection-Modus aufgefallene Anfrage sollte strukturiert geloggt werden, mit Regel-ID, Anomaly-Score, betroffenem Parameter und dem tatsächlich gematchten Muster. Ohne dieses Detail-Logging ist weder False-Positive-Triage noch forensische Aufarbeitung eines echten Angriffs praktikabel. ModSecurity schreibt diese Informationen standardmäßig ins Audit-Log, das sich strukturiert als JSON exportieren und in ein zentrales SIEM- oder Log-Management-System wie den ELK-Stack oder Grafana Loki einspeisen lässt.

Für den operativen Betrieb sind Alerts auf ungewöhnliche Muster wichtiger als Alerts auf jeden Einzeltreffer: ein plötzlicher Anstieg geblockter Requests von einer einzelnen IP-Range, eine neue Regel-ID mit ungewöhnlich hoher Trefferrate nach einem Deployment, oder ein Anomaly-Score-Anstieg auf einem bislang unauffälligen Endpunkt sind die Signale, die ein Sicherheitsteam tatsächlich benötigt. Rohes Request-für-Request-Logging ohne Aggregation und Schwellenwert-Alerts führt in der Praxis zuverlässig zu Alert-Fatigue und dazu, dass echte Vorfälle im Rauschen untergehen.

{
  "timestamp": "2026-07-11T14:32:07Z",
  "clientIp": "203.0.113.45",
  "action": "BLOCK",
  "ruleId": "941100",
  "ruleGroup": "OWASP-CRS-941-APPLICATION-ATTACK-XSS",
  "matchedPattern": "<script>alert(1)</script>",
  "matchedField": "ARGS:comment",
  "anomalyScore": 8,
  "anomalyThreshold": 5,
  "requestUri": "/catalog/product/reviewPost",
  "httpMethod": "POST",
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
  "triageStatus": "pending_review",
  "triageNote": "Legitimate customer submitted a product review containing HTML-like text in a code snippet. Confirmed false positive, added scoped exception for ARGS:comment on this URI only."
}

9. Firewall, WAF und Code-Fix im direkten Vergleich

Netzwerk-Firewall, WAF und ein tatsächlicher Code-Fix wirken auf unterschiedlichen Ebenen und schließen unterschiedliche Lücken. Die folgende Übersicht zeigt, welche Bedrohung welche Schutzschicht tatsächlich abdeckt und wo jede Schicht an ihre Grenzen stößt.

In der Praxis überschneiden sich alle drei Schichten nur teilweise: Eine Firewall schützt die Infrastruktur, eine WAF schützt die Anfrageebene, und nur ein Code-Fix schließt die eigentliche Schwachstelle dauerhaft. Wer alle drei Schichten kombiniert, statt auf eine einzelne zu vertrauen, erreicht die höchste realistische Schutzwirkung.

10. Zusammenfassung

Firewall- und WAF-Grundlagen lösen unterschiedliche Probleme: Eine Netzwerk-Firewall schützt auf OSI-Schicht 3/4 vor unautorisiertem Netzwerkzugriff, während eine Web Application Firewall auf Schicht 7 den Inhalt von HTTP-Anfragen bewertet und applikationsspezifische Angriffe wie SQL-Injection oder Cross-Site-Scripting erkennt. Signaturbasierte Regeln wie das OWASP Core Rule Set decken bekannte Angriffsmuster zuverlässig ab, während anomaliebasierte Erkennung zusätzlich unbekannte Varianten aufspürt, aber mehr Tuning-Aufwand gegen False Positives erfordert.

Der wichtigste Grundsatz bleibt: Eine WAF ist Defense-in-Depth, keine Reparatur der eigentlichen Schwachstelle. Prepared Statements, Output-Encoding und saubere serverseitige Validierung bleiben Pflicht, unabhängig davon, wie gut die WAF konfiguriert ist. Wer Netzwerk-Firewall, WAF-Regelwerk mit sauberem False-Positive-Tuning, strukturiertes Logging und sichere Anwendungsentwicklung kombiniert, erreicht ein Sicherheitsniveau, das keine einzelne Schicht allein leisten könnte.

11. FAQ: Firewall- und WAF-Grundlagen