Vanliga frågor och svar om Azure Firewall

Azure Firewall är en hanterad, molnbaserad tjänst för nätverkssäkerhet som skyddar dina Azure Virtual Network-resurser. Det är en helt tillståndskänslig brandvägg som en tjänst med inbyggd hög tillgänglighet och obegränsad skalbarhet i molnet. Du kan centralt skapa, framtvinga och logga principer för tillämpning och nätverksanslutning över prenumerationer och virtuella nätverk.

Mer information om Azure Firewall-funktioner finns i Azure Firewall-funktioner.

Du kan distribuera Azure Firewall på alla virtuella nätverk, men det vanliga är att kunder distribuerar brandväggen på ett centralt virtuellt nätverk och peer-kopplar andra virtuella nätverk till den i en ”nav och eker”-modell. Du kan sedan ange standardvägen från de peerkopplade virtuella nätverken så att den pekar på det här centrala virtuella brandväggsnätverket. Global VNet-peering stöds, men det rekommenderas inte på grund av potentiella problem med prestanda och svarstider mellan regioner. För att få bästa prestanda bör du distribuera en brandvägg per region.

Fördelen med den här modellen är att du får central kontroll över flera virtuella eker-nätverk för olika prenumerationer. Det finns också kostnadsbesparingar eftersom du inte behöver distribuera en brandvägg i varje virtuellt nätverk separat. Kostnadsbesparingarna bör ställas i jämförelse med kostnaden för peering utifrån kundens trafikmönster.

Du kan konfigurera Azure Firewall med hjälp av Azure Portal, PowerShell, REST API eller med hjälp av mallar. Se Självstudie: Distribuera och konfigurera Azure Firewall med hjälp av Azure Portal för stegvisa instruktioner.

Azure Firewall stöder regler och regelsamlingar. En regelsamling är en uppsättning regler som delar samma ordning och prioritet. Regelsamlingar körs i prioritetsordning. DNAT-regelsamlingar är nätverksregelsamlingar med högre prioritet, som har högre prioritet än programregelsamlingar, och alla regler avslutas.

Det finns tre typer av regelsamlingar:

• Programregler: Konfigurera fullständigt kvalificerade domännamn (FQDN) som kan nås från ett virtuellt nätverk.
• Nätverksregler: Konfigurera regler som innehåller källadresser, protokoll, målportar och måladresser.
• NAT-regler: Konfigurera DNAT-regler för att tillåta inkommande Internet- eller intranätanslutningar (förhandsversion).

Mer information finns i Konfigurera Azure Firewall-regler.

Azure Firewall har stöd för inkommande och utgående filtrering. Inkommande skydd används vanligtvis för icke-HTTP-protokoll som RDP-, SSH- och FTP-protokoll. För inkommande HTTP- och HTTPS-skydd använder du en brandvägg för webbprogram, till exempel Azure Web Application Firewall (WAF) eller funktionerna för TLS-avlastning och djup paketgranskning i Azure Firewall Premium.

Ja, Azure Firewall Basic stöder tvingad tunneltrafik.

Azure Firewall är integrerad med Azure Monitor, vilket gör så att du kan se och analysera brandväggsloggar. Loggar kan skickas till Log Analytics, Azure Storage och Event Hubs. De kan analyseras i Log Analytics eller med andra verktyg som Excel och Power BI. Mer information finns i Självstudie: Övervaka Azure Firewall-loggar.

Azure Firewall är en hanterad, molnbaserad nätverkssäkerhetstjänst som skyddar dina virtuella nätverksresurser. Det är en helt tillståndskänslig brandvägg som en tjänst med inbyggd hög tillgänglighet och obegränsad molnskalbarhet. Den är förintegrerad med leverantörer av säkerhet som en tjänst från tredje part (SECaaS) för att tillhandahålla avancerad säkerhet för ditt virtuella nätverk och förgrena Internetanslutningar. Mer information om Azure-nätverkssäkerhet finns i Azure-nätverkssäkerhet.

Brandväggen för webbprogram (WAF) är en funktion i Application Gateway som ger ett centraliserat inkommande skydd av dina webbprogram mot vanliga sårbarheter och sårbarheter. Azure Firewall ger inkommande skydd för icke-HTTP/S-protokoll (till exempel RDP, SSH, FTP), utgående skydd på nätverksnivå för alla portar och protokoll och skydd på programnivå för utgående HTTP/S.

Azure Firewall-tjänsten kompletterar nätverkssäkerhetsgruppens funktioner. Tillsammans ger de bättre "skydd på djupet" nätverkssäkerhet. Nätverkssäkerhetsgrupper innehåller distribuerad filtrering av nätverkstrafik som begränsar trafiken till resurser i virtuella nätverk i varje prenumeration. Azure Firewall är en helt tillståndskänslig, centraliserad nätverksbrandvägg som en tjänst, som ger skydd på nätverk- och programnivå i olika prenumerationer och virtuella nätverk.

Azure Firewall är en hanterad tjänst med flera skyddslager, inklusive plattformsskydd med NSG:er på nätverkskortsnivå (kan inte visas). NSG:er på undernätsnivå krävs inte i AzureFirewallSubnet och inaktiveras för att säkerställa att tjänsten inte avbryts.

För säker åtkomst till PaaS-tjänster rekommenderar vi tjänstslutpunkter. Du kan välja att aktivera tjänstslutpunkter i Azure Firewall-undernätet och inaktivera dem på de anslutna virtuella ekernätverken. På så sätt kan du dra nytta av båda funktionerna: tjänstslutpunktssäkerhet och central loggning för all trafik.

Se Prissättning för Azure Firewall.

Du kan använda Azure PowerShell för att frigöra och allokera metoder. För en brandvägg som konfigurerats för tvingad tunneltrafik är proceduren något annorlunda.

Till exempel för en brandvägg SOM INTE har konfigurerats för tvingad tunneltrafik:

# Stop an existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet,@($publicip1,$publicip2))

Set-AzFirewall -AzureFirewall $azfw

För en brandvägg som konfigurerats för tvingad tunneltrafik är stopp samma sak. Men för att starta krävs att den offentliga IP-adressen för hantering åter associeras tillbaka till brandväggen:

# Stop an existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip= Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azfw | Set-AzFirewall

För en brandvägg i en säker arkitektur för virtuell hubb är stopp detsamma, men start måste använda det virtuella hubb-ID:t:

# Stop and existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall

$virtualhub = get-azvirtualhub -ResourceGroupName "RG name of vHUB" -name "vHUB name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Azfw RG Name"
$azfw.Allocate($virtualhub.Id)
$azfw | Set-AzFirewall

När du allokerar och frigör stoppas brandväggsfakturering och startar därefter.

Rekommendationen är att konfigurera tillgänglighetszoner under den första brandväggsdistributionen. I vissa fall går det dock att ändra tillgänglighetszoner efter distributionen. Krav:

• Brandväggen distribueras i ett virtuellt nätverk. Det stöds inte med brandväggar som distribueras i en säker virtuell hubb.
• Brandväggens region stöder tillgänglighetszoner.
• Alla anslutna offentliga IP-adresser distribueras med tillgänglighetszoner. På egenskapssidan för varje offentlig IP-adress kontrollerar du att fältet tillgänglighetszoner finns och konfigureras med samma zoner som du har konfigurerat för brandväggen.

Det går bara att konfigurera om tillgänglighetszoner när du startar om brandväggen. När du har allokerat brandväggen och precis innan du startar brandväggen med Set-AzFirewallanvänder du följande Azure PowerShell för att ändra brandväggens zoner-egenskap :

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip= Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azFw.Zones=1,2,3
$azfw | Set-AzFirewall

Tjänstbegränsningar för Azure Firewall finns i Azure-prenumerations- och tjänstgränser, kvoter och begränsningar.

Ja, du kan använda Azure Firewall i ett virtuellt navnätverk för att dirigera och filtrera trafik mellan flera virtuella ekernätverk. Undernät i vart och ett av de virtuella ekernätverken måste ha en UDR som pekar på Azure Firewall som en standardgateway för att det här scenariot ska fungera korrekt.

Ja. Att konfigurera UDR:er för att omdirigera trafik mellan undernät i samma virtuella nätverk kräver dock mer uppmärksamhet. Även om det räcker med att använda VNET-adressintervallet som målprefix för UDR, dirigerar detta även all trafik från en dator till en annan dator i samma undernät via Azure Firewall-instansen. Undvik detta genom att inkludera en väg för undernätet i UDR med en nästa hopptyp av VNET. Det kan vara besvärligt och felbenäget att hantera dessa vägar. Den rekommenderade metoden för intern nätverkssegmentering är att använda nätverkssäkerhetsgrupper, som inte kräver UDR.

Azure Firewall inte SNAT när mål-IP-adressen är ett privat IP-intervall per IANA RFC 1918 eller IANA RFC 6598 för privata nätverk. Om din organisation använder ett offentligt IP-adressintervall för privata nätverk använder Azure Firewall SNAT trafiken till en av brandväggens privata IP-adresser i AzureFirewallSubnet. Du kan konfigurera Azure Firewall till att inte SNAT ditt offentliga IP-adressintervall. Mer information finns i avsnittet om Azure Firewall och SNAT med privata IP-adressintervall.

Dessutom är trafik som bearbetas av programregler alltid SNAT-ed. Om du vill se den ursprungliga käll-IP-adressen i loggarna för FQDN-trafik kan du använda nätverksregler med mål-FQDN.

Tvingad tunneltrafik stöds när du skapar en ny brandvägg. Du kan inte konfigurera en befintlig brandvägg för tvingad tunneltrafik. Mer information finns i Framtvingad tunneltrafik i Azure Firewall.

Azure Firewall måste ha direktanslutning till internet. Om ditt AzureFirewallSubnet lär sig en standardväg till ditt lokala nätverk via BGP måste du åsidosätta detta med udr 0.0.0.0/0 med värdet NextHopType inställt som Internet för att upprätthålla direkt Internetanslutning.

Om konfigurationen kräver tvingad tunneltrafik till ett lokalt nätverk och du kan fastställa mål-IP-prefixen för dina Internetmål kan du konfigurera dessa intervall med det lokala nätverket som nästa hopp via en användardefinierad väg i AzureFirewallSubnet. Du kan också använda BGP för att definiera dessa vägar.

Ja.

• Brandväggen och det virtuella nätverket måste finnas i samma resursgrupp.
• Den offentliga IP-adressen kan finnas i valfri resursgrupp.
• Brandväggen, det virtuella nätverket och den offentliga IP-adressen måste alla finnas i samma prenumeration.

• URL – Asterisker fungerar när de placeras till höger eller längst till vänster. Om den är till vänster kan den inte ingå i det fullständiga domännamnet.
• FQDN – Asterisker fungerar när de placeras till vänster.
• ALLMÄNT – Asterisker till vänster betyder bokstavligen allt till vänster matchningar, vilket innebär att flera underdomäner och/eller potentiellt oönskade domännamnsvariationer matchas - se följande exempel.

Exempel:

När du gör en konfigurationsändring försöker Azure Firewall uppdatera alla underliggande serverdelsinstanser. I sällsynta fall kan en av dessa serverdelsinstanser misslyckas med att uppdatera med den nya konfigurationen och uppdateringsprocessen stoppas med ett misslyckat etableringstillstånd. Azure Firewall fungerar fortfarande, men den tillämpade konfigurationen kan vara i ett inkonsekvent tillstånd, där vissa instanser har den tidigare konfigurationen där andra har den uppdaterade regeluppsättningen. Om detta händer kan du prova att uppdatera konfigurationen en gång till tills åtgärden har slutförts och brandväggen har statusen Lyckades etablera.

Azure Firewall består av flera serverdelsnoder i en aktiv-aktiv konfiguration. För planerat underhåll har vi logik för anslutningsdränering för att korrekt uppdatera noder. Uppdateringar planeras under icke-kontorstid för var och en av Azure-regionerna för att ytterligare begränsa risken för störningar. För oplanerade problem instansierar vi en ny nod för att ersätta den misslyckade noden. Anslutningen till den nya noden återupprättas vanligtvis inom 10 sekunder från tidpunkten för felet.

Vid planerat underhåll uppdaterar anslutningsdräneringslogik korrekt serverdelsnoder. Azure Firewall väntar 90 sekunder på att befintliga anslutningar ska stängas. Under de första 45 sekunderna accepterar serverdelsnoden inte nya anslutningar och under den återstående tiden svarar den med RST på alla inkommande paket. Om det behövs kan klienter automatiskt återupprätta anslutningen till en annan serverdelsnod.

Ja. Det finns en gräns på 50 tecken för ett brandväggsnamn.

Azure Firewall måste etablera fler instanser av virtuella datorer när den skalar. Ett /26-adressutrymme säkerställer att brandväggen har tillräckligt med IP-adresser för att hantera skalningen.

Nej. Azure Firewall behöver inte ett undernät som är större än /26.

Azure Firewalls ursprungliga dataflödeskapacitet är 2,5–3 Gbit/s och skalas ut till 30 Gbit/s för Standard SKU och 100 Gbit/s för Premium SKU. Den skalas ut automatiskt baserat på CPU-användning, dataflöde och antalet anslutningar.

Azure Firewall skalas gradvis när det genomsnittliga dataflödet eller CPU-förbrukningen är 60 %, eller om antalet anslutningar som används är 80 %. Den börjar till exempel skalas ut när den når 60 % av sitt maximala dataflöde. Maximala dataflödesnummer varierar beroende på brandväggs-SKU och aktiverade funktioner. Mer information finns i Azure Firewall-prestanda.

Utskalning tar fem till sju minuter.

När du testar prestanda kontrollerar du att du testar i minst 10 till 15 minuter och startar nya anslutningar för att dra nytta av nyligen skapade brandväggsnoder.

När en anslutning har en tidsgräns för inaktivitet (fyra minuter utan aktivitet) avslutar Azure Firewall anslutningen på ett korrekt sätt genom att skicka ett TCP RST-paket.

En instans av en virtuell Azure Firewall-instans kan inträffa under skalningsuppsättningen för virtuella datorer i (nedskalning) eller under uppgraderingen av flottans programvara. I dessa fall lastbalanseras nya inkommande anslutningar till de återstående brandväggsinstanserna och vidarebefordras inte till den nedladdade brandväggsinstansen. Efter 45 sekunder börjar brandväggen avvisa befintliga anslutningar genom att skicka TCP RST-paket. Efter ytterligare 45 sekunder stängs den virtuella brandväggsdatorn av. Mer information finns i TCP-återställning och timeout för lastbalanserare.

Nej. Azure Firewall blockerar Active Directory-åtkomst som standard. Om du vill tillåta åtkomst konfigurerar du tjänsttaggen AzureActiveDirectory. Mer information finns i Tjänsttaggar för Azure Firewall.

Ja, du kan använda Azure PowerShell för att göra det:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

En TCP-ping ansluter faktiskt inte till mål-FQDN. Azure Firewall tillåter inte en anslutning till någon IP-måladress/FQDN om det inte finns en explicit regel som tillåter det.

TCP-ping är ett unikt användningsfall där brandväggen, om det inte finns någon tillåten regel, svarar på klientens TCP-pingbegäran trots att TCP-pingen inte når mål-IP-adressen/FQDN. I det här fallet loggas inte händelsen. Om det finns en nätverksregel som tillåter åtkomst till mål-IP-adressen/FQDN når ping-begäran målservern och svaret vidarebefordras tillbaka till klienten. Den här händelsen loggas i nätverksregelloggen.

Ja. Läs mer i Azure subscription and service limits, quotas, and constraints (Azure-prenumeration och tjänstbegränsningar, kvoter och begränsningar)

Nej, det finns för närvarande inte stöd för att flytta en IP-grupp till en annan resursgrupp.

Ett standardbeteende för en nätverksbrandvägg är att se till att TCP-anslutningar hålls vid liv och att omedelbart stänga dem om det inte finns någon aktivitet. Tidsgränsen för TCP-inaktivitet i Azure Firewall är fyra minuter. Den här inställningen kan inte konfigureras av användaren, men du kan kontakta Azure-supporten för att öka tidsgränsen för inaktivitet för inkommande och utgående anslutningar upp till 15 minuter. Det går inte att ändra tidsgränsen för inaktivitet för trafik i öst-väst.

Om en period av inaktivitet är längre än tidsgränsvärdet finns det ingen garanti för att TCP- eller HTTP-sessionen bibehålls. En vanlig metod är att använda en TCP keep-alive. Den här metoden håller anslutningen aktiv under en längre period. Mer information finns i .NET-exemplen.

Ja, men du måste konfigurera brandväggen i läget tvingad tunneltrafik. Den här konfigurationen skapar ett hanteringsgränssnitt med en offentlig IP-adress som används av Azure Firewall för dess åtgärder. Den här offentliga IP-adressen är avsedd för hanteringstrafik. Den används uteslutande av Azure-plattformen och kan inte användas för något annat syfte. Nätverket för klientdatasökväg kan konfigureras utan en offentlig IP-adress, och Internettrafik kan tvingas tunneltrafik till en annan brandvägg eller blockeras helt.

Azure Firewall flyttar eller lagrar inte kunddata från den region som den distribueras i.

Ja. Mer information finns i Säkerhetskopiera Azure Firewall och Azure Firewall Policy med Logic Apps.

Nej, för närvarande stöds inte Azure Firewall i skyddade virtuella hubbar (vWAN) i Qatar.

Azure Firewall använder Azure Virtual Machines under som har ett hårt antal anslutningar. Det totala antalet aktiva anslutningar per virtuell dator är 250 000.

Den totala gränsen per brandvägg är den virtuella datorns anslutningsgräns (250 000) x antalet virtuella datorer i brandväggsserverdelspoolen. Azure Firewall börjar med två virtuella datorer och skalas ut baserat på CPU-användning och dataflöde.

Azure Firewall använder för närvarande TCP/UDP-källportar för utgående SNAT-trafik, utan inaktiv väntetid. När en TCP/UDP-anslutning stängs visas den TCP-port som används omedelbart som tillgänglig för kommande anslutningar.

Som en lösning för vissa arkitekturer kan du distribuera och skala med NAT Gateway med Azure Firewall för att tillhandahålla en bredare pool med SNAT-portar för variabilitet och tillgänglighet.

Specifika NAT-beteenden beror på brandväggens konfiguration och vilken typ av NAT som har konfigurerats. Brandväggen har till exempel DNAT-regler för inkommande trafik samt nätverksregler och programregler för utgående trafik via brandväggen.

Mer information finns i NAT-beteenden i Azure Firewall.