Vad är Azure Firewall?

  • Artikel

Azure Firewall är en molnbaserad och intelligent nätverksbrandväggssäkerhetstjänst som ger det bästa av skydd mot rashot för dina molnarbetsbelastningar som körs i Azure. Det är en helt tillståndskänslig brandvägg som en tjänst med inbyggd hög tillgänglighet och obegränsad molnskalbarhet. Det ger både öst-väst och nord-syd trafikinspektion. Om du vill veta vad som är öst-västlig och nord-syd trafik, se Öst-väst och nord-syd trafik.

Azure Firewall finns i tre SKU:er: Standard, Premium och Basic.

Azure Firewall Standard

Azure Firewall Standard tillhandahåller L3-L7-filtrering och hotinformationsflöden direkt från Microsoft Cyber Security. Hotinformationsbaserad filtrering kan avisera och neka trafik från/till kända skadliga IP-adresser och domäner som uppdateras i realtid för att skydda mot nya och nya attacker.

Översikt över Firewall Standard

Mer information om brandväggsstandardfunktioner finns i Azure Firewall Standard-funktioner.

Azure Firewall Premium

Azure Firewall Premium har avancerade funktioner som signaturbaserad IDPS för att möjliggöra snabb identifiering av attacker genom att söka efter specifika mönster. Dessa mönster kan innehålla bytesekvenser i nätverkstrafik eller kända skadliga instruktionssekvenser som används av skadlig kod. Det finns mer än 67 000 signaturer i över 50 kategorier som uppdateras i realtid för att skydda mot nya och nya kryphål. Exploateringskategorierna omfattar skadlig kod, nätfiske, myntutvinning och trojanska attacker.

Översikt över Firewall Premium

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

Azure Firewall Basic

Azure Firewall Basic är avsett för små och medelstora kunder (SMB) för att skydda sina Azure-molnmiljöer. Det ger det grundläggande skydd som SMB-kunder behöver till ett överkomligt pris.

Diagram som visar Firewall Basic.

Azure Firewall Basic liknar Firewall Standard, men har följande huvudsakliga begränsningar:

  • Endast stöd för hotinformationsaviseringsläge
  • Fast skalningsenhet för att köra tjänsten på två serverdelsinstanser för virtuella datorer
  • Rekommenderas för miljöer med ett uppskattat dataflöde på 250 Mbit/s

Mer information om Azure Firewall Basic finns i Azure Firewall Grundläggande funktioner.

Jämför funktioner

Om du vill jämföra alla brandväggs-SKU-funktioner läser du Välj rätt Azure Firewall SKU för att uppfylla dina behov.

Azure Firewall Manager

Du kan använda Azure Firewall Manager för att centralt hantera Azure Firewalls i flera prenumerationer. Brandväggshanteraren använder brandväggsprincipen för att tillämpa en gemensam uppsättning nätverk/programregler och konfiguration på brandväggarna i din klientorganisation.

Firewall Manager stöder brandväggar i både VNet- och Virtual WAN-miljöer (Secure Virtual Hub). Säkra virtuella hubbar använder Virtual WAN vägautomatiseringslösningen för att förenkla routning av trafik till brandväggen med bara några få steg.

Mer information om Azure Firewall Manager finns i Azure Firewall Manager.

Prissättning och serviceavtal

Azure Firewall prisinformation finns i Azure Firewall prissättning.

Information om Azure Firewall serviceavtal finns i Azure Firewall serviceavtal.

Regioner som stöds

De regioner som stöds för Azure Firewall finns i Tillgängliga Azure-produkter per region.

Nyheter

Information om vad som är nytt med Azure Firewall finns i Azure-uppdateringar.

Kända problem

Azure Firewall Standard

Azure Firewall Standard har följande kända problem:

Anteckning

Alla problem som gäller Standard gäller även för Premium.

Problem Description Åtgärd
Nätverksfiltreringsregler för icke-TCP-/UDP-protokoll (till exempel ICMP) fungerar inte för Internetbunden trafik Regler för nätverksfiltrering för icke-TCP/UDP-protokoll fungerar inte med SNAT till din offentliga IP-adress. Icke-TCP-/UDP-protokoll stöds mellan ekerundernät och virtuella nätverk. Azure Firewall använder Standard Load Balancer, som för närvarande inte stöder SNAT för IP-protokoll. Vi undersöker alternativ för att stödja det här scenariot i en framtida version.
Saknat PowerShell- och CLI-stöd för ICMP Azure PowerShell och CLI stöder inte ICMP som ett giltigt protokoll i nätverksregler. Det går fortfarande att använda ICMP som ett protokoll via portalen och REST-API:et. Vi arbetar med att lägga till ICMP i PowerShell och CLI snart.
FQDN-taggar kräver att protokoll: port anges Programregler med FQDN-taggar kräver port: protokolldefinition. Du kan använda https som port: protokoll-värde. Vi arbetar med att göra det här fältet valfritt när FQDN-taggar används.
Det går inte att flytta en brandvägg till en annan resursgrupp eller prenumeration Det går inte att flytta en brandvägg till en annan resursgrupp eller prenumeration. Stöd för den här funktionen finns i vår planering. För att kunna flytta en brandvägg till en annan resursgrupp eller prenumeration måste du ta bort den aktuella instansen och återskapa den i den nya resursgruppen eller prenumerationen.
Hotinformationsaviseringar kan maskeras Nätverksregler med mål 80/443 för utgående filtrering maskerar hotinformationsaviseringar när de konfigureras till aviseringsläge. Skapa utgående filtrering för 80/443 med hjälp av programregler. Eller ändra hotinformationsläget till Avisering och Neka.
Azure Firewall DNAT fungerar inte för privata IP-mål Azure Firewall DNAT-stöd är begränsat till utgående/ingress på Internet. DNAT fungerar för närvarande inte för privata IP-mål. Till exempel eker till eker. En korrigering undersöks.
Med skyddade virtuella hubbar kan tillgänglighetszoner endast konfigureras under distributionen. Du kan inte konfigurera Tillgänglighetszoner när en brandvägg med skyddade virtuella hubbar har distribuerats. Det här är avsiktligt.
SNAT för inkommande anslutningar Förutom DNAT är anslutningar via brandväggens offentliga IP-adress (inkommande) SNATed till en av brandväggens privata IP-adresser. Det här kravet idag (även för aktiva/aktiva NVA:er) för att säkerställa symmetrisk routning. Överväg att använda XFF-huvuden för att bevara den ursprungliga källan för HTTP/S. Du kan till exempel använda en tjänst som Azure Front Door eller Azure Application Gateway framför brandväggen. Du kan också lägga till WAF som en del av Azure Front Door och kedja i brandväggen.
SQL FQDN-filtrering stöder endast i proxyläge (port 1433) För Azure SQL Database Azure Synapse Analytics och Azure SQL Managed Instance:

SQL FQDN-filtrering stöds endast i proxyläge (port 1433).

För Azure SQL IaaS:

Om du använder portar som inte är standard kan du ange dessa portar i programreglerna.		 För SQL i omdirigeringsläge (standard om du ansluter inifrån Azure) kan du i stället filtrera åtkomst med hjälp av SQL-tjänsttaggen som en del av Azure Firewall nätverksregler.
Utgående SMTP-trafik på TCP-port 25 blockeras Utgående e-postmeddelanden som skickas direkt till externa domäner (t.ex outlook.com . och gmail.com) på TCP-port 25 kan blockeras av Azure-plattformen. Det här är standardplattformsbeteendet i Azure Azure Firewall inte inför någon mer specifik begränsning. Använd autentiserade SMTP-relätjänster, som vanligtvis ansluter via TCP-port 587, men som också stöder andra portar. Mer information finns i Felsöka utgående SMTP-anslutningsproblem i Azure. För närvarande kanske Azure Firewall kan kommunicera med offentliga IP-adresser med hjälp av utgående TCP 25, men det är inte garanterat att det fungerar och stöds inte för alla prenumerationstyper. För privata IP-adresser som virtuella nätverk, VPN och Azure ExpressRoute stöder Azure Firewall en utgående anslutning av TCP-port 25.
SNAT-portöverbelastning Azure Firewall har för närvarande stöd för 2 496 portar per offentlig IP-adress per instans av vm-skalningsuppsättningar i serverdelen. Som standard finns det två vm-skalningsuppsättningsinstanser. Det finns alltså 4992 portar per flöde (mål-IP, målport och protokoll (TCP eller UDP). Brandväggen skalar upp till högst 20 instanser. Detta är en plattformsbegränsning. Du kan kringgå gränserna genom att konfigurera Azure Firewall distributioner med minst fem offentliga IP-adresser för distributioner som är känsliga för SNAT-överbelastning. Detta ökar SNAT-portarna som är tillgängliga med fem gånger. Allokera från ett IP-adressprefix för att förenkla underordnade behörigheter. För en mer permanent lösning kan du distribuera en NAT-gateway för att övervinna SNAT-portgränserna. Den här metoden stöds för VNET-distributioner.

Mer information finns i Skala SNAT-portar med Azure Virtual Network NAT.
DNAT stöds inte med tvingad tunneltrafik aktiverat Brandväggar som distribueras med tvingad tunneltrafik aktiverad kan inte stödja inkommande åtkomst från Internet på grund av asymmetrisk routning. Detta är avsiktligt på grund av asymmetrisk routning. Retursökvägen för inkommande anslutningar går via den lokala brandväggen, som inte har sett anslutningen upprättas.
Utgående passiv FTP kanske inte fungerar för brandväggar med flera offentliga IP-adresser, beroende på ftp-serverkonfigurationen. Passiv FTP upprättar olika anslutningar för kontroll- och datakanaler. När en brandvägg med flera offentliga IP-adresser skickar utgående data väljer den slumpmässigt en av sina offentliga IP-adresser för källans IP-adress. FTP kan misslyckas när data- och kontrollkanaler använder olika käll-IP-adresser, beroende på ftp-serverkonfigurationen. En explicit SNAT-konfiguration planeras. Under tiden kan du konfigurera FTP-servern så att den accepterar data och styr kanaler från olika käll-IP-adresser (se ett exempel för IIS). Du kan också överväga att använda en enda IP-adress i den här situationen.
Inkommande passiv FTP kanske inte fungerar beroende på FTP-serverkonfigurationen Passiv FTP upprättar olika anslutningar för kontroll- och datakanaler. Inkommande anslutningar på Azure Firewall är SNATed till en av brandväggens privata IP-adresser för att säkerställa symmetrisk routning. FTP kan misslyckas när data- och kontrollkanaler använder olika käll-IP-adresser, beroende på ftp-serverkonfigurationen. Bevara den ursprungliga käll-IP-adressen håller på att undersökas. Under tiden kan du konfigurera FTP-servern så att den accepterar data och styr kanaler från olika käll-IP-adresser.
Aktiv FTP fungerar inte när FTP-klienten måste nå en FTP-server via Internet. Aktiv FTP använder ett PORT-kommando från FTP-klienten som dirigerar FTP-servern till vilken IP- och port som ska användas för datakanalen. Det här PORT-kommandot använder den privata IP-adressen för klienten som inte kan ändras. Trafik på klientsidan som passerar Azure Firewall är NAT för Internetbaserad kommunikation, vilket gör portkommandot som visas som ogiltigt av FTP-servern. Detta är en allmän begränsning för aktiv FTP när den används med NAT på klientsidan.
NetworkRuleHit-måttet saknar en protokolldimension Måttet ApplicationRuleHit tillåter filtreringsbaserat protokoll, men den här funktionen saknas i motsvarande NetworkRuleHit-mått. En korrigering undersöks.
NAT-regler med portar mellan 64000 och 65535 stöds inte Azure Firewall tillåter alla portar i intervallet 1–65535 i nätverk och programregler, men NAT-regler stöder endast portar i intervallet 1–63999. Det här är en aktuell begränsning.
Konfigurationsuppdateringar kan ta i genomsnitt fem minuter En Azure Firewall konfigurationsuppdatering kan ta i genomsnitt tre till fem minuter och parallella uppdateringar stöds inte. En korrigering undersöks.
Azure Firewall använder SNI TLS-huvuden för att filtrera HTTPS- och MSSQL-trafik Om webbläsar- eller serverprogramvaran inte stöder SNI-tillägget (Server Name Indicator) kan du inte ansluta via Azure Firewall. Om webbläsar- eller serverprogramvaran inte stöder SNI kanske du kan styra anslutningen med hjälp av en nätverksregel i stället för en programregel. Se Servernamnsindikator för programvara som stöder SNI.
Det går inte att lägga till brandväggsprinciptaggar med hjälp av portalen eller ARM-mallar (Azure Resource Manager) Azure Firewall Policy har en korrigeringsstödsbegränsning som hindrar dig från att lägga till en tagg med hjälp av Azure Portal- eller ARM-mallarna. Följande fel genereras: Det gick inte att spara taggarna för resursen. En korrigering undersöks. Eller så kan du använda cmdleten Set-AzFirewallPolicy Azure PowerShell för att uppdatera taggar.
IPv6 stöds inte för närvarande Om du lägger till en IPv6-adress i en regel misslyckas brandväggen. Använd endast IPv4-adresser. IPv6-supporten är under utredning.
Det går inte att uppdatera flera IP-grupper med konfliktfel. När du uppdaterar två eller flera IP-grupper som är anslutna till samma brandvägg hamnar en av resurserna i ett feltillstånd. Det här är ett känt problem/en begränsning.

När du uppdaterar en IP-grupp utlöses en uppdatering av alla brandväggar som IPGroup är ansluten till. Om en uppdatering av en andra IP-grupp startas medan brandväggen fortfarande är i uppdateringstillståndet misslyckas IPGroup-uppdateringen.

För att undvika felet måste IP-grupper som är anslutna till samma brandvägg uppdateras en i taget. Tillåt tillräckligt med tid mellan uppdateringar för att brandväggen ska komma ur uppdateringstillståndet .
Det går inte att ta bort RuleCollectionGroups med ARM-mallar. Det går inte att ta bort en RuleCollectionGroup med ARM-mallar och resulterar i fel. Det här är inte en åtgärd som stöds.
DNAT-regel för att tillåta all (*) kommer att SNAT-trafik. Om en DNAT-regel tillåter någon (*) som käll-IP-adress matchar en implicit nätverksregel VNet-VNet trafik och kommer alltid att SNAT trafiken. Det här är en aktuell begränsning.
Det går inte att lägga till en DNAT-regel i en skyddad virtuell hubb med en säkerhetsprovider. Detta resulterar i en asynkron väg för den returnerade DNAT-trafiken, som går till säkerhetsprovidern. Stöds inte.
Ett fel uppstod när fler än 2 000 regelsamlingar skapades. Det maximala antalet NAT-/program- eller nätverksregelsamlingar är 2 000 (Resource Manager gräns). Det här är en aktuell begränsning.
XFF-rubrik i HTTP/S XFF-huvuden skrivs över med den ursprungliga käll-IP-adressen enligt brandväggen. Detta gäller för följande användningsfall:
– HTTP-begäranden
– HTTPS-begäranden med TLS-avslutning		 En korrigering undersöks.
Det går inte att uppgradera till Premium med Tillgänglighetszoner i regionen Sydostasien Du kan för närvarande inte uppgradera till Azure Firewall Premium med Tillgänglighetszoner i regionen Sydostasien. Distribuera en ny Premium-brandvägg i Sydostasien utan Tillgänglighetszoner eller distribuera i en region som stöder Tillgänglighetszoner.
Det går inte att distribuera brandväggen med Tillgänglighetszoner med en nyligen skapad offentlig IP-adress När du distribuerar en brandvägg med Tillgänglighetszoner kan du inte använda en nyligen skapad offentlig IP-adress. Skapa först en ny zonredundant offentlig IP-adress och tilldela sedan den tidigare skapade IP-adressen under brandväggsdistributionen.
Azures privata DNS-zon stöds inte med Azure Firewall Azures privata DNS-zon fungerar inte med Azure Firewall oavsett Azure Firewall DNS-inställningar. Om du vill använda en privat DNS-server använder du Azure Firewall DNS-proxy i stället för en privat DNS-zon i Azure.

Azure Firewall Premium

Azure Firewall Premium har följande kända problem:

Problem Description Åtgärd
ESNI-stöd för FQDN-upplösning i HTTPS Krypterad SNI stöds inte i HTTPS-handskakning. Idag stöder endast Firefox ESNI via anpassad konfiguration. Den föreslagna lösningen är att inaktivera den här funktionen.
Klientcertifieringsautentisering stöds inte Klientcertifikat används för att skapa ett ömsesidigt identitetsförtroende mellan klienten och servern. Klientcertifikat används under en TLS-förhandling. Azure-brandväggen omförhandlar en anslutning till servern och har ingen åtkomst till den privata nyckeln för klientcertifikaten. Ingen
QUIC/HTTP3 QUIC är den nya huvudversionen av HTTP. Det är ett UDP-baserat protokoll över 80 (PLAN) och 443 (SSL). FQDN/URL/TLS-inspektion stöds inte. Konfigurera att skicka UDP 80/443 som nätverksregler.
Ej betrodda kundsignerade certifikat Kundsignerade certifikat är inte betrodda av brandväggen när de har tagits emot från en intranätbaserad webbserver. En korrigering undersöks.
Fel käll-IP-adress i aviseringar med IDPS för HTTP (utan TLS-inspektion). När HTTP-trafik i oformaterad text används och IDPS utfärdar en ny avisering, och målet är en offentlig IP-adress, är den visade käll-IP-adressen fel (den interna IP-adressen visas i stället för den ursprungliga IP-adressen). En korrigering undersöks.
Spridning av certifikat När ett CA-certifikat har tillämpats på brandväggen kan det ta mellan 5 och 10 minuter innan certifikatet börjar gälla. En korrigering undersöks.
Stöd för TLS 1.3 TLS 1.3 stöds delvis. TLS-tunneln från klienten till brandväggen baseras på TLS 1.2 och från brandväggen till den externa webbservern baseras på TLS 1.3. Uppdateringar utreds.
Tillgänglighetszoner för Firewall Premium i regionen Sydostasien Du kan för närvarande inte distribuera Azure Firewall Premium med Tillgänglighetszoner i regionen Sydostasien. Distribuera brandväggen i Sydostasien utan Tillgänglighetszoner eller distribuera i en region som stöder Tillgänglighetszoner.
Förfallodatum för TLSi-mellanliggande CA-certifikat I vissa unika fall kan det mellanliggande CA-certifikatet löpa ut två månader före det ursprungliga förfallodatumet. Förnya det mellanliggande CA-certifikatet två månader före det ursprungliga förfallodatumet. En korrigering undersöks.

Nästa steg