Durchgeschleust

von Thomas Drilling

Die Azure-Firewall ist ein cloudnativer, intelligenter Netzwerkfirewall- und Sicherheitsdienst. Dazu gehören ein Bedrohungsschutz, ein Paketfilter und eine Anwendungsfirewall für Cloud-Workloads, vereint in einem plattformbasierten Angebot. Im Detail handelt es sich um eine vollständig zustandsbehaftete Firewall-as-a-Service mit integrierter Hochverfügbarkeit und uneingeschränkter Cloudskalierbarkeit, die sowohl Ost-West- als auch Nord-Süd-Traffic verwaltet. Wir werfen einen Blick auf das Forced Tunneling, das es erlaubt, Nordtraffic vor dem Verlassen des regionalen Azure-Gateways von einer lokalen Firewall inspizieren zu lassen.

Zunächst wenden wir uns der Azure-Firewall selbst zu, ohne Fokus auf die Tunnelerzwingung: Wer die Fähigkeiten des Dienstes im Vergleich zum Preis [1] richtig einordnen möchte, sollte sich vergegenwärtigen, wie infrastrukturbasierte Workloads – in erster Linie virtuelle Maschinen – bei Azure normalerweise mit der Außenwelt kommunizieren.

Virtuelle Maschinen werden bei Azure stets in virtuellen Netzwerken (VNet) bereitgestellt. Jedes VNet verwendet einen frei wählbaren Adressbereich gemäß RFC 1918 und muss über wenigstens ein Subnetz verfügen, in dem jede VM mit der privaten IP-Adresse (aus dem Adressbereich des Subnetzes) ihres virtuellen Netzwerk-Interfaces präsent ist. Sie kann natürlich auch auf mehrere private IP-Adressen, entweder in Form von mehreren IP-Konfigurationen (von denen immer eine primär ist) oder in Form von mehreren Netzwerkinterfaces zurückgreifen. Die virtuelle Maschine braucht das virtuelle Netzwerk, um

- mit anderen virtuellen Maschinen im gleichen Netzwerk,

- mit anderen Azure-Diensten, die im gleichen virtuellen Netzwerk durch einen Service- oder Private-Endpoint präsent sind,

- via VNet-Peering oder IPSEC-VPN mit Azure-VMs in anderen virtuellen Azure-Netzwerken,

- via IPSEC-VPN oder Express Route mit dem lokalen Standort,

- mit anderen Azure-Ressourcen über deren öffentlichen Endpunkt oder

zu kommunizieren. Die ausgehende Internetkommunikation funktionierte (noch bis zum 30. September 2025) ohne weitere Konfiguration out-of-the-box automatisch, auch ohne explizite öffentliche IP. Microsoft nennt dieses implizite NAT-ähnliche Verfahren "Standardzugriff in ausgehender Richtung". Es wurde aber zum genannten Datum eingestellt. Danach müssen Kunden eine explizite ausgehenden Internetkommunikation konfigurieren, zum Beispiel durch Verwendung einer öffentlichen IP-Adresse, eines NAT-Gateways oder SNAT im Zusammenhang mit der Verwendung der Azure-Firewall. Für eingehende Internetkonnektivität braucht die VM in jedem Fall (direkt oder indirekt) eine öffentliche IP-Adresse, die mit zusätzlichen Kosten von zirka 3,50 Euro pro Monat für die Standard-SKU (Stock Keeping Untits; Basic-SKU ist ebenfalls bereits abgekündigt) zu Buche schlägt.

Jedes virtuelle Netzwerk in Azure verfügt standardmäßig über ein für den Kunden (als Dienst) nicht sichtbares Default-Gateway sowie eine Default-Routentabelle. Sie sehen das Gateway zwar nicht als Entität in Azure, aber ein ipconfig im Gastsystem der VM oder ein von außen über den VM-Agenten an die VM herangetragenes PS-Skript offenbart dessen Existenz. Das Gateway agiert im Adressbereich des virtuellen Netzwerks unter der ersten verfügbaren IP-Adresse (nach der Netzwerkadresse), also zum Beispiel 10.0.0.1.

Routing in Azure

Die nicht sichtbare (System)-Routingtabelle enthält passende Routen zum Beispiel zum Default-Gateway (für die Internetkommunikation). Azure erstellt Systemrouten automatisch und weist sie sämtlichen Subnetzen eines virtuellen Netzwerks zu, wobei die Routendefinition jeweils aus einem Adresspräfix und einem Next-Hop-Typ besteht. Letzterer kann zum Beispiel eine Art Alias, beziehungsweise Dienstmarkierung sein.

So ist "Internet" beispielsweise dem Adresspräfix "0.0.0.0/0" zugeordnet. Wenn also das Ziel nicht im Adressbereich des Netzwerks liegt, verläuft die Route über das Default-Gateway. Der Next-Hop-Typ "Virtuelles Netzwerk" steht dagegen für den Adressraum des virtuellen Netzwerks selbst, das heißt Azure erstellt automatisch je eine Route mit einem Adresspräfix, das jeweils dem jeweiligen Adressbereich entspricht, der im Adressraum des virtuellen Netzwerks definiert ist.

Benötigen Sie über die Systemrouten hinausgehende spezielle Routen, wie in unserem Firewallszenario, müssen Sie eigene Routingtabellen erstellen und mit Routen bestücken, weil Sie die Systemrouten weder sehen noch ändern können. Das nennt man dann benutzerdefiniertes Routing (UDR), das in Azure stets eine höhere Priorität genießt, noch vor gelernten Routen (BGP) und den Systemrouten.

Der Next-Hop-Typ ist im weiteren Verlauf noch elementar, denn über diesen muss auch die Azure-Firewall als Next-Hop innerhalb einer benutzerdefinierten Routentabelle festgelegt werden, wenn diese von den Devices (zum Beispiel VMs) im Quellnetzwerk als Gateway genutzt wird. Dies geschieht mithilfe des Next-Hop-Typs "Virtuelles Gerät" (Virtual Appliance), spezifiziert durch die private IP-Adresse der Azure-Firewall.

Allerdings muss eine benutzerdefinierte Routentabelle dem Quellnetzwerk in Azure auch aktiv zugeordnet sein. Ansonsten würde für jeglichen Internetdatenverkehr unverändert das Default-Gateway genutzt und Sie wundern sich möglicherweise, warum Ihre Azure-Firewall gar nicht verwendet wird, beziehungsweise merken es nicht einmal oder allenfalls dann, wenn Ihre Firewallregeln nicht zu greifen scheinen.

Dies lässt sich unter anderem gut nachverfolgen mit dem Azure Network Watcher, entweder mit der Topologie-Visualisierung, der Next-Hop-Analyse, dem Verbindungs-Troubleshooting und oder der VPN-Analyse. Da Dienste wie die Azure-Firewall Kosten verursachen (in der Standard-SKU liegt das Angebot bei zirka 1000 Euro im Monat für die Bereitstellung, zuzüglich Datenübertragung) wird der Dienst üblicherweise im Rahmen einer Hub-and-Spoke-Architektur betrieben, wobei die Spoke-Netzwerke mit dem Hub über eine Peering-Connection verbunden sein und jeweils mit einer benutzerdefinierten Routentabelle ausgestattet sein müssen, um die Azure-Firewall zu erreichen. Das Azure-Architekturzentrum [2] gibt darüber Auskunft.

Paketfilter statt Firewall

Während Routentabelle und Default Gateway für jedes virtuelle Netzwerk in Azure obligatorisch sind, gilt das nicht für Paketfilter, in Azure "Netzwerksicherheitsgruppen" (Network Security Groups) genannt. Zwar wird jede neu erstellte VM in Azure, beziehungsweise deren Netzwerkinterface, mit einem neuen Paketfilter verknüpft, der Benutzer kann die Erstellung eines solchen aber auch umgehen. Paketfilter sind in Azure funktional das, was der Name verspricht und was der Linux-Nutzer unter "Firewall" versteht, nicht aber der Windows-User. Sicherheitsgruppen wirken ausschließlich im OSI-Layer 4, unterstützen daher nur die Protokolle UDP und TCP, (sowie ICMP).

Ansonsten gleichen die Funktionalitäten denen des Linux-Kernels (netfilter beziehungsweise iptables). Das bedeutet, es gibt Eingangs- und Ausgangsregeln mit Stateful Inspection (bei Linux auch Connection Tracking genannt), deren Abarbeitungsreihenfolge durch die Priorität bestimmt wird. Die Regel mit der höchsten Priorität kommt damit zuletzt dran und ist in der Regel eine Deny-Regel. Jede Regel umfasst Angaben zu Port (zum Beispiel 80), Protokoll (TCP oder UDP), Quelle, Ziel und Aktion (Allow oder Deny), wobei Sie Quelle und oder Ziel durch IP-Adressen, IP-Adress-Bereiche oder Service-Tags (Aliase) definieren. Mit den drei stets automatisch angelegten Default-Ein- und Ausgangsregeln kann jede VM mit jeder anderen VM im gleichen Netzwerk kommunizieren. Außerdem akzeptiert der Azure Load Balancer jeden internen Eingangsdatenverkehr und blockiert jeglichen sonstigen Eingangsdatenverkehr.

Die Standard-Ausgangsregeln wirken ähnlich, nur dass Sie ausgehenden Internet-Datenverkehr erlauben. Werden Sicherheitsgruppen im Zuge der VM-Erstellung automatisch erzeugt, verknüpft Azure sie mit dem Netzwerkinterface der spezifischen VM. Legen Sie Netzwerk-sicherheitsgruppen vorab an, können Sie sie einer VM bei der VM-Erstellung zuweisen oder an ein Subnetz hängen. Damit nutzen "alle" VMs im Subnetz den Paketfilter.

Trotzdem sind Paketfilter eben nur Paketfilter und wirken nicht auf Anwendungsebene, wie man es sich eventuell als Windows-Anwender vorstellt, was uns zur Azure-Firewall als Plattform-as-a-Service für Schicht 3 bis 7 führt. Alternativ könnten Sie auch den Azure-Markplatz nach verfügbaren Firewallangeboten durchforsten, was nahezu alle erwähnenswerten Hersteller von Barracuda über Fortigate bis Sophos zu Tage fördert. Viele basieren auf virtuellen Maschinen (IaaS) und verursachen den gleichen Pflege- und Verwaltungsaufwand wie Ihre lokale Firewall. Für Hochverfügbarkeit und Patching sind Sie dann selbst verantwortlich. Es finden sich aber durchaus auch SaaS- und PaaS-Offerings im Marktplatz, einschließlich "Azure-Firewall".

Azure-Firewall bereitstellen

Es gibt die Azure-Firewall wie erwähnt in drei Stock Keeping Units: "Basic", "Standard" und "Premium" [3], wobei Sie für die Tunnelerzwingung mindestens Standard benötigen. Die Bereitstellung an sich ist einfach beziehungsweise weitgehend selbsterklärend. Aufwand macht eher die Planung drumherum, in Bezug auf Virtual-Networking, Hub-and-Spoke (Peering) und UDR. Der erste Punkt ist insofern wichtig, weil die Azure-Firewall als Plattform-as-a-Service ein ganz bestimmtes Subnetz für sich allein benötigt, in dem sie mit ihren IP-Adressen sichtbar ist.

Dieses muss "AzureFirewallSubnet" heißen und in CIDR-Notation mindestens eine Größe von "/26" haben (64 IP-Adressen). Das können Sie aber leicht sicherstellen, wenn Sie beim Erstellen des Subnetzes die Vorlage "Azure Firewall" nutzen. Für das Feature Tunnelerzwingung muss das Firewall-VNet außerdem ein weiteres Subnetz mit dem Namen "AzureFirewallManagementSubnet" enthalten. Auch dafür gibt es bei der Netzwerkerstellung eine passende Vorlage "Firewall Management (forced tunneling)."

Ein paar Begrifflichkeiten sollten noch geklärt sein. Sie finden im Azure-Portal "Firewalls", "Firewall-Manager" und "Firewall-Policies" (alle drei stehen mit der Azure-Firewall im Zusammenhang) sowie die WAF-Richtlinien (Web Application Firewall). Letztere sind das, was der Name sagt und tangieren uns hier nicht. Der Firewallmanager ist ein zentraler Verwaltungshub, wenn Sie mehrere Azure-Firewalls betreiben und ihren Firewallregeln unabhängig von den Firewallinstanzen erstellen, verwalten und bei Bedarf zuweisen möchten. Die Azure-Firewall lässt sich aber auch in einer Art Classic-Mode betreiben, bei dem das Erstellen der Firewallregeln in der Firewall stattfindet.

Mit den passenden Ressourcen vorab erstellt – es fehlen lediglich noch zwei öffentliche IP-Adressen für die Firewall selbst und deren Managementinterface (nur bei Tunnelerzwingung erforderlich), die Sie aber auch on-the-fly direkt beim Erstellen der Firewall anlegen können – ist der Bereitstellungsdialog für die Azure-Firewall im Portal schnell befüllt: Optional stellen Sie die Firewall mithilfe der Azure-PowerShell wie folgt bereit:

Firewallregeln definieren

Der Hauptgrund (neben Forced Tunneling) zum Einsatz der Azure-Firewall – anstelle von Default-Routing mit Default-Gateway, Systemrouten und Netzwerk-sicherheitsgruppen (siehe oben) – ist, dass Sie den ein- und ausgehenden Datenverkehr von Azure zum Internet und/oder zum lokalen Standort (via IPSEC-VPN) präziser und granularer kontrollieren möchten, als nur mithilfe von Paketfiltern im OSI-Layer 4. Die Azure-Firewall unterstützt dazu Regeln für die Anwendungsebene (App Rules), Netzwerkebene (Network Rules) sowie NAT-Regeln für Destination-NAT.

Letztere sind nützlich, um virtuelle Maschinen in einem Azure-VNET (ohne öffentliche IP-Adresse) für Maintenance- oder Managementaufgaben beispielsweise sicher per RDP zu erreichen. Andernfalls bräuchten Sie einen selbst verwalteten Jump-Host oder den - ebenfalls kostenpflichtigen – Azure Bastion Dienst. Bei einer DNAT-Regel verwenden Sie die öffentliche IP-Adresse der Azure-Firewall als Ziel, TCP als Protokoll, 3389 als Ziel-Protokoll sowie die private IP-Adresse der Ziel-VM als übersetztes Ziel, ebenfalls mit 3389 .

Der wichtigste Use-Case für die Azure-Firewall sind Anwendungsregeln für ausgehenden HTTPS-Datenverkehr. Der Clou dabei ist, dass Sie FQDNs (anstelle von IP-Adressen) in Regeln verwenden können. Zudem kennt die Azure-Firewall FQDN-Tags. Darunter versteht Microsoft jeweils eine Gruppe von vollqualifizierten Domänennamen, die bekannten Microsoft-Diensten zugeordnet sind, zum Beispiel um den erforderlichen ausgehenden Netzwerkdatenverkehr über die Firewall zuzulassen, wie zum Beispiel Windows-Updatetraffic.

Außerdem lassen sich bei der Regelerstellung im Zielfeld für Netzwerkregeln Azure-Firewall-Dienst-Tags verwenden, anstelle bestimmter IP-Adressen. Ein Dienst-Tag stellt jeweils eine Gruppe von IP-Adressen dar. Dienst-Tags dienen vorrangig dazu, die Komplexität von Sicherheitsregeln zu verringern. Darüber hinaus enthält die Azure-Firewall eine integrierte Regelsammlung für sogenannte Infrastruktur-FQDNs, die standardmäßig zulässig sind. Diese FQDNs sind plattformspezifisch und lassen sich nicht für andere Zwecke nutzen.

Die in Bild 3 konfigurierte Regel ist ein sehr einfaches Beispiel für eine Art "Surfregel". Sie erlaubt ausgehenden HTTPS-Datenverkehr zu "https://duckduckgo.com" aus dem Workload-Quellnetzwerk 10.2. 0.0/24. Trotzdem kennt die Azure-Firewall auch Netzwerkregeln (Layer 4). Anwendungs- und Netzwerkregeln entfalten dann zum Beispiel in Kombination ihre Wirkung. So können Sie beispielsweise einschränken, dass das Auflösen von "https://duckduckgo.com" nur über benutzerdefinierte DNS-Server erfolgen darf, die Sie vorher bei den zuständigen DNS-Servern des Workload-Netzwerks hinterlegt haben. Die zugehörige Netzwerkregel in der Azure-Firewall wäre dann eine UDP-Regel für Port 53 mit dem Ziel Ihrer benutzerdefinierten DNS-Server, zum Beispiel 8.8.8.8.

Forced Tunneling in Azure

Sie können die Azure-Firewall aber auch so konfigurieren, dass diese den gesamten Internetdatenverkehr zunächst an den festgelegten nächsten Hop, zum Beispiel eine Edge-Firewall am lokalen Standort, weiterleitet, statt direkt ins Internet. Einige Unternehmen verlangen aus Compliancegründen, dass mehrere Netzwerksicherheitsgeräte, wie zum Beispiel Firewalls, ausgehenden Netzwerkdatenverkehr überprüfen, bevor dieser an ein Internetziel geht. Vielleicht schreibt auch Ihre Sicherheitsrichtlinie zwingend vor, dass Sie den gesamten internetgebundenen Datenverkehr zunächst an eine andere Netzwerk-Firewall (Network Virtual Appliance, NVA) in Azure oder direkt an eine lokale Firewall senden und diese ihn überprüft, bevor er das Internet erreicht.

Die Azure-Firewall unterstützt zudem auch so genanntes "geteiltes Tunneln", also die Möglichkeit, den Datenverkehr selektiv weiterzuleiten. Ein Szenario hierfür wäre zum Beispiel die Aktivierung von Windows-Lizenzen über das KMS-System (Key Management Services), bei denen Azure-basierte Windows-VMs eine öffentliche Quell-IP-Adresse benötigen, die Microsoft besitzt, und nicht ihre lokale Internetgateway-IP-Adresse. Sie könnten das mithilfe von benutzerdefinierten Routingtabellen im AzureFirewallSubnet (siehe unten) lösen. Für die genannten Tunnelerzwingungs-Szenarien müssen Sie die Azure-Firewall mit aktivierter Management-NIC ohne öffentliche IP-Adresse bereitstellen. Bei aktivierter Management-NIC erstellt Azure eine separate Management-Netzwerkschnittstelle mit öffentlicher IP-Adresse, die der Azure-Firewall für ihre Verwaltungsvorgänge dient.

Testumgebung aus GitHub aufsetzen

Zum Ausprobieren der Tunnelerzwingung können Sie komfortabel auf ein von Microsoft auf GitHub bereitgestelltes Test-Lab [4] zurückgreifen. Dieses behandelt sowohl die "normale" Tunnelerzwingung als auch das geteilte Tunneln für das skizzierte KMS-Szenario.

Das Lab bedient sich für das Site-to-Site-VPN eines in Azure simulierten lokalen Standorts. Dieser ist mit dem Hub-VNet einer Azure-Firewall per IPSC-Site-to-Site-VPN mithilfe des Azure-VPN-Gateways verbunden. Dazu bedarf es je eines zusätzlichen Subnetzes mit dem Namen "GatewaySubet". Die Firewall am lokalen Standort ist ebenfalls durch eine Azure-Firewall repräsentiert. Sie benötigen also in Summe drei virtuelle Netzwerke: Eines repräsentiert die On-Premises-Seite und enthält ein Gateway-Subnet für das VPN-Gateway, das obligatorische Firewall-Subnet für die Azure-Firewall, die die lokale Firewall darstellt, und ein Workload-Subnet für einen Test-Workload in Form einer Azure-VM.

Auf der Azure-Seite verwendet das Lab eine Hub-and-Spoke-Architektur, in der das Workload-VNet mit dem Hub-Vnet "ge-peert" ist. Letzteres enthält ebenfalls ein GatewaySubnet für das VPN-Gateway, ein AzureFirewallSubnet für die Azure-Firewall und ein weiteres Subnetz "AzureFirewallManagementSubnet" für die Management-NIC.

Außerdem erstellt die Lab-Umgebung die erforderlichen Routingtabellen mit benutzerdefinierten Routen. Das ARM-Template auf GitHub erleichtert das Bereitstellen der benötigten Komponenten extrem. Sie müssen lediglich einen Admin-Benutzernamen nebst Passwort und einen Pre-Shared-Key (PSK) für die IPsec-Verbindung festlegen. Die Bereitstellung dauert etwa 40 Minuten und gibt die abgebildete Umgebung verteilt auf zwei Ressourcengruppen aus: Darin enthält die erste Ressourcengruppe "rg-fw-azure" alle Komponenten der Azure-Umgebung, also das Hub-Netzwerk mit den benötigten Subnetzen, das Spoke-Network mit dem Workers-Subnet und das VPN-Gateway (einschließlich zugehörigem Local Network Gateway). Ebenfalls dazu gehören die Site-to-Site-Connection für das VPN-Gateway, die Azure-Firewall, die Firefall-Richtlinie, drei benutzerdefinierte Routingtabellen "route-spokes-snets", "route-fw-snets" und "platform-managed-rt", die benötigten öffentlichen IP-Adressen, eine Diagnoseeinstellung und einen Log-Analytics Workspace für die Überwachung.

Die zweite Ressourcengruppe "rg-fw-onprem" enthält die "simulierte" On-Premises-Firewall (in Form einer Azure-Firewall), das "simulierte" On-Premises- VPN-Device (in Form eines Azure-VPN-Gateways nebst Local Network Gateway) in den jeweiligen Subnetzen des On-Premises-VNets, eine Site-to-Site-VPN-Verbindung zu Azure (beim Azure-VPN-Gateway ist die "Verbindung" stets eine eigenständige Entität), sowie eine Workload-VM im zugehörigen Subnetz für die On-Premises-Worker. Außerdem gibt es auch hier die benötigten Firewallrichtlinien, sowie ein Diagnotic-Setting.

Das Master-Template verweist übrigens auf vier verlinkte Templates. Das erste Template erstellt in einem Durchgang alle Azure-seitigen Ressourcen, das zweite verlinkte Template erzeugt die komplette (in Azure simulierte) On-Premises-Umgebung, das dritte legt die beiden Azure-VPN-Verbindungsobjekte (VPN Connection) für die IPSEC-Site-2-Site-Richtlinie an und das vierte Template erstellt die Diagnoseeinstellungen für die On-Premises-Firewall, um die benötigten Überwachungsprotokolle an einen Log-Analytics-Workspace in Azure zu streamen. Haben Sie in Ihrem lokalen VS Code die ARM-Extension und den ARM-Template-Viewer installiert, können Sie die Komponenten im Template auch visualisieren.

Sie können auch sämtliche benötigten Objekte Schritt-für-Schritt von Hand im Azure-Portal bereitstellen. Die Vorgehensweise und erforderlichen Parameter für Netzwerkbereiche finden Sie ebenso auf GitHub [5]. Am einfachsten und schnellsten gelingt das Bereitstellen der Testumgebung jedoch direkt aus der Cloudshell mit folgendem PowerShell-Kommando:

Tunnelerzwingung ausprobieren

Nach dem erfolgreichen Bereitstellen testen Sie das Setup. Überprüfen Sie zuerst die Konnektivität von der Azure-VM zur lokalen VM. Damit wissen Sie, ob die grundsätzliche Bereitstellung, das Routing und die Tunnelerzwingung funktionieren. Dabei fließt der Datenverkehr von der in Azure gehosteten VM im Subnetz "snet-trust-workers" des VNets "vnet-spoke-workers" über die Azure-Firewall im Hub. Die wiederum befindet sich über das VPN-Gateway "vgw-vnet-hub-secured" im VNet "vnet-hub-secured".

Der Grund: Hier kommt nur die Standardroute (Systemroute) für IPsec zum Einsatz, die das System über BGP lernt. Der Datenverkehr gelangt dann an die lokale Firewall, von wo er die lokale VM erreicht. Zur Vermeidung asymmetrischen Routings ist der Rückweg zur Azure-VM der Gleiche, sodass das folgende Commandlet Erfolg vermelden sollte:

Dieser Befehl initiiert eine TCP-Verbindung zu Port 3389, der auf Windows-Rechnern standardmäßig geöffnet ist. 10.100.0.68 ist die IP-Adresse unserer "lokalen" VM. Um sich vorab nicht mühselig via RDP auf die VM-Konsole verbinden zu müssen, greifen Sie auf die Möglichkeit der PS-Skript-Ausführung von außen über den VM-Agenten im Azure-Portal unter "Vorgänge" zurück.

Sie möchten natürlich in erster Linie wissen, ob der ausgehende Internetdatenverkehr aus dem Workload-Netz in Azure die lokale Firewall als Internet-Gateway verwendet. Dazu greifen Sie von der Azure-VM auf eine öffentliche IP-Adresse zu. Sie sehen dann in Log Analytics, wie die Anforderung die lokale Firewall aufgrund der erzwungenen Tunnelkonfiguration erreicht. Auch ist erkennbar, dass die Tunnelerzwingung in der gesamten Umgebung für jeglichen Datenverkehr funktioniert, der eine öffentliche IP-Adresse zum Ziel hat. Das bestätigt, dass die in der Azure-Firewall konfigurierten Anwendungsregeln korrekt arbeiten. Diese sehen Sie im Firewallmanager oder direkt in den zugehörigen Policies.

Das erlaubte Ziel in Form des FQDNs "owaspdirect.azurewebsites.net" (eine im Zuge des Deployments als Azure Container Instance bereitgestellte App in Azure) wird von einer Anwendungsregel in der Azure-Firewall zugelassen, wenn die Quelle die IP-Gruppe "ipp-azure-network" ist, dann aber wegen der Tunnel-erwingung über den lokalen Standort geleitet und von der dortigen Firewall verworfen. Um dies zu testen, rufen wir zunächst "owaspdirect.azurewebsites.net" im Browser der VM auf.

Sie erhalten nicht nur einen Fehler im Browser angezeigt, auch in der Protokollanalyse der Azure-Firewall finden Sie die Fehlermeldung "Aktion: Verweigern. Ursache: Es stimmt keine Regel überein. Fahren Sie mit der Standardaktion fort.", weil die Azure-Firewall in der lokalen Umgebung den Datenverkehr verwirft. Das erkennen Sie im konfigurierten Log-Analytics-Arbeitsbereich. Dort finden sich zwei Einträge für diese Anforderung, je eine pro Azure-Firewall. Der zweite Logeintrag zeigt, dass die lokale Firewall die Anforderung abgelehnt hat, was wiederrum bestätigt, dass die Konfiguration den gesamten Internetdatenverkehr zum lokalen Netzwerk zwingt, denn die Azure-Container-Instance hat einen öffentlichen Endpunkt.

Ein Blick auf die Quell-IP-Adresse der "lokalen" Firewall offenbart, dass eine Source-NAT-Regel diese an die private IP-Adresse einer der Azure-Firewall-Instanzen (192.168.0.70) gesendet hat. Dieses Verhalten rührt daher, dass die Firewall den gesamten Datenverkehr mit einer Ziel-IP-Adresse außerhalb der RFC 1918-Bereiche als "NAT'd" einstuft. Sie können übrigens das SNAT-Verhalten der Azure-Firewall ändern, indem Sie in der zugehörigen Richtlinie zur Registerkarte "Private IP-Bereiche (SNAT)" wechseln und eine der verfügbaren Optionen auswählen, um das SNAT-Verhalten der Firewall zu steuern. Derzeit noch in Vorschau ist beispielsweise die Option "Automatisches Lernen von IP-Präfixen".

Ein weiteres unterstütztes Szenario ist der erwähnte geteilte Tunnel. Dies kommt zum Beispiel im oben beschriebenen KMS-Szenario während einer Windows-Aktivierung zum Einsatz, denn zunächst einmal würden Aktivierungen aufgrund des erzwungenen Tunnelns fehlschlagen, weil die Konfiguration den "gesamten" Datenverkehr der zu aktivierenden Azure-VM an das lokale Netzwerk leitet. Die Azure-VM kann dann keine Verbindung mit KMS-Servern zwecks Windows-Aktivierung herstellen. Die "Azure Windows Virtual Machines Troubleshooting Documentation" [6] beschreibt das Szenario genau und erfordert ein benutzerdefiniertes Routing.

Im Lab fügen Sie dazu der an das "AzureFirewallSubnet" angehängten Routingtabelle "route-fw-snet" eine neue Route "send-to-kms" mit dem Ziel 23.102.135.246/32 hinzu mit "Internet" als Next-Hop-Typ. Die IP-Adresse 23.102.135.246 ist eine von drei KMS-Servern, die die Windows-Aktivierungen für Azure-VMs weltweit verarbeiten. Darin müssen Sie den Datenverkehr durch die Azure-Firewall zulassen. Das erledigt die Regel "send-to-kms".

Damit erlauben Sie alle Verbindungen vom Subnetz 192.168.2.0/24 zu KMS-Servern über das Internet. Sie können dies erneut in Ihrer Azure-VM-PowerShell-Sitzung oder über die Remote-Skriptausführung testen. Ziehen Sie dazu wieder die Protokolle Ihrer Azure-Firewall in Log-Analytics heran. Diese bestätigen, dass der Datenverkehr die Firewall durchlaufen hat und die TCP-Anforderung an das Internet zugelassen wurde.

Fazit

Erzwungenes Tunneling ist schon lange eine wichtige Sicherheitsanforderung vieler Unternehmen. Die Notwendigkeit, internetgebundenen Datenverkehr aus Azure-Ressourcen zu überprüfen und zu überwachen, wächst mit der zunehmenden Verbreitung von in Azure betriebener Infrastruktur. Das Konfigurieren der Azure-Firewall derart, dass der gesamte Datenverkehr für zusätzliche Überwachung nachgelagert getunnelt wird, erfüllt die strengen Anforderungen zur Aufrechterhaltung der Compliance für Cloudumgebungen vieler Unternehmen und Branchen. Darüber hinaus ist die Fähigkeit, spezifischen Datenverkehr aufzuteilen, um andere Abhängigkeiten und Anforderungen zu erfüllen, der Schlüssel zur Aufrechterhaltung einer betriebsbereiten und kontrollierten Infrastruktur.

Forced Tunneling in der Azure-Firewall