Bedrohlicher Datenverkehr muss blockiert werden? Konfiguriere Firewall-IDPS

Eine Allow-Regel bestätigt, dass ein Ziel genehmigt ist. Sie beweist jedoch nicht, dass jede an dieses Ziel gesendete Anfrage sicher ist. Ein kompromittierter Workload könnte schädliche Anweisungen über eine Verbindung senden, die von der Firewall grundsätzlich zugelassen wird.

Aktiviere das Intrusion Detection and Prevention System (IDPS) von Azure Firewall Premium. IDPS vergleicht den Datenverkehr mit von Microsoft verwalteten Signaturen. Diese Muster stehen für Exploits, Malware, Command-and-Control-Kommunikation und andere Bedrohungen.

Die beiden Teile des Namens beschreiben seine Betriebsarten:

Intrusion Detection  -> verdächtigen Datenverkehr erkennen und melden
Intrusion Prevention -> verdächtigen Datenverkehr erkennen, melden und blockieren

Dieser Trip baut auf Verschlüsselter Datenverkehr muss geprüft werden? Konfiguriere TLS-Inspektion mit Azure Firewall Premium auf. Behalte Premium-Firewall und -Policy, TLS-Konfiguration, vertrauenswürdige Lab-CA, Route, private VM und Bastion-Verbindung.

Die Kontrollen arbeiten jetzt zusammen:

Application Rule -> erlaubt www.microsoft.com
TLS Inspection   -> entschlüsselt die HTTPS-Anfrage
IDPS             -> prüft ihren Inhalt und blockiert eine passende Bedrohungssignatur

Dieses Lab sendet nur ein harmloses Textmuster, das eine IDPS-Testsignatur erkennen soll. Es lädt keine Malware herunter und führt keine Malware aus.

Azure Firewall Premium und Log Analytics sind kostenpflichtig. Schließe den Test ab und bereinige die Ressourcen zeitnah, wenn du sie nicht mehr benötigst.

Alert and Deny aktivieren

Öffne afw-cloudtrips-test-weu. Öffne auf Overview die zugeordnete Premium Firewall Policy. Wähle Settings > IDPS.

IDPS bietet diese Modi:

• Off prüft den Datenverkehr nicht mit IDPS-Signaturen.
• Alert erkennt und protokolliert passenden Datenverkehr, lässt ihn aber weiterlaufen.
• Alert and deny erkennt, protokolliert und blockiert passenden Datenverkehr.

Wähle Alert and deny und danach Apply oder Save. Warte, bis der Bereitstellungsstatus der Policy Succeeded lautet.

In der Produktion beginnen Teams normalerweise mit Alert, prüfen legitimen Datenverkehr auf False Positives, passen einzelne Signaturen an und wechseln danach zu Alert and deny. Dieses isolierte Lab kann den Prevention-Modus sofort verwenden, weil sein Testmuster absichtlich gesendet wird.

Füge keinen IDPS Bypass hinzu. Ein Bypass weist die Firewall an, IDPS für die passende Quelle, das Ziel, den Port oder das Protokoll nicht auszuführen. Das würde diesen Test verhindern.

IDPS-Ereignisse an Log Analytics senden

Die Blockierung beweist, dass die Kontrolle funktioniert. Die Logs erklären, warum sie die Verbindung blockiert hat. Azure Firewall bewahrt keine abfragbaren Ressourcenlogs auf, solange eine Diagnostic Setting sie nicht an ein Ziel sendet.

Suche nach Log Analytics workspaces und wähle Create. Konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: law-cloudtrips-network-test-weu
Region: West Europe

Wähle Review + create und danach Create.

Öffne Diagnostic settings nicht im Log-Analytics-Workspace. Diese Seite zeigt Workspace-Kategorien wie Audit, Summary Logs und Job Logs und nicht den Firewall-Datenverkehr.

Kehre stattdessen zur eigentlichen Azure-Firewall-Ressource afw-cloudtrips-test-weu zurück. Öffne Monitoring > Diagnostic settings und wähle Add diagnostic setting. Die Firewall ist die Logquelle; der Log-Analytics-Workspace ist nur das Ziel. Konfiguriere:

Diagnostic setting name: diag-cloudtrips-afw-idps
Log category: Azure Firewall IDPS Signature
Destination: Send to Log Analytics workspace
Subscription: CloudTrips TEST
Log Analytics workspace: law-cloudtrips-network-test-weu
Destination table: Resource specific

In manchen Portalversionen wird die Kategorie nur als IDPS log angezeigt. Wähle die Kategorie, deren Beschreibung sich auf Treffer von IDPS-Signaturen bezieht. Wähle Resource specific, damit Ereignisse in die eigene Tabelle AZFWIdpsSignature geschrieben werden. Wähle Save.

Wenn die Firewall bereits eine Diagnoseeinstellung besitzt, die die IDPS-Kategorie im ressourcenspezifischen Modus an diesen Workspace sendet, verwende sie weiter, anstatt ein Duplikat zu erstellen.

Es kann bis zu 30 Minuten dauern, bis neue Azure-Firewall-Logs erstmals erscheinen. Der Datenverkehrstest selbst muss nicht warten. Die abschließende Abfrage kann zunächst jedoch keine Zeilen zurückgeben.

Beweisen, dass normales HTTPS weiterhin funktioniert

Starte vm-cloudtrips-bastion-test-weu, falls sie beendet und ihre Zuordnung aufgehoben wurde, und verbinde dich über Connect > Bastion.

Führe zuerst eine normale Anfrage aus:

curl --max-time 20 -I https://www.microsoft.com

Eine normale Antwort wie 200, 301 oder 302 beweist, dass Application Rule, TLS Inspection, CA-Vertrauen und Route weiterhin funktionieren. IDPS blockiert nicht jede Anfrage. Es blockiert Datenverkehr, der einer aktiven Signatur entspricht.

Eine harmlose IDPS-Signatur auslösen

Sende jetzt eine weitere Anfrage mit dem Testwert HaxerMen im HTTP User-Agent-Header:

curl --max-time 20 \
  -A "HaxerMen" \
  https://www.microsoft.com \
  --output /dev/null \
  --verbose

Der User-Agent identifiziert normalerweise die Clientsoftware, die eine HTTP-Anfrage sendet. Hier enthält er eine harmlose Zeichenfolge, die eine von Microsoft dokumentierte IDPS-Testsignatur erkennt. Da TLS Inspection für die vorhandene Regel Allow-Microsoft-Web aktiviert ist, kann die Firewall diesen Header innerhalb der HTTPS-Verbindung lesen.

Die Anfrage sollte fehlschlagen, ein Timeout erreichen oder ohne normale HTTP-Antwort enden. Das ist das erwartete Ergebnis: Die Application Rule ließ das Ziel zu, aber IDPS erkannte das Testmuster und verweigerte die Anfrage.

In der ausführlichen Ausgabe liefern diese Zeilen den Nachweis:

issuer: CN=Azure Firewall Manager CA
SSL certificate verify ok.
User-Agent: HaxerMen
Operation timed out ... with 0 bytes received

Die Azure-Firewall-CA und die erfolgreiche Zertifikatsprüfung beweisen, dass TLS Inspection die Verbindung entschlüsselt hat. Die Anfrage wurde verbunden und gesendet, nach dem HaxerMen-Header kam jedoch keine Antwort. Zusammen mit der erfolgreichen normalen Anfrage aus dem vorherigen Schritt ist dieses Timeout das erwartete IDPS-Deny-Ergebnis. Bestätige den genauen Grund als Nächstes im IDPS-Log.

Der genaue curl-Fehler kann variieren, weil die Firewall den verdächtigen Datenverkehr verwirft, anstatt eine normale Webantwort zurückzugeben. Schwäche die Regel nicht ab und verwende nicht --insecure; das Zertifikatsvertrauen ist nicht die Ursache dieses erwarteten Fehlers.

Die blockierte Signatur finden

Öffne afw-cloudtrips-test-weu und wähle Monitoring > Logs. Wenn Azure nach einem Scope fragt, wähle law-cloudtrips-network-test-weu.

Führe diese Abfrage in Kusto Query Language (KQL) aus:

AZFWIdpsSignature
| where TimeGenerated > ago(1h)
| project TimeGenerated, SourceIp, DestinationIp, Protocol,
    SignatureId, Description, Action
| order by TimeGenerated desc

Suche nach dem Ereignis der Testanfrage. Es sollte eine Deny-Aktion und eine Beschreibung zum verdächtigen HaxerMen-User-Agent zeigen. Microsoft hat diesen Test mit der Signatur-ID 2032081 dokumentiert. Verwaltete Signaturen können jedoch aktualisiert werden. Verwende das von deinem aktuellen Testlauf erzeugte Ereignis als Nachweis.

Wenn zunächst keine Zeile erscheint, warte einige Minuten und führe die Abfrage erneut aus. Bei einer neu erstellten Diagnoseeinstellung kann die erste Logübertragung bis zu 30 Minuten dauern. Ändere die Firewall Policy während dieser Wartezeit nicht wiederholt.

Das Ergebnis trennt die Verantwortlichkeiten deutlich: Die Application Rule erlaubte das Ziel, TLS Inspection machte den verschlüsselten Header sichtbar und IDPS erkannte eine Bedrohungssignatur und blockierte die Anfrage.

Firewall-Lab bereinigen

Dies ist der letzte Trip der aktuellen Azure-Firewall-Reihe. Azure Firewall Premium bleibt auch bei gestoppter Test-VM kostenpflichtig.

Wenn du die Firewall für spätere Experimente behalten möchtest, setze IDPS auf Alert oder Off, gib die VM frei und behalte die Diagnoselogs zur Auswertung.

Wenn das Firewall-Lab abgeschlossen ist, lösche zuerst Default-To-Azure-Firewall aus rt-cloudtrips-app-test-weu. Dadurch erhält das Subnetz seine normale ausgehende Route zurück, bevor die Firewall verschwindet. Lösche danach:

afw-cloudtrips-test-weu
Die zugehörige Premium Firewall Policy
pip-cloudtrips-afw-test-weu
AzureFirewallSubnet
Den erzeugten TLS Key Vault und die Managed Identity
law-cloudtrips-network-test-weu, wenn er nur von diesem Lab verwendet wird

Wenn du die VM behältst, entferne die Lab-CA mit dem Bereinigungsbefehl des vorherigen TLS-Inspection-Trips aus ihrem Ubuntu Trust Store. Wenn du die VM löschst, verschwindet die Änderung am Zertifikatsvertrauen zusammen mit dem Betriebssystemdatenträger.