Regels voor Azure Firewall configureren

U kunt NAT-regels, netwerkregels en toepassingsregels configureren op Azure Firewall klassieke regels of firewallbeleid. Azure Firewall wordt al het verkeer standaard toegestaan, totdat de regels handmatig zijn geconfigureerd om verkeer toe te staan.

Regelverwerking met klassieke regels

Regelverzamelingen worden verwerkt op basis van het regeltype in volgorde van prioriteit, lagere getallen tot hogere getallen van 100 tot 65.000. De naam van een regelverzameling mag alleen letters, cijfers, onderstrepingstekens, punten of afbreekstreepingstekens hebben. Het moet beginnen met een letter of cijfer en eindigen met een letter, cijfer of onderstrepingsteken. De maximale naamlengte is 80 tekens.

Het is het beste om de prioriteitsnummers van uw regelverzameling in eerste instantie in te delen in 100 stappen (100, 200, 300, e.d.), zodat u zo nodig meer regelverzamelingen kunt toevoegen.

Regelverwerking met behulp van firewallbeleid

Met firewallbeleid zijn regels ingedeeld in regelverzamelingen en regelverzamelingsgroepen. Regelverzamelingsgroepen bevatten nul of meer regelverzamelingen. Regelverzamelingen zijn het type NAT, Network of Applications. U kunt meerdere regelverzamelingstypen binnen één regelgroep definiëren. U kunt nul of meer regels definiëren in een regelverzameling. Regels in een regelverzameling moeten van hetzelfde type zijn (NAT, netwerk of toepassing).

Regels worden verwerkt op basis van regel verzameling groep prioriteit en regel verzameling prioriteit. Prioriteit is een getal tussen 100 (hoogste prioriteit) en 65.000 (laagste prioriteit). Regelverzamelingsgroepen met de hoogste prioriteit worden het eerst verwerkt. Binnen een regelverzamelingsgroep worden regelverzamelingen met de hoogste prioriteit (laagste aantal) eerst verwerkt.

Als een firewallbeleid wordt overgenomen van een bovenliggend beleid, hebben regelverzamelingsgroepen in het bovenliggende beleid altijd voorrang, ongeacht de prioriteit van een onderliggend beleid.

Notitie

Toepassingsregels worden altijd verwerkt na netwerkregels, die worden verwerkt na DNAT-regels, ongeacht de regelverzamelingsgroep of regelverzamelingsprioriteit en beleidsin overname.

Hier is een voorbeeldbeleid:

Naam Type Prioriteit Regels Overgenomen van
BaseRCG1 Regelverzamelingsgroep 200 8 Bovenliggend beleid
DNATRc1 DNAT-regelverzameling 600 7 Bovenliggend beleid
NetworkRc1 Verzameling netwerkregel 800 1 Bovenliggend beleid
BaseRCG2 Regelverzamelingsgroep 300 3 Bovenliggend beleid
AppRCG2 Verzameling toepassingsregel 1200 2 Bovenliggend beleid
NetworkRC2 Verzameling netwerkregel 1300 1 Bovenliggend beleid
ChildRCG1 Regelverzamelingsgroep 300 5 -
ChAppRC1 Verzameling toepassingsregel 700 3 -
ChNetRC1 Verzameling netwerkregel 900 2 -
ChildRCG2 Regelverzamelingsgroep 650 9 -
ChNetRC2 Verzameling netwerkregel 1100 2 -
ChAppRC2 Verzameling toepassingsregel 2000 7 -
ChDNATRC3 DNAT-regelverzameling 3000 2 -

De verwerking van de regel wordt in de volgende volgorde: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.

Zie voor meer informatie over regelsets voor firewallbeleid Azure Firewall Beleidsregelsets.

Bedreigingsinformatie

Als u filteren op basis van bedreigingsinformatie inschakelen, hebben deze regels de hoogste prioriteit en worden ze altijd eerst verwerkt (vóór netwerk- en toepassingsregels). Filteren op bedreigingsinformatie kan verkeer weigeren voordat geconfigureerde regels worden verwerkt. Zie filteren op basis Azure Firewall bedreigingsinformatie voor meer informatie.

ONTHEEMDEN

Wanneer IDPS is geconfigureerd in de waarschuwingsmodus, werkt de IDPS-engine parallel aan de verwerkingslogica van de regel en worden waarschuwingen gegenereerd voor overeenkomende handtekeningen voor zowel binnenkomende als uitgaande stromen.Voor een overeenkomst met de IDPS-handtekening wordt een waarschuwing vastgelegd in firewalllogboeken. Omdat de ENGINE IDPS echter parallel met de engine voor regelverwerking werkt, kan verkeer dat wordt geweigerd/toegestaan door toepassings-/netwerkregels nog steeds een andere logboekinvoer genereren.

Wanneer IDPS is geconfigureerd in de modus Waarschuwingen en Weigeren, wordt de ENGINE IDPS inline en geactiveerd na de engine voor het verwerken   van regels. Beide engines genereren dus waarschuwingen en kunnen overeenkomende stromen blokkeren. 

Sessiedalingen die worden uitgevoerd door IDPS, blokkeert de stroom op de stille kracht. Er wordt dus geen RST verzonden op TCP-niveau.Omdat IDPS verkeer inspecteert altijd nadat de netwerk-/toepassingsregel is gematcht (toestaan/weigeren) en is gemarkeerd in logboeken, kan er een ander dropbericht worden geregistreerd waarin IDPS besluit de sessie te weigeren vanwege een overeenkomst met een handtekening.

Wanneer TLS-inspectie is ingeschakeld, wordt zowel niet-versleuteld als versleuteld verkeer geïnspecteerd. 

Uitgaande connectiviteit

Netwerkregels en toepassingsregels

Als u netwerkregels en toepassingsregels configureert, worden netwerkregels toegepast in volgorde van prioriteit vóór toepassingsregels. De regels zijn aan het einde. Dus als er een overeenkomst wordt gevonden in een netwerkregel, worden er geen andere regels verwerkt. Indien geconfigureerd, wordt IDPS uitgevoerd op al het doorkruiste verkeer en bij overeenkomst met de handtekening kan IDPS verdacht verkeer waarschuwen of/en blokkeren.

Als er geen overeenkomende netwerkregel is en het protocol HTTP, HTTPS of MSSQL is, wordt het pakket vervolgens geëvalueerd door de toepassingsregels in volgorde van prioriteit.

Voor HTTP zoekt Azure Firewall toepassingsregel overeenkomstig de Host-header. Voor HTTPS zoekt Azure Firewall naar een overeenkomst met een toepassingsregel op basis van alleen SNI.

In http- en TLS geïnspecteerde HTTPS-gevallen negeert de firewall het doel-IP-adres van het pakket en gebruikt het door DNS opgeloste IP-adres van de hostheader. De firewall verwacht poortnummer op te halen in de Host-header, anders wordt ervan uitgenomen dat de standaardpoort 80 is. Als er een niet-overeenkomende poort is tussen de werkelijke TCP-poort en de poort in de hostheader, wordt het verkeer uitgevallen.DNS-resolutie wordt uitgevoerd door Azure DNS of door een aangepaste DNS als deze is geconfigureerd op de firewall. 

Notitie

Zowel HTTP- als HTTPS-protocollen (met TLS-inspectie) worden altijd ingevuld door Azure Firewall met XFF-header (X-Forwarded-For) die gelijk is aan het oorspronkelijke bron-IP-adres. 

Wanneer een toepassingsregel TLS-inspectie bevat, verwerkt de firewallregelen engine SNI, Hostheader en ook de URL die aan de regel moet voldoen.

Als er nog steeds geen overeenkomst wordt gevonden binnen toepassingsregels, wordt het pakket geëvalueerd op basis van de infrastructuurregelverzameling. Als er nog steeds geen overeenkomst is, wordt het pakket standaard geweigerd.

Notitie

Netwerkregels kunnen worden geconfigureerd voor TCP,UDP,ICMP of elk   IP-protocol. Elk IP-protocol bevat alle IP-protocollen zoals gedefinieerd in het document IANA-protocolnummers (Internet Assigned Numbers Authority). Als een doelpoort expliciet is geconfigureerd, wordt de regel omgezet in een TCP+UDP-regel. Vóór 9 november 2020 bedoelde Any   TCP, of UDP of ICMP. Het is dus mogelijk dat u vóór die datum een regel hebt geconfigureerd met Protocol = Alle, en doelpoorten = '*'. Als u geen IP-protocol wilt toestaan zoals momenteel is gedefinieerd, wijzigt u de regel om expliciet de want(en) protocollen (TCP, UDP of ICMP) te configureren.

Binnenkomende connectiviteit

DNAT-regels en netwerkregels

Inkomende internetverbinding kan worden ingeschakeld door DNAT (Destination Network Address Translation) te configureren, zoals beschreven in Zelfstudie:Inkomende verkeer filteren met Azure Firewall DNAT met behulp van de Azure Portal . NAT-regels worden met prioriteit toegepast vóór netwerkregels. Als er een overeenkomst wordt gevonden, wordt er een impliciete overeenkomstige netwerkregel toegevoegd om het vertaalde verkeer toe te staan. Uit veiligheidsoverwegingen wordt aanbevolen om een specifieke internetbron toe te voegen om DNAT-toegang tot het netwerk toe te staan en het gebruik van jokertekens te voorkomen.

Toepassingsregels worden niet toegepast op binnenkomende verbindingen. Als u dus het inkomende HTTP/S-verkeer wilt filteren, moet u Web Application Firewall (WAF). Zie Wat is Azure Web Application Firewall? voor meer Azure Web Application Firewall.

Voorbeelden

De volgende voorbeelden tonen de resultaten van een aantal van deze regelcombinaties.

Voorbeeld 1

Verbinding met google.com is toegestaan vanwege een overeenkomende netwerkregel.

Netwerkregel

  • Actie: Toestaan
naam Protocol Brontype Bron Doeltype Doeladres Doelpoorten
Web toestaan TCP IP-adres * IP-adres * 80.443

Toepassingsregel

  • Actie: Weigeren
naam Brontype Bron Protocol:Poort Doel-FQDN's
Deny-google IP-adres * http:80,https:443 google.com

Resultaat

De verbinding met google.com is toegestaan omdat het pakket overeenkomt met de regel Webnetwerk toestaan. De verwerking van regels stopt op dit moment.

Voorbeeld 2

SSH-verkeer wordt geweigerd omdat de verzameling netwerkregel weigeren een hogere prioriteit heeft.

Netwerkregelverzameling 1

  • Naam: Allow-collection
  • Prioriteit: 200
  • Actie: Toestaan
naam Protocol Brontype Bron Doeltype Doeladres Doelpoorten
Allow-SSH TCP IP-adres * IP-adres * 22

Netwerkregelverzameling 2

  • Naam: Deny-collection
  • Prioriteit: 100
  • Actie: Weigeren
naam Protocol Brontype Bron Doeltype Doeladres Doelpoorten
Deny-SSH TCP IP-adres * IP-adres * 22

Resultaat

SSH-verbindingen worden geweigerd omdat een netwerkregelverzameling 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, worden alle relevante bestaande sessies weggelaten.

3-way handshake gedrag

Als stateful service wordt Azure Firewall TCP-handshake in drie richting voltooid 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 naar VNet-B betekent niet dat nieuwe, geïnitieerde verbindingen van VNet-B naar VNet-A zijn toegestaan.

Als gevolg hiervan hoeft u geen expliciete regel voor weigeren van VNet-B naar VNet-A te maken. Als u deze regel voor weigeren maakt, onderbreekt u de 3-way handshake van de eerste regel voor toestaan van VNet-A naar VNet-B.

Volgende stappen