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 fullständigt tillståndsfull brandvägg som en tjänst med inbyggd hög tillgänglighet och obegränsad molnskalbarhet. 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 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 peer-erade virtuella nätverk så att den pekar på det centrala virtuella brandväggsnätverket. Global VNet-peering stöds, men det rekommenderas inte på grund av potentiella prestanda- och svarstidsproblem i olika 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 VNet 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. Stegvisa instruktioner finns i Azure Firewall: Distribuera och Azure Portal med hjälp av Azure Portal här guiden.

Azure Firewall har stöd för regler och regelsamlingar. En regelsamling är en uppsättning regler som har samma ordning och prioritet. Regelsamlingar körs i prioritetsordning. Nätverksregelsamlingar 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 undernät.
• 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 Internetanslutningar.

Azure Firewall har stöd för inkommande och utgående filtrering. Inkommande skydd används vanligtvis för icke-HTTP/S-protokoll. Till exempel RDP-, SSH- och FTP-protokoll. För bästa inkommande HTTP/S-skydd använder du en brandvägg för webbaserade program, till exempel Azure Web Application Firewall (WAF).

Azure Firewall är integrerad med Azure Monitor för att visa och analysera brandväggsloggar. Loggar kan skickas till Log Analytics, Azure Storage eller Event Hubs. De kan analyseras i Log Analytics eller av olika verktyg, till exempel Excel och Power BI. Mer information finns i Självstudie: Övervaka Azure Firewall loggar.

Azure Firewall är en hanterad, molnbaserad tjänst för nätverkssäkerhet som skyddar dina virtuella nätverksresurser. Det är en fullständigt tillståndskänslig tjänst med inbyggd hög tillgänglighet och obegränsad molnskalbarhet. Det är förintegrerat med tredjepartsleverantörer av säkerhet som en tjänst (SECaaS) för att tillhandahålla avancerad säkerhet för ditt virtuella nätverk och förgrening av Internetanslutningar.

Den Web Application Firewall (WAF) är en funktion i Application Gateway som ger ett centraliserat inkommande skydd av dina webbprogram mot vanliga kryphål 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.

Tjänsten Azure Firewall kompletterar funktionen för nätverkssäkerhetsgrupp. Tillsammans ger de bättre "djupskydd" för nätverket. 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 fullständigt tillståndsfull, centraliserad nätverksbrandvägg som en tjänst, som ger skydd på nätverks- och programnivå över olika prenumerationer och virtuella nätverk.

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

För säker åtkomst till PaaS-tjänster rekommenderar vi tjänstslutpunkter. Du kan välja att aktivera tjänstslutpunkter i Azure Firewall och inaktivera dem i 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 Azure Firewall priser.

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

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

# 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 tunneling är det samma att stoppa. Men för att starta måste 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

När du allokerar och friser, stoppas brandväggsfakturering och startar därefter.

Mer Azure Firewall finns i Begränsningar, kvoter och begränsningar för Azure-prenumerationer och -tjänster.

Ja, du kan använda Azure Firewall ett virtuellt navnätverk för att dirigera och filtrera trafik mellan två 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 ytterligare uppmärksamhet. Det räcker att använda VNET-adressintervallet som målprefix för UDR, men det dirigerar ä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 nästa hopptyp för VNET. Det kan vara besvärligt och lätt 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: er.

Azure Firewall inte SNAT när målets IP-adress är ett privat IP-intervall per IANA RFC 1918. Om din organisation använder ett offentligt IP-adressintervall för privata nätverk Azure Firewall SNAT trafiken till en av brandväggens privata IP-adresser i AzureFirewallSubnet. Du kan konfigurera Azure Firewall att inte använda SNAT för 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ålets FQDN.

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

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 en UDR på 0.0.0.0/0 med NextHopType-värdet 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-prefix 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. Eller så kan du använda BGP för att definiera dessa vägar.

Ja. Brandväggen, det virtuella nätverket och den offentliga IP-adressen måste finnas i samma resursgrupp.

Nej. NAT-regler lägger implicit till en motsvarande nätverksregel för att tillåta den översatta trafiken. Du kan åsidosätta det här beteendet genom att uttryckligen lägga till en nätverksregelsamling med neka-regler som matchar den översatta trafiken. Mer information om regelbearbetningslogik för Azure Firewall finns i Regelbearbetningslogik för Azure Firewall.

• URL – Asterisker fungerar när de placeras på den högra eller vänstra sidan. Om den finns till vänster kan den inte vara en del av FQDN.
• FQDN – Asterisker fungerar när de placeras på den vänstra sidan.

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 serverinstanser misslyckas med att uppdatera med den nya konfigurationen och uppdateringsprocessen stoppas med ett misslyckat etableringstillstånd. Din Azure Firewall-instans 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 inträffar kan du försöka uppdatera konfigurationen en gång till tills åtgärden lyckas och brandväggen har etableringstillståndet Lyckades.

Azure Firewall består av flera servernoder i en aktiv-aktiv-konfiguration. Vid planerat underhåll har vi anslutningstömningslogik för att uppdatera noderna på ett smidigt sätt. Uppdateringar planeras under icke-affärstimmar för var och en av Azure-regionerna för att ytterligare begränsa risken för avbrott. För oplanerade problem instansierar vi en ny nod för att ersätta noden som misslyckades. Anslutningen till den nya noden återupprättas vanligtvis inom 10 sekunder från tidpunkten för felet.

Vid planerat underhåll uppdaterar anslutningstömningslogiken på ett smidigt sätt backend-noderna. Azure Firewall väntar 90 sekunder på att befintliga anslutningar ska stängas. Om det behövs kan klienter automatiskt återupprätta anslutningen till en annan backend-nod.

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 de skalas. Ett /26-adressutrymme säkerställer att brandväggen har tillräckligt med TILLGÄNGLIGA IP-adresser för skalningen.

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

Azure Firewall ursprungliga dataflödeskapaciteten är 2,5–3 Gbit/s och skalas ut till 30 Gbit/s. Den skalas ut automatiskt baserat på cpu-användning och dataflöde.

Azure Firewall skalas gradvis när den genomsnittliga dataflödet eller CPU-förbrukningen är på 60 %. Standardvärdet för distributionens maximala dataflöde är cirka 2,5–3 Gbit/s och börjar skala ut när det når 60 % av det antalet. Utskalning tar fem till sju minuter.

När du testar prestanda bör du testa i minst 10 till 15 minuter och starta 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) Azure Firewall anslutningen på ett smidigt sätt genom att skicka ett TCP RST-paket.

En Azure Firewall avstängning av VM-instansen kan ske under skalningsuppsättningsskalning i (skala ned) eller under programvaruuppgradering av vagnpark. I dessa fall belastningsutjämnas nya inkommande anslutningar till de återstående brandväggsinstanserna och vidarebefordras inte till den nedströms-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 Load Balancer TCP-återställning och tidsgräns för inaktivitet.

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

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 inte till målets FQDN. Detta beror på Azure Firewall transparenta proxyn lyssnar på port 80/443 efter utgående trafik. TCP-ping upprättar en anslutning till brandväggen, som sedan släpper paketet. Det här beteendet har ingen säkerhetspåverkan. Men för att undvika förvirring undersöker vi potentiella ändringar av det här beteendet.

På samma sätt för inkommande DNAT-trafik Azure Firewall kan tcp-anslutningar upprättas via port 80/443. Brandväggen släpper dock och nekar paketet enligt design, såvida det inte uttryckligen tillåts i regler.

Ja. Mer information finns i 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-anslutningarna hålls aktiva och att snabbt stänga dem om det inte finns någon aktivitet. Azure Firewall TCP-tidsgränsen för inaktivitet är fyra minuter. Den här inställningen kan inte konfigureras av användaren, men du kan kontakta Azure Support att öka tidsgränsen för inaktivitet på upp till 30 minuter.

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

Nej, för närvarande måste du distribuera Azure Firewall med en offentlig IP-adress.

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