Konfigurieren von Azure Firewall-Regeln

Sie können NAT-Regeln, Netzwerkregeln und Anwendungsregeln in Azure Firewall entweder mithilfe klassischer Regeln oder der Firewallrichtlinie konfigurieren. Azure Firewall verweigert standardmäßig jeglichen Datenverkehr, bis Regeln zum Zulassen von Datenverkehr manuell konfiguriert werden. Die Regeln werden beendet, sodass die Regelverarbeitung bei einer Übereinstimmung beendet wird.

Regelverarbeitung mithilfe klassischer Regeln

Regelsammlungen werden entsprechend dem Regeltyp in Prioritätsreihenfolge verarbeitet – niedrigere Zahlen bis höhere Zahlen von 100 bis 65.000. Der Name einer Regelsammlung darf nur Buchstaben, Ziffern, Unterstriche, Punkte oder Bindestriche enthalten. Er muss mit einem Buchstaben oder einer Zahl beginnen und mit einem Buchstaben, einer Zahl oder einem Unterstrich enden. Die maximale Namenslänge ist 80 Zeichen.

Es empfiehlt sich, die Prioritätsnummern der Regelsammlung zunächst in Inkrementen von 100 (100, 200, 300 usw.) aufzuteilen, damit Sie bei Bedarf Platz zum Hinzufügen weiterer Regelsammlungen haben.

Regelverarbeitung mithilfe der Firewallrichtlinie

Mit der Firewallrichtlinie werden Regeln in Regelsammlungen und Regelsammlungsgruppen organisiert. Regelsammlungsgruppen enthalten null oder mehr Regelsammlungen. Regelsammlungen sind vom Typ NAT, Netzwerk oder Anwendungen. Sie können mehrere Regelsammlungstypen innerhalb einer einzelnen Regelgruppe definieren. Sie können null oder mehr Regeln in einer Regelsammlung definieren. Regeln in einer Regelsammlung müssen denselben Typ (NAT, Netzwerk oder Anwendung) aufweisen.

Regeln werden basierend auf der Priorität der Regelsammlungsgruppe und der Priorität der Regelsammlung verarbeitet. Die Priorität ist eine beliebige Zahl zwischen 100 (höchste Priorität) und 65.000 (niedrigste Priorität). Regelsammlungsgruppen mit der höchsten Priorität werden zuerst verarbeitet. Innerhalb einer Regelsammlungsgruppe werden Regelsammlungen mit der höchsten Priorität (niedrigste Zahl) zuerst verarbeitet.

Wenn eine Firewallrichtlinie von einer übergeordneten Richtlinie geerbt wird, haben Regelsammlungsgruppen in der übergeordneten Richtlinie immer Vorrang und zwar unabhängig von der Priorität einer untergeordneten Richtlinie.

Zusammenfassung:

Die übergeordnete Richtlinie hat immer Vorrang.

1. Regelsammlungsgruppen werden in der Reihenfolge ihrer Priorität verarbeitet.
2. Regelsammlungen werden in der Reihenfolge ihrer Priorität verarbeitet.
3. Es werden DNAT-Regeln, dann Netzwerkregeln, dann Anwendungsregeln verarbeitet.

Nachfolgend ist eine Beispielrichtlinie aufgeführt:

Es gilt die Annahme, dass BaseRCG1 eine Priorität für die Regelsammlungsgruppe (200) ist, die diese Regelsammlungen enthält: DNATRC1, DNATRC3 und NetworkRC1.
BaseRCG2 ist eine Priorität für die Regelsammlungsgruppe (300), die diese Regelsammlungen enthält: AppRC2 und NetworkRC2.
ChildRCG1 ist eine Priorität für die Regelsammlungsgruppe (300), die diese Regelsammlungen enthält: ChNetRC1 und ChAppRC1.
ChildRCG2 ist eine Priorität für die Regelsammlungsgruppe (650), die folgende Regelsammlungen enthält: ChNetRC2, ChAppRC2 und ChDNATRC3.

Gemäß der folgenden Tabelle:

Anfängliche Iteration für DNAT-Regeln:

Der Prozess beginnt mit der Untersuchung der Regelsammlungsgruppe (RCG, Rule Collection Group) mit der niedrigsten Zahl, was BaseRCG1 mit einer Priorität von 200 ist. Innerhalb dieser Gruppe sucht er nach DNAT-Regelsammlungen und bewertet sie nach ihren Prioritäten. In diesem Fall werden DNATRC1 (Priorität 600) und DNATRC3 (Priorität 610) gefunden und entsprechend verarbeitet.
Danach wechselt er zur nächsten Regelsammlungsgruppe BaseRCG2 (Priorität 300), findet aber keine DNAT-Regelsammlung.
Danach fährt er mit ChildRCG1 (Priorität 300) fort, ebenfalls ohne DNAT-Regelsammlung.
Schließlich überprüft er ChildRCG2 (Priorität 650) und findet die ChDNATRC3-Regelsammlung (Priorität 3000).

Iteration für NETWORK-Regeln:

Nach der Rückkehr zu BaseRCG1 wird die Iteration fortgesetzt, diesmal für NETWORK-Regeln. Es wird nur NetworkRC1 (Priorität 800) gefunden.
Anschließend wird mit BaseRCG2 fortgefahren, wo NetworkRC2 (Priorität 1300) sich befindet.
Dann wird mit ChildRCG1 fortgefahren und ChNetRC1 (Priorität 700) als NETWORK-Regel ermittelt.
Schließlich findet er in ChildRCG2 ChNetRC2 (Priorität 1100) als NETWORK-Regelsammlung.

Letzte Iteration für APPLICATION-Regeln:

Nach der Rückkehr zu BaseRCG1 führt der Prozess eine Iteration für APPLICATION-Regeln durch, findet jedoch keine.
In BaseRCG2 identifiziert er AppRC2 (Priorität 1200) als APPLICATION-Regel.
In ChildRCG1 wird ChAppRC1 (Priorität 900) als APPLICATION-Regel gefunden.
Schließlich findet er in ChildRCG2 ChAppRC2 (Priorität 2000) als APPLICATION-Regel.

Zusammenfassend werden die Regeln in der folgenden Reihenfolge verarbeitet: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.

Dieser Vorgang umfasst die Analyse von Regelsammlungsgruppen nach Priorität und innerhalb jeder Gruppe werden die Regeln entsprechend ihren Prioritäten für jeden Regeltyp (DNAT, NETWORK und APPLICATION) sortiert.

Daher werden zunächst alle DNAT-Regeln aus allen Regelsammlungsgruppen verarbeitet, die Regelsammlungsgruppen nach Prioritätsreihenfolge analysiert und die DNAT-Regeln innerhalb jeder Regelsammlungsgruppe nach Priorität sortiert. Anschließend wird derselbe Prozess für NETWORK-Regeln und schließlich für APPLICATION-Regeln verwendet.

Weitere Informationen über Firewall-Richtlinien-Regelsätze finden Sie unter Azure Firewall-Richtlinien-Regelsätze.

Threat Intelligence

Wenn Sie das Threat Intelligence-gestützte Filtern aktivieren, haben diese Regeln die höchste Priorität und werden immer zuerst verarbeitet (vor Netzwerk- und Anwendungsregeln). Threat Intelligence-gestütztes Filtern kann den Datenverkehr ablehnen, bevor konfigurierte Regeln verarbeitet werden. Weitere Informationen finden Sie unter Threat Intelligence-gestütztes Filtern für Azure Firewall.

IDPS

Wenn IDPS im Warnmodus konfiguriert ist, arbeitet die IDPS-Engine parallel zur Regelverarbeitungslogik und generiert Warnungen bei übereinstimmenden Signaturen für eingehende und ausgehende Datenflüsse. Bei einer IDPS-Signaturübereinstimmung wird eine Warnung in den Firewallprotokollen erfasst. Da die IDPS-Engine jedoch parallel zur Regelverarbeitungs-Engine arbeitet, kann Datenverkehr, der durch Anwendungs-/Netzwerkregeln verweigert oder zugelassen wird, dennoch einen weiteren Protokolleintrag generieren.

Wenn IDPS im Warn- und Verweigerungsmodus konfiguriert ist, ist die IDPS-Engine inline und wird nach der Regelverarbeitungs-Engine aktiviert. Daher generieren beide Engines Warnungen und können übereinstimmende Datenflüsse blockieren. 

Sitzungen, die von IDPS verworfen werden, blockieren automatisch den Datenfluss. Daher wird kein RST auf TCP-Ebene gesendet. Da IDPS den Datenverkehr immer überprüft, nachdem die Netzwerk-/Anwendungsregel abgeglichen (Zulassen/Verweigern) und in Protokollen markiert wurde, kann eine weitere Verwerfen-Nachricht protokolliert werden, wenn IDPS entscheidet, die Sitzung aufgrund einer Signaturübereinstimmung zu verweigern.

Wenn die TLS-Überprüfung aktiviert ist, wird sowohl unverschlüsselter als auch verschlüsselter Datenverkehr überprüft. 

Ausgehende Konnektivität

Netzwerkregeln und Anwendungsregeln

Wenn Sie Netzwerkregeln und Anwendungsregeln konfigurieren, werden die Netzwerkregeln in der Prioritätsreihenfolge vor den Anwendungsregeln angewendet. Die Regeln können zur Beendigung von Vorgängen führen. Wenn also eine Übereinstimmung in einer Netzwerkregel gefunden wird, werden keine anderen Regeln mehr verarbeitet. Wenn IDPS konfiguriert ist, wird der gesamte übermittelte Datenverkehr überprüft, und bei einer Signaturübereinstimmung kann IDPS eine Warnung ausgeben und/oder verdächtigen Datenverkehr blockieren.

Wenn sich keine Übereinstimmung für eine Netzwerkregel ergibt und als Protokoll HTTP, HTTPS oder MSSQL verwendet wird, wird das Paket von den Anwendungsregeln in der Reihenfolge ihrer Priorität ausgewertet.

Bei HTTP sucht Azure Firewall anhand des Hostheaders nach einer Übereinstimmung mit einer Anwendungsregel. Bei HTTPS sucht Azure Firewall nur anhand von SNI nach einer Übereinstimmung mit einer Anwendungsregel.

Sowohl bei HTTP als auch bei HTTPS mit TLS-Überprüfung ignoriert die Firewall die Ziel-IP-Adresse des Pakets und verwendet die vom DNS aufgelöste IP-Adresse aus dem Hostheader. Die Firewall erwartet die Portnummer im Hostheader, andernfalls wird der Standardport 80 angenommen. Wenn der tatsächliche TCP-Port nicht mit dem Port im Hostheader übereinstimmt, wird der Datenverkehr verworfen. Die DNS-Auflösung erfolgt durch Azure DNS oder durch ein benutzerdefiniertes DNS, wenn dies in der Firewall konfiguriert ist. 

Wenn eine Anwendungsregel eine TLS-Überprüfung enthält, werden SNI, Hostheader und auch die URL von der Firewallregel-Engine verarbeitet, um der Regel zu entsprechen.

Falls sich innerhalb der Anwendungsregeln immer noch keine Übereinstimmung ergibt, wird das Paket anhand der Regelsammlung der Infrastruktur ausgewertet. Wenn sich auch hierbei keine Übereinstimmung ergibt, wird das Paket standardmäßig abgelehnt.

Eingehende Konnektivität

DNAT-Regeln und Netzwerkregeln

Eingehende Internet- oder Intranetkonnektivität kann aktiviert werden, indem DNAT (Destination Network Address Translation) konfiguriert wird. Die Vorgehensweise wird unter Filtern von eingehendem Internet- oder Intranetdatenverkehr per Azure Firewall-DNAT im Azure-Portal beschrieben. NAT-Regeln werden in der Priorität vor Netzwerkregeln angewendet. Wenn eine Übereinstimmung gefunden wird, wird der Datenverkehr gemäß der DNAT-Regel übersetzt und von der Firewall zugelassen. Der Datenverkehr unterliegt damit keiner weiteren Verarbeitung durch andere Netzwerkregeln. Aus Sicherheitsgründen besteht die empfohlene Vorgehensweise darin, eine bestimmte Internetquelle hinzuzufügen, um DNAT-Zugriff auf das Netzwerk zu gewähren und die Verwendung von Platzhaltern zu vermeiden.

Anwendungsregeln werden nicht für eingehende Verbindungen angewendet. Wenn Sie also eingehenden HTTP/S-Datenverkehr filtern möchten, sollten Sie Web Application Firewall (WAF) verwenden. Weitere Informationen finden Sie unter Was ist die Azure Web Application Firewall?

Beispiele

Die folgenden Beispiele verdeutlichen die Ergebnisse einiger dieser Regelkombinationen.

Beispiel 1

Die Verbindung mit „google.com“ ist aufgrund einer übereinstimmenden Netzwerkregel zulässig.

Netzwerkregel

• Aktion: Allow

Anwendungsregel

• Aktion: Verweigern

Ergebnis

Die Verbindung mit „google.com“ ist zulässig, da das Paket mit der Allow-web-Netzwerkregel übereinstimmt. An dieser Stelle wird die Regelverarbeitung angehalten.

Beispiel 2

Der SSH-Datenverkehr wird abgelehnt, da er durch eine Deny-Netzwerkregelsammlung mit höherer Priorität blockiert wird.

Netzwerkregelsammlung 1

• Name: Allow-collection
• Priorität: 200
• Aktion: Zulassen

Netzwerkregelsammlung 2

• Name: Deny-collection
• Priorität: 100
• Aktion: Deny

Ergebnis

SSH-Verbindungen werden abgelehnt, da sie durch eine Netzwerkregelsammlung mit höherer Priorität blockiert werden. An dieser Stelle wird die Regelverarbeitung angehalten.

Regeländerungen

Wenn Sie eine Regel ändern, um zuvor zugelassenen Datenverkehr abzulehnen, werden alle relevanten vorhandenen Sitzungen verworfen.

Dreiwegehandshake-Verhalten

Als zustandsbehafteter Dienst führt Azure Firewall einen TCP-Dreiwegehandshake für zulässigen Datenverkehr von einer Quelle zum Ziel durch. Beispiel: VNet-A zu VNet-B.

Das Erstellen einer Zulassungsregel von VNet-A zu VNet-B bedeutet nicht, dass neue initiierte Verbindungen von VNet-B zu VNet-A zugelassen werden.

Daher ist es nicht erforderlich, eine explizite Ablehnungsregel von VNet-B zu VNet-A zu erstellen.

Nächste Schritte

• Erfahren Sie mehr über Azure Firewall NAT-Verhalten.
• Erfahren Sie, wie Sie eine Azure Firewall bereitstellen und konfigurieren.
• Weitere Informationen zur Azure-Netzwerksicherheit