Automatisierung von WAF-Tests mit Fastlys WAF Simulator

Haben Sie sich schon einmal gefragt, ob eine soeben erstellte Regel für Ihre Web Application Firewall (WAF) auch wirklich den erwarteten Nutzen bringt? Und wie testet man das Ganze eigentlich? Werden Regeln einfach festgelegt und dann einfach sich selbst überlassen? Wie lässt sich sicherstellen, dass eine Regel im Laufe der Zeit weiterhin wie erwartet funktioniert? Und woher weiß ich, ob sich eine Regeländerung durch ein Teammitglied negativ auf die Angriffserkennung unserer WAF auswirkt?

Antworten auf alle diese Fragen liefert der neue WAF Simulator von Fastly, ein innovatives Feature, mit dem Sie Regeln in einer sicheren und kontrollierten Simulationsumgebung validieren können. Nachdem Sie eine WAF-Regel erstellt haben, können Sie mithilfe unseres Simulators sicherstellen, dass sie auch wie gewünscht funktioniert. Sie müssen dafür nicht zwischen verschiedenen Systemen hin und her wechseln, sondern geben einfach einen Auszug Ihres Anfrage-/Antwortcodes ein und der Simulator liefert Ihnen die erwartete WAF-Antwort.

In diesem Blogpost erfahren Sie, wie Sie mit unserem WAF Simulator Regeln testen können, welche Vorteile kontinuierliche Tests haben und wie Sie den WAF Simulator in eine CI/CD-Pipeline für automatisierte kontinuierliche Tests integrieren können. Außerdem erhalten Sie ein anschauliches Beispiel für die Verwendung von Tests zur Ermittlung von Änderungen an der WAF.

Testen mit dem WAF Simulator – so funktioniert’s

Fastly Kunden können Regeln mithilfe des WAF Simulator in der Management-Konsole testen und validieren. Gehen Sie nach dem Erstellen einer Regel für eine Website einfach zu Rules -> Simulator, geben Sie eine Beispielanfrage und eine Beispielantwort ein und klicken Sie anschließend auf Simulate. Nach Abschluss der Simulation werden Ihnen die WAF-Antwort und -Signale angezeigt.

Hier sehen Sie eine in der Management-Konsole getestete Site Rule, wonach eine Anfrage mit einem Pfad in einer Liste sensibler Account-API-Endpunkte abgeglichen und entsprechend getaggt wird.

Sobald feststeht, dass die Regel erwartungsgemäß funktioniert, kann die Testkonfiguration für laufende Tests angepasst werden. Mehr dazu später.

Vorteile regelmäßiger Tests

Mit der Zeit können WAF-Regeln veraltet sein oder Fehlkonfigurationen enthalten, die zu falsch positiven (Blockierung von legitimem Traffic) oder falsch negativen Ergebnissen (fehlende Blockierung von bösartigem Traffic) führen können. Wenn Mitarbeiter, die mit der WAF-Konfiguration vertraut sind, das Unternehmen verlassen, besteht außerdem die Gefahr, dass entscheidendes Wissen über die Konfiguration und die Beweggründe für bestimmte Regeln verloren geht. Hinzu kommt, dass viele Unternehmen an Compliance-Standards gebunden sind, und regelmäßige Tests können zur Einhaltung dieser Standards beitragen. Die Einführung kontinuierlicher Tests stellt nicht nur sicher, dass die Regeln wie vorgesehen funktionieren, sondern erleichtert auch den Wissenstransfer, hilft bei der Einhaltung von Compliance-Standards und fördert eine proaktive Sicherheitskultur.

Integration des WAF Simulator in Ihre CI/CD-Pipeline

Eine Möglichkeit, kontinuierliche Tests durchzuführen, ist die Verwendung einer CI/CD-Pipeline. Zur Veranschaulichung haben wir ein Beispiel-Repository erstellt, das Terraform Code für zwei Webanwendungen enthält, die von der Fastly Next-Gen WAF (NGWAF) geschützt werden: app1.example.com und app2.example.com. Wir haben ein in Go programmiertes Tool zur Verfügung gestellt, das automatisierte Tests mit dem Fastly WAF Simulator erleichtern soll. Insbesondere haben wir eine CI/CD-Pipeline integriert, die mithilfe von Github Actions Workflows Tests für jede Codeänderung im Hauptzweig durchführt.

Testkonfigurationen

Tests werden im yaml-Format geschrieben und im Verzeichnis test/rules gespeichert**.** Die yaml-Dateien dienen als strukturierte Methode zur Definition und Verwaltung von Testfällen. Jede Testdatei enthält eine Reihe von Tests und jeder Test enthält folgende Felder:

name: (Pflichtfeld) Eindeutige Bezeichnung für den Testfall
site: (Pflichtfeld) Name der zu testenden Website in der Fastly NGWAF
rule_id: (optional) ID der zu testenden Regel
description: (optional) Genaue Beschreibung des Testgegenstands
type: (optional) Echt positiv, falsch negativ, falsch positiv, echt negativ
request: (Pflichtfeld) HTTP-Anfrage, die im Rahmen des Tests gesendet wird
response: (Pflichtfeld) Erwartete Antwort für den Test
expect: (Pflichtfeld) Beschreibt das erwartete Testergebnis
- waf_response: Erwarteter Antwortcode von der WAF
- signals: Liste der mit Signalen behafteten Daten, die beim Test zurückgegeben werden. Jedes Signal enthält mehrere Werte und sollte weggelassen werden, wenn keine Werte vorhanden sind.
  - type: Signal-ID (bzw. Signaltyp)
  - location: Speicherort des mit einem Signal behafteten Wertes (QUERYSTRING, USERAGENT)
  - name: Name des zugewiesenen Signals
  - value: Spezifischer Wert, der das Signal ausgelöst hat
  - detector: Kennung des Detektors, der das Signal erzeugt hat
  - redaction: Binärer Indikator (1 oder 0), der angibt, ob der Wert des Signals bearbeitet wurde

Beispiel einer Testdatei:

tests:
 - name: sensitive account api test 001
   site: app1.example.com
   rule_id: 63d04576d3b2e101d4f1345d
   description: tags request with site.sensitive-account-api
   type: true positive
   request: |
     POST /api/v1/account/update_profile HTTP/1.1
     Host: app1.example.com
     Content-Type: application/x-www-form-urlencoded
     Accept: */*
     User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4)
     Content-Length: 8

     user=foo
   response: |
     HTTP/1.1 200 OK
   expect:
     waf_response: 200
     signals:
     - type: site.sensitive-account-api
       detector: 63e4404084fb8b01d40e3468

Jede Testdatei wird geparst und an den WAF Simulator gesendet. Das Skript vergleicht die simulierten WAF-Antworten und -Signale mit den erwarteten WAF-Antworten und -Signalen, die für den Test definiert wurden. Schlägt ein Test fehl, werden entsprechende Detailinformationen ausgegeben und der Fehlerzähler erhöht.

Erste Schritte

Führen Sie die nachfolgenden Schritte aus:

Klonen Sie das Repository https://github.com/fastly/waf-simulator-automation.
Erstellen Sie einen NGWAF API-Schlüssel.
1. Melden Sie sich unter https://dashboard.signalsciences.net/login bei der Management-Konsole der NGWAF an.
2. Wählen Sie im Reiter My Profile unter API Access Tokens die Option Add API access token aus.
3. Geben Sie einen Namen ein und wählen Sie Create API access token aus.

Legen Sie Ihre Fastly NGWAF Anmeldedaten als Umgebungsvariablen fest.

export SIGSCI_EMAIL='your-email'
export SIGSCI_TOKEN='your-token'
export SIGSCI_CORP='your-corp-id'

Führen Sie die hier beschriebenen Schritte aus, um Terraform zu installieren (falls nicht bereits geschehen).
Wechseln Sie vom Projektverzeichnis zum Verzeichnis terraform und führen Sie nachfolgende Befehle aus:
```
terraform init
terraform plan -out ngwaf.plan
terraform apply ngwaf.plan
```
Nachdem Sie den apply-Befehl ausgeführt haben, notieren Sie sich die Ausgabewerte von sensitive_account_api_rule_id und invalid_host_header_rule_id.
Öffnen Sie tests/rules/app1.example.com/sensitive-account-api.yaml und ersetzen Sie 65a190f3e3148001dc71a5ca überall durch den Wert unter sensitive_account_api_rule_id aus dem Terraform Output.
Öffnen Sie tests/rules/app2.example.com/invalid-host-headers.yaml und ersetzen Sie 65a190f40f6eb201dc0fdd81 überall durch den Wert unter invalid_host_header_rule_id aus dem Terraform Output.
Sobald die Testdateien aktualisiert wurden, können Sie die Tests mit dem WAF Simulator durchführen, um zu überprüfen, ob Ihre WAF-Regeln korrekt funktionieren.
Führen Sie die hier beschriebenen Schritte aus, um Go zu installieren (falls nicht bereits geschehen).
Gehen Sie zurück ins Stammverzeichnis des Projekts und führen Sie folgenden Befehl aus:

go run tests/main.go

Wenn Sie keine Fehlermeldungen erhalten haben, wurden die Tests erfolgreich abgeschlossen. Wenn Fehler festgestellt wurden, verwenden Sie die Logs zur Fehlersuche und Problembehebung.
Erstellen Sie mit den hier beschriebenen Schritten ein neues Repository auf GitHub.
Ändern Sie die Remote URL auf Ihr neues Repository.

git remote set-url origin https://github.com/yourusername/new-repository.git

Fügen Sie SIGSCI_EMAIL, SIGSCI_CORP und SIGSCI_TOKEN zu GitHub Secrets hinzu.
Ändern Sie in der Workflow-Datei .github/workflows/tests.yaml den Namen der Verzweigung von main-branch zu main.
Fügen Sie Ihre Änderungen hinzu und committen Sie sie.

git add .github/workflows/tests.yaml
git commit -m "update workflow"

Pushen Sie nun den Code mit dem Befehl git push zu Ihrem neuen Repository.

git push origin main

Überprüfen Sie anschließend Ihr Repository auf GitHub, um sich zu vergewissern, dass der Test-Workflow ausgeführt wird.
Navigieren Sie in Ihrem Repository oben auf der Seite zum Tab Actions. Dort finden Sie eine Liste der in Zusammenhang mit Ihrem Repository kürzlich ausgeführten Workflows. Jede Ausführung ist mit einem Commit oder einem Ereignis verbunden, das sie ausgelöst hat (z. B. ein Push auf den Hauptzweig).
Wenn der Workflow erfolgreich ausgeführt wurde, funktionieren Ihre WAF-Regeln wie erwartet.
Wenn Fehler festgestellt wurden, verwenden Sie die Logs zur Fehlersuche und Problembehebung. Bestätigen Sie Ihre Änderungen, sobald Sie Korrekturen vorgenommen haben, und pushen Sie sie erneut, um den Workflow zu initiieren.

Basierend auf diesem Konzept können Sie eine Webhook Integration konfigurieren, um automatisch einen Test-Workflow auszulösen, sobald eine Regel geändert wurde. Dies kann beispielsweise hilfreich sein, um sicherzustellen, dass über die Management-Konsole vorgenommene Änderungen an WAF-Regeln keine negativen Auswirkungen auf die Erkennung von Bedrohungen haben.

Beispielszenario

Sehen wir uns die Regel invalid host header an, die wir für app2.example.com erstellt haben. Diese Regel verhindert Angriffe auf HTTP Host Header, die selbst unter vermeintlich sicheren Webserverkonfigurationen möglich sind. Die Werte in der untenstehenden Liste werden genau mit dem Host Header abgeglichen. Wenn ein Host Header mit keinem Wert in dieser Liste übereinstimmt, blockiert die Regel die Anfrage und wendet das Signal site.invalid-host-header an.

www.app2.example.com
app2.example.com

Wir richten Tests ein, um sicherzustellen, dass Anfragen, die einen ungültigen Host Header enthalten, korrekt blockiert und getaggt werden.

Angenommen, ein Teammitglied fügt eine neue Subdomain namens payments.app2.example.com zur WAF hinzu. Nach diesem Update erhalten Nutzer die Antwort „406 Not Acceptable“, wenn sie versuchen, auf payments.app2.example.com zuzugreifen. Um dieses Problem schnell zu beheben, meldet sich ein Teammitglied bei der Management-Konsole der WAF an und nimmt eine Regeländerung vor, sodass die Anfragen nicht mehr blockiert, sondern zugelassen werden.

Diese Änderung löst einen Test-Workflow aus, der einen Fehler hervorruft, da die Tests von einer Regel ausgingen, die Anfragen blockiert, diese aber jetzt zugelassen werden. Anstatt alle Anfragen zuzulassen, hätte das Teammitglied payments.app2.example.com in die Liste der zulässigen Hosts aufnehmen sollen. Da die Tests aber bereits im Gange waren, erhielten die zuständigen Teammitglieder eine Fehlermeldung und konnten die entsprechenden Regelanpassungen vornehmen. Ohne diese Feedback-Schleife hätte eine solche Änderung unbemerkt bleiben können, was zu der falschen Annahme geführt hätte, dass die WAF Anfragen mit ungültigen Host Headern weiterhin blockiert.

Dieses Beispiel verdeutlicht, wie wichtig Tests sind, um Änderungen an WAF-Regeln zu identifizieren, vor allem in Situationen, in denen es mehrere Verantwortliche gibt. Die Durchführung regelmäßiger Tests spielt also eine wichtige Rolle bei der Erkennung von Veränderungen, die sonst unbemerkt bleiben könnten.

Zusammenfassung

Folgende Gesichtspunkte haben wir in diesem Blogpost behandelt:

Testen von WAF-Regeln mit dem WAF Simulator
Vorteile regelmäßiger Tests
Integration des WAF Simulator in eine CI/CD-Pipeline
Beispiel für die Verwendung von Tests zur Ermittlung von Änderungen an der NGWAF

Für die Wartungsfreundlichkeit einer WAF ist es entscheidend, dass sich das Verhalten von Regeln testen und validieren lässt. Regelmäßige Tests gewährleisten nicht nur die dauerhafte Wirksamkeit Ihrer WAF-Regeln, sondern tragen auch zur Erhaltung der zugrunde liegenden Logik bei, helfen bei der Einhaltung von Compliance-Anforderungen und fördern eine proaktive Sicherheitskultur.