häufig gestellte Fragen Azure Firewall

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.

Eine detaillierte Liste der Azure Firewall Features finden Sie unter Azure Firewall Features.

Azure Firewall können in jedem virtuellen Netzwerk bereitgestellt werden. Es wird jedoch in der Regel in einem zentralen virtuellen Netzwerk in einem Hub-and-Spoke-Modell bereitgestellt, wobei andere virtuelle Netzwerke mit ihm verknüpft sind. Die Standardroute von den virtuellen Peernetzwerken wird so festgelegt, dass sie auf dieses virtuelle Netzwerk der zentralen Firewall verweist. Während das globale virtuelle Netzwerk-Peering unterstützt wird, wird es aufgrund potenzieller Leistungs- und Latenzprobleme in allen Regionen nicht empfohlen. Um eine optimale Leistung zu erzielen, stellen Sie eine Firewall pro Region bereit.

Dieses Modell ermöglicht die zentrale Kontrolle über mehrere Spoke-VNets über verschiedene Abonnements hinweg und bietet Kosteneinsparungen, indem vermieden wird, dass eine Firewall in jedem virtuellen Netzwerk bereitgestellt werden muss. Kosteneinsparungen sollten im Hinblick auf die zugehörigen Peering-Kosten basierend auf Verkehrsmustern bewertet werden.

Azure Firewall können über das Azure Portal, PowerShell, REST-API oder Vorlagen bereitgestellt werden. Schrittweise Anleitungen finden Sie unter Tutorial: Bereitstellen und Konfigurieren von Azure Firewall mithilfe des Azure Portals.

Azure Firewall verwendet Regeln und Regelsammlungen. Eine Regelsammlung ist eine Reihe von Regeln mit der gleichen Reihenfolge und Priorität. Regelsammlungen werden in der Prioritätsreihenfolge ausgeführt. DNAT-Regelsammlungen haben eine höhere Priorität als Netzwerkregelsammlungen, die wiederum eine höhere Priorität haben als Anwendungsregelsammlungen. Alle Regeln können zur Beendigung von Vorgängen führen.

Es gibt drei Arten von Regelsammlungen:

• Anwendungsregeln: Konfigurieren Sie vollqualifizierte Domänennamen (FQDNs), auf die über ein virtuelles Netzwerk zugegriffen werden kann.
• Netzwerkregeln: Konfigurieren sie Regeln mit Quelladressen, Protokollen, Zielports und Zieladressen.
• NAT-Regeln: Konfigurieren Sie DNAT-Regeln, um eingehende Internet- oder Intranetverbindungen (Vorschau) zuzulassen.

Weitere Informationen finden Sie unter Configure Azure Firewall Rules.

Azure Firewall wird in Azure Monitor integriert, um Protokolle anzuzeigen und zu analysieren. Protokolle können mithilfe von Tools wie Log Analytics, Excel oder Power BI an Log Analytics, Azure Storage oder Event Hubs gesendet und analysiert werden. Weitere Informationen finden Sie unter Tutorial: Überwachen Azure Firewall Protokolle.

Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst, der virtuelle Netzwerkressourcen schützt. Es ist eine vollständig zustandsbehaftete Firewall als ein Dienst mit integrierter Hochverfügbarkeit und uneingeschränkter Cloudskalierbarkeit. Es ist mit Drittanbietern für Security-as-a-Service (SECaaS) vorkonfiguriert, um die Sicherheit für virtuelle Netzwerke und Standort-Internetverbindungen zu verbessern. Weitere Informationen finden Sie unter Azure Netzwerksicherheit.

Das Anwendungsgateway WAF bietet zentralisierten eingehenden Schutz für Webanwendungen vor gängigen Exploits und Sicherheitsrisiken. Azure Firewall bietet eingehenden Schutz für Nicht-HTTP/S-Protokolle (z. B. RDP, SSH, FTP), ausgehenden Schutz auf Netzwerkebene für alle Ports und Protokolle sowie Schutz auf Anwendungsebene für ausgehende HTTP/S.

Azure Firewall ergänzt NSGs, um eine bessere Netzwerksicherheit mit einer "Defense-in-Depth"-Strategie zu bieten. NSGs bieten verteilte Netzwerkschicht-Datenverkehrsfilterung, um den Datenverkehr in virtuellen Netzwerken in jedem Abonnement einzuschränken. Azure Firewall bietet zentralen, vollständig zustandsbehafteten Netzwerkschutz und Anwendungsschutz für Abonnements und virtuelle Netzwerke.

Azure Firewall ist ein verwalteter Dienst mit mehreren Schutzebenen, einschließlich Plattformschutz mit NIC-Level-NSGs (nicht sichtbar). NSGs auf Subnetzebene sind im AzureFirewallSubnet nicht erforderlich und werden deaktiviert, um Dienstunterbrechungen zu verhindern.

Private Endpunkte sind eine Komponente von Private Link, einer Technologie, die es ermöglicht, mit Azure PaaS-Diensten mit privaten IP-Adressen anstatt mit öffentlichen zu interagieren. Azure Firewall kann verwendet werden, um den Zugriff auf öffentliche IP-Adressen zu verhindern und dadurch eine Datenexfiltration zu vermeiden, speziell für Azure-Dienste, die nicht Private Link nutzen. Ebenso können Zero-Trust-Richtlinien implementiert werden, indem definiert wird, wer in Ihrer Organisation auf diese Azure PaaS-Dienste zugreifen muss, da Private Link standardmäßig Netzwerkzugriff für Ihr gesamtes Unternehmensnetzwerk ermöglicht.

Der richtige Entwurf für die Überprüfung des Datenverkehrs zu privaten Endpunkten mit Azure Firewall hängt von Ihrer Netzwerkarchitektur ab, weitere Details finden Sie im Artikel Azure Firewall Szenarien zum Überprüfen des Datenverkehrs, der an einen privaten Endpunkt bestimmt ist.

Virtual Network Dienstendpunkte sind eine Alternative zu Private Link, um den Netzwerkzugriff auf Azure PaaS-Dienste zu steuern. Selbst wenn der Client weiterhin öffentliche IP-Adressen für den Zugriff auf den PaaS-Dienst verwendet, wird das Quellsubnetz sichtbar gemacht, sodass der PaaS-Zieldienst Filterregeln implementieren und den Zugriff pro Subnetz einschränken kann. Sie finden einen detaillierten Vergleich zwischen beiden Mechanismen in "Private Endpunkte vergleichen" und "Dienstendpunkte vergleichen".

Azure Firewall Anwendungsregeln können verwendet werden, um sicherzustellen, dass keine Datenexfiltration für nicht autorisierte Dienste stattfindet, und um Zugriffsrichtlinien mit einer erhöhten Granularität außerhalb der Subnetzebene zu implementieren. In der Regel müssen Endpunkte des virtuellen Netzwerks im Subnetz des Clients aktiviert werden, die eine Verbindung mit einem Azure Dienst herstellen. Wenn Sie jedoch Datenverkehr zu Dienstendpunkten mit Azure Firewall prüfen, müssen Sie stattdessen den entsprechenden Dienstendpunkt im Azure Firewall Subnetz aktivieren und im Subnetz des tatsächlichen Clients deaktivieren (in der Regel ein speichen virtuelles Netzwerk). Auf diese Weise können Sie Anwendungsregeln in Azure Firewall verwenden, um zu steuern, auf welche Azure Dienste Ihre Azure Workloads Zugriff haben.

Details zu den Preisen finden Sie unter Azure Firewall Pricing.

Dienstbeschränkungen finden Sie unter Azure Abonnement- und Dienstbeschränkungen, Kontingente und Einschränkungen.

Azure Firewall werden kundendaten nicht außerhalb der Region verschoben oder gespeichert, in der sie bereitgestellt wird.

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

Ja, Azure Firewall unterstützt sowohl eingehende als auch ausgehende Datenverkehrsfilterung. Eingehende Filterung wird in der Regel für Nicht-HTTP-Protokolle wie RDP, SSH und FTP verwendet. Bei eingehendem HTTP- und HTTPS-Datenverkehr sollten Sie eine Webanwendungsfirewall wie Azure Web Application Firewall (WAF) oder die TLS-Offload- und Deep Packet Inspection-Features von Azure Firewall Premium verwenden.

Ja, Azure Firewall Basic unterstützt erzwungenes Tunneln.

Ein TCP-Ping stellt tatsächlich keine Verbindung mit dem Ziel-FQDN her. Azure Firewall blockiert Verbindungen zu einer Ziel-IP-Adresse oder einem FQDN, außer wenn dies explizit durch eine Regel erlaubt ist.

Im Falle eines TCP-Pings reagiert die Firewall selbst auf die TCP-Pinganforderung des Clients, wenn keine Regel den Datenverkehr zulässt. Diese Antwort erreicht nicht die Ziel-IP-Adresse oder den Ziel-FQDN und wird nicht protokolliert. Wenn eine Netzwerkregel explizit den Zugriff auf die Ziel-IP-Adresse oder den FQDN zulässt, erreicht die Pinganforderung den Zielserver, und seine Antwort wird an den Client zurückgeleitet. Dieses Ereignis wird im Protokoll für Netzwerkregeln protokolliert.

Nein, Azure Firewall unterstützt BGP-Peering nicht nativ. Das Feature Autolearn SNAT-Routen verwendet jedoch indirekt BGP über Azure Route Server.

Azure Firewall unterstützt nicht systemeigene ESP (Kapselung der Sicherheitsnutzlast), Sie können jedoch ESP-Datenverkehr zulassen, indem Sie eine Netzwerkregel wie folgt konfigurieren:

Azure Firewall konfiguration (Netzwerkregel):

• Protokoll: Egal welcher
• Quellport: * (Beliebig)
• Zielport: * (Beliebig)
• Quelle/Ziel: Angeben von IP-Adressen nach Bedarf

Mit dieser Konfiguration können ESP-Pakete (IP-Protokollnummer 50) und anderer nicht TCP/UDP-Datenverkehr mit der Regel übereinstimmen. Beachten Sie jedoch, dass Azure Firewall keine ESP-Nutzlasten prüft.

Reference: Wenn NSG (Network Security Group) anstelle von Azure Firewall: NSG bietet keine direkte Option zum Angeben von ESP (IP-Protokollnummer 50), esp-Pakete können jedoch mithilfe der folgenden Einstellungen zulässig sein:

• Protokoll: Egal welcher
• Port: * (beliebig)
• Quelle/Ziel: Angeben von IP-Adressen nach Bedarf

Recommendations:

• Für IPsec-VPN-Konfigurationen wird die Verwendung von Azure VPN Gateway empfohlen.
• Erwägen Sie die Verwendung eines NVA(Network Virtual Appliance)-Musters je nach Ihren Anforderungen.

Sie können Azure PowerShell verwenden, um die Azure Firewall freizugeben und zuzuweisen. Der Prozess variiert je nach Konfiguration.

Für eine Firewall ohne Verwaltungs-NIC:

# Stop the 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

Für eine Firewall mit einer Verwaltungs-NIC:

# Stop the 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"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Für eine Firewall in einem gesicherten virtuellen Hub:

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

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Es wird empfohlen, Verfügbarkeitszonen während der Erstbereitstellung zu konfigurieren. Sie können sie jedoch nach der Bereitstellung neu konfigurieren, wenn:

• Die Firewall wird in einem virtuellen Netzwerk bereitgestellt (wird in gesicherten virtuellen Hubs nicht unterstützt).
• Die Region unterstützt Verfügbarkeitszonen.
• Alle angefügten öffentlichen IP-Adressen werden mit denselben Zonen konfiguriert.

So konfigurieren Sie Verfügbarkeitszonen neu:

1. Heben Sie die Zuweisung der Firewall auf:

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

2. Aktualisieren Sie die Zonenkonfiguration, und weisen Sie die Firewall zu:

   $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"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Ja:

• Die Azure Firewall und das virtuelle Netzwerk müssen sich in derselben Ressourcengruppe befinden.
• Die öffentliche IP-Adresse kann sich in einer anderen Ressourcengruppe befinden.
• Alle Ressourcen (Azure Firewall, virtuelles Netzwerk, öffentliche IP) müssen sich im selben Abonnement befinden.

Ein Fehler beim Bereitstellungsstatus gibt an, dass ein Konfigurationsupdate für eine oder mehrere Back-End-Instanzen fehlgeschlagen ist. Die Azure Firewall bleibt betriebsbereit, die Konfiguration kann jedoch inkonsistent sein. Wiederholen Sie das Update, bis sich der Bereitstellungsstatus in "Erfolgreich" ändert.

Azure Firewall verwendet eine aktiv aktive Konfiguration mit mehreren Back-End-Knoten. Während der geplanten Wartung sorgt der Verbindungsausgleich für ordnungsgemäße Updates. Bei ungeplanten Fehlern ersetzt ein neuer Knoten den fehlgeschlagenen Knoten, und die Konnektivität wird in der Regel innerhalb von 10 Sekunden wiederhergestellt.

Ja, Firewallnamen sind auf 50 Zeichen beschränkt.

Ein /26-Subnetz stellt ausreichende IP-Adressen für die Skalierung sicher, da die Azure Firewall zusätzliche Instanzen virtueller Computer bereit stellt.

Nein, ein /26-Subnetz reicht für alle Skalierungsszenarien aus.

Azure Firewall wird automatisch basierend auf CPU-Auslastung, Durchsatz und Verbindungsanzahl skaliert. Die Durchsatzkapazität reicht von 2,5 bis 3 GBit/s anfangs bis 30 GBit/s (Standard-SKU) oder 100 GBit/s (Premium-SKU).

Ja. Ausführliche Informationen finden Sie unter Azure-Abonnement- und Dienstbeschränkungen, Kontingente und Einschrä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. Azure Firewall TCP-Leerlauftimeout beträgt vier Minuten. Diese Einstellung kann nicht vom Benutzer konfiguriert werden, Sie können jedoch Azure Support kontaktieren, um das Leerlauftimeout für eingehende und ausgehende Verbindungen auf bis zu 15 Minuten zu erhöhen. Das Leerlauftimeout für 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 Beispielen .NET.

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.

Ja. Weitere Informationen finden Sie unter Backup Azure Firewall und Azure Firewall Richtlinie mit Logik-Apps.

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

Ja, Sie können Azure Firewall in einem virtuellen Hubnetzwerk verwenden, um den Datenverkehr zwischen einem virtuellen Netzwerk mit mehreren Speichen zu routen und zu filtern. Subnetze in jedem der virtuellen Speichennetzwerke müssen über einen UDR verfügen, der auf die Azure Firewall als Standardgateway zeigt, damit dieses Szenario ordnungsgemäß funktioniert.

Ja. Das Konfigurieren der UDRs zum Umleiten des Datenverkehrs zwischen Subnetzen im selben virtuellen Netzwerk erfordert jedoch mehr Aufmerksamkeit. Obwohl die Verwendung des virtuellen Netzwerkadressenbereichs als Zielpräfix für udR ausreichend ist, leitet dies auch den gesamten Datenverkehr von einem Computer an einen anderen Computer im selben Subnetz über die Azure Firewall Instanz weiter. Um dies zu vermeiden, schließen Sie eine Route für das Subnetz im UDR mit einem nächsten Hoptyp vom Typ virtuelles Netzwerk 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 führt kein SNAT durch, wenn die Ziel-IP-Adresse gemäß IANA RFC 1918 oder IANA RFC 6598 zu einem privaten IP-Bereich gehört, der für private Netzwerke reserviert ist. Wenn Ihre Organisation einen öffentlichen IP-Adressbereich für private Netzwerke verwendet, führt die Azure-Firewall eine SNAT (Source Network Address Translation) des Datenverkehrs zu einer der privaten IP-Adressen der Firewall im AzureFirewallSubnet durch. Sie können Azure Firewall so konfigurieren, dass kein SNAT für Ihren öffentlichen IP-Adressbereich ausgeführt wird. Weitere Informationen finden Sie unter Azure Firewall SNAT private IP-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.

Erzwungenes Tunneling wird beim Erstellen einer neuen Firewall unterstützt und wird auch für vorhandene Firewalls unterstützt, indem eine Verwaltungs-NIC für erzwungene Tunneling hinzugefügt wird. Weitere Informationen zu neuen Bereitstellungen finden Sie unter Azure Firewall Zwangstunneling. Informationen zu vorhandenen Firewalls finden Sie unter Azure Firewall Management NIC.

Azure Firewall müssen ü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.

• URL – Sternchen funktionieren, wenn sie auf der rechten oder linkssten Seite platziert werden. Wenn es sich auf der linken Seite befindet, kann es nicht Teil des FQDN sein.
• FQDN – Sternchen funktionieren, wenn sie auf der linken Seite platziert werden.
• ALLGEMEIN - Sternchen auf der äußersten linken Seite bedeuten, dass buchstäblich alles links davon übereinstimmt, was bedeutet, dass mehrere Subdomänen und/oder potenziell unerwünschte Variationen von Domainnamen übereinstimmen - siehe die folgenden Beispiele.

Beispiele:

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

Ja, Sie können Azure PowerShell verwenden, um dies zu tun:

# 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 sie zulässt.

TCP-Ping ist ein besonderer Anwendungsfall: Wenn keine Zulassungsregel vorhanden ist, antwortet die Firewall selbst auf die TCP-Ping-Anforderung des Clients, auch wenn der TCP-Ping nicht die IP-Zieladresse/den FQDN erreicht. In diesem Fall wird das Ereignis nicht protokolliert. Wenn eine Netzwerkregel vorhanden ist, die den Zugriff auf die IP-Zieladresse bzw. 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 Azure-Abonnement- und Dienstbeschränkungen, Kontingente und Einschrä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. Azure Firewall TCP-Leerlauftimeout beträgt vier Minuten. Diese Einstellung kann nicht vom Benutzer konfiguriert werden, Sie können jedoch Azure Support kontaktieren, um das Leerlauftimeout für eingehende und ausgehende Verbindungen auf bis zu 15 Minuten zu erhöhen. Das Leerlauftimeout für 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 Beispielen .NET.

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 verschiebt oder speichert keine Kundendaten außerhalb der Region, in der es bereitgestellt ist.

Ja. Weitere Informationen finden Sie unter Backup Azure Firewall und Azure Firewall Richtlinie mit Logik-Apps.

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

Azure Firewall verwendet Azure Virtual Machines, die eine feste Verbindungsgrenze haben. Die Gesamtzahl der aktiven Verbindungen pro virtuellen Computer beträgt 250k.

Das Gesamtlimit pro Firewall ist das VM-Verbindungslimit (250 000) x die Anzahl der VMs im Back-End-Pool der Firewall. Azure Firewall beginnt mit zwei virtuellen Computern und skaliert basierend auf CPU-Auslastung und Durchsatz.

Azure Firewall verwendet derzeit TCP/UDP-Quellports für ausgehenden SNAT-Datenverkehr ohne Leerlaufzeit. Wenn eine TCP/UDP-Verbindung geschlossen wird, wird der verwendete TCP-Port sofort als verfügbar für anstehende Verbindungen angesehen.

Als Problemumgehung für bestimmte Architekturen können Sie NAT-Gateway mit Azure Firewall bereitstellen und skalieren, um einen breiteren Pool von SNAT-Ports für Variabilität und Verfügbarkeit bereitzustellen.

Das spezifische NAT-Verhalten hängt von der Konfiguration der Firewall und der Art von NAT ab, die konfiguriert ist. Die Firewall verfügt beispielsweise über DNAT-Regeln für den eingehenden Datenverkehr und über Netzwerkregeln und Anwendungsregeln für den ausgehenden Datenverkehr durch die Firewall.

Weitere Informationen finden Sie unter Azure Firewall NAT Behaviors.

Für jede geplante Wartung gibt es Verbindungsausgleichslogik zum ordnungsgemäßen Aktualisieren von Back-End-Knoten. Azure Firewall wartet 90 Sekunden, bis vorhandene Verbindungen geschlossen werden. In den ersten 45 Sekunden akzeptiert der Back-End-Knoten keine neuen Verbindungen, und in der verbleibenden Zeit reagiert er mit RST allen eingehenden Paketen. Bei Bedarf können Clients automatisch eine neue Verbindung mit einem anderen Back-End-Knoten herstellen.

Das Herunterfahren einer Azure Firewall VM-Instanz kann während der Skalierung von virtuellen Maschinen (Hochskalieren) oder während eines Software-Upgrades des gesamten Clusters auftreten. 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 Load Balancer TCP Reset and Idle Timeout.

Azure Firewall wird schrittweise skaliert, wenn der durchschnittliche Durchsatz oder die CPU-Auslastung bei 60%liegt oder die Anzahl der Verbindungen bei 80%liegt. Zum Beispiel beginnt der Dienst mit dem Aufskalieren, wenn er 60 % des maximalen Durchsatzes erreicht. Die maximalen Durchsatznummern variieren je nach Azure Firewall SKU und aktivierten Features. Weitere Informationen finden Sie unter Azure Firewall Performance.

Das Aufskalieren dauert zwischen fünf und sieben Minuten. Stellen Sie bei Leistungstests sicher, dass Sie mindestens 10 bis 15 Minuten testen und neue Verbindungen starten, um neu erstellte Azure Firewall Knoten zu nutzen.

Wenn eine Verbindung über ein Leerlauftimeout (vier Minuten ohne Aktivität) verfügt, beendet Azure Firewall die Verbindung ordnungsgemäß, indem ein TCP-RST-Paket gesendet wird.

Azure Dienste werden regelmäßig wartungsrelevante Updates unterzogen, um Funktionen, Zuverlässigkeit, Leistung und Sicherheit zu verbessern. Mit einem konfigurierten Wartungszeitraum werden die Wartung des Gastbetriebssystems und die Dienstwartung innerhalb dieses Zeitfensters ausgeführt. Die vom Kunden kontrollierte Wartung umfasst jedoch keine Hostupdates oder kritische Sicherheitsupdates.

Erweiterte Benachrichtigungen für Azure Firewall Wartung sind nicht verfügbar.

Nein, ein Mindestens fünfstündiges Wartungsfenster ist erforderlich.

Nein, Wartungsfenster werden derzeit so konfiguriert, dass sie täglich wieder auftreten.

Die vom Kunden kontrollierte Wartung unterstützt Gast-OS- und Dienst-Updates, die die wichtigsten Wartungsaspekte für Kunden betreffen. Einige Updates, z. B. Hostupdates, liegen jedoch außerhalb des Umfangs der vom Kunden kontrollierten Wartung. In seltenen Fällen können wir Ihre Kontrolle über das Wartungsfenster außer Kraft setzen, um Sicherheitsprobleme mit hohem Schweregrad zu beheben.

Ja.

Nein. Derzeit kann nur eine Wartungskonfiguration einem Azure Firewall zugeordnet werden.

Alle Azure Firewall SKUs – Basic, Standard und Premium unterstützen vom Kunden kontrollierte Wartung.

Es kann bis zu 24 Stunden dauern, bis die Azure Firewall dem Wartungsplan folgt, nachdem die Wartungsrichtlinie zugeordnet wurde.

Wartungsaktivitäten für Ihre Azure Firewall werden während des Zeitraums vor dem geplanten Wartungsfenster nicht angehalten. Für Tage, die nicht in Ihrem Wartungsplan enthalten sind, werden regelmäßige Wartungsvorgänge wie gewohnt auf der Ressource fortgesetzt.

Weitere Informationen finden Sie unter Konfigurieren der vom Kunden gesteuerten Wartung.