Azure Firewall: Regeln für RDP-Zugriff und ausgehenden HTTP-Traffic erstellen

Für 2.) müssen wir mit einer benutzer­definierten Route Table dafür sorgen, dass die VM die System-Route umgeht und stattdessen die Azure-Firewall nutzt. In welche Reihenfolge man die einzelnen Schritte abarbeitet, ist eigentlich egal. Wenn etwa beim Einrichten der Firewall ein VNet fehlt, dann wird dieses gleich erzeugt.

Wir starten trotzdem mit den Netzwerken und legen zwei neue VNets namens workload-vnet und firewall-vnet an.

Netzwerke anlegen

Die jeweiligen Adressbereiche im Tab IP-Adressen des VNet-Assistenten können Sie frei wählen. Sie dürfen allerdings nicht identisch sein oder sich überschneiden, da Sie ja beide VNets später via Peering verbinden wollen. Grundsätzlich dürfen VNet-Adressbereiche aber schon identisch sein, da es sich ja um private Cloud-only-Netze handelt.

Wir wählen 10.1.0.0/20  für workload-vnet und 10.2.0.0/24 für firewall-vnet. Ferner brauchen Sie je ein Subnetz. Wir verwenden 10.1.0.0/24 für workload-subnet und 10.2.0.0/26 für das Firewall-Subnetz. Dieses muss AzureFirewallSubet heißen und kleiner oder gleich /26 sein.

Virtuelle Maschine erstellen

Im nächsten Schritt erstellen wir eine Windows-VM namens workload-vm im Workload-Subnet, in unserem Beispiel mit Windows Server 2019 als Gast-OS. Wie das in Azure grundsätzlich funktioniert, sollte bekannt sein.

Wählen Sie nur im Schritt 3 des VM-Bereit­stellungs­assistenten als Netzwerk das oben erstellte Workload-VNet und darin das Workload-Subnetz aus. Bei Öffentliche IP entscheiden Sie sich nicht für den Standardvorschlag, sondern für den Eintrag Keine.

Bei allen weiteren Einstellungen und Tabs (Verwaltung, Erweitert, usw.) können sie die Vorgaben übernehmen. Das betrifft auch das Öffnen des RDP-Protokolls in der automatisch angelegten Netzwerk­sicherheits­gruppe vom Typ Basic.

Peering

Schließlich müssen Sie eine Verbindung zwischen dem Workload-VNet und dem Firewall-VNet erstellen, damit VMs im Workload-Subnet mit der Azure Firewall über private IP-Adressen und den Azure-Backbone kommunizieren können. Das ist nicht zwingend für die Azure-Firewall, allerdings gehört eine Hub-und-Spoke-Architektur zu den empfohlenen Entwurfsmustern.

Theoretisch könnten Sie auch mit einem VNet und je einem Subnet für Workloads und Firewall arbeiten. Allerdings kostet eine lokale Peering-Verbindung nichts, ist einfach einzurichten und erhöht die Sicherheit und Isolation.

Klicken Sie also entweder in Ihrem Workload-VNet oder Ihrem Firewall-VNet (die Richtung spielt keine Rolle) auf Peerings und fügen eine neue Peering-Verbindung hinzu.

Hier legen Sie je einen beliebigen Namen für die Peering-Verbindung für beide Richtungen fest, belassen alle weiteren Einstellungen auf Default und wählen bei Virtuelles Netzwerk das Ziel­netzwerk.

Firewall bereitstellen

Jetzt können Sie die Azure-Firewall bereitstellen. Suchen Sie dazu im Azure-Portal nach Firewalls (nicht "Firewall Manager" oder "Firewall Richtlinien"!) und klicken auf Firewall erstellen. Achten Sie darauf, die Firewall in der Region zu erstellen, in der sich auch Ihre Netzwerke und VMs befinden.

Als Firewall-Tier wählen Sie Standard. Außerdem brauchen Sie eine erste Firewall-Policy. Hier können Sie mit Add new eine solche erstellen und dazu einen beliebigen Namen verwenden. Auch hier ist die korrekte Region wichtig.

Bei Wählen Sie ein virtuelles Netzwerk aus entscheiden Sie sich für Vorhandene verwenden und dann Ihr eben erstelltes Firewall-VNet. Schließlich müssen Sie noch bei Öffentliche IP-Adresse mit Neues Element hinzufügen eine Public IP hinzufügen. Den Schalter bei Tunnelerzwingung können Sie deaktiviert lassen.

Wurde die Firewall mit der vom Bereitstellungs­assistenten eingerichteten Default-Policy erstellt, dann wechseln Sie zunächst zur Übersichtsseite Ihrer Firewall. Hier sehen Sie das gewählte Netzwerk, die private IP-Adresse und den Namen der Firewall-Policy.

Die öffentliche IP-Adresse hingegen finden Sie im Menü Konfiguration der öffentlichen IP-Adresse.

Firewall-Policies

Folgen Sie nun von der Übersichtsseite dem Link zu Ihrer Firewall-Policy (hier "myfwpol") oder suchen Sie im Azure Portal nach Firewall-Richtlinien und klicken dann auf deren Namen, denn Sie haben zwar jetzt eine Firewall-Richtlinie, aber noch keine Regelsammlungen. Um unser oben gestecktes Szenario abzubilden, benötigen Sie nun je eine DNAT- und eine Anwendungs­regel.

Beginnen Sie mit Regelsammlung hinzufügen, um eine DNAT-Regel zu erzeugen. Die Regel­sammlung bekommt einen Namen (zum Beispiel dnat-ruleset1) und mindestens eine Regel.

Unsere RDP-Regel erhält ebenfalls einen Namen ("rdp_allow") sowie:

• einen Quelltyp (z.B. "IP-Adresse")
• eine Quelle (z. B. Ihre eigene öffentliche IP oder "*")
• ein Protokoll (TCP)
• einen Ziel-Port (3389)
• einen Zieltyp ("IP-Adresse")
• ein Ziel (öffentliche IP-Adresse der Azure-Firewall)
• eine Übersetzte Adresse (private IP-Adresse der Workload-VM)
• einen Übersetzten Port.

Letzterer muss natürlich 3389 sein, während Sie beim Ziel-Port theoretisch freie Wahl hätten, dann aber Ihren RDP-Client entsprechend konfigurieren müssten.

Regelsammlung für ausgehendes HTTP

Nach dem gleichen Muster erstellen Sie nun eine Anwendungs­regel­sammlung. Hier geht es darum, dass die Azure-Firewall ausgehenden HTTP-Datenverkehr anhand von Ziel-FQDNs steuert.

Wir wollen gemäß unserem oben skizzierten Szenario google.com und google.de erlauben. In diesem Fall ist der Quelltyp "IP-Adresse" und die Quelle wahlweise "*", der Adressbereich des Subnets oder die private IP der Workload-VM.

Das Protokoll formulieren Sie nach dem Muster "http:80,https:443". Der Zieltyp ist hier "FQDN" und das Ziel "www.google.com, www.google.de".

Firewall testen

Für die eingehende Kommunikation sollte die Azure Firewall bereits funktionieren. Wenn Sie sich über einen RDP-Client (z. B. MSTSC) mit der öffentlichen IP-Adresse der Firewall auf Port 3389 verbinden, dann landen Sie auf Ihrer Azure-VM.

Vor dem Testen der FQDN-Regel müssen Sie jedoch erst  dafür sorgen, dass die Azure-VM für Internet-Konnektivität nicht das Default Gateway des Workload-VNets nutzt, sondern die Azure Firewall.

Routing-Tabellen einrichten

Suchen Sie dazu im Azure-Portal nach dem Dienst Routingtabellen und erstellen klicken Sie auf Routingtabelle erstellen. Die Routingtabelle braucht nur einen Namen und die passende Region. Das Propagieren von Routen via BGP können Sie deaktivieren.

Nun wechseln Sie in Ihre Routingtabelle und legen im Menü Routen mit Hinzufügen eine neue Route an.

Diese benötigt einen Namen, eine Quelle (IP-Adressen), einen Eintrag bei Quell-IP-Adressen/CIDR-Bereiche (hier können Sie den CIDR Ihres Workload-Subnets verwenden), einen Typ des nächsten Hops (hier müssen Sie den Eintrag Virtuelle Appliance nehmen, auch wenn es sich bei der Azure Firewall um einen PaaS-Dienst handelt) und die Adresse des nächsten Hops. Hier tragen Sie die private IP-Adresse der Azure Firewall ein.

Schließlich müssen Sie noch ihre neue Routingtabelle mit dem Workload-VNet und dem Workload-Subnet verbinden. Klicken Sie dazu im Hauptmenü Ihrer Routingtabelle auf Subnetze, dort auf Zuordnen und wählen Sie Ihre Zielnetzwerke samt Subnetz aus.

Verbinden Sie sich nun für den finalen Test per RDP mit Ihrer Workload-VM, öffnen dort einen Browser und prüfen Sie, ob Sie Google erreichen können. Alle anderen Webseiten sollten abgelehnt werden.

Fazit

Die Azure Firewall hat nicht den Funktionsumfang einer Stateful Firewall à la Sophos oder Fortigate, ist aber einfach einzurichten, erfüllt ihren Zweck, ist relativ preiswert und erfordert keine Wartung.

Wir haben nur anhand zweier einfacher Beispiele das Wirken von DNAT- und Anwendungs-Regeln gezeigt. Natürlich können Sie auch ganz normale Netzwerkregeln mit Port und Protokoll oder FQDN anlegen. Darüber hinaus gibt es viele interessante erweiterte Funktionen, wie die eingebaute Bedrohungs­analyse.