Konfigurera brandväggsregler

  • Artikel

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.

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.

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 (200) som innehåller regelsamlingarna: ChNetRC1, ChAppRC1.
ChildRCG2 är en regelsamlingsgrupp 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 -

Inledande bearbetning:

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 200), 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 inom regelsamlingsgrupper:

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 Internetanslutning kan aktiveras genom att konfigurera DNAT (Destination Network Address Translation) enligt beskrivningen i Filtrera inkommande trafik med Azure Firewall DNAT med hjälp av Azure-portalen. 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

Anslut 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. Om du skapar den här neka-regeln avbryter du trevägshandskakningen från den första tillåtna regeln från VNet-A till VNet-B.

Nästa steg