BlogAzure Firewall Teil 2: Workshop

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.   

Folgende beiden Regeln wollen wir implementieren:

  1. 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 …
  2. … 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.

Zunächst lege in Azure die benötigten virtuellen Netzwerke und Subnetze an

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“.

Eine neue VM in Azure muss in das richtige Netzwerk

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:

Eine Peering-Verbindung ist einfach einzurichten

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.

Das Erstellen der Firewall an sich ist einfach. Der „Aufwand“ steckt später in den Richtlinien

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“.

Die Übersicht der Auzre-Firewall

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.

Einer DNAT-Regel in der Azure Firewall

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.

Eine Anwendungsregel erlaubt ausgehenden http-Traffic zu bestimmten FQDNs

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.

RDP-Verbindung zu einer 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.

Eine neue Routingtabelle in Azure

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.

Das Erstellen einer Route in der Route Table

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.

Das Zuordnen der Routingtabelle

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.

Das Erreichen von www.google.com wird durch die Firewall erlaubt

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.

Schulungen die dich interessieren könnten

Bewertungen

Kundenstimme
Torsten B.
Westdeutscher Rundfunk WDR
star-participantstar-participantstar-participantstar-participantstar-participant
Das Seminar hat nicht nur Spaß gemacht, sondern auch wirklich 'ne Menge gebracht :-)
Kundenstimme
Mausolf B.
Struers GmbH
star-participantstar-participantstar-participantstar-participantstar-participant
Tolle Schulung - kompetenter Trainer, der geduldig auf alle Fragen einging, diese beantworten konnte und darüber hinaus viele neue Anregungen mit auf den Weg gab. Die Schulung hat Spaß gemacht.
Kundenstimme
Markus H.
CARAT Dreieich
star-participantstar-participantstar-participantstar-participantstar-participant
Der Trainer machte einen sehr netten und kompetenten Eindruck und ging auf unsere Wünsche und Anregungen sehr praxisorientiert ein .
Kundenstimme
Wolfgang N.
ThyssenKrupp Nirosta
star-participantstar-participantstar-participantstar-participantstar-participant
Eine gute Adresse für das Erlernen scheinbar schwieriger und trockener Themen, die hier gut aufbereitet werden.