-->
Guten Tag,
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 Service 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:
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
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
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“
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 Denner
(Originalpost erschienen auf http://it-rumpelkammer.de)