Vad är Azure Firewall?
Azure Firewall är en molnbaserad och intelligent tjänst för nätverksbrandväggssäkerhet som ger det bästa möjliga skydd mot hot för dina molnarbetsbelastningar som körs i Azure. Det är en fullständigt tillståndsfull brandvägg som en tjänst med inbyggd hög tillgänglighet och obegränsad molnskalbarhet. Den tillhandahåller trafikgranskning både öst-väst och nord-syd.
Azure Firewall finns i två SKU:er: Standard och Premium.
Azure Firewall Standard
Azure Firewall Standard tillhandahåller L3-L7-filtrering och hotinformationsflöden direkt från Microsoft Cyber Security. Hotinformationsbaserad filtrering kan varna 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.
Mer information om Brandväggsstandardfunktioner finns i Azure Firewall Standard-funktioner.
Azure Firewall Premium
Azure Firewall Premium innehåller 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 fler än 58 000 signaturer i över 50 kategorier som uppdateras i realtid för att skydda mot nya och nya kryphål. Sårbarhetskategorierna omfattar skadlig kod, nätfiske, myntutvinning och trojanattacker.
Mer information om brandväggsfunktioner Premium finns i Azure Firewall Premium funktioner.
Azure Firewall Manager
Du kan använda Azure Firewall Manager hantera Azure Firewall centralt över flera prenumerationer. Firewall Manager använder brandväggsprincipen för att tillämpa en gemensam uppsättning nätverks-/programregler och konfiguration på brandväggarna i din klientorganisation.
Firewall Manager har stöd för brandväggar i både VNet- och Virtual WAN-miljöer (Secure Virtual Hub). Säkra virtuella hubbar använder Virtual WAN för att förenkla routning av trafik till brandväggen med några klick.
Mer information om Azure Firewall Manager finns i Azure Firewall Manager.
Priser och serviceavtal
Mer Azure Firewall prisinformation finns i Azure Firewall prissättning.
Information Azure Firewall serviceavtal finns i Azure Firewall serviceavtal.
Nyheter
Information om vad som är nytt med Azure Firewall finns i Azure-uppdateringar.
Kända problem
Azure Firewall har följande kända problem:
| Problem | Beskrivning | Åtgärd |
|---|---|---|
| Nätverksfiltreringsregler för icke-TCP-/UDP-protokoll (till exempel ICMP) fungerar inte för Internetbunden trafik | Nätverksfiltreringsregler 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 utforskar 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 protokoll via portalen och REST API. 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 finns inte stöd för 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. |
| Aviseringar om hotinformation kan bli maskerade | Nätverksregler med mål 80/443 för utgående filtrering maskerar hotinformationsaviseringar när de är konfigurerade för endast 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 från Internet. DNAT fungerar för närvarande inte för privata IP-mål. Till exempel eker till eker. | Det här är en aktuell begränsning. |
| Det går inte att ta bort den första offentliga IP-konfigurationen | Varje Azure Firewall offentlig IP-adress tilldelas till en IP-konfiguration. Den första IP-konfigurationen tilldelas under brandväggsdistributionen och innehåller vanligtvis även en referens till brandväggsundernätet (om det inte uttryckligen har konfigurerats annorlunda via en malldistribution). Du kan inte ta bort den här IP-konfigurationen eftersom den skulle ta bort brandväggen. Du kan fortfarande ändra eller ta bort den offentliga IP-adress som är associerad med den här IP-konfigurationen om brandväggen har minst en annan offentlig IP-adress tillgänglig att använda. | Det här är avsiktligt. |
| Tillgänglighetszoner kan bara konfigureras under distributionen. | Tillgänglighetszoner kan bara konfigureras under distributionen. Du kan inte konfigurera Tillgänglighetszoner när en brandvägg har distribuerats. | Det här är avsiktligt. |
| SNAT på 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 Azure Front Door eller Azure Application Gateway framför brandväggen. Du kan också lägga till WAF som en del Azure Front Door och kedja i brandväggen. |
| SQL FQDN-filtreringsstöd 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 icke-standardportar 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 Azure Firewall nätverksregler. |
| Utgående SMTP-trafik på TCP-port 25 blockeras | Utgående e-postmeddelanden som skickas direkt till externa domäner (till exempel och ) på outlook.com gmail.com TCP-port 25 blockeras av Azure Firewall. Det här är standardplattformsbeteendet i Azure. |
Använd autentiserade SMTP-relätjänster, som vanligtvis ansluter via TCP-port 587, men har även stöd för andra portar. Mer information finns i Felsöka problem med utgående SMTP-anslutning i Azure. För närvarande Azure Firewall kan kommunicera med offentliga IP-adresser med hjälp av utgående TCP 25, men det fungerar inte 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 stöder för närvarande 1 024 portar per offentlig IP-adress per instans av VM-skalningsuppsättning på serverdatorn. Som standard finns det två instanser av VM-skalningsuppsättningen. | Det här är en SLB-begränsning och vi letar ständigt efter möjligheter att öka gränserna. Under tiden rekommenderar vi att du konfigurerar Azure Firewall distributioner med minst fem offentliga IP-adresser för distributioner som är sårbara för SNAT-utmattning. Detta ökar de tillgängliga SNAT-portarna med fem gånger. Allokera från ett IP-adressprefix för att förenkla underordnade behörigheter. |
| DNAT stöds inte med tvingad tunneling aktiverat | Brandväggar som distribueras med tvingad tunneldirigering aktiverad stöder inte inkommande åtkomst från Internet på grund av asymmetrisk routning. | Detta är enligt design 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ättad. |
| 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 dess offentliga IP-adresser för källans IP-adress. FTP kan misslyckas när data och kontrollkanaler använder olika IP-källadresser, beroende på din FTP-serverkonfiguration. | 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 enskild 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 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 IP-källadresser, beroende på din FTP-serverkonfiguration. | Vi undersöker bevarandet av den ursprungliga KÄLL-IP-adressen. Under tiden kan du konfigurera FTP-servern så att den accepterar data och kontrollkanaler från olika IP-källadresser. |
| 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 vilken IP-adress och port som ska användas för datakanalen. Det här PORT-kommandot använder klientens privata IP-adress som inte kan ändras. Trafik på klientsidan som går genom Azure Firewall är NAT för Internetbaserad kommunikation, vilket gör PORT-kommandot som betraktas som ogiltigt av FTP-servern. | Det här är en allmän begränsning för aktiv FTP när den används tillsammans med NAT på klientsidan. |
| NetworkRuleHit-mått saknar en protokolldimension | ApplicationRuleHit-måttet 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 alla portar i intervallet 1–65535 i nätverks- 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 (Servernamnindikator) kan du inte ansluta via Azure Firewall. | Om webbläsare eller serverprogramvara inte stöder SNI kan du eventuellt styra anslutningen med hjälp av en nätverksregel i stället för en programregel. Se Servernamnindikator programvara som stöder SNI. |
| Anpassad DNS fungerar inte med tvingad tunneling | Om tvingad tunneling är aktiverat fungerar inte anpassad DNS. | En korrigering undersöks. |
| Start/stopp fungerar inte med en brandvägg som konfigurerats i tvingad tunnelläge | Start/stopp fungerar inte med Azure Firewall som konfigurerats i tvingad tunnelläge. Försök att starta Azure Firewall med konfigurerad tvingad tunneling resulterar i följande fel: Set-AzFirewall: AzureFirewall FW-xx-hanterings-IP-konfiguration kan inte läggas till i en befintlig brandvägg. Distribuera om med en IP-hanteringskonfiguration om du vill använda stöd för tvingad tunneldirigering. StatusCode: 400 ReasonPhrase: Felaktig begäran |
Under undersökning. Som en lösning kan du ta bort den befintliga brandväggen och skapa en ny med samma parametrar. |
| Det går inte att lägga till brandväggsprinciptaggar med hjälp av portalen Azure Resource Manager arm-mallar | Azure Firewall princip har en begränsning för korrigeringsstöd som förhindrar att du lägger till en tagg med hjälp av Azure Portal eller ARM-mallar. Följande fel genereras: Det gick inte att spara taggarna för resursen. | En korrigering undersöks. Du kan också använda cmdleten Azure PowerShell för Set-AzFirewallPolicy 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-stöd är under undersökning. |
| Uppdatering av flera IP-grupper misslyckas med konfliktfel. | När du uppdaterar två eller flera IP-grupper som är kopplade till samma brandvägg hamnar en av resurserna i ett misslyckat tillstånd. | Det här är ett känt problem/en begränsning. När du uppdaterar en IP-grupp utlöses en uppdatering för alla brandväggar som IPGroup är kopplad till. Om en uppdatering till en andra IP-grupp startas när brandväggen fortfarande är i uppdateringstillstånd misslyckas IPGroup-uppdateringen. För att undvika felet måste IP-grupper som är kopplade till samma brandvägg uppdateras en i taget. Låt det ta tillräckligt med tid mellan uppdateringarna för att brandväggen ska kunna ta sig 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 det resulterar i fel. | Det här är inte en åtgärd som stöds. |
| DNAT-regeln för att tillåta alla (*) kommer att SNAT-trafik. | Om en DNAT-regel tillåter någon (*) som IP-källadress kommer en implicit nätverksregel att matcha VNet-VNet trafik och SNAT-trafiken alltid. | Det här är en aktuell begränsning. |
| Att lägga till en DNAT-regel till en skyddad virtuell hubb med en säkerhetsprovider stöds inte. | Detta resulterar i en asynkron väg för den returnerande DNAT-trafiken, som går till säkerhetsleverantören. | Stöds inte. |
| Fel påträffades när du skapade fler än 2 000 regelsamlingar. | Det maximala antalet NAT/program- eller nätverksregelsamlingar är 2 000 (Resource Manager gräns). | Det här är en aktuell begränsning. |
| Det går inte att se nätverksregelnamnet i Azure Firewall loggar | Azure Firewall loggdata för nätverksregel visar inte regelnamnet för nätverkstrafik. | En funktion undersöks för att stödja detta. |