Die Azure Firewall ist ein voll verwalteter Plattform-Dienst von Microsoft, welcher auf der Perimeter-Ebene agiert. Dieser Beitrag zeigt einfache Einsatzbeispiele mit einer Azure-VM, die per RDP von außen erreicht werden soll und die über eine Anwendungsregel einen eingeschränkten Zugang zum Internet erhalten soll.
Folgende beiden Regeln wollen wir implementieren:
- Eine eingehende NAT-Regel, damit die Azure-VM im Workload-VNet (welche dann keine öffentliche IP-Adresse mehr benötigt) vom On-Premise-Standort per RDP erreicht werden kann
- Eine ausgehende FQDN-Regel, die Nutzern der Azure-VM den Zugriff auf das Internet erlaubt, aber nur für www.google.com und www.google.de
Für 2.) müssen wir mit einer benutzerdefinierten 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-Bereitstellungsassistenten 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 Netzwerksicherheitsgruppe 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 Zielnetzwerk.
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 Bereitstellungsassistenten 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-Richtlinien erstellen
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 Anwendungsregel.
Beginnen Sie mit Regelsammlung hinzufügen, um eine DNAT-Regel zu erzeugen. Die Regelsammlung 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 Anwendungsregelsammlung. 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.