Azure Firewall Teil 2: Workshop
Im Rahmen der Netzwerksicherheit von Azure gibt es zahlreiche Dienste und Features wie Virtuelle Netzwerke, Netzwerksicherheitsgruppen, VNet-Peering, Dienstendpunkte oder die Azure Firewall von denen jede für sich eine Verbesserung des Schutzes deiner Backend-Ressourcen in Azure sowie deiner lokalen Ressourcen darstellt. Auf der Perimeter-Ebene agiert z. B. die Azure Firewall, ein voll verwalteter Plattform-Dienst von Microsoft. Dieser Workshop zeigt ein einfaches Einsatzbeispiel mit einer Azure-VM und einer DNAT- sowie einer Anwendungsregel.
Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!
Folgende beiden Regeln wollen wir implementieren:
- Eine eingehende NAT-Regel, damit die Azure-VM im Workload-VNet (welche dann verständlicherweise keine öffentliche IP-Adresse mehr benötigt) vom On-Premise-Standort per RDP erreicht werden kann und …
- … eine ausgehende FQDN-Regel, die Nutzern der Azure-VM das Internet-Surfen 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 die Azure-Firewall nutzt. In welche Reihenfolge du die einzelnen Einrichtungsschritte vornimmst ist eigentlich egal, d. h. wenn beim Einrichten der Firewall ein VNet fehlt, wird dieses gleich mit eingerichtet. Wir starten trotzdem mit den Netzwerken und legen zwei neue VNets „Workload-VNet“ und „Firewall-VNet“ an.
Netzwerke anlegen
Die jeweiligen Adressbereiche – im Tab „IP-Adressen“ des VNet-Bereitstellung-Assistenten – kannst du frei wählen. Sie dürfen allerdings nicht identisch sein oder sich überschneiden, da du ja beide VNets später via Peering verbinden willst. Grundsätzlich dürfen VNet-Adressbereiche aber schon identisch sein, da es sich um private Cloud-Only-Netze handelt. Wir wählen 10.1.0.0/20 (workload-vnet) und 10.2.0.0/24 (firewall-vnet). Ferner brauchst du je ein Subnetz. Wir verwenden 10.1.0.0/24 (workload-subnet) und 10.2.0.0/26 für das Firewall-Subnetz. Dieses muss allerdings zwingend „AzureFirewallSubet“ heißen und es muss kleiner oder gleich /26 sein.
Windows-VM mit Azure erstellen
Im nächsten Schritt erstelle in Azure eine Windows-VM “workload-vm“ z. B. mit Windows Server 2019 in deinem Workload-Subnet. Wie das in Azure funktioniert sollte bekannt sein. Wähle nur im Schritt 3 des VM-Bereitstellungsassistenten „Netzwerk“ das oben erstellen Workload-VNet und darin das Workload-Subnetz aus und wähle bei „Öffentliche IP“ statt des Standardvorschlags den Eintrag „Keine“. Bei allen weiteren Einstellungen und Tabs („Verwaltung“, „Erweitert“…usw.) kannst du die Standard-Vorgaben übernehmen. Das betrifft auch das Öffnen des RDP-Protokolls in der automatisch angelegten Netzwerksicherheitsgruppe vom Typ „Basic“.
Peering zwischen Workload-VNet und Firewall-VNet
Schließlich musst du eine Peering-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 kannst du 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ört die Sicherheit und Isolation. Klicke also entweder in deinem Workload-VNet oder deinem Firewall-VNet (die „Richtung“ spielt keine Rolle) auf „Peerings“ füge mit „Hinzufügen“ eine neue Peering-Verbindung hinzu: Hier legst du je einen beliebigen Namen für die Peering-Verbindung in der „Hin“-Richtung und der „Rück-Richtung“ fest, belasse alle weiteren Einstellungen auf Default und wähle bei „Virtuelles Netzwerk“ das Ziel-Netzwerk. Wir knüpfen in der Abbildung ein Peering vom Workload-VNet zum Firewall-VNet:
Azure Firewall bereitstellen
Jetzt kannst du die Azure Firewall bereitstellen. Suche dazu im Azure-Portal nach „Firewalls“ (nicht „Firewall Manager“ oder „Firewall Richtlinien“) und klicke auf „Firewall erstellen“. Achte darauf, die Firewall in der Region zu erstellen, in der sich auch deine Netzwerke und VMs befinden.
Als Firewall-Tier wähle „Standard“. Außerdem brauchst du eine erste Firewall-Richtlinie (Firewall policy). Hier kannst du mit „Add new“ eine Neue erstellen und dazu einen beliebigen Namen verwenden. Auch hier ist die richtige Region wichtig. Bei „Wählen Sie ein virtuelles Netzwerk aus“ verwende anstelle von „Neu erstellen“ „Vorhandene verwenden“ und dann dein eben erstelltes Firewall-VNet aus. Schließlich musst du noch bei „Öffentliche IP-Adresse“ mit „Neues Element hinzufügen“ eine neue Public IP hinzufügen. Den Schalter bei „Tunnelerzwingung“ kannst du deaktiviert lassen. Wurde die Firewall mit der vom Bereitstellungsassistenten eingerichteten Default-Policy erstellt, wechsel zunächst zur Übersichtsseite deiner Azure Firewall. Hier siehst du z. B. das gewählte Netzwerk, die private IP-Adresse und den Namen der Firewall-Policy. Die öffentliche IP-Adresse hingegen findest du im Menü „Konfiguration der öffentlichen IP-Adresse“.
Azure Firewall Policies
Folge nun von der Übersichtsseite dem Link zu deiner Firewall-Policy (hier „myfwpol“) oder suche im Azure Portal nach „Firewall-Richtlinien“ und klicke dann auf deren Namen, z. B. bei uns „myfwpol“, denn du hast zwar jetzt einen Firewall-Richtlinie, aber noch keine Regelsammlungen. Um unser oben gestecktes Szenario abzubilden, benötigst du nun je eine DNAT-Regel und eine Anwendungs-Regel.
Beginne mit ersterer und füge mit „Regelsammlung hinzufügen“ eine DNAT-Regel hinzu. Die Regelsammlung bekommt einen Namen (z. B. „dnat-ruleset1“) und mindestens eine Regel.
Unsere RDP-Regel bekommt ebenfalls einen Namen (z. B. „rdp_allow“) einen Quelltyp (z.B. IP-Adresse) eine Quelle (z. B. deine eigene öffentliche IP oder „*“), ein Protokoll (TCP), einen Zielport (3389), einen Zieltyp (IP-Adresse), ein Ziel (öffentliche IP-Adresse der Azure Firewall), eine „Übersetze Adresse“ (private IP-Adresse der Workload-VM) und einen „Übersetzen Port“. Dieser muss natürlich 3389 sein, während du beim Zielport theoretisch freie Wahl hättest, allerdings bei Abweichung deinen RDP-Client entsprechend konfigurieren musst. Die vollständige Regel könnte so aussehen:
Nach dem gleichen Muster erstelle 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“, die Quelle wallweise *, der Adressbereich des Subnets oder die private IP der Workload-VM. Das Protokoll formuliere nach dem Muster „http:80,https:443“. Der Zieltyp ist hier „FQDN“ und das Ziel www.google.com, www.google.de.
Du kannst alle Regelsammlungen anschließend im Menü „Regelsammlungen“ sehen:
Azure Firewall testen
Für eingehende Kommunikation sollte die Azure Firewall so schon funktionieren. Verbindest du dich dazu mit einem RDP-Client (z. B. MSTSC) mit der öffentlichen IP-Adresse der Firewall auf Port 3389 landest du auf deiner Azure-VM.
Zum Testen der FQDN-Regel musst du allerdings zunächst dafür sorgen, dass die Azure-VM für Internet-Konnektivität auch die Azure Firewall nutzen und nicht das Default-Gateway des Workload-VNets.
Routingtabellen im Azure Portal einrichten
Suche dazu im Azure-Portal nach dem Dienst „Routingtabellen“ und erstelle mit einem Klick auf „Routingtabelle erstellen“ eine Neue. Die Routingtabelle braucht nur einen Namen und die passende Region. Das Propagieren von Routen via BGP kannst du deaktivieren.
Nun wechsel „in“ deine Routingtabelle und lege 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 kannst du den CIDR deines Workload-Subnets verwenden), einen „Typ des nächsten Hops“ (hier musst du 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 trage die „private“ IP-Adresse der Azure Firewall ein.
Schließlich musst du noch deine neue Routingstabelle mit dem Workload-VNet und dem Workload-Subnet verbinden. Klicke dazu im Hauptmenü deiner Routingtabelle auf „Subnetze“, dort auf „Zuordnen“ und wähle dein Ziel-Netzwerk samt Subnetz aus.
Verbinde dich nun für den finalen Test mit Hilfe der eingehenden DNAT-Regel per RDP mit deiner Workload-VM, öffne dort einen Browser und prüfe, ob du Google erreichen kannst. Alle anderen Webseiten sollten abgelehnt werden.
Fazit
Die Azure Firewall hat nicht den Funktionsumfang eines Stateful Firewall al 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 kannst du auch ganz normale Netzwerkregeln mit Port und Protokoll oder FQLN anlegen. Darüber hinaus gibt es viele interessante erweiterte Funktionen, wie die eingebaute Bedrohungsanalyse.
Kontakt
„*“ zeigt erforderliche Felder an
powered by Borlabs Cookie