Konfigurera Azure Firewall regler

Du kan konfigurera NAT-regler, nätverksregler och programregler på Azure Firewall antingen med hjälp av klassiska regler eller brandväggsprincip. Azure Firewall nekar all trafik som standard tills regler konfigureras manuellt för att tillåta trafik.

Regelbearbetning med hjälp av 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 ha bokstäver, siffror, understreck, punkter eller bindestreck. Det måste börja med en bokstav eller en siffra och sluta med en bokstav, en siffra eller ett understreck. Den maximala namnlängden är 80 tecken.

Det är bäst att först ge regelsamlingen prioritetsnummer i 100 steg (100, 200, 300 och så vidare) så att du kan 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 flera regelsamlingar. Regelsamlingar är av typen NAT, nätverk eller program. Du kan definiera flera regelsamlingstyper i en enda regelgrupp. Du kan definiera noll eller flera 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) och 65 000 (lägst prioritet). Regelsamlingsgrupper med högst prioritet bearbetas först. I en regelsamlingsgrupp bearbetas regelsamlingar med högst prioritet (lägst antal) först.

Om en brandväggsprincip ärvs från en överordnad princip har regelsamlingsgrupper i den överordnade principen alltid företräde oavsett prioriteten för en underordnad princip.

Här är ett exempel på en princip:

Regelbearbetningen kommer att ske i följande ordning: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.

Mer information om regeluppsättningar för brandväggsprincip finns i Azure Firewall principregeluppsättningar.

Hotinformation

Om du aktiverar hotinformationsbaserad filtrering har dessa regler högsta prioritet och bearbetas alltid först (före nätverks- och programregler). Filtrering av hotinformation kan neka trafik innan konfigurerade regler bearbetas. Mer information finns i Azure Firewall hotinformationsbaserad filtrering.

INTERNFLYKTINGAR

När IDPS har konfigurerats i aviseringsläge fungerar IDPS-motorn parallellt med regelbearbetningslogiken och genererar aviseringar på matchande signaturer för både inkommande och utgående flöden.För en IDPS-signaturmatchning loggas en avisering i brandväggsloggarna. Men eftersom IDPS-motorn fungerar parallellt med regelbearbetningsmotorn kan trafik som nekas/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 infogade och aktiveras efter regelbearbetningsmotorn. Därför genererar båda motorerna aviseringar och kan blockera matchande flöden. 

Sessionsfall som görs av IDPS blockerar flödet tyst. Därför skickas ingen RST på TCP-nivå.Eftersom IDPS kontrollerar trafiken alltid efter att nätverks-/programregeln har matchats (Tillåt/neka) och markerats i loggar kan ett annat släpp-meddelande loggas där IDPS bestämmer sig för att neka sessionen på grund av en signaturmatchning.

När TLS-kontroll är aktiverat inspekteras både okrypterad och krypterad trafik. 

Utgående anslutning

Nätverksregler och programregler

Om du konfigurerar nätverksregler och programregler tillämpas nätverksregler i prioritetsordning före programreglerna. Reglerna avslutas. Så om en matchning hittas i en nätverksregel bearbetas inga andra regler. Om IDPS har konfigurerats sker det på all trafik som passerar och vid signaturmatchning kan IDPS varna eller/och blockera misstänkt trafik.

Om det inte finns någon nätverksregelmatchning, och om protokollet är HTTP, HTTPS eller MSSQL, utvärderas paketet av programreglerna i prioritetsordning.

För HTTP Azure Firewall efter en programregelmatchning enligt värdhuvudet. För HTTPS Azure Firewall efter en programregelmatchning endast enligt SNI.

I både HTTP- och TLS-kontrollerade HTTPS-fall ignorerar brandväggen paketets IP-måladress och använder den DNS-matchade IP-adressen från värdhuvudet. Brandväggen förväntar sig att hämta portnummer i värdhuvudet, annars förutsätts standardporten 80. Om det finns ett portmatchningsfel mellan den faktiska TCP-porten och porten i värdhuvudet ignoreras trafiken.DNS-upplösningen görs av Azure DNS eller av en anpassad DNS om den har konfigurerats i brandväggen. 

När en programregel innehåller TLS-kontroll bearbetar brandväggsregelmotorn SNI, värdrubriken och även URL:en för att matcha 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.

Inkommande anslutningar

DNAT-regler och nätverksregler

Inkommande Internetanslutning kan aktiveras genom att konfigurera DNAT (Destination Network Address Translation) enligt beskrivningen i Självstudie: Filtrera inkommande trafik med Azure Firewall DNAT med hjälp av Azure Portal. NAT-regler tillämpas i prioritet före nätverksregler. Om en matchning hittas läggs en implicit motsvarande nätverksregel som tillåter den översatta trafiken till. 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. Så om du vill filtrera inkommande HTTP/S-trafik bör du använda Web Application Firewall (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

Programregel

• Åtgärd: Deny

Resultat

Anslutningen till google.com tillåts eftersom paketet matchar nätverksregeln Allow-web. Regelbearbetningen stoppas nu.

Exempel 2

SSH-trafik nekas eftersom samlingen Neka nätverksregel med högre prioritet blockerar den.

Nätverksregelsamling 1

• Namn: Tillåt samling
• Prioritet: 200
• Åtgärd: Tillåt

Nätverksregelsamling 2

• Namn: Deny-collection
• Prioritet: 100
• Åtgärd: Deny

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 ignoreras alla relevanta befintliga sessioner.

Beteende för trevägshandskakning

Som en tillståndsfull tjänst Azure Firewall en TCP 3-vägs handskakning 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 den trevägshandskakningen från den första regeln för att tillåta från VNet-A till VNet-B.

Nästa steg

• Lär dig hur du distribuerar och konfigurerar en Azure Firewall.