Die Azure Firewall ist ein cloudnativer und intelligenter Netzwerk-Firewall-Sicherheitsdienst, der in viele verschiedene Anwendungsfälle integriert werden kann. Es handelt sich um eine vollständig zustandsbehaftete Firewall als Dienst mit integrierter Hochverfügbarkeit und uneingeschränkter Cloud-Skalierbarkeit, die sowohl eine Ost-West- als auch eine Nord-Süd-Verkehrskontrolle ermöglicht. Abhängig davon, wie der Datenverkehr durch die Azure Firewall fließt, gibt es erwartete NAT-Verhaltensweisen. NAT oder Network Address Translation ist eine Methode zur Neuzuordnung einer IP-Adresse in eine andere durch Änderung der Netzwerkadressinformationen im IP-Header von Paketen. Wenn der Datenverkehr eine Azure Firewall passiert, kann die Firewall NAT durchführen, um die Quell- oder Ziel-IP-Adressen und Ports der Pakete zu übersetzen. Das spezifische NAT-Verhalten hängt von der Konfiguration der Firewall und der Art des verwendeten NAT ab. In diesem Blog behandeln wir, welche Verhaltensweisen bei fließendem Datenverkehr zu erwarten sindeingehender Verkehr, durch DNAT-Regeln und für ausgehenden Datenverkehr über dieNetzwerk, UndAnwendungRegeln der Azure Firewall.
Azure Firewall kann eingehenden Internet-Netzwerkverkehr in seine öffentliche IP-Adresse übersetzen und ihn an die privaten IP-Adressen in Ihren virtuellen Netzwerken oder an eine andere öffentliche IP filtern. Dies wird mithilfe von DNAT-Regeln (Destination Network Address Translation) in der Azure Firewall-Richtlinie erreicht. Wenn ein neuer Fluss mit einer DNAT-Regel in der Azure Firewall übereinstimmt, werden sowohl die Quell- als auch die Ziel-IP-Adresse in neue Werte übersetzt. Wenn das Ziel eine private IP-Adresse im virtuellen Netzwerk ist, wird die Quell-IP-Adresse in eine der IP-Adressen im virtuellen Netzwerk übersetztAzureFirewallSubnetdes virtuellen Netzwerks, während die Ziel-IP-Adresse in das übersetzt wird, was in der DNAT-Regel als konfiguriert wurdeÜbersetzte Adresse. Außerdem wird der vom Quellcomputer verwendete Quellport über die Verbindung beibehalten.
Unten finden Sie ein Beispiel für einen Netzwerkfluss, der eine DNAT-Regel verwendet, die auf eine virtuelle Maschine abzielt, die einen IIS-Server hostet und den TCP-Port 80 überwacht. Die Clientmaschine ist eine in Azure gehostete virtuelle Maschine, die direkt ins Internet geht, um sie zu erreichen Die öffentliche IP von Azure Firewall. Nachfolgend finden Sie die DNAT-Regelkonfiguration, die auf den Backend-IIS-Server abzielt.
Der Client sendet einen Invoke-WebRequest-Befehl an den FQDN (Fully Qualified Domain Name), der in die öffentliche IP der Firewall, 40.122.188.187, aufgelöst wird. Das Cmdlet Invoke-WebRequest sendet HTTP- und HTTPS-Anfragen an eine Webseite oder einen Webdienst. Es analysiert die Antwort und gibt Sammlungen von Links, Bildern und anderen wichtigen HTML-Elementen zurück.
Aus Sicht des Kunden liefert die Paketerfassung relevante Informationen. Die Quell-IP ist die private IP der virtuellen Clientmaschine, 10.100.0.4, und die Ziel-IP ist die der Azure Firewall, 40.122.188.187. Die Paketerfassung zeigt auch den Quellport 56393 und den Zielport 80 an.
Sobald die Azure Firewall den Fluss empfängt, protokolliert sie die Aktion in einem konfigurierten Protokollanalyse-Arbeitsbereich. Das folgende Protokoll zeigt die Quell-IP und den Port, die der Client-Computer verwendet, wenn er das Internet durchquert, 20.29.103.252:80, die Ziel-IP und den Ziel-Port, 40.122.188.187:80, und die übersetzte IP und den Port, bei dem es sich um die private IP handelt Adresse der virtuellen Zielmaschine in Azure, 10.200.0.4:80.
Konzentrieren Sie sich nun auf das NAT-Verhalten der Azure Firewall, indem Sie eine Paketerfassung analysieren, die von der virtuellen Zielmaschine stammt. Die Paketerfassung zeigt, dass die Quell-IP in einen neuen Wert übersetzt wurde, 10.0.0.5. Diese IP wird vom AzureFirewallSubnet innerhalb des virtuellen Netzwerks abgeleitet. Die Ziel-IP wurde ebenfalls in 10.200.0.4 übersetzt, die Ziel-VM, die IIS hostet.
*Notiz: Als empfohlene Best Practice wird in dieser Konfiguration empfohlen, den eingehenden Datenverkehr am Zielport auf den IP-Bereich des zu beschränken, wenn NSGs (Netzwerksicherheitsgruppen) in der Umgebung verwendet werdenAzureFirewallSubnet. Das explizite Verweigern aller Regeln in der NSG führt dazu, dass dieser DNAT-Verkehr fehlschlägt, es sei denn, eine höher priorisierte NSG-Regel wird mit konfiguriertAzureFirewallSubnetIP-Bereich.
Das DNAT-Verhalten der Azure Firewall ist einfach zu verfolgen und ermöglicht eine einfache Fehlerbehebung, wenn ein Ablauf durchgehend verfolgt werden muss. Obwohl die Quell- und Ziel-IPs übersetzt werden und in einigen Szenarien auch der Zielport übersetzt wird, werden Werte innerhalb des Flusses beibehalten, die bei der Identifizierung eines Pakets für die Fehlerbehebung im Netzwerk hilfreich sein können. Beispielsweise verwaltet die Azure Firewall den Quellport, die IP-ID sowie die Sequenznummern, wenn tatsächliche Werte und nicht von der Paketerfassungsanwendung generierte Werte verwendet werden.
Azure Firewall ermöglicht die zentrale Erstellung von Netzwerkfilterregeln zum Zulassen oder Verweigern nach Quell- und Ziel-IP-Adresse, Port und Protokoll. Die Firewall ist vollständig zustandsbehaftet, sodass sie legitime Pakete für verschiedene Verbindungstypen unterscheiden kann. Azure Firewall unterstützt die zustandsbehaftete Filterung von Layer-3- und Layer-4-Netzwerkprotokollen. Wenn es um das NAT-Verhalten der Azure Firewall über Netzwerkregeln geht, unterscheiden sich die Verhaltensweisen je nach Konfiguration der Umgebung. In den folgenden Abschnitten behandeln wir verschiedene gängige Azure Firewall-Szenarien und erklären jeweils das NAT-Verhalten.
Ost-West-Verkehrsfluss (IANA RFC 1918 & IANA RFC 6598)
Der Ost-West-Verkehrsfluss bezieht sich auf den Datenverkehr zwischen virtuellen Azure-Netzwerken, entweder Subnetzen innerhalb der virtuellen Netzwerke oder zwischen virtuellen Spoke-Netzwerken, sowie auf den Datenverkehr zwischen virtuellen Azure-Netzwerken und lokalen Netzwerken über Virtual Private Network (VPN)- oder ExpressRoute (ExR)-Verbindungen. Wenn sich dieser Datenverkehr innerhalb des RFC 1918- oder RFC 6598-Adressraums befindet und der Fluss durch eine Netzwerkregel gefiltert wird, führt die Azure Firewall für den Fluss kein SNAT (Source Network Address Translation) durch. Das bedeutet, dass alle Tupel eines Netzwerkflusses beim Durchlaufen der Azure Firewall erhalten bleiben. Dieses Verhalten kann über die Konfiguration privater IP-Bereiche in der Azure Firewall-Richtlinie manipuliert werden. Innerhalb dieser Konfiguration können Änderungen vorgenommen werden, um verschiedene SNAT-Verhaltensweisen der Azure Firewall für Netzwerkregeln anzupassen.
- Erzwingen Sie zunächst die SNAT-Verkehrsflüsse der Firewall, die für einen RFC 1918/RFC 6598-Adressraum bestimmt sind, an eine IP-Adresse desAzureFirewallSubnet.
- Zweitens verhindern Sie, dass die Firewall SNAT-Datenverkehr unabhängig vom Ziel durchführt. Diese Konfiguration verhindert, dass die Azure Firewall den Datenverkehr direkt an das Internet weiterleitet. Verwenden Sie dies, wenn Sie die Azure Firewall in einer erzwungenen Tunnelkonfiguration verwenden, bei der ein anderes Netzwerkgerät der Ausgangspunkt ist.
- Passen Sie abschließend den IP-Adressbereich an, für den die Firewall kein SNAT durchführt. In dieser Konfiguration werden Nicht-IANA-RFC-1918- und Nicht-IANA-RFC-6598-Adressräume definiert.
Ost-West-Verkehrsfluss (nicht IANA RFC 1918 und nicht IANA RFC 6598 privater Adressraum)
Es gibt Szenarien, in denen Organisationen öffentliche IP-Adressräume verwenden müssen, um ihre privaten Netzwerke zu definieren. Wenn dies erledigt ist, führt die Azure Firewall standardmäßig ein SNAT dieser Netzwerkflüsse durch. Wenn diese öffentlichen Bereiche in Azure oder vor Ort definiert sind und die Azure Firewall über eine direkte Route über virtuelles Netzwerk-Peering oder VPN/ExR-Verbindungen verfügt, sehen unsere Ziele die IP-Adressen derjenigen in denAzureFirewallSubnet. Da die Firewall einen privaten Netzwerkpfad zu diesem Adressraum kennt, verwendet sie die IP desAzureFirewallSubnetzu SNAT, anstatt seine öffentliche IP zu verwenden.
Nachfolgend finden Sie ein Beispiel dafür, wie der Datenverkehr bei Verwendung öffentlicher IP-Adressräume in privaten Netzwerken aussieht. Der Clientcomputer ist eine in Azure gehostete virtuelle Maschine, die die Azure Firewall durchläuft und durch eine Layer-3-Netzwerkregel gefiltert wird. Das Ziel ist eine in Azure gehostete virtuelle Maschine, die einen öffentlichen IP-Bereich für ihr Netzwerk verwendet. Nachfolgend finden Sie die Netzwerkregelkonfiguration, die diesen Datenverkehr zulässt.
Auf dem Client-Computer verwendet der Client Test-NetConnection, um ICMP-Verkehr (Internet Control Message Protocol) an das Ziel 200.35.0.4 zu senden. Das Cmdlet Test-NetConnection zeigt Diagnoseinformationen für eine Verbindung an. Es unterstützt Ping-Tests, TCP-Tests (Transmission Control Protocol), Routenverfolgung und Routenauswahldiagnosen.
Aus Sicht des Clients zeigt die Paketerfassung das ICMP-Paket, das für 200.35.0.4 bestimmt ist, und die Quell-IP 10.100.0.4.
Sobald die Azure Firewall diesen Fluss empfängt, wird er durch die Netzwerkregel gefiltert und zum Ziel durchgelassen. Das Protokoll unten zeigt die ursprüngliche Quell-IP und Ziel-IP sowie das als ICMP Typ=8 definierte Protokoll.
Aus Sicht des Ziels zeigt die Paketerfassung, dass SNAT durchgeführt wird. Die Quell-IP-Adresse hat sich von der ursprünglichen IP-Adresse 10.100.0.4 in die des geändertAzureFirewallSubnet, 10.0.0.6, obwohl das Ziel technisch gesehen ein privates Netzwerk ist.
Dieses Verhalten ist zu erwarten, da der Zieladressraum ein öffentlicher IP-Bereich ist, auch wenn er als privates Netzwerk verwendet wird. Die Manipulation dieses Verhaltens ist einfach und kann durch Auswahl erfolgenFüralle IP-Adressen außer den unten angegebenenund dann den Bereich im definierenAusgeschlossenes Quell-NAT (SNAT)Adressen.
Unten sehen Sie, wie das Ping-Verhalten aussieht, wenn die oben genannte Änderung angewendet wird. Hier ist der neue Ping vom Client-Computer, sobald die Änderung vorgenommen wurde.
Hier ist der Ping von der Zielseite. Beachten Sie, dass SNAT nicht mehr von der Azure Firewall ausgeführt wird.
Nord-Süd-Verkehrsfluss
Anstelle von Anwendungsregeln können auch Netzwerkregeln zum Filtern des Nord-Süd-Verkehrs verwendet werden. Nord-Süd-Verkehr bezieht sich auf den Verkehr, der in ein Rechenzentrum oder in diesem Fall in eine Azure-Region hinein und aus diesem heraus fließt. Wenn Sie sowohl Netzwerk- als auch Anwendungsregeln für die HTTP/s-Filterung verwenden, werden die Netzwerkregeln vor den Anwendungsregeln auf den Datenfluss angewendet. In diesem Fall wird das folgende NAT-Verhalten erwartet.
Auf dem Clientcomputer führt der Client einen Nslookup für den FQDN cxefirewall.centralus.cloudapp.azure.com und dann einen Invoke-WebRequest für dieselbe Domäne aus, um HTTP-Verkehr über die Firewall zu initiieren. Der Nslookup gibt eine Ziel-IP von 104.43.236.2 zurück, die öffentliche IP, die direkt einer virtuellen Maschine zugeordnet ist, die IIS hostet.
Aus Sicht des Clients zeigt die Paketerfassung die an 104.43.236.2 gerichtete HTTP-Anfrage mit der Quell-IP 10.100.0.4.
Wenn die Azure Firewall den Datenfluss empfängt, wird er mit einer Netzwerkregel abgeglichen und dann an das öffentliche Internet weitergeleitet. Das Protokoll zeigt die ursprüngliche Quell- und Ziel-IP sowie den ursprünglichen Quell- und Zielport.
Auf dem Zielserver zeigt die Paketerfassung, dass sich die Quell-IP zur öffentlichen IP der Azure Firewall geändert hat. Der Quellport wurde ebenfalls geändert, da der Datenfluss durch eine Netzwerkregel gefiltert und dann ins Internet weitergeleitet wurde. In diesem Szenario werden andere Werte beibehalten, wenn Netzwerkregeln für ausgehenden Datenverkehr verwendet werden, die bei der End-to-End-Ablaufverfolgung hilfreich sein können, z. B. die Seq-Nummer und die IP-ID.
FQDN-Filterung (öffentliche und interne Endpunkte)
Azure Firewall kann FQDNs in Netzwerkregeln basierend auf der DNS-Auflösung in der Firewall-Richtlinie verwenden. Diese Funktion ermöglicht es der Firewall, ausgehenden Datenverkehr mit jedem TCP/UDP-Protokoll (einschließlich NTP, SSH, RDP und mehr) zu filtern. Bei Verwendung der FQDN-Filterung in Netzwerkregeln muss der DNS-Proxy aktiviert sein. Wenn die FQDN-Filterung in Netzwerkregeln verwendet wird, führt die Azure Firewall SNAT für den Fluss durch, selbst wenn das Ziel innerhalb des Adressraums von RFC 1918 und RFC 6598 liegt. Nachfolgend finden Sie ein Beispiel dafür, wann die FQDN-Filterung in Netzwerkregeln verwendet wird und die Ziel-IP innerhalb des RFC 1918-Adressraums liegt.
Auf dem Clientcomputer führt der Client einen Nslookup für den FQDN aus.www.cxefirewall.netund dann ein Invoke-WebRequest für dieselbe Domäne, um HTTP-Verkehr über die Firewall zu initiieren. Aus dem Nslookup geht hervor, dass die Ziel-IP 10.200.0.4 ist, eine private IP.
Aus Sicht des Clients zeigt die Paketerfassung die an 10.200.0.4 gerichtete HTTP-Anfrage mit der Quell-IP 10.100.0.4.
Sobald die Azure Firewall diesen Fluss empfängt, wird er mithilfe der FQDN-Filterung durch die Netzwerkregel gefiltert und zum Ziel durchgelassen. Das Protokoll zeigt die ursprüngliche Quell- und Ziel-IP sowie den Quell- und Zielport. Die Protokolle, die generiert werden, wenn die Netzwerkregel einen FQDN anstelle eines definierten IP-Bereichs verwendet, zeigen das Ziel als IP und nicht als FQDN an, der für die Regel konfiguriert ist.
Auf dem Zielserver zeigt die Paketerfassung, dass die Anfrage mit einer Quell-IP von 10.0.0.6 gelandet ist, einer IP, die Teil von istAzureFirewallSubnet. Es zeigt auch, dass der Quellport auch über die Azure Firewall verwaltet wurde. Selbst wenn das Ziel eine private IP ist, wird dieses SNAT-Verhalten erwartet, wenn die FQDN-Filterung in Netzwerkregeln verwendet wird.
Die Azure Firewall kann mithilfe von Anwendungsregeln ausgehenden HTTP/S-Datenverkehr oder Azure SQL-Datenverkehr auf eine angegebene Liste von FQDNs einschließlich Platzhaltern beschränken. Wenn ein Fluss mit einer Anwendungsregel übereinstimmt, führt die Azure Firewall immer SNAT für den Datenverkehr aus, unabhängig davon, was in der Funktion „Private IP-Bereiche“ konfiguriert wurde.
Auf dem Clientcomputer führt der Client einen Nslookup für den FQDN cxefirewall.centralus.cloudapp.azure.com und dann einen Invoke-WebRequest für dieselbe Domäne aus, um HTTP-Verkehr über die Firewall zu initiieren. Der Nslookup gibt eine Ziel-IP von 104.43.236.2 zurück, die öffentliche IP, die direkt einer virtuellen Maschine zugeordnet ist, die IIS hostet.
Aus Sicht des Clients zeigt die Paketerfassung die an 104.43.236.2 gerichtete HTTP-Anfrage mit der Quell-IP 10.100.0.4. Beachten Sie den Quellport 56067 und sogar die Sequenznummern in der Info-Spalte der Paketerfassung, da sich das SNAT-Verhalten durch Anwendungsregeln von Netzwerkregeln unterscheidet.
Sobald die Azure Firewall diesen Fluss empfängt, wird er durch die Anwendungsregel gefiltert und dann an das öffentliche Internet weitergeleitet. Das Protokoll zeigt die ursprüngliche Quell- und Ziel-IP sowie den Quell- und Zielport.
Auf dem Zielserver zeigt die Paketerfassung, dass sich die Quell-IP zur öffentlichen IP der Azure Firewall geändert hat. Der Quellport und die Sequenznummern wurden ebenfalls geändert, da der Fluss durch eine Anwendungsregel gefiltert wurde. Dieses SNAT-Verhalten wird in dieser Konfiguration erwartet.
Wie bereits erwähnt, gibt es viele verschiedene Anwendungsfälle, für die Azure Firewall verwendet werden kann, und verschiedene Möglichkeiten, wie der Netzwerkverkehr durch die Ressource fließen kann. Wenn Sie wissen, welches NAT-Verhalten zu erwarten ist, wenn Datenverkehr über Ihre Azure Firewall fließt, können Sie potenzielle Netzwerkprobleme schnell erkennen und Datenflüsse durchgängig nachverfolgen.
Beachten Sie die Einfachheit der in den Beispielen verwendeten Protokolle und möchten Sie mehr erfahren? Lesen Sie mehr über die strukturierten Protokolle von Azure FirewallHier.
Ressourcen
- Übersicht über Azure Firewall –Was ist Azure Firewall? | Microsoft Learn
- Übersicht über Azure Firewall Manager –Was ist Azure Firewall Manager? | Microsoft Learn
- Azure Firewall-SKUs –Auswahl der richtigen Azure Firewall-SKU für Ihre Anforderungen | Microsoft Learn
- Azure Firewall SNAT-Dokumentation –Private Azure Firewall SNAT-IP-Adressbereiche | Microsoft Learn
- Azure Firewall Policy FQDN-Filterung (Netzwerkregeln) –Azure Firewall Manager-Filterung in Netzwerkregeln | Microsoft Learn
- Strukturierte Azure Firewall-Protokolle –Azure Structured Firewall-Protokolle (Vorschau) | Microsoft Learn
- Azure Firewall-Grenzwerte –Grenzwerte und Kontingente für Azure-Abonnements – Azure Resource Manager | Microsoft Learn