Hallo,

bei größeren Azure Umgebungen sehe ich öfter, dass anstelle NSGs (Network Security Groups) eine 3rd Party NGFW (Next Generation Firewall) eingesetzt wird. Die NGFWs bieten häufig mehr Möglichkeiten Traffic zu filtern, als es eine NSG kann. Ein Problem der NGFWs ist jedoch, dass in der Cloud selten ein Active/Active Cluster zum Einsatz kommen kann, teilweise die Firewallhersteller schlechte Dokumentationen haben oder ihre Produkte gar nicht für die Cloud freigegeeben haben. Zudem ist der Einsatz einer 3rd Party Lösung teuer, da zum einen die VM in Azure bezahlt werden muss, zusätzlich aber auch die Lizenz des Firewall Herstellers, häufig zwei mal, da in der Regel ein Cluster betrieben wird.

Als Alternative dazu bietet Microsoft die Azure Firewall an (https://docs.microsoft.com/en-us/azure/firewall/overview). Die Azure Firewall stellt drei Funktionen zur Verfügung: Layer 3 Filter (Port/IP Filter; „Network Rules“), Layer 7 Filter (URL basiert; „Application Rules“) und NAT Support (DNAT/SNAT; „NAT Rules“). Die Azure Firewall ist dabei von Beginn an hochverfügbar (keine zweite Azure Firewall notwendig) und skaliert mit dem Traffic, es sind also keine manuellen Schritte notwendig sollte mehr Traffic auftreten.

Ein weiterer Vorteil beim Einsatz der Azure Firewall ist, dass von Microsoft sogenannte Servce Tags zur Verfügung gestellt werden (es können auch eigene konfiguriert werden). Die von Microsoft gepflegten Service Tags sind eine Gruppe von IP Adressen für eine bestimmte Technologie (z. B. KeyVault oder SQL). Das ist sehr hilfreich, da man nicht selber in den IP Addresslisten von Microsoft nachschauen muss welche IP Adressen man für welche Ressource freigeben muss, sondern Microsoft pflegt diese Listen selber.

Nachfolgend zeige ich ein einfaches Deployment für eine IaaS Testumgebung damit Ihr mit der Azure Firewall ein wenig spielen könnt.

Szenario:
Eine Workstation, eine VM in Azure, die Kommunikation zwischen Workstation und VM ist durch die Azure Firewall geschützt. Für dieses Beispiel wurde die Azure Disk Encryption aktiviert. Jeder Traffic soll durch die Azure  Firewall laufen, daher müssen zusätzlich noch UDRs (User Defined Routes) definiert werden, damit das Standardrouting von Azure überschrieben wird und der Traffic entsprechend durch die Firewall verarbeitet wird.

Hinweis: das Setup für eine VM, das VNet, das VPN Gateway, KeyVault und aktivieren der Disk Encryption wird hier nicht beschrieben! 

Hinweis: die nachfolgende Installation ist sehr einfach und nur zum Demonstrieren der Funktionalität. Bitte nicht ohne weitere Anpassungen in Produktion verwenden!

Folgende Daten werden im Beispiel verwendet:

• Virtual Network: 172.20.0.0/24
• GatewaySubnet: 172.20.0.0/26
• AzureFirewallSubnet: 172.20.0.64/26
• VMSubnet: 172.20.0.128/26
• VPN Address Pool: 192.168.0.0/24

Deployed wurde bereits:

• eine Resource Group (der Einfachheit halber alles in einer RG)
• VM (OHNE Public IP)
• Virtual Network
• GatewaySubnet
• VMSubnet
• VPN Gateway
• P2S VPN
• KeyVault, KEK
• DiskEncryption aktiviert
• es werden KEINE NSGs verwendet

Los geht’s:

1. Deploy Azure Firewall

• aus dem Azure Katalog die Firewall wählen und die Felder füllen
• ACHTUNG: Azure Firewall und VNet müssen in einer Resource Group sein

2. konfigurieren der ersten Regeln (RDP und KeyVault)

• dazu die Firewall öffnen und die Regeln konfigurieren
• für dieses Beispiel werden die „Network Rules“ benötigt (Layer 3)
• Regel 1: IP Address, „RDP“, TCP, Source: 192.168.0.0/24, Target: 172.20.0.0/24, Ports: 3389
• Regel 2: Service Tag, „KeyVault“, TCP+UDP, Source: 172.20.0.0/24, Service Tags „AzureKeyVault“, Port: *

• damit sind die benötigten Regeln konfiguriert

3. Routen konfigurieren

3.1. UDR für das VMSubnet

• Name: „VMSubnetRouteTable“;
• „Virtual Network gateway route propagation“: DISABLED
• Route1: Target: 0.0.0.0/0, Next Hop: Virtual Appliance, IP: 172.20.0.68 (IP of Firewall)
• Route2: Target: 172.20.0.0/26, Next Hop: Virtual Appliance
• associate with „VMSubnet“

3.2. UDR für das GatewaySubnet

• Name: „VMSubnetRouteTable“
• „Virtual Network gateway route propagation“: DISABLED
• Route1: Target: 172.20.0.128/26, Next Hop: Virtual Appliance, IP: 172.20.0.68 (IP of Firewall)
• Route2: Target: 192.168.0.0/24, Next Hop: Virtual Network Gateway
• associate with „GatewaySubnet“

Nun ist eure VM von eurer Workstation aus per RDP erreichbar.

Viel Spaß beim ausprobieren!

David