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


    Tags: , ,

    Azure FirewallDie Azure Firewall ist ein voll verwalteter Plattform-Dienst von Microsoft, welcher auf der Perimeter-Ebene agiert. Dieser Beitrag zeigt einfache Einsatz­bei­spiele mit einer Azure-VM, die per RDP von außen erreicht werden soll und die über eine Anwen­dungs­regel einen eingeschränkten Zugang zum Internet erhalten soll.

    Folgende beiden Regeln wollen wir implementieren:

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

    Virtuelles Netzwerk im Azure-Portal anlegen

    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.

    Ergänzend zum VNet benötigt man noch ein Subnetz, in diesem Fall AzureFirewallSubnet.

    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.

    Eine neue VM in Azure muss mit dem richtigen Netzwerk verbunden werden.

    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.

    Knüpfen eines Peerings vom Workload-VNet zum Firewall-VNet

    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.

    Das Erstellen der Firewall an sich ist einfach. Der größere Aufwand steckt später in den Richtlinien.

    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.

    Übersicht über die Eigenschaften und Einstellungen der Azure-Firewall

    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.

    Eine DNAT-Regel in der Azure Firewall konfigurieren

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

    Diese Anwendungsregel erlaubt ausgehenden http-Traffic zu bestimmten FQDNs.

    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.

    Erfolgreiche RDP-Verbindung zur 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.

    Eine neue Routingtabelle in Azure anlegen.

    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.

    Das Erstellen einer Route in der Route Table

    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.

    Routingtabelle zu den Netzwerken zuordnen

    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.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet seit mehr als 20 Jahren selb­ständig als Redakteur und Autor für viele ehe­malige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buch­autor und IT-Consultant.

    Seit 5 Jahren ist Thomas neben seiner journa­listischen Tätig­keit haupt­beruflicher, selb­ständiger IT-Trainer für VMware und Microsoft.

    Seine Themen­schwer­punkte sind Virtua­lisierung und Cloud Com­puting, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zerti­fi­zierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas ist außerdem zertifi­zierter AWS Solu­tions Archi­tect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Admini­strator.

    Thomas führt aktuell jeden zwei­ten Mon­tag einen 4-tägigen Grund­lagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Infor­mationen und Anmel­dung über sein AWS-Blog.

    Ähnliche Beiträge

    Weitere Links

    1 Kommentar

    Schade, eigentlich für mich ein sehr interessantes Thema. Aber warum werden Begriffe wie "Workload-VNet" verwendet, auf die selbst Google und Microsoft sich mit der Erklärung schwer tun und den Nutzen des Textes bis zur Unverständlichkeit verstümmeln?
    Stellen Sie doch für die ganz Doofen wie mich bitte an den Anfang des Artikels einen Fremdwort-Index. Das würde mir sehr helfen.
    Vielen Dank für Ihre Mühe.