Eine Webanwendung benötigt OWASP-Schutz? Aktiviere WAF

Das CloudTrips Application Gateway kann HTTP-Anfragen routen und umschreiben, aber der Standard_v2-Tarif untersucht sie nicht auf häufige Webangriffe. Eine bösartige Anfrage kann deshalb die Anwendung erreichen, wenn die Anwendung sie nicht selbst erkennt.

Aktiviere Azure Web Application Firewall (WAF), damit Application Gateway Layer-7-Anfragen prüft, bevor sie an die privaten Web-VMs weitergeleitet werden. Verwende das verwaltete Default Rule Set von Azure, um häufige Muster wie SQL Injection und Cross-Site Scripting zu erkennen.

OWASP steht für Open Worldwide Application Security Project. Diese Community veröffentlicht weitverbreitete Leitlinien zu Risiken von Webanwendungen. Die verwalteten Azure-Regeln decken OWASP-Top-10-Angriffsarten ab und ergänzen Microsoft Threat Intelligence. WAF reduziert die Gefährdung durch häufige Angriffe, ersetzt aber keinen sicheren Anwendungscode, keine Authentifizierung, keine Updates und keine Tests.

Dieser Trip hängt von Header und URLs müssen geändert werden? Konfiguriere Application-Gateway-Rewrite-Regeln ab. Behalte agw-cloudtrips-web-test-weu, seine öffentliche IP, beide privaten Web-VMs sowie die funktionierende Routing- und Rewrite-Konfiguration.

WAF_v2 ist teurer als Standard_v2 und bleibt kostenpflichtig, solange das Application Gateway bereitgestellt ist. Führe die Application-Gateway-Labs zusammen aus und entferne das Gateway nach Abschluss der Sequenz.

Eine WAF Policy erstellen

Suche nach Web Application Firewall policies und wähle Create. Trage unter Basics ein:

Policy for: Regional WAF (Application Gateway and Application Gateway for Containers)
Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Policy name: wafp-cloudtrips-appgw-test-weu
Region: West Europe

Das aktuelle Portal verwendet eine gemeinsame Regional-WAF-Option für das klassische Application Gateway und Application Gateway for Containers. Wähle diese kombinierte Option. Wenn das Portal warnt, dass OWASP-Regelwerke und Microsoft_DefaultRuleSet_2.2 für Application Gateway for Containers nicht verfügbar sind, fahre fort: Dieses Lab ordnet die Policy der klassischen WAF_v2-Ressource agw-cloudtrips-web-test-weu zu, für die DRS 2.2 unterstützt wird.

Konfiguriere unter Policy settings:

Policy state: Enabled
Policy mode: Prevention
Request body inspection: Enabled

Im Modus Detection werden passende Anfragen protokolliert, aber weiterhin an das Backend geleitet. Dieser Trip benötigt Prevention, weil eine Anfrage beim Erreichen des Blockierungsschwellwerts mit HTTP 403 Forbidden gestoppt werden soll.

Die Managed Rules auswählen

Öffne Managed rules. Verwende das neueste unterstützte von Azure verwaltete Regelwerk:

Rule set type: Microsoft Default Rule Set
Rule set version: 2.2

Das Portal kann dies als DRS 2.2 anzeigen. DRS bedeutet Default Rule Set. Es enthält verwaltete Schutzregeln gegen SQL Injection, Cross-Site Scripting, Protokollverletzungen, Remote File Inclusion und weitere häufige Webbedrohungen.

Lasse die verwalteten Regelgruppen aktiviert und erstelle für dieses Lab keine Exclusions. Exclusions sollten erst hinzugefügt werden, wenn Logs belegen, dass ein bestimmter sicherer Anwendungswert ein False Positive verursacht.

Füge unter Association noch keine Zuordnung hinzu. Erstelle zuerst die Policy. Wähle diese Policy im nächsten Schritt direkt auf der Seite Web application firewall des Application Gateways aus, während du den Tarif auf WAF_v2 änderst.

Wähle Review + create > Create.

Gateway aktualisieren und Policy auswählen

Öffne agw-cloudtrips-web-test-weu und wähle Settings > Web application firewall. Konfiguriere unter Configure:

Tier: WAF V2
WAF policy: wafp-cloudtrips-appgw-test-weu

Wähle die vorhandene Policy aus, bevor du Save wählst. Azure muss den Tarif ändern und die WAF Policy im selben Update zuordnen. Wenn nur der Tarif unter Configuration geändert wird, schlägt das Speichern mit Direct WAF configuration on Application Gateway has been retired fehl, weil neue WAF_v2-Bereitstellungen die veraltete Inline-WAF-Konfiguration nicht mehr verwenden dürfen.

Wähle Save und warte, bis der Bereitstellungsstatus wieder Succeeded lautet. Die Policy ist global zugeordnet und schützt alle aktiven Listener und Pfadregeln des Gateways, einschließlich /, /images/* und /api/*.

Dieses Update ersetzt weder die öffentliche IP noch Listener, Routingregeln, das Rewrite Set, Backend Pools oder Backend Settings.

Prüfen, ob normaler Datenverkehr weiterhin funktioniert

Rufe die vorhandene öffentliche IP ab, falls sie nicht mehr in deiner Shell gespeichert ist:

APPGW_IP=$(az network public-ip show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name pip-cloudtrips-appgw-test-weu \
  --query ipAddress \
  --output tsv)

Sende eine normale Anfrage über das Gateway:

curl --include "http://${APPGW_IP}/api/health"

Die Anfrage sollte weiterhin HTTP 200, die CloudTrips-Health-JSON-Antwort und den im vorherigen Trip erstellten Response Header zurückgeben:

HTTP/1.1 200 OK
X-CloudTrips-Gateway: ApplicationGateway

{"service":"CloudTrips API","status":"healthy","backend":"WEB02"}

Ein harmloses SQL-Injection-Testmuster senden

Sende nun Text, der einem klassischen SQL-Injection-Versuch in einem Query Parameter ähnelt. Die Zeichenfolge ist ausschließlich eine Testeingabe und führt auf dem statischen Python-Backend kein SQL aus:

curl --include \
  "http://${APPGW_IP}/?search=%27%20OR%201%3D1--"

Der dekodierte Query-Wert lautet ' OR 1=1--. Verwaltete SQL-Injection-Regeln erkennen dieses Muster. Im Prevention-Modus sollte die Antwort lauten:

HTTP/1.1 403 Forbidden

Die Anfrage wird am Application Gateway gestoppt und nicht an eine der beiden VMs weitergeleitet. Wenn die Policy gerade erst zugeordnet wurde, warte eine Minute auf die Verteilung der Konfiguration und teste erneut.

Die beiden Tests trennen Verfügbarkeit von Schutz: Normaler API-Datenverkehr erreicht weiterhin das richtige Backend, während eine Anfrage mit einem verwalteten Angriffsmuster vor dem Öffnen der Backend-Verbindung abgewiesen wird.

Behalte das WAF-aktivierte Application Gateway und seine Backends, wenn du mit den folgenden Web-Traffic-Management-Trips fortfährst. Wenn die Lab-Sequenz abgeschlossen ist, lösche zuerst das Application Gateway und danach seine öffentliche IP, um die Gebühren zu stoppen. Die WAF Policy selbst verarbeitet und berechnet keinen Datenverkehr mehr, sobald sie keinem Gateway zugeordnet ist.