Azure Firewall-regels configureren
U kunt NAT-regels, netwerkregels en toepassingsregels configureren in Azure Firewall met behulp van klassieke regels of firewallbeleid. Azure Firewall weigert standaard al het verkeer, totdat regels handmatig zijn geconfigureerd om verkeer toe te staan.
Regelverwerking met klassieke regels
Regelverzamelingen worden verwerkt volgens het regeltype in volgorde van prioriteit, lagere getallen naar hogere getallen van 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.
U kunt het beste eerst de prioriteitsnummers van uw regelverzameling in 100 stappen (100, 200, 300 enzovoort) ruimte geven, zodat u indien nodig meer regelverzamelingen kunt toevoegen.
Regelverwerking met firewallbeleid
Met firewallbeleid zijn regels ingedeeld in regelverzamelingen en regelverzamelingsgroepen. Regelverzamelingsgroepen bevatten nul of meer regelverzamelingen. Regelverzamelingen zijn 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).
Regels worden verwerkt op basis van de prioriteit van regelverzamelingsgroepen en regelverzamelingen. Prioriteit is een getal tussen 100 (hoogste prioriteit) en 65.000 (laagste prioriteit). Regelverzamelingsgroepen met de hoogste prioriteit worden eerst verwerkt. Binnen een regelverzamelingsgroep worden regelverzamelingen met de hoogste prioriteit (laagste getal) eerst verwerkt.
Als een firewallbeleid wordt overgenomen van een bovenliggend beleid, heeft 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 regelverzamelingsgroep of regelverzamelingsprioriteit en overname van beleid.
Hier volgt een voorbeeldbeleid:
Ervan uitgaande dat BaseRCG1 een groepsprioriteit voor regels (200) is die de regelverzamelingen bevat: DNATRC1, DNATRC3,NetworkRC1.
BaseRCG2 is een groepsprioriteit voor regels (300) die de regelverzamelingen bevat: AppRC2, NetworkRC2.
ChildRCG1 is een groepsprioriteit voor regels (200) die de regelverzamelingen bevat: ChNetRC1, ChAppRC1.
ChildRCG2 is een regelverzamelingsgroep die de regelverzamelingen bevat: ChNetRC2, ChAppRC2, ChDNATRC3.
Volgens de volgende tabel:
| Name | Type | Prioriteit | Regels | Overgenomen van |
|---|---|---|---|---|
| BaseRCG1 | Groep Regelverzameling | 200 | 8 | Bovenliggend beleid |
| DNATRC1 | DNAT-regelverzameling | 600 | 7 | Bovenliggend beleid |
| DNATRC3 | DNAT-regelverzameling | 610 | 3 | Bovenliggend beleid |
| NetworkRC1 | Verzameling met netwerkregels | 800 | 1 | Bovenliggend beleid |
| BaseRCG2 | Groep Regelverzameling | 300 | 3 | Bovenliggend beleid |
| AppRC2 | Verzameling met toepassingsregels | 1200 | 2 | Bovenliggend beleid |
| NetworkRC2 | Verzameling met netwerkregels | 1300 | 1 | Bovenliggend beleid |
| ChildRCG1 | Groep Regelverzameling | 300 | 5 | - |
| ChNetRC1 | Verzameling met netwerkregels | 700 | 3 | - |
| ChAppRC1 | Verzameling met toepassingsregels | 900 | 2 | - |
| ChildRCG2 | Groep Regelverzameling | 650 | 9 | - |
| ChNetRC2 | Verzameling met netwerkregels | 1100 | 2 | - |
| ChAppRC2 | Verzameling met toepassingsregels | 2000 | 7 | - |
| ChDNATRC3 | DNAT-regelverzameling | 3000 | 2 | - |
Initiële verwerking:
Het proces begint met het onderzoeken van de regelverzamelingsgroep (RCG) met het laagste getal, dat BaseRCG1 is met een prioriteit van 200. Binnen deze groep wordt gezocht naar DNAT-regelverzamelingen en geëvalueerd op basis van hun prioriteiten. In dit geval worden DNATRC1 (prioriteit 600) en DNATRC3 (prioriteit 610) dienovereenkomstig gevonden en verwerkt.
Vervolgens wordt het verplaatst naar de volgende RCG, BaseRCG2 (prioriteit 200), maar vindt geen DNAT-regelverzameling.
Hierna gaat het verder met ChildRCG1 (prioriteit 300), ook zonder een DNAT-regelverzameling.
Ten slotte wordt ChildRCG2 (prioriteit 650) gecontroleerd en wordt de ChDNATRC3-regelverzameling (prioriteit 3000) gevonden.
Iteratie binnen regelverzamelingsgroepen:
Als u terugkeert naar BaseRCG1, wordt de iteratie voortgezet, deze keer voor NETWERKregels. Alleen NetworkRC1 (prioriteit 800) is gevonden.
Vervolgens wordt het verplaatst naar BaseRCG2, waar NetworkRC2 (prioriteit 1300) zich bevindt.
Als u overstapt op ChildRCG1, wordt ChNetRC1 (prioriteit 700) gedetecteerd als netwerkregel.
Ten slotte wordt in ChildRCG2 ChNetRC2 (prioriteit 1100) gevonden als de verzameling NETWERKregels.
Uiteindelijke iteratie voor TOEPASSINGsregels:
Als u terugkeert naar BaseRCG1, wordt het proces herhaald voor TOEPASSINGsregels, maar er zijn geen gevonden.
In BaseRCG2 identificeert het AppRC2 (prioriteit 1200) als de TOEPASSINGsregel.
In ChildRCG1 wordt ChAppRC1 (prioriteit 900) gevonden als de TOEPASSINGsregel.
Ten slotte wordt in ChildRCG2 ChAppRC2 (prioriteit 2000) als toepassingsregel gevonden.
Samengevat is de regelverwerkingsreeks als volgt: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.
Dit proces omvat het analyseren van regelverzamelingsgroepen op prioriteit en binnen elke groep, het ordenen van de regels op basis van hun prioriteiten voor elk regeltype (DNAT, NETWERK en TOEPASSING).
Dus eerst worden alle DNAT-regels verwerkt uit alle regelverzamelingsgroepen, waarbij de regelverzamelingsgroepen worden geanalyseerd op volgorde van prioriteit en de DNAT-regels binnen elke regelverzamelingsgroep worden gerangschikt op volgorde van prioriteit. Vervolgens hetzelfde proces voor NETWERKregels en ten slotte voor TOEPASSINGsregels.
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 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 van bedreigingsinformatie van Azure Firewall voor meer informatie.
IDPS
Wanneer IDPS is geconfigureerd in de waarschuwingsmodus , werkt de IDPS-engine parallel aan de regelverwerkingslogica en worden waarschuwingen gegenereerd voor overeenkomende handtekeningen voor zowel binnenkomende als uitgaande stromen. Voor een idPS-handtekeningovereenkomst wordt een waarschuwing vastgelegd in firewalllogboeken. Omdat de IDPS-engine echter parallel werkt met de regelverwerkingsengine, kan verkeer dat is geweigerd of toegestaan door toepassings-/netwerkregels, nog steeds een andere logboekvermelding genereren.
Wanneer IDPS is geconfigureerd in de modus Waarschuwing en Weigeren , is de IDPS-engine inline en geactiveerd na de regelengine. Daarom genereren beide engines waarschuwingen en kunnen overeenkomende stromen blokkeren.
Sessieuitval uitgevoerd door IDPS blokkeert de stroom op de achtergrond. Er wordt dus geen RST verzonden op TCP-niveau. Omdat IDPS verkeer controleert altijd nadat de netwerk-/toepassingsregel is vergeleken (toestaan/weigeren) en is gemarkeerd in logboeken, kan een ander drop-bericht worden geregistreerd waar 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 voordat toepassingsregels worden toegepast. De regels worden beëindigd. Dus als een overeenkomst wordt gevonden in een netwerkregel, worden er geen andere regels verwerkt. Als dit is geconfigureerd, wordt IDPS uitgevoerd voor al het doorkruiste verkeer en bij overeenkomst met handtekeningen kan IDPS waarschuwingen geven of/en verdacht verkeer blokkeren.
Toepassingsregels evalueren vervolgens het pakket in prioriteitsvolgorde 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ïnspecteerd HTTPS-gevallen negeert de firewall het doel-IP-adres van het pakket en maakt gebruik van het door DNS omgezet IP-adres van de hostheader. De firewall verwacht poortnummer op te halen in de hostheader, anders wordt ervan uitgegaan dat de standaardpoort 80 is. Als er een poort niet overeenkomt tussen de werkelijke TCP-poort en de poort in de hostheader, wordt het verkeer verwijderd. DNS-omzetting 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 engine voor firewallregels SNI, hostheader en ook de URL die overeenkomt met de regel.
Als er nog steeds geen overeenkomst wordt gevonden in toepassingsregels, wordt het pakket geëvalueerd op basis van de verzameling infrastructuurregels. 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 Internet Assigned Numbers Authority (IANA) Protocol Numbers. Als een doelpoort expliciet is geconfigureerd, wordt de regel omgezet in een TCP+UDP-regel. Vóór 9 november 2020 zijn alle bedoelde TCP of UDP of ICMP bedoeld. 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
Inkomende internetverbinding kan worden ingeschakeld door DNAT (Destination Network Address Translation) te configureren, zoals beschreven in Binnenkomend verkeer filteren met Azure Firewall DNAT met behulp van Azure Portal. NAT-regels worden toegepast in prioriteit vóór netwerkregels. Als er een overeenkomst wordt gevonden, wordt het verkeer vertaald volgens de DNAT-regel en toegestaan door de firewall. Het verkeer is dus niet onderworpen aan verdere verwerking door andere netwerkregels. Om veiligheidsredenen is het raadzaam om een specifieke internetbron toe te voegen om DNAT-toegang tot het netwerk toe te staan en jokertekens te voorkomen.
Toepassingsregels worden niet toegepast op binnenkomende verbindingen. Als u dus inkomend HTTP/S-verkeer wilt filteren, moet u WaF (Web Application Firewall) gebruiken. Zie Wat is Azure Web Application Firewall?
Voorbeelden
In de volgende voorbeelden ziet u de resultaten van een aantal van deze regelcombinaties.
Voorbeeld 1
Verbinding maken ion to google.com is toegestaan vanwege een overeenkomende netwerkregel.
Netwerkregel
- Actie: Toestaan
| name | Protocol | Source type | Bron | Doeltype | Doeladressen | Doelpoorten |
|---|---|---|---|---|---|---|
| Allow-web | TCP | IP-adres | * | IP-adres | * | 80.443 |
Toepassingsregel
- Actie: Weigeren
| name | Source type | 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 voor het toestaan van het webnetwerk . De verwerking van regels stopt op dit moment.
Voorbeeld 2
SSH-verkeer wordt geweigerd omdat het verzamelen van netwerkregels met een hogere prioriteit wordt geblokkeerd.
Verzameling van netwerkregels 1
- Naam: Verzameling toestaan
- Prioriteit: 200
- Actie: Toestaan
| name | Protocol | Source type | Bron | Doeltype | Doeladressen | Doelpoorten |
|---|---|---|---|---|---|---|
| Allow-SSH | TCP | IP-adres | * | IP-adres | * | 22 |
Verzameling van netwerkregels 2
- Naam: Deny-collection
- Prioriteit: 100
- Actie: Weigeren
| name | Protocol | Source type | Bron | Doeltype | Doeladressen | 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, worden alle relevante bestaande sessies verwijderd.
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 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 te maken van VNet-B naar VNet-A. Als u deze regel voor weigeren maakt, onderbreekt u de drierichtingshanddruk van de eerste regel voor toestaan van VNet-A naar VNet-B.