Grundkonzepte der ALB WAF

In Arbeit: Diese Seite und die Funktionen der ALB WAF befinden sich derzeit in aktiver Entwicklung. Wesentliche Änderungen und Verbesserungen sind geplant. Konfigurationen und die Verfügbarkeit von Funktionen können sich ändern.

Eine Web Application Firewall fungiert als Sicherheitsschild für Ihre Webanwendungen. Die ALB WAF arbeitet auf Layer 7 (Application Layer), prüft eingehenden Traffic und blockiert bösartige Requests wie Bots und gängige Exploits, bevor diese Ihren Backend-Services schaden können. Sie stellt sicher, dass sicherer Traffic passieren kann, während Bedrohungen abgewehrt werden.

Die STACKIT ALB WAF nutzt die Coraza Engine und integriert sich nahtlos in den STACKIT Application Load Balancer (ALB).

Welche Funktionen die STACKIT ALB WAF derzeit unterstützt, sehen Sie in der Übersicht der [ALB WAF Funktionen](/de/products/network/load-balancing-and-content-delivery/application-load-balancer/basics/features-ALB WAF/).

Kernkonzepte

Zu verstehen, wie die ALB WAF Objekte verarbeitet und referenziert, ist entscheidend für die Konfiguration Ihrer Security Policies.

Firewall-Konfiguration

Die ALB WAF Config ist das zentrale Konfigurationsobjekt, das Ihre Firewall-Einstellungen enthält. Sie dient als Container, in dem Sie Ihre gewünschten Managed Rule Sets oder Custom Rule Groups referenzieren.

• Limits: Standardmäßig können Sie bis zu 150 eindeutige ALB WAF Configs pro Projekt speichern.
• Scope: Eine einzelne ALB WAF Config kann mehreren Listenern zugewiesen werden.

Managed Rule Sets

Managed Rule Sets sind vorkonfigurierte Sammlungen von Regeln, die vor weit verbreiteten Schwachstellen schützen. Die erste und primäre Sammlung ist das OWASP Core Ruleset (CRS), das Ihre Anwendungen vor den OWASP-Top-10-Bedrohungen schützt (einschließlich SQL Injection und Cross-Site Scripting).

• Anpassung: Anstatt komplexe Regeln von Grund auf neu zu schreiben, können Sie einzelne Regeln innerhalb des Managed Sets über die API global aktivieren, deaktivieren oder protokollieren.

Custom Rule Groups

Mit Custom Rule Groups können Sie Sammlungen spezialisierter Security-Regeln definieren, die auf Ihre Anforderungen zugeschnitten sind.

• Abstrahierter Aufbau: Um die Komplexität zu reduzieren, werden Regeln über die API mit einem strukturierten JSON-Modell konfiguriert.
• Limits: Standardmäßig können Sie bis zu 150 eindeutige Custom-Rule-Konfigurationen pro Projekt speichern.
• Auswertungsreihenfolge: Custom Rules werden vor den Managed Rule Sets ausgewertet. So können Sie frühzeitig in der Inspektionskette Ausnahmen definieren oder bestimmte Body auf eine Whitelist setzen.

Listener-Integration

Der Schutz durch die ALB WAF wird pro Listener aktiviert. Ein ALB-Listener verfügt über ein Property-Feld namens wafConfigName. Sobald diese Referenz mit einem gültigen ALB WAF Config-Namen befüllt ist, beginnt die Firewall sofort damit, den gesamten Traffic zu prüfen, der über diesen bestimmten Port läuft.

Firewall-Konfiguration erstellen

Um den Schutz durch die ALB WAF zu aktivieren, folgen Sie diesem strukturierten, dreistufigen Vorgehen.

1. Erstellen Sie Ihre Regeln: Bevor Sie Ihre ALB WAF Config erstellen, müssen Sie mindestens eines der folgenden Elemente konfigurieren:

   • Managed Rule Set: Konfigurieren Sie Ihre grundlegenden Schutzregeln (zum Beispiel OWASP CRS).
   • Custom Rule Group: Definieren Sie die Custom Rule Group, die Sie verwenden möchten.

2. Stellen Sie die ALB WAF Config zusammen: Erstellen Sie Ihre zentrale ALB WAF Config-Entität. Weisen Sie der Config im Body Ihres API-Requests einen eindeutigen Namen zu und verknüpfen Sie die Identifier der Managed Rule Sets oder Custom Rule Groups, die Sie im ersten Schritt erstellt haben.

3. Verknüpfen Sie die ALB WAF Config mit einem ALB-Listener: Aktivieren Sie die Firewall, indem Sie Ihre Config an den Application Load Balancer binden:

   • Geben Sie beim Erstellen oder Aktualisieren eines ALB-Listeners Ihren ALB WAF Config-Namen im Feld wafConfigName innerhalb des Konfigurationsblocks des Listeners an.
   • Der ALB initialisiert automatisch die Coraza Engine und wendet Ihre ALB WAF Config auf den Traffic-Pfad des Listeners an.

Observability

Die ALB WAF ist in die Observability-Pipeline des STACKIT Application Load Balancers integriert. Envoy-System-Logs und ALB-Metriken sind im Observability-Abschnitt der Grundkonzepte des ALB beschrieben; dieser Abschnitt dokumentiert die für die ALB WAF spezifischen Records.

ALB WAF Logs

Sobald an einem ALB-Listener eine ALB WAF-Konfiguration angehängt ist, sendet der ALB zusätzlich ALB WAF-Logs, die von der eingebetteten Coraza Engine erzeugt werden. Alle ALB WAF-Records tragen den Tag wasm log coraza-filter <waf-config-name> coraza-filter_vm_id: und werden unter dem Label component="waf" übermittelt, sodass Sie diese in Ihren Observability-Abfragen mit einem einzigen Label-Selektor von Envoy-System-Logs isolieren können.

Pro geprüfter Transaktion werden zwei Record-Typen emittiert:

• Rule-Match-Records — eine Zeile pro Regel, die auf den Request oder die Response zutrifft. Sie enthalten die lesbare Meldung, die Regel-Metadaten (id, severity, tag, ver usw.) sowie den Request-Kontext (hostname, uri, unique_id).
• Audit-Records — eine einzelne AuditLog:{...} JSON-Zeile, welche die vollständige Transaktion zusammenfasst (Client, Request, Response, Engine-Zustand, aktive Rule Sets und ob die Transaktion unterbrochen wurde). Verwenden Sie Audit-Records für die strukturierte Weiterverarbeitung.

Requests, die den Anomaly-Score-Schwellenwert erreichen, erzeugen einen zusätzlichen Blocking-Evaluation-Eintrag (Rule IDs im Bereich 949xxx des OWASP Core Rule Sets) und, wenn die Transaktion gestoppt wird, eine Zeile Transaction interrupted mit action="deny" und der unterbrechenden phase.

Aufbau eines Rule-Match-Records

Jeder Rule-Match-Record ist eine syslog-Zeile, gefolgt von einem Envoy-WASM-Wrapper und dem Coraza-Body. Der Body beginnt mit der Client-Adresse und einem Action-Ausdruck (zum Beispiel Warning. für Erkennungen oder Access denied (phase N). für Blockierungen), gefolgt von der Regelmeldung und einer Reihe von geklammerten Key-Value-Feldern.

Die folgenden Felder sind in jedem Rule-Match-Record enthalten:

Feld	Beschreibung	Beispiel
client	Quell-IP und, sofern verfügbar, Port des verbindenden Clients.	89.248.168.239
file	Pfad der SecLang-Datei, in der die Regel deklariert wurde. Custom Rule Groups erscheinen unter ihrem eigenen Dateinamen; Managed Rules verwenden das Verzeichnis @owasp_crs/.	@owasp_crs/REQUEST-911-METHOD-ENFORCEMENT.conf
line	Zeilennummer in der SecLang-Datei als Querverweis.	142
id	Numerischer Regel-Identifier. Das OWASP CRS verwendet feste Bereiche (zum Beispiel 911xxx für Method Enforcement, 949xxx für Anomaly-Score-Blocking).	911100
msg	Das in der Regel deklarierte msg:-Feld; der lesbare Grund für den Treffer.	Method is not allowed by policy
data	Der zur Trefferzeit expandierte logdata:-Wert – in der Regel die problematische Eingabe (MATCHED_VAR).	DELETE
severity	Schweregrad der Regel, wie vom Autor deklariert (emergency, critical, error, warning, notice, info, debug).	critical
ver	Versions-Tag des Rule Sets.	OWASP_CRS/4.14.0
tag	Ein oder mehrere Klassifizierungs-Tags (Angriffsklasse, OWASP-Kategorie, CAPEC- oder PCI-Referenz, Paranoia-Level).	attack-generic, paranoia-level/1, PCI/12.1
hostname	Host, der den Request erhalten hat (interne ALB-Adresse).	10.0.0.53
uri	Request-URI, welche die Auswertung ausgelöst hat.	/api/orders/42
unique_id	Korrelations-ID, die für eine Transaktion in allen Log-Zeilen geteilt wird – Rule-Match, Blocking-Evaluation, Transaction interrupted und AuditLog.	NLksGGQmUYxKYMEEKzD

Die unique_id ist der primäre Korrelationsschlüssel. Filtern Sie danach, um alle Log-Zeilen einer einzelnen Anfrage zu rekonstruieren.

Beispiel: DELETE durch eine Method-Enforcement-Regel blockiert

Die folgende OWASP-CRS-Regel blockiert jede HTTP-Methode, die nicht in der tx.allowed_methods-Allowlist enthalten ist, und addiert den Critical Anomaly Score zum Phase-1-Gesamtwert:

SecRule REQUEST_METHOD "!@within %{tx.allowed_methods}" \
    "id:911100,\
    phase:1,\
    block,\
    msg:'Method is not allowed by policy',\
    logdata:'%{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'attack-generic',\
    tag:'paranoia-level/1',\
    tag:'OWASP_CRS',\
    tag:'OWASP_CRS/METHOD-ENFORCEMENT',\
    tag:'capec/1000/210/272/220/274',\
    tag:'PCI/12.1',\
    ver:'OWASP_CRS/4.14.0',\
    severity:'CRITICAL',\
    setvar:'tx.inbound_anomaly_score_pl1=+%{tx.critical_anomaly_score}'"

Ein DELETE /api/orders/42-Request von 203.0.113.17 erzeugt die folgende Record-Sequenz, korreliert durch unique_id="AbCdEfGhIjKlMnOpQrS":

1. Method-Enforcement-Treffer (id:911100) — protokolliert die nicht erlaubte Methode und erhöht den Phase-1-Anomaly-Score.
2. Blocking-Evaluation (id:949111) — der kumulierte Score überschreitet den Inbound-Schwellenwert und der Request wird abgelehnt.
3. Transaktionsunterbrechung — einzeilige Zusammenfassung mit action="deny" und der unterbrechenden phase.
4. Audit-Record — AuditLog:{...} JSON mit dem vollständigen Transaktionsstatus und is_interrupted:true.

Gekürzte Ansicht (syslog-Präfix und Envoy-Wrapper auf ... gekürzt), die nur den Coraza-Body zeigt:

... coraza-filter my-coraza: [client "203.0.113.17"] Coraza: Warning. Method is not allowed by policy [file "@owasp_crs/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line "142"] [id "911100"] [msg "Method is not allowed by policy"] [data "DELETE"] [severity "critical"] [ver "OWASP_CRS/4.14.0"] [tag "OWASP_CRS/METHOD-ENFORCEMENT"] [hostname "10.0.0.53"] [uri "/api/orders/42"] [unique_id "AbCdEfGhIjKlMnOpQrS"]
... coraza-filter my-coraza: [client "203.0.113.17"] Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1 (Total Score: 5) [file "@owasp_crs/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "11900"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 5)"] [severity "emergency"] [hostname "10.0.0.53"] [uri "/api/orders/42"] [unique_id "AbCdEfGhIjKlMnOpQrS"]
... coraza-filter my-coraza: Transaction interrupted tx_id="AbCdEfGhIjKlMnOpQrS" context_id=127 action="deny" phase="http_request_headers"

Vollständiger, ungekürzter Record-Satz, wie er im Observability-Log-Stream erscheint:

Mar 09 15:17:08 my-alb-abcdef123-804c9 envoy[779444]: [2026-03-09 15:17:08.522][779453][warning][wasm] [source/extensions/common/wasm/context.cc:1140] wasm log coraza-filter my-coraza coraza-filter_vm_id: [client "203.0.113.17"] Coraza: Warning. Method is not allowed by policy [file "@owasp_crs/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line "142"] [id "911100"] [rev ""] [msg "Method is not allowed by policy"] [data "DELETE"] [severity "critical"] [ver "OWASP_CRS/4.14.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/METHOD-ENFORCEMENT"] [tag "capec/1000/210/272/220/274"] [tag "PCI/12.1"] [hostname "10.0.0.53"] [uri "/api/orders/42"] [unique_id "AbCdEfGhIjKlMnOpQrS"]
Mar 09 15:17:08 my-alb-abcdef123-804c9 envoy[779444]: [2026-03-09 15:17:08.523][779453][critical][wasm] [source/extensions/common/wasm/context.cc:1146] wasm log coraza-filter my-coraza coraza-filter_vm_id: [client "203.0.113.17"] Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1 (Total Score: 5) [file "@owasp_crs/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "11900"] [id "949111"] [rev ""] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 5)"] [data ""] [severity "emergency"] [ver "OWASP_CRS/4.14.0"] [maturity "0"] [accuracy "0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"] [hostname "10.0.0.53"] [uri "/api/orders/42"] [unique_id "AbCdEfGhIjKlMnOpQrS"]
Mar 09 15:17:08 my-alb-abcdef123-804c9 envoy[779444]: [2026-03-09 15:17:08.523][779453][info][wasm] [source/extensions/common/wasm/context.cc:1137] wasm log coraza-filter my-coraza coraza-filter_vm_id: Transaction interrupted tx_id="AbCdEfGhIjKlMnOpQrS" context_id=127 action="deny" phase="http_request_headers"
Mar 09 15:17:08 my-alb-abcdef123-804c9 envoy[779444]: [2026-03-09 15:17:08.523][779453][info][wasm] [source/extensions/common/wasm/context.cc:1137] wasm log coraza-filter my-coraza coraza-filter_vm_id: AuditLog:{"transaction":{"timestamp":"2026/03/09 15:17:08","unix_timestamp":1773069428523000000,"id":"AbCdEfGhIjKlMnOpQrS","client_ip":"203.0.113.17","client_port":41022,"host_ip":"10.0.0.53","host_port":443,"server_id":"188.34.102.37","request":{"method":"DELETE","protocol":"HTTP/1.1","uri":"/api/orders/42","http_version":"","headers":{":authority":["api.example.com"],":method":["DELETE"],":path":["/api/orders/42"],":scheme":["https"]},"body":"","files":null,"args":{},"length":0},"response":{"protocol":"","status":0,"headers":{},"body":""},"producer":{"connector":"","version":"","server":"","rule_engine":"On","stopwatch":"1773069428523000000 1660000; combined=1515000, p1=1424000, p2=0, p3=0, p4=0, p5=91000","rulesets":["OWASP_CRS/4.14.0"]},"highest_severity":"","is_interrupted":true}}

Custom-Rule-Group-Logs: Regeln, die in einer Custom Rule Group definiert sind, emittieren dieselbe Record-Struktur, wobei file auf Ihren Custom-Group-Namen gesetzt ist und id im automatisch zugewiesenen Bereich liegt, der von der API zurückgegeben wird. Die Variablen, Operatoren und Transformationen, die in den Feldern data, uri und msg erscheinen, finden Sie in der Referenz für ALB WAF Rule-Selectors.