ALB WAF Funktionen

In Arbeit: Diese Seite und die Funktionen der ALB WAF befinden sich in aktiver Entwicklung. Konfigurationen, Standard-Werte und die Verfügbarkeit von Funktionen können sich vor der allgemeinen Verfügbarkeit noch ändern.

Diese Seite beschreibt die Funktionen und den Konfigurations-Bereich der STACKIT Application Load Balancer Web Application Firewall (ALB WAF). Wenn Sie neu bei der ALB WAF sind, lesen Sie zunächst Grundkonzepte der ALB WAF.

Die ALB WAF nutzt die Coraza Engine. Ihr Regel-Modell folgt der SecLang-Grammatik, STACKIT stellt sie jedoch über eine strukturierte JSON-API bereit, sodass Sie keine SecLang-Direktiven manuell verfassen müssen.

Funktionsübersicht und Verfügbarkeit

Die folgende Tabelle listet jede Funktions-Gruppe auf und zeigt, wo sie heute verfügbar ist. Zeilen mit WIP zeigen an, dass die Schnittstelle noch entwickelt wird und noch nicht stabil für den Produktions-Einsatz ist.

Funktion	API	SDK	Terraform	Portal
ALB WAF Konfiguration	Verfügbar	Verfügbar	WIP	WIP
Listener-Anbindung	Verfügbar	Verfügbar	Verfügbar	WIP
Managed Rule Sets (OWASP CRS)	Verfügbar	WIP	WIP	WIP
Modus pro Regel (aktivieren/deaktivieren/nur protokollieren)	Verfügbar	WIP	WIP	WIP
Custom Rule Groups (SecLang-Abstraktion)	Verfügbar	WIP	WIP	WIP
Projekt-Quoten für ALB WAF, MRS und CRG	Verfügbar	WIP	WIP	WIP

ALB WAF Konfiguration

Eine ALB WAF-Konfiguration (waf_config) ist das übergeordnete Objekt, das die Regel-Quellen zusammenfasst, die Ihren Traffic prüfen. Jede Konfiguration:

• Gehört zu einem einzelnen Projekt und einer Region.
• Hat einen eindeutigen, DNS-kompatiblen Namen (1–63 Zeichen, Kleinbuchstaben, alphanumerische Zeichen und Bindestriche).
• Kann höchstens ein Managed Rule Set per Name und höchstens eine Custom Rule Group per Name referenzieren.
• Kann an beliebig viele ALB-Listener im selben Projekt angehängt werden.
• Akzeptiert bis zu 64 benutzerdefinierte Labels für organisatorische Metadaten.

Eine Konfiguration referenziert ein Managed Rule Set über managedRuleSetName und eine Custom Rule Group über customRuleGroupName. Beide sind einzeln optional, aber mindestens eines muss gesetzt sein, damit die Konfiguration Traffic prüft.

Endpunkte sowie das vollständige Request- und Response-Schema des Konfigurations-Objekts finden Sie unter v1beta API: ALB WAF configurations.

Listener-Anbindung

Die ALB WAF wird pro Listener auf dem Application Load Balancer aktiviert. Um den Schutz zu aktivieren, setzen Sie die Eigenschaft wafConfigName des Listeners auf den Namen einer bestehenden ALB WAF-Konfiguration im selben Projekt und derselben Region.

Der Listener beginnt dann, den gesamten Layer-7-Traffic auf diesem Port zu prüfen, bevor er an Ihre Target Pools weitergeleitet wird. Durch Entfernen des Felds wird die ALB WAF für diesen Listener deaktiviert, ohne die ALB WAF-Konfiguration zu löschen.

Den vollständigen Request-Body des Listeners und die Position von wafConfigName finden Sie in der v2 API: ALB Listeners-Referenz.

Managed Rule Sets

Ein Managed Rule Set (MRS) ist eine vorgefertigte Regel-Sammlung, die für Sie gepflegt wird. Es bietet Basis-Schutz, ohne dass Sie eigene Erkennungs-Logik entwickeln müssen. Jedes MRS ist ein benanntes Objekt pro Projekt und Region, und jede ALB WAF-Konfiguration im selben Bereich kann es referenzieren.

Aktuell liefert die ALB WAF folgenden Managed Rule Set-Typ:

Typ	Quelle	Zweck
TYPE_OWASP_CRS	OWASP Core Rule Set (CRS)	Breiter Schutz gegen die OWASP Top 10-Bedrohungen wie SQL Injection, Cross-Site Scripting (XSS), das Ausführen von Remote-Code und Local File Inclusion.

Wenn Sie ein MRS abrufen, enthält die Antwort die gebundene CRS-version (zum Beispiel v4.14.0) sowie eine Zuordnung von Regel-Gruppen, jeweils mit der Gruppen-ID als Schlüssel (zum Beispiel enthält Gruppe 942 SQL-Injection-Regeln). Jede Gruppe enthält eine Zuordnung einzelner Regeln mit der Regel-ID als Schlüssel (zum Beispiel 942100) und den Feldern description, severity (CRITICAL, ERROR, WARNING, INFO) sowie mode.

Verwalten Sie MRS-Objekte und prüfen Sie das vollständige Request- und Response-Schema unter v1beta API: ManagedRuleSet.

Modus pro Regel

Sie müssen die OWASP CRS-Standard-Werte nicht vollständig übernehmen. Verwenden Sie PATCH, um den Zustand einzelner Regeln zu überschreiben, ohne alle anderen zu ändern. Die folgenden Modi werden unterstützt:

Modus	Wirkung
MODE_ENABLED	Prüft Traffic und wendet die Aktion der Regel bei einem Treffer an.
MODE_DISABLED	Überspringt die Regel vollständig. Es wird nichts geprüft und nichts protokolliert.
MODE_LOG_ONLY	Prüft Traffic und protokolliert Treffer, blockiert den Request jedoch nicht.

Der Patch-Body ist partiell: Nur die groups- und rules-Einträge, die Sie angeben, werden aktualisiert. So können Sie eine einzelne Regel-ID adressieren, ohne die restliche Gruppe erneut zu senden. Verwenden Sie MODE_LOG_ONLY, um die Auswirkung einer Regel auf den Produktions-Traffic zu beobachten, bevor Sie diese durchsetzen, und MODE_DISABLED, um eine Regel dauerhaft zu deaktivieren, die Sie als False Positive für Ihre Workload akzeptiert haben.

Den genauen PATCH-Request-Aufbau finden Sie in der v1beta API: ManagedRuleSet-Referenz.

Custom Rule Groups

Eine Custom Rule Group (CRG) ermöglicht es Ihnen, eigene Erkennungs-Logik für Fälle zu definieren, die das OWASP CRS nicht abdeckt – etwa anwendungsspezifische Allow-Lists, Prüfungen der Geschäfts-Logik oder gezielte Virtual Patches. Jede CRG ist ein benanntes Objekt pro Projekt und Region, und jede ALB WAF-Konfiguration im selben Bereich kann sie referenzieren.

STACKIT abstrahiert die zugrunde liegende Coraza SecLang-Grammatik in ein strukturiertes JSON-Modell, sodass Sie Regeln mit typisierten Feldern konfigurieren, anstatt SecLang-Direktiven manuell zu verfassen. Die Engine übersetzt Ihr JSON zur Laufzeit in SecLang.

Verwalten Sie CRG-Objekte und prüfen Sie das vollständige Request- und Response-Schema unter v1beta API: CustomRuleGroup.

Struktur einer Regel

Jede Regel in einer CRG hat folgenden Aufbau:

• Regel-ID — Wird vom Backend automatisch im Bereich 1–99999 vergeben. Sie legen sie bei der Erstellung nicht fest; sie wird bei GET zurückgegeben.
• Beschreibung — Eine Freitext-Erläuterung des Angriffs-Vektors oder der Geschäfts-Logik, die von der Regel abgedeckt wird.
• Verhalten — Was passiert, wenn die Regel zutrifft:
  • action — Eines von ACTION_DENY (gibt HTTP 403 zurück und stoppt die Verarbeitung), ACTION_PASS (fährt mit der nächsten Regel fort) oder ACTION_ALLOW (schließt die verbleibende Inspektion für den Request kurz).
  • log — Boolean. Wenn true, wird der Treffer in das Security-Log geschrieben.
  • log_msg — Erforderlich, wenn log true ist. Eine kurze lesbare Meldung, die dem Log-Eintrag zur Unterstützung bei der Fehleranalyse beigefügt wird.
  • severity — Klassifizierung für nachgelagerte Analysen. Eines von SEVERITY_EMERGENCY, SEVERITY_ALERT, SEVERITY_CRITICAL, SEVERITY_ERROR, SEVERITY_WARNING, SEVERITY_NOTICE, SEVERITY_INFO oder SEVERITY_DEBUG.
• Bedingungen — Eine geordnete Liste von Prüfungen, die von oben nach unten ausgewertet werden. Die erste zutreffende Bedingung löst die Aktion der Regel aus. Jede Bedingung kombiniert:
  • variable — Der Teil der HTTP-Transaktion, der geprüft werden soll. Ein optionaler value schränkt eine Map-Variable auf einen einzelnen Schlüssel ein (zum Beispiel Host innerhalb von VARIABLE_REQUEST_HEADERS).
  • transformations — Geordnete Schritte zur Normalisierung, die vor dem Operator ausgeführt werden.
  • operator — Die Logik des Vergleichs, die gegen die transformierte Variable ausgeführt wird.

Den vollständigen Katalog der unterstützten Variablen, Operatoren und Transformationen – einschließlich der API-Konstante und der Semantik jedes Werts – finden Sie in der Referenz für ALB WAF Rule Selectors.

Reihenfolge der Auswertung: Regeln innerhalb einer Gruppe werden in der von der API zurückgegebenen Reihenfolge ausgewertet, und Bedingungen innerhalb einer Regel werden von oben nach unten ausgewertet. Custom Rule Groups werden vor Managed Rule Sets ausgewertet, sodass Sie sie verwenden können, um Traffic auf eine Allow-List zu setzen, der andernfalls eine CRS-Regel auslösen würde.

Anwendungsbeispiel: Traffic zu einem unerwarteten Host blockieren

Ein typisches Beispiel für den Einsatz von Custom Rule Groups ist das Ablehnen von Requests, deren Host-Header nicht auf einer Allow-List steht. Sie würden dies als einzelne Regel ausdrücken mit:

• Einer Bedingung, die VARIABLE_REQUEST_HEADERS auf den Host-Schlüssel einschränkt, den Wert mit TRANSFORMATION_LOWERCASE normalisiert und ihn mit OPERATOR_BEGINS_WITH gegen den erlaubten Hostnamen prüft.
• Einem Verhalten von ACTION_DENY mit log: true und einer aussagekräftigen log_msg wie Host header not on allow-list, klassifiziert als SEVERITY_CRITICAL.

Den konkreten Request-Body und alle akzeptierten Felder finden Sie unter v1beta API: CustomRuleGroup. Verfügbare Selector-Werte sind in der Referenz für ALB WAF Rule Selectors aufgeführt.

Die Regel-ID wird automatisch vom Backend vergeben und bei nachfolgenden GET-Requests zurückgegeben.

Quoten

Jedes Projekt verfügt über separate Quoten für ALB WAF-Konfigurationen, Managed Rule Sets und Custom Rule Groups. Die Standard- und Maximum-Werte sind für alle drei gleich:

Ressource	Standard-Limit pro Projekt	Maximum-Limit pro Projekt
ALB WAF-Konfigurationen	150	STACKIT Support kontaktieren
Managed Rule Sets	150	STACKIT Support kontaktieren
Custom Rule Groups	150	STACKIT Support kontaktieren

Die aktuelle Nutzung finden Sie unter GET /v1beta/projects/{projectId}/regions/{region}/quotas. Wenn Sie ein Limit erhöhen möchten, wenden Sie sich an den STACKIT Support.

Verwandte Seiten

• Referenz für ALB WAF Rule Selectors
• Grundkonzepte der ALB WAF
• Grundkonzepte des ALB
• Coraza SecLang Referenz
• OWASP Core Rule Set