Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
U kunt Azure Firewall configureren met NAT-regels, netwerkregels en toepassingsregels met behulp van klassieke regels of een firewallbeleid. Standaard weigert Azure Firewall al het verkeer totdat u handmatig regels configureert om verkeer toe te staan. De regels zijn eindig, dus regelverwerking stopt bij een overeenkomstige regel.
Regelverwerking met behulp van klassieke regels
De firewall verwerkt regelverzamelingen in volgorde van prioriteit op regeltype, van lagere getallen tot hogere getallen (100 tot 65.000). De naam van een regelverzameling mag alleen letters, cijfers, onderstrepingstekens, punten of afbreekstreepjes bevatten. Deze moet beginnen met een letter of cijfer en eindigen met een letter, cijfer of onderstrepingsteken. De maximale naamlengte is 80 tekens.
Plaats in eerste instantie de prioriteitsnummers van uw regelverzameling in 100 stappen (100, 200, 300, enzovoort), zodat u indien nodig meer regelverzamelingen kunt toevoegen.
Regelverwerking met behulp van firewallbeleid
Met behulp van firewallbeleid ordent u regels in regelverzamelingen en regelverzamelingsgroepen. Regelverzamelingsgroepen bevatten nul of meer regelverzamelingen. Regelverzamelingen zijn van het type NAT, Netwerk of Toepassingen. U kunt meerdere typen regelverzamelingen definiëren binnen één regelgroep. U kunt nul of meer regels definiëren in een regelverzameling. Regels in een regelverzameling moeten van hetzelfde type zijn (NAT, Netwerk of Toepassing).
Het systeem verwerkt regels op basis van de prioriteit van regelcollectiegroepen en regelcollecties. Prioriteit is een getal tussen 100 (hoogste prioriteit) en 65.000 (laagste prioriteit). Het systeem verwerkt groepen van regelverzamelingen met de hoogste prioriteit eerst. Binnen een regelverzamelingsgroep verwerkt het systeem regelverzamelingen met de hoogste prioriteit (laagste getal) eerst.
Als u een firewallbeleid overneemt van een bovenliggend beleid, hebben regelverzamelingsgroepen in het bovenliggende beleid altijd voorrang, ongeacht de prioriteit van een onderliggend beleid.
Notitie
Het systeem verwerkt altijd applicatieregels na netwerkregels en verwerkt netwerkregels na DNAT-regels, ongeacht de regelverzamelingsgroep of regelverzamelingsprioriteit en de overname van beleid.
Samenvatten:
- Het bovenliggende beleid heeft altijd voorrang op het onderliggende beleid.
- Het systeem verwerkt regelverzamelingsgroepen in volgorde van prioriteit.
- Het systeem verwerkt regelverzamelingen in volgorde van prioriteit.
- Het systeem verwerkt DNAT-regels, vervolgens netwerkregels en vervolgens toepassingsregels.
Hier volgt een voorbeeldbeleid met vier regelverzamelingsgroepen. BaseRCG1 en BaseRCG2 zijn overgenomen van een ouderbeleid; ChildRCG1 en ChildRCG2 behoren tot het kindbeleid.
Aanbeveling
Afkortingen die in deze tabellen worden gebruikt: RCG = regelverzamelingsgroep, RC = regelverzameling. Prioriteitsnummers variëren van 100 (hoogste prioriteit) tot 65.000 (laagste prioriteit).
Beleidsstructuur:
| Niveau | Naam | Typologie | Prioriteit | Richtlijnen | Policy |
|---|---|---|---|---|---|
| Groep | BaseRCG1 | Groep Regelverzameling | 200 | 8 | Parent |
| Verzameling | DNATRC1 | DNAT | 600 | 7 | Parent |
| Verzameling | DNATRC3 | DNAT | 610 | 3 | Parent |
| Verzameling | NetworkRC1 | Netwerk | Achthonderd | 1 | Parent |
| Groep | BaseRCG2 | Groep Regelverzameling | 300 | 3 | Parent |
| Verzameling | AppRC2 | Application | 1200 | 2 | Parent |
| Verzameling | NetworkRC2 | Netwerk | 1300 | 1 | Parent |
| Groep | ChildRCG1 | Groep Regelverzameling | 300 | 5 | Kind |
| Verzameling | ChNetRC1 | Netwerk | 700 | 3 | Kind |
| Verzameling | ChAppRC1 | Application | 900 | 2 | Kind |
| Groep | ChildRCG2 | Groep Regelverzameling | 650 | 9 | Kind |
| Verzameling | ChNetRC2 | Netwerk | 1100 | 2 | Kind |
| Verzameling | ChAppRC2 | Application | 2000 | 7 | Kind |
| Verzameling | ChDNATRC3 | DNAT | 3000 | 2 | Kind |
De firewall doorloopt drie keer alle regelverzamelingsgroepen: eenmaal per regeltype in volgorde: DNAT, vervolgens Netwerk en vervolgens Toepassing. Binnen elke pas worden groepen in volgorde van prioriteit verwerkt en vervolgens regelverzamelingen binnen elke groep in volgorde van prioriteit. In de volgende tabel ziet u de volledige verwerkingsvolgorde voor dit voorbeeld:
Verwerkingsvolgorde:
| Stap | Regelverzameling | Typologie | Bovenliggende RCG |
|---|---|---|---|
| 1 | DNATRC1 | DNAT | BaseRCG1 (200) |
| 2 | DNATRC3 | DNAT | BaseRCG1 (200) |
| 3 | ChDNATRC3 | DNAT | ChildRCG2 (650) |
| 4 | NetworkRC1 | Netwerk | BaseRCG1 (200) |
| 5 | NetworkRC2 | Netwerk | BaseRCG2 (300) |
| 6 | ChNetRC1 | Netwerk | ChildRCG1 (300) |
| 7 | ChNetRC2 | Netwerk | ChildRCG2 (650) |
| 8 | AppRC2 | Application | BaseRCG2 (300) |
| 9 | ChAppRC1 | Application | ChildRCG1 (300) |
| 10 | ChAppRC2 | Application | ChildRCG2 (650) |
Zie Azure Firewall Policy-regelsets voor meer informatie over firewallbeleidssets.
Bedreigingsinformatie
Als u filteren op basis van bedreigingsinformatie inschakelt, hebben deze regels de hoogste prioriteit. Azure Firewall verwerkt deze altijd eerst, vóór netwerk- en toepassingsregels. Filteren op basis van bedreigingsinformatie kan verkeer blokkeren voordat Azure Firewall geconfigureerde regels verwerkt. Zie Filteren op basis van bedreigingsinformatie van Azure Firewall voor meer informatie.
Indringingsdetectie- en preventiesysteem (IDPS)
Wanneer u IDPS configureert in de waarschuwingsmodus , werkt de IDPS-engine parallel met de regelverwerkingslogica. Er worden waarschuwingen gegenereerd voor overeenkomende handtekeningen voor zowel binnenkomende als uitgaande stromen. Voor een overeenkomst met een IDPS-handtekening registreert Azure Firewall een waarschuwing in firewalllogboeken. Omdat de IDPS-engine echter parallel werkt met de regelverwerkingsengine, kan verkeer dat toepassings- of netwerkregels toestaan of weigeren nog steeds een andere logboekvermelding genereren.
Wanneer u IDPS configureert in de modus Waarschuwing en Weigeren, functioneert de IDPS-engine inline en wordt deze geactiveerd na de verwerking door de regelengine. Daarom genereren beide engines waarschuwingen en kunnen overeenkomende stromen blokkeren.
De sessieverlies dat de IDPS uitvoert, blokkeert de gegevensstroom stilletjes. Er wordt dus geen RST verzonden op TCP-niveau. Aangezien IDPS altijd verkeer inspecteert nadat de netwerk- of applicatieregel overeenkomt (toestaan of weigeren) en is gemarkeerd in logboeken, kan een ander Drop-bericht worden geregistreerd wanneer IDPS besluit de sessie te weigeren vanwege een overeenkomst met een handtekening.
Wanneer u TLS-inspectie inschakelt, inspecteert Azure Firewall zowel niet-versleuteld als versleuteld verkeer.
Ondersteuning voor impliciet retourverkeer (stateful TCP/UDP)
U kunt firewallregels configureren om verkeer in één richting toe te staan. Azure Firewall kan bijvoorbeeld verbindingen toestaan die u vanuit een on-premises netwerk naar een virtueel Azure-netwerk initieert, terwijl nieuwe verbindingen die u vanuit het virtuele Azure-netwerk naar on-premises start, moeten worden geblokkeerd. Als u dit beleid wilt afdwingen, voegt u een expliciete regel voor weigeren toe voor verkeer van het virtuele Azure-netwerk naar het on-premises netwerk.
Azure Firewall ondersteunt deze configuratie. Azure Firewall is stateful, zodat retourverkeer wordt toegestaan voor een tot stand gebrachte TCP- of UDP-verbinding (bijvoorbeeld de SYN-ACK/ACK-pakketten voor een verbinding die u on-premises hebt gestart), zelfs wanneer er een expliciete regel voor weigeren bestaat in de omgekeerde richting. De expliciete regel voor weigeren blijft nieuwe verbindingen blokkeren die u vanuit het virtuele Azure-netwerk naar on-premises start.
Uitgaande connectiviteit
Netwerkregels en toepassingsregels
Als u netwerkregels en toepassingsregels configureert, past Azure Firewall netwerkregels in prioriteitsvolgorde toe voordat toepassingsregels worden toegepast. De regels worden beëindigd. Dus als Azure Firewall een overeenkomst in een netwerkregel vindt, worden er geen andere regels verwerkt. Als u IDPS configureert, wordt deze door Azure Firewall uitgevoerd op al het doorkruiste verkeer. Wanneer IDPS een handtekeningovereenkomst vindt, kan deze waarschuwingen genereren of verdacht verkeer blokkeren, afhankelijk van de IDPS-modus.
Toepassingsregels evalueren het pakket in volgorde van prioriteit als er geen netwerkregelovereenkomst is en of het protocol HTTP, HTTPS of MSSQL is.
Voor HTTP zoekt Azure Firewall naar een toepassingsregelovereenkomst op basis van de hostheader. Voor HTTPS zoekt Azure Firewall naar een toepassingsregelovereenkomst op basis van alleen SNI.
In zowel HTTP- als TLS-geïnspecteerde HTTPS-gevallen negeert de firewall het doel-IP-adres van het pakket en maakt gebruik van het door DNS omgezette IP-adres uit de Host-header. Als er een poort niet overeenkomt tussen de werkelijke TCP-poort en de poort in de hostheader, wordt het verkeer door de firewall verwijderd. Azure DNS of een aangepaste DNS die u op de firewall configureert, voert DNS-omzetting uit.
Notitie
Azure Firewall vult altijd zowel HTTP- als HTTPS-protocollen (met TLS-inspectie) met de XFF-header (X-Forwarded-For) die is ingesteld op het oorspronkelijke bron-IP-adres.
Wanneer een toepassingsregel TLS-inspectie bevat, verwerkt de engine voor firewallregels SNI, hostheader en ook de URL die overeenkomt met de regel.
Als Azure Firewall geen overeenkomst binnen toepassingsregels vindt, wordt het pakket geëvalueerd op basis van de verzameling infrastructuurregels. Als Azure Firewall nog steeds geen overeenkomst vindt, wordt het pakket standaard geweigerd.
Verzameling infrastructuurregels
Azure Firewall bevat een ingebouwde regelverzameling voor infrastructuur-FQDN’s die standaard zijn toegestaan. Deze FQDN’s zijn specifiek voor het platform en kunnen niet voor andere doeleinden worden gebruikt. De verzameling infrastructuurregels wordt verwerkt na de toepassingsregels en vóór de uiteindelijke alles-weigeren regel.
De ingebouwde verzameling infrastructuurregels bevat de volgende services:
- Rekenkrachttoegang tot opslag Platform Image Repository (PIR)
- Status van toegang tot opslag van beheerde schijven
- Diagnostische gegevens en logboekregistratie van Azure (MDS)
De verzameling infrastructuurregels overschrijven
U kunt de ingebouwde infrastructuurregelverzameling overschrijven door een verzameling van alle toepassingsregels te weigeren die voor het laatst wordt verwerkt. Het wordt altijd verwerkt voordat de infrastructuurregelcollectie plaatsvindt. Alles wat zich niet in de verzameling infrastructuurregels bevindt, wordt standaard geweigerd.
Notitie
U kunt netwerkregels configureren voor TCP, UDP, ICMP of Elk IP-protocol. Alle IP-protocollen omvatten alle IP-protocollen zoals ze zijn gedefinieerd in het document van de Internet Assigned Numbers Authority (IANA) Protocolnummers. Als u expliciet een doelpoort configureert, wordt de regel omgezet in een TCP+UDP-regel. Vóór 9 november 2020 betekende Any TCP, UDP of ICMP. Mogelijk hebt u vóór die datum een regel geconfigureerd met Protocol = Any, en doelpoorten = '*'. Als u geen IP-protocol wilt toestaan zoals momenteel is gedefinieerd, wijzigt u de regel om expliciet de gewenste protocollen (TCP, UDP of ICMP) te configureren.
Binnenkomende connectiviteit
DNAT-regels en netwerkregels
U kunt inkomende internet- of intranetconnectiviteit inschakelen door DNAT (Destination Network Address Translation) te configureren, zoals beschreven in binnenkomend internet- of intranetverkeer filteren met Azure Firewall DNAT met behulp van azure Portal. NAT-regels zijn van toepassing in prioriteit vóór netwerkregels. Als Azure Firewall een overeenkomst vindt, wordt het verkeer omgezet volgens de DNAT-regel en wordt het toegestaan. Het verkeer wordt dus niet onderworpen aan verdere verwerking door andere netwerkregels. Voeg om veiligheidsredenen een specifieke internetbron toe om DNAT-toegang tot het netwerk toe te staan en vermijd het gebruik van jokertekens.
Azure Firewall past geen toepassingsregels toe voor binnenkomende verbindingen. Als u dus inkomend HTTP/S-verkeer wilt filteren, gebruikt u Web Application Firewall (WAF). Zie Wat is Azure Web Application Firewall voor meer informatie.
Voorbeelden
In de volgende voorbeelden ziet u de resultaten van een aantal van deze regelcombinaties.
Voorbeeld 1
De verbinding met google.com is toegestaan omdat een netwerkregel overeenkomt.
Netwerkregel — Actie: Toestaan
| Naam | protocol | Brontype | Bron | Doeltype | Bestemmingsadres | Doelpoorten |
|---|---|---|---|---|---|---|
| Web toestaan | TCP | IP-adres | * | IP-adres | * | 80.443 |
Toepassingsregel - Handeling: Weigeren
| Naam | Brontype | Bron | Protocol:Poort | Doel-FQDNs |
|---|---|---|---|---|
| Weiger-google | IP-adres | * | http:80,https:443 | google.com |
Resultaat
De verbinding met google.com is toegestaan omdat het pakket overeenkomt met de regel voor het toestaan van het webnetwerk . Regelverwerking stopt hier.
Voorbeeld 2
SSH-verkeer wordt geweigerd omdat een netwerkregelverzameling met een hogere prioriteit het verkeer blokkeert door een Deny-regel.
Netwerkregelverzameling 1 — Naam: Allow-verzameling, Prioriteit: 200, Actie: Allow
| Naam | protocol | Brontype | Bron | Doeltype | Bestemmingsadres | Doelpoorten |
|---|---|---|---|---|---|---|
| Allow-SSH | TCP | IP-adres | * | IP-adres | * | 22 |
Netwerkregelverzameling 2 — Naam: Weigeren-verzameling, Prioriteit: 100, Actie: Deny
| Naam | protocol | Brontype | Bron | Doeltype | Bestemmingsadres | Doelpoorten |
|---|---|---|---|---|---|---|
| Deny-SSH | TCP | IP-adres | * | IP-adres | * | 22 |
Resultaat
SSH-verbindingen worden geweigerd omdat een verzameling van netwerkregels met een hogere prioriteit deze blokkeert. De verwerking van regels stopt op dit moment.
Regelwijzigingen
Als u een regel wijzigt om eerder toegestaan verkeer te weigeren, verwijdert Azure Firewall alle relevante bestaande sessies.
Handshakegedrag in drie richtingen
Als stateful service voltooit Azure Firewall een TCP-handshake in drie richtingen voor toegestaan verkeer, van een bron naar de bestemming. Bijvoorbeeld VNet-A naar VNet-B.
Het maken van een regel voor toestaan van VNet-A tot VNet-B betekent niet dat nieuw geïnitieerde verbindingen van VNet-B naar VNet-A zijn toegestaan.
Als gevolg hiervan hoeft u geen expliciete regel voor weigeren te maken van VNet-B naar VNet-A.