Azure Firewall – Häufig gestellte Fragen

Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst, der Ihre Azure Virtual Network-Ressourcen schützt. Es ist eine vollständig zustandsbehaftete Firewall als ein Dienst mit integrierter Hochverfügbarkeit und uneingeschränkter Cloudskalierbarkeit. Sie können Richtlinien zur Anwendungs- und Netzwerkkonnektivität übergreifend für Abonnements und virtuelle Netzwerke zentral erstellen, erzwingen und protokollieren.

Informationen zu Features von Azure Firewall finden Sie unter Azure Firewall-Features.

Sie können Azure Firewall in einem virtuellen Netzwerk bereitstellen, Kunden stellen Azure Firewall jedoch in der Regel in einem zentralen virtuellen Netzwerk bereit und verbinden andere virtuelle Netzwerke in einem Hub-and-Spoke-Modell damit. Sie können die Standardroute von den verbundenen virtuellen Netzwerken anschließend so festlegen, dass sie auf dieses zentrale virtuelle Firewall-Netzwerk verweist. Globales VNET-Peering wird unterstützt, aber aufgrund von potenziellen Leistungs- und Latenzproblemen in den Regionen nicht empfohlen. Für optimale Leistungen stellen Sie eine Firewall pro Region bereit.

Der Vorteil dieses Modells ist die Möglichkeit, die Kontrolle über mehrere Spoke-VNETs über verschiedene Abonnements hinweg zentral auszuüben. Es ergeben sich zudem Kosteneinsparungen, da Sie nicht in jedem VNet separat eine Firewall bereitstellen müssen. Die Kosteneinsparungen sollten anhand der zugeordneten Peeringkosten auf der Grundlage der Datenverkehrsmuster der Kunden gemessen werden.

Sie können Azure Firewall über das Azure-Portal, PowerShell, die REST-API oder Vorlagen einrichten. Siehe Tutorial: Bereitstellen und Konfigurieren von Azure Firewall über das Azure-Portal.

Azure Firewall unterstützt-Regeln und Regelsammlungen. Eine Regelsammlung ist eine Liste von Regeln mit gleicher Reihenfolge und Priorität. Regelsammlungen werden in der Reihenfolge ihrer Priorität ausgeführt. Netzwerkregelsammlungen haben höhere Priorität als Anwendungsregelsammlungen, und alle Regeln werden beendet.

Es gibt drei Arten von Regelsammlungen:

• Anwendungsregeln: Konfigurieren vollqualifizierter Domänennamen (Fully Qualified Domain Names, FQDNs), auf die von einem Subnetz aus zugegriffen werden kann.
• Netzwerkregeln: Konfigurieren von Regeln mit Quelladressen, Protokollen, Zielports und Zieladressen.
• NAT-Regeln: Konfigurieren von DNAT-Regeln, um eingehende Internetverbindungen zuzulassen.

Azure Firewall unterstützt Filter für eingehenden und ausgehenden Datenverkehr. Der eingehende Schutz wird in der Regel für Nicht-HTTP-Protokolle wie RDP-, SSH- und FTP-Protokolle verwendet. Verwenden Sie für den eingehenden HTTP- und HTTPS-Schutz eine Webanwendungsfirewall wie Azure Web Application Firewall (WAF) oder die TLS-Auslagerungs- und Tiefenpaketüberprüfungsfunktionen von Azure Firewall Premium.

Azure Firewall ist zum Anzeigen und Analysieren von Firewallprotokollen in Azure Monitor integriert. Protokolle können an Log Analytics, Azure Storage oder Event Hubs gesendet werden. Sie können in Log Analytics oder von anderen Tools, wie Excel und Power BI, analysiert werden. Weitere Informationen finden Sie im Tutorial: Überwachen von Azure Firewall-Protokollen.

Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst zum Schutz Ihrer VNet-Ressourcen. Es ist eine vollständig zustandsbehaftete Firewall-as-a-Service mit integrierter Hochverfügbarkeit und uneingeschränkter Cloudskalierbarkeit. Es ist bereits in SECaaS-Anbieter (Security-as-a-Service) von Drittanbietern integriert, um erweiterte Sicherheit für Ihr virtuelles Netzwerk und Ihre Internetverbindungen von Zweigstellen bereitzustellen.

Die Web Application Firewall (WAF) ist ein Feature von Application Gateway, das zentralisierten Schutz des eingehenden Datenverkehrs für Ihre Webanwendungen vor allgemeinen Exploits und Sicherheitsrisiken bietet. Azure Firewall bietet Schutz für eingehenden Datenverkehr für Nicht-HTTP/S-Protokolle (z.B. RDP, SSH, FTP), Schutz auf Netzwerkebene für eingehenden Datenverkehr für alle Ports und Protokolle sowie Schutz auf Anwendungsebene für ausgehenden HTTP/S-Datenverkehr.

Der Azure Firewall-Dienst ergänzt die Funktionen der Netzwerksicherheitsgruppen. Zusammen bieten sie eine bessere „Defense-in-Depth“-Netzwerksicherheit. Netzwerksicherheitsgruppen bieten verteilte Datenverkehrsfilterung auf Netzwerkebene, um den Datenverkehr auf Ressourcen in virtuellen Netzwerken in jedem Abonnement zu beschränken. Azure Firewall ist eine vollständig zustandsbehaftete, zentrale Netzwerkfirewall als Dienst, die Schutz auf Netzwerk- und Anwendungsebene für verschiedene Abonnements und virtuelle Netzwerke bietet.

Azure Firewall ist ein verwalteter Dienst mit mehreren Schutzebenen, z. B. Plattformschutz mit NSGs auf NIC-Ebene (nicht sichtbar). NSGs auf Subnetzebene sind in AzureFirewallSubnet nicht erforderlich und deaktiviert, um zu verhindern, dass es zu Dienstunterbrechungen kommt.

Für den sicheren Zugriff auf PaaS-Dienste werden Dienstendpunkte empfohlen. Sie können Dienstendpunkte im Azure Firewall-Subnetz aktivieren und diese im verbundenen virtuellen Spoke-Netzwerk deaktivieren. Auf diese Weise profitieren Sie von beiden Features: von der Dienstendpunktsicherheit und der zentralen Protokollierung des gesamten Datenverkehrs.

Informationen hierzu finden Sie unter Azure Firewall – Preise.

Sie können Azure PowerShell verwenden, um Methoden zuzuordnen und die Zuordnung dafür aufzuheben (Zuordnen und Zuordnung aufheben). Bei einer Firewall, die für die Tunnelerzwingung konfiguriert ist, muss etwas anders vorgegangen werden.

Beispiel für eine NICHT für die Tunnelerzwingung konfigurierte Firewall:

# Stop an existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet,@($publicip1,$publicip2))

Set-AzFirewall -AzureFirewall $azfw

Bei einer für die Tunnelerzwingung konfigurierten Firewall ist der Prozess zum Anhalten der gleiche. Für den Start muss der Firewall jedoch die öffentliche IP-Adresse für die Verwaltung erneut zugewiesen werden:

# Stop an existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip= Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azfw | Set-AzFirewall

Für eine Firewall in einer Architektur mit einem geschützten virtuellen Hub ist die Vorgehensweise zum Beenden identisch, aber zum Starten muss die ID des virtuellen Hubs verwendet werden:

# Stop and existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$virtualhub = get-azvirtualhub -ResourceGroupName "RG name of vHUB" -name "vHUB name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Azfw RG Name"
$azfw.Allocate($virtualhub.Id)
$azfw | Set-AzFirewall

Wenn Sie Zuordnungen erteilen und aufheben, wird die Firewall-Abrechnung entsprechend gestartet oder pausiert.

Die Einschränkungen des Azure Firewall-Diensts finden Sie unter Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen.

Ja, Sie können Azure Firewall in einem virtuellen Hubnetzwerk verwenden, um den Datenverkehr zwischen zwei virtuellen Spoke-Netzwerken weiterzuleiten und zu filtern. Subnetze in jedem der virtuellen Spoke-Netzwerke müssen über eine UDR verfügen, die auf die Azure Firewall als Standardgateway verweist, damit dieses Szenario ordnungsgemäß funktioniert.

Ja. Die Konfiguration der UDRs zur Umleitung des Datenverkehrs zwischen Subnetzen im gleichen VNET erfordert jedoch zusätzliche Anstrengungen. Während die Verwendung des VNET-Adressbereichs als Zielpräfix für den UDR ausreicht, wird auch der gesamte Datenverkehr von einem Computer zu einem anderen Computer im gleichen Subnetz über die Azure Firewall-Instanz geleitet. Um dies zu vermeiden, fügen Sie eine Route für das Subnetz in den UDR mit dem Typ VNET für den nächsten Hop ein. Das Verwalten dieser Routen kann umständlich und fehleranfällig sein. Die empfohlene Methode für die interne Netzwerksegmentierung ist die Verwendung von Netzwerksicherheitsgruppen, die keine UDRs erfordern.

Azure Firewall bietet kein SNAT, wenn die Ziel-IP-Adresse ein privater IP-Bereich gemäß IANA RFC 1918 ist. Wenn Ihre Organisation einen öffentlichen IP-Adressbereich für private Netzwerke verwendet, leitet Azure Firewall den Datenverkehr per SNAT an eine der privaten IP-Adressen der Firewall in AzureFirewallSubnet weiter. Sie können Azure Firewall so konfigurieren, dass Ihr öffentlicher IP-Adressbereich nicht per SNAT weitergeleitet wird. Weitere Informationen finden Sie unter Azure Firewall SNAT – private Adressbereiche.

Darüber hinaus wird von Anwendungsregeln verarbeiteter Datenverkehr immer durch SNAT übersetzt. Wenn Sie die ursprüngliche Quell-IP-Adresse in Ihren Protokollen für FQDN-Datenverkehr anzeigen möchten, können Sie Netzwerkregeln mit dem Ziel-FQDN verwenden.

Tunnelerzwingung wird beim Erstellen einer neuen Firewall unterstützt. Sie können eine vorhandene Firewall nicht für die Tunnelerzwingung konfigurieren. Weitere Informationen finden Sie unter Azure Firewall-Tunnelerzwingung.

Azure Firewall muss über eine direkte Internetverbindung verfügen. Wenn Ihr Subnetz „AzureFirewallSubnet“ eine Standardroute zu Ihrem lokalen Netzwerk über BGP erfasst, müssen Sie diese mit der benutzerdefinierten Route 0.0.0.0/0 überschreiben. Legen Sie dabei den Wert NextHopType auf Internet fest, um die direkte Internetkonnektivität beizubehalten.

Wenn für Ihre Konfiguration die Erzwingung eines Tunnels zu einem lokalen Netzwerk erforderlich ist und Sie die Ziel-IP-Präfixe für Ihre Internetziele ermitteln können, können Sie diese Bereiche mit dem lokalen Netzwerk als nächsten Hop über eine benutzerdefinierte Route im Subnetz „AzureFirewallSubnet“ konfigurieren. Oder Sie können BGP verwenden, um diese Routen zu definieren.

Ja. Firewall, VNET und die öffentliche IP-Adresse müssen sich in der gleichen Ressourcengruppe befinden.

Nein. Mit NAT-Regeln wird implizit eine entsprechende Netzwerkregel hinzugefügt, um den übersetzten Datenverkehr zuzulassen. Sie können dieses Verhalten außer Kraft setzen, indem Sie explizit eine Netzwerkregelsammlung mit Ablehnungsregeln hinzufügen, die für den übersetzten Datenverkehr geeignet sind. Weitere Informationen zur Logik für die Azure Firewall-Regelverarbeitung finden Sie unter Logik für die Azure Firewall-Regelverarbeitung.

• URL: Sternchen funktionieren, wenn sie ganz rechts oder ganz links platziert werden. Wenn sie sich auf der linken Seite befinden, können sie nicht Teil des FQDN sein.
• FQDN: Sternchen funktionieren, wenn sie ganz links platziert werden.
• ALLGEMEIN: Die Sternchen auf der linken Seite bedeuten, dass buchstäblich alles, was links davon steht, übereinstimmt, d. h. mehrere Subdomänen und/oder potenziell unerwünschte Domänennamenvariationen gelten als übereinstimmend (siehe Beispiele unten).

Beispiele:

Wenn eine Konfigurationsänderung angewendet wird, versucht Azure Firewall alle zugrunde liegenden Back-End-Instanzen zu aktualisieren. In seltenen Fällen kann bei der Aktualisierung einer dieser Back-End-Instanzen mit der neuen Konfiguration ein Fehler auftreten und der Aktualisierungsvorgang mit dem Bereitstellungsstatus „Fehler“ angehalten werden. Azure Firewall ist noch funktionsfähig, die angewendete Konfiguration befindet sich jedoch unter Umständen in einem inkonsistenten Zustand, in dem einige Instanzen die vorherige Konfiguration und andere den aktualisierten Regelsatz verwenden. Versuchen Sie in diesem Fall, die Konfiguration noch einmal zu aktualisieren, bis der Vorgang erfolgreich war und für Ihre Firewall der Bereitstellungsstatus Erfolgreich angezeigt wird.

Azure Firewall besteht aus mehreren Back-End-Knoten in einer aktiv/aktiv-Konfiguration. Für jede geplante Wartung gibt es Verbindungsausgleichslogik zum ordnungsgemäßen Aktualisieren von Knoten. Updates sind für jede Azure-Region außerhalb der Geschäftszeiten geplant, um das Risiko einer Unterbrechung weiter einzuschränken. Bei nicht geplanten Problemen wird ein neuer Knoten instanziiert, um den fehlerhaften Knoten zu ersetzen. Die Konnektivität zum neuen Knoten wird in der Regel innerhalb von 10 Sekunden nach dem Zeitpunkt des Fehlers wieder hergestellt.

Für jede geplante Wartung gibt es Verbindungsausgleichslogik zum ordnungsgemäßen Aktualisieren von Back-End-Knoten. Azure Firewall wartet 90 Sekunden lang darauf, dass bestehende Verbindungen geschlossen werden. Bei Bedarf können Clients automatisch eine neue Verbindung mit einem anderen Back-End-Knoten herstellen.

Ja. Ein Firewallname ist auf 50 Zeichen beschränkt.

Der Azure Firewall-Dienst muss mehr VM-Instanzen bereitstellen, als er skaliert. Ein /26-Adressraum stellt sicher, dass für die Firewall genügend IP-Adressen vorhanden sind, um der Skalierung gerecht zu werden.

Nein. Azure Firewall benötigt kein Subnetz, das größer als /26 ist.

Die anfängliche Durchsatzkapazität von Azure Firewall beträgt 2,5–3 GBit/s, und sie skaliert auf 30 GBit/s für Standard-SKU und 100 GBit/s für Premium-SKU. Das automatische Aufskalieren erfolgt basierend auf der CPU-Auslastung und dem Durchsatz.

Azure Firewall wird schrittweise skaliert, wenn der durchschnittliche Durchsatz oder die CPU-Auslastung 60 % beträgt. Der Dienst beginnt mit dem Aufskalieren, wenn er 60 % des maximalen Durchsatzes erreicht. Die maximalen Durchsatzzahlen variieren je nach Firewall-SKU und aktivierten Features. Weitere Informationen finden Sie unter Azure Firewall-Leistung.

Das Aufskalieren dauert zwischen fünf und sieben Minuten.

Sorgen Sie bei Leistungstests dafür, mindestens 10 bis 15 Minuten zu testen, und richten Sie neue Verbindungen ein, um neu erstellte Firewallknoten nutzen zu können.

Wenn für eine Verbindung ein Leerlauftimeout (vier Minuten lang keine Aktivität) vorliegt, beendet Azure Firewall die Verbindung ordnungsgemäß, indem ein TCP-RST-Paket gesendet wird.

Während des Abskalierens (Herunterskalierens) von VM-Skalierungsgruppen oder bei Flottensoftwareupgrades kann es zum Herunterfahren einer Azure Firewall-VM-Instanz kommen. In diesen Fällen werden neue eingehende Verbindungen per Lastenausgleich zu den verbleibenden Firewallinstanzen und nicht zur heruntergefahrenen Firewallinstanz weitergeleitet. Nach 45 Sekunden beginnt die Firewall, vorhandene Verbindungen durch Senden von TCP-RST-Paketen abzulehnen. Nach weiteren 45 Sekunden wird die Firewall-VM heruntergefahren. Weitere Informationen finden Sie unter TCP-Zurücksetzung und Leerlauftimeout für Load Balancer.

Nein. Standardmäßig blockiert Azure Firewall den Zugriff auf Active Directory. Konfigurieren Sie das Diensttag „AzureActiveDirectory“, um den Zugriff zuzulassen. Weitere Informationen finden Sie unter Azure Firewall-Diensttags.

Ja, Sie können dafür Azure PowerShell verwenden:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Ein TCP-Ping stellt tatsächlich keine Verbindung mit dem Ziel-FQDN her. Azure Firewall lässt keine Verbindung mit einer Ziel-IP-Adresse/einem FQDN zu, es sei denn, es gibt eine explizite Regel, die diese zulässt.

TCP-Ping ist ein besonderer Anwendungsfall: Wenn keine Zulassungsregel vorhanden ist und der TCP-Ping die IP-Zieladresse/den FQDN nicht erreichen kann, wird die TCP-Pinganforderung von der Firewall selbst beantwortet. In diesem Fall wird das Ereignis nicht protokolliert. Wenn eine Netzwerkregel vorhanden ist, die den Zugriff auf die IP-Zieladresse/den FQDN zulässt, erreicht die Pinganforderung den Zielserver, und die Antwort wird an den Client zurückgeleitet. Dieses Ereignis wird im Protokoll für Netzwerkregeln protokolliert.

Ja. Weitere Informationen finden Sie unter Grenzwerte für Azure-Abonnements, -Dienste und -Kontingente sowie allgemeine Beschränkungen.

Nein, das Verschieben einer IP-Gruppe in eine andere Ressourcengruppe wird zurzeit nicht unterstützt.

Das Standardverhalten einer Netzwerkfirewall besteht darin, TCP-Verbindungen aufrechtzuerhalten und sie sofort zu schließen, wenn es keine Aktivität gibt. Das TCP-Leerlauftimeout von Azure Firewall beträgt vier Minuten. Diese Einstellung kann nicht vom Benutzer konfiguriert werden. Sie können sich jedoch an den Azure-Support wenden, um das Leerlauftimeout für eingehende Verbindungen auf bis zu 30 Minuten zu erhöhen. Das Leerlauftimeout für ausgehenden oder Ost-West-Datenverkehr kann nicht geändert werden.

Wenn die Dauer einer Inaktivitätsperiode den Timeoutwert überschreitet, gibt es keine Garantie dafür, dass die TCP- oder HTTP-Sitzung aufrechterhalten wird. Eine gängige Methode zur Aufrechterhaltung von Verbindungen ist TCP-Keep-Alive. Dadurch bleibt die Verbindung länger aktiv. Weitere Informationen finden Sie in den .NET-Beispielen.

Ja, aber Sie müssen die Firewall im Modus „Tunnelerzwingung“ konfigurieren. Diese Konfiguration erstellt eine Verwaltungsschnittstelle mit einer öffentlichen IP-Adresse, die von Azure Firewall für ihre Vorgänge verwendet wird. Diese öffentliche IP-Adresse ist für Verwaltungsdatenverkehr vorgesehen. Sie wird ausschließlich von der Azure-Plattform verwendet und kann nicht für andere Zwecke verwendet werden. Das Tenant Datapath-Netzwerk kann ohne öffentliche IP-Adresse konfiguriert werden, und der Internet-Datenverkehr kann zu einer anderen Firewall getunnelt oder vollständig blockiert werden.

Azure Firewall speichert Kundendaten in der Region, in der sie bereitgestellt werden, und verschiebt sie nicht aus dieser Region.

Ja. Weitere Informationen finden Sie unter Sichern von Azure Firewall und der Azure Firewall-Richtlinie mit Logic Apps.

Nein, derzeit wird Azure Firewall in geschützten virtuellen Hubs (vWAN) in Katar nicht unterstützt.