Konfigurera brandväggsregler
Du kan konfigurera NAT-regler, nätverksregler och programregler i Azure Firewall med hjälp av antingen klassiska regler eller brandväggsprincip. Azure Firewall nekar all trafik som standard, tills regler har konfigurerats manuellt för att tillåta trafik. Reglerna avslutas, så regelbearbetningen stoppas vid en matchning.
Regelbearbetning med klassiska regler
Regelsamlingar bearbetas enligt regeltypen i prioritetsordning, lägre tal till högre tal från 100 till 65 000. Ett regelsamlingsnamn får bara innehålla bokstäver, siffror, understreck, punkter eller bindestreck. Den måste börja med en bokstav eller siffra och sluta med en bokstav, ett tal eller ett understreck. Den maximala namnlängden är 80 tecken.
Det är bäst att först utrymme din regelsamling prioritetsnummer i 100 steg (100, 200, 300 och så vidare) så att du har utrymme att lägga till fler regelsamlingar om det behövs.
Regelbearbetning med brandväggsprincip
Med brandväggsprincip ordnas regler i regelsamlingar och regelsamlingsgrupper. Regelsamlingsgrupper innehåller noll eller fler regelsamlingar. Regelsamlingar är av typen NAT, Nätverk eller Program. Du kan definiera flera typer av regelsamlingar i en enda regelgrupp. Du kan definiera noll eller fler regler i en regelsamling. Regler i en regelsamling måste vara av samma typ (NAT, Nätverk eller Program).
Regler bearbetas baserat på regelsamlingens gruppprioritet och regelsamlingens prioritet. Prioritet är ett tal mellan 100 (högsta prioritet) till 65 000 (lägsta prioritet). Regelsamlingsgrupper med högsta prioritet bearbetas först. I en regelsamlingsgrupp bearbetas regelsamlingar med högsta prioritet (lägsta antal) först.
Om en brandväggsprincip ärvs från en överordnad princip har regelsamlingsgrupper i den överordnade principen alltid företräde oavsett prioritet för en underordnad princip.
Kommentar
Programregler bearbetas alltid efter nätverksregler, som bearbetas efter DNAT-regler oavsett regelsamlingsgrupp eller regelsamlingsprioritet och principarv.
Så för att sammanfatta:
Den överordnade principen har alltid företräde.
- Regelsamlingsgrupper bearbetas i prioritetsordning.
- Regelsamlingar bearbetas i prioritetsordning.
- DNAT-regler, sedan Nätverksregler och sedan Programregler bearbetas.
Här är en exempelprincip:
Förutsatt att BaseRCG1 är en regelsamlingsgruppprioritet (200) som innehåller regelsamlingarna: DNATRC1, DNATRC3, NetworkRC1.
BaseRCG2 är en regelsamlingsgruppprioritet (300) som innehåller regelsamlingarna: AppRC2, NetworkRC2.
ChildRCG1 är en regelsamlingsgruppprioritet (300) som innehåller regelsamlingarna: ChNetRC1, ChAppRC1.
ChildRCG2 är en regelsamlingsgruppprioritet (650) som innehåller regelsamlingarna: ChNetRC2, ChAppRC2, ChDNATRC3.
Enligt följande tabell:
| Namn | Type | Prioritet | Regler | Ärvd från |
|---|---|---|---|---|
| BaseRCG1 | Regelsamlingsgrupp | 200 | 8 | Överordnad princip |
| DNATRC1 | DNAT-regelinsamling | 600 | 7 | Överordnad princip |
| DNATRC3 | DNAT-regelinsamling | 610 | 3 | Överordnad princip |
| NetworkRC1 | Nätverksregelsamling | 800 | 1 | Överordnad princip |
| BaseRCG2 | Regelsamlingsgrupp | 300 | 3 | Överordnad princip |
| AppRC2 | Insamling av programregler | 1200 | 2 | Överordnad princip |
| NetworkRC2 | Nätverksregelsamling | 1300 | 1 | Överordnad princip |
| ChildRCG1 | Regelsamlingsgrupp | 300 | 5 | - |
| ChNetRC1 | Nätverksregelsamling | 700 | 3 | - |
| ChAppRC1 | Insamling av programregler | 900 | 2 | - |
| ChildRCG2 | Regelsamlingsgrupp | 650 | 9 | - |
| ChNetRC2 | Nätverksregelsamling | 1100 | 2 | - |
| ChAppRC2 | Insamling av programregler | 2000 | 7 | - |
| ChDNATRC3 | DNAT-regelinsamling | 3000 | 2 | - |
Initial iteration för DNAT-regler:
Processen börjar med att undersöka regelsamlingsgruppen (RCG) med det lägsta talet, vilket är BaseRCG1 med prioriteten 200. Inom den här gruppen söker den efter DNAT-regelsamlingar och utvärderar dem enligt deras prioriteringar. I det här fallet hittas och bearbetas DNATRC1 (prioritet 600) och DNATRC3 (prioritet 610).
Därefter flyttas den till nästa RCG, BaseRCG2 (prioritet 300), men hittar ingen DNAT-regelsamling.
Därefter fortsätter den till ChildRCG1 (prioritet 300), även utan en DNAT-regelsamling.
Slutligen kontrollerar den ChildRCG2 (prioritet 650) och hittar ChDNATRC3-regelsamlingen (prioritet 3000).
Iteration för NÄTVERKsregler:
När iterationen återgår till BaseRCG1 fortsätter den här gången för NETWORK-regler. Endast NetworkRC1 (prioritet 800) hittas.
Sedan flyttas den till BaseRCG2, där NetworkRC2 (prioritet 1300) finns.
När du går vidare till ChildRCG1 identifieras ChNetRC1 (prioritet 700) som NETWORK-regel.
Slutligen, i ChildRCG2, hittar den ChNetRC2 (prioritet 1100) som NETWORK-regelsamlingen.
Slutlig iteration för PROGRAMregler:
När du återgår till BaseRCG1 itererar processen för PROGRAMregler, men ingen hittas.
I BaseRCG2 identifierar den AppRC2 (prioritet 1200) som programregel.
I ChildRCG1 hittas ChAppRC1 (prioritet 900) som programregel.
I ChildRCG2 letar den slutligen upp ChAppRC2 (prioritet 2000) som PROGRAMregel.
Sammanfattningsvis är regelbearbetningssekvensen följande: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.
Den här processen omfattar analys av regelinsamlingsgrupper efter prioritet och inom varje grupp, och ordning av reglerna enligt deras prioriteringar för varje regeltyp (DNAT, NÄTVERK och PROGRAM).
Så först bearbetas alla DNAT-regler från alla regelinsamlingsgrupper, analyserar regelsamlingsgrupperna efter prioritetsordning och beställer DNAT-reglerna inom varje regelsamlingsgrupp efter prioritetsordning. Sedan samma process för NETWORK-regler och slutligen för PROGRAMregler.
Mer information om regeluppsättningar för brandväggsprinciper finns i Regeluppsättningar för Azure Firewall Policy.
Hotinformation
Om du aktiverar hotinformationsbaserad filtrering är dessa regler högsta prioritet och bearbetas alltid först (före nätverk och programregler). Filtrering av hotinformation kan neka trafik innan några konfigurerade regler bearbetas. Mer information finns i Hotinformationsbaserad filtrering i Azure Firewall.
IDPS
När IDPS har konfigurerats i aviseringsläge fungerar IDPS-motorn parallellt med logiken för regelbearbetning och genererar aviseringar om matchande signaturer för både inkommande och utgående flöden. För en IDPS-signaturmatchning loggas en avisering i brandväggsloggar. Men eftersom IDPS-motorn fungerar parallellt med regelbearbetningsmotorn kan trafik som nekas eller tillåts av program-/nätverksregler fortfarande generera en annan loggpost.
När IDPS har konfigurerats i aviserings- och neka-läge är IDPS-motorn infogad och aktiverad efter regelbearbetningsmotorn. Båda motorerna genererar därför aviseringar och kan blockera matchande flöden.
Sessioner som avbryts av IDPS blockerar flödet tyst. Därför skickas ingen RST på TCP-nivån. Eftersom IDPS inspekterar trafiken alltid efter att nätverks-/programregeln har matchats (Tillåt/neka) och markerats i loggar, kan ett annat Drop-meddelande loggas där IDPS bestämmer sig för att neka sessionen på grund av en signaturmatchning.
När TLS-inspektionen är aktiverad inspekteras både okrypterad och krypterad trafik.
Utgående anslutning
Regler för nätverksregler och program
Om du konfigurerar nätverksregler och programregler tillämpas nätverksregler i prioritetsordning före programregler. Reglerna avslutas. Så om en matchning hittas i en nätverksregel bearbetas inga andra regler. Om det är konfigurerat utförs IDPS på all trafik som passerar och vid signaturmatchning kan IDPS avisera eller/och blockera misstänkt trafik.
Programregler utvärderar sedan paketet i prioritetsordning om det inte finns någon nätverksregelmatchning och om protokollet är HTTP, HTTPS eller MSSQL.
För HTTP söker Azure Firewall efter en programregelmatchning enligt värdhuvudet. För HTTPS söker Azure Firewall efter en programregelmatchning endast enligt SNI.
I både HTTP- och TLS-inspekterade HTTPS-fall ignorerar brandväggen paketets mål-IP-adress och använder DEN DNS-lösta IP-adressen från värdhuvudet. Brandväggen förväntar sig att få portnummer i värdhuvudet, annars förutsätter den standardporten 80. Om det finns ett portfel mellan den faktiska TCP-porten och porten i värdhuvudet tas trafiken bort. DNS-matchning utförs av Azure DNS eller av en anpassad DNS om den konfigureras i brandväggen.
Kommentar
Både HTTP- och HTTPS-protokoll (med TLS-inspektion) fylls alltid i av Azure Firewall med XFF-huvudet (X-Forwarded-For) som är lika med den ursprungliga käll-IP-adressen.
När en programregel innehåller TLS-inspektion bearbetar brandväggsregler motorn SNI, värdhuvud och även URL:en som matchar regeln.
Om det fortfarande inte finns någon matchning i programreglerna utvärderas paketet mot infrastrukturregelsamlingen. Om det fortfarande inte finns någon matchning nekas paketet som standard.
Kommentar
Nätverksregler kan konfigureras för TCP, UDP, ICMP eller alla IP-protokoll. Alla IP-protokoll innehåller alla IP-protokoll enligt definitionen i dokumentet IANA-protokollnummer (Internet Assigned Numbers Authority). Om en målport är explicit konfigurerad översätts regeln till en TCP+UDP-regel. Före den 9 november 2020 betydde Any TCP, UDP eller ICMP. Så du kan ha konfigurerat en regel före det datumet med Protokoll = Alla och målportar = '*'. Om du inte tänker tillåta något IP-protokoll enligt definitionen ändrar du regeln så att du uttryckligen konfigurerar de protokoll som du vill ha (TCP, UDP eller ICMP).
Inkommande anslutning
DNAT-regler och nätverksregler
Inkommande Internet- eller intranätanslutningar (förhandsversion) kan aktiveras genom att konfigurera DNAT (Destination Network Address Translation) enligt beskrivningen i Filtrera inkommande Internet- eller intranättrafik med Azure Firewall DNAT med hjälp av Azure Portal. NAT-regler tillämpas i prioritet före nätverksregler. Om en matchning hittas översätts trafiken enligt DNAT-regeln och tillåts av brandväggen. Trafiken kan därför inte bearbetas ytterligare av andra nätverksregler. Av säkerhetsskäl är den rekommenderade metoden att lägga till en specifik Internetkälla för att tillåta DNAT-åtkomst till nätverket och undvika att använda jokertecken.
Programregler tillämpas inte för inkommande anslutningar. Om du vill filtrera inkommande HTTP/S-trafik bör du därför använda Brandvägg för webbprogram (WAF). Mer information finns i Vad är Azure Web Application Firewall?
Exempel
I följande exempel visas resultatet av några av dessa regelkombinationer.
Exempel 1
Anslutning till google.com tillåts på grund av en matchande nätverksregel.
Nätverksregel
- Åtgärd: Tillåt
| name | Protokoll | Source type | Källa | Måltyp | Måladress | Målportar |
|---|---|---|---|---|---|---|
| Allow-web | TCP | IP-adress | * | IP-adress | * | 80 443 |
Programregel
- Åtgärd: Neka
| name | Source type | Källa | Protokoll:Port | Mål-FQDN |
|---|---|---|---|---|
| Neka google | IP-adress | * | http:80,https:443 | google.com |
Resultat
Anslutningen till google.com tillåts eftersom paketet matchar regeln Tillåt webbnätverk . Regelbearbetningen stoppas nu.
Exempel 2
SSH-trafik nekas eftersom en högre prioritet Neka nätverksregelsamling blockerar den.
Nätverksregelsamling 1
- Namn: Tillåt samling
- Prioritet: 200
- Åtgärd: Tillåt
| name | Protokoll | Source type | Källa | Måltyp | Måladress | Målportar |
|---|---|---|---|---|---|---|
| Allow-SSH | TCP | IP-adress | * | IP-adress | * | 22 |
Nätverksregelsamling 2
- Namn: Neka-samling
- Prioritet: 100
- Åtgärd: Neka
| name | Protokoll | Source type | Källa | Måltyp | Måladress | Målportar |
|---|---|---|---|---|---|---|
| Neka SSH | TCP | IP-adress | * | IP-adress | * | 22 |
Resultat
SSH-anslutningar nekas eftersom en nätverksregelsamling med högre prioritet blockerar den. Regelbearbetningen stoppas nu.
Regeländringar
Om du ändrar en regel för att neka tidigare tillåten trafik tas alla relevanta befintliga sessioner bort.
Trevägshandskakningsbeteende
Som en tillståndskänslig tjänst slutför Azure Firewall en TCP-trevägshandskakning för tillåten trafik, från en källa till målet. Till exempel VNet-A till VNet-B.
Att skapa en Tillåt-regel från VNet A till VNet B innebär inte att nya initierade anslutningar från VNet B till VNet A tillåts.
Därför behöver du inte skapa en explicit neka-regel från VNet-B till VNet-A.