Domande frequenti su Firewall di Azure

Generale

Che cos'è Firewall di Azure?

Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che protegge le risorse Rete virtuale di Azure. È un firewall con stato completo distribuito come servizio con disponibilità elevata e scalabilità cloud senza limiti. È possibile creare, applicare e registrare criteri di connettività di applicazione e di rete in modo centralizzato tra le sottoscrizioni e le reti virtuali.

Quali funzionalità supportano Firewall di Azure?

Per un elenco dettagliato delle funzionalità di Firewall di Azure, vedere Firewall di Azure features.

Qual è il modello di distribuzione tipico per Firewall di Azure?

Firewall di Azure possono essere distribuiti in qualsiasi rete virtuale. Tuttavia, viene in genere distribuito in una rete virtuale centrale in un modello hub-spoke, con altre reti virtuali con peering. Il percorso predefinito dalle reti virtuali interconnesse è impostato per puntare a questa rete virtuale del firewall centrale. Anche se il peering di rete virtuale globale è supportato, non è consigliabile a causa di potenziali problemi di prestazioni e latenza tra aree. Per prestazioni ottimali, distribuire un firewall per area.

Questo modello consente il controllo centralizzato su più reti virtuali spoke in sottoscrizioni diverse e offre risparmi sui costi evitando la necessità di dover distribuire un firewall in ogni rete virtuale. I risparmi sui costi devono essere valutati rispetto ai costi di peering associati in base ai modelli di traffico.

Come è possibile distribuire Firewall di Azure?

Firewall di Azure possono essere distribuiti usando il portale di Azure, PowerShell, l'API REST o i modelli. Per istruzioni dettagliate, vedere Tutorial: Distribuire e configurare Firewall di Azure usando il portale di Azure.

Quali sono alcuni concetti chiave Firewall di Azure?

Firewall di Azure usa regole e raccolte di regole. Una raccolta di regole è un set di regole con lo stesso ordine e priorità. Le raccolte di regole vengono eseguite in ordine di priorità. Le raccolte regole DNAT hanno priorità più alta rispetto alle raccolte di regole di rete, che a loro volta hanno priorità più alta rispetto alle raccolte di regole dell'applicazione. L'elaborazione delle regole non avviene a ciclo continuo.

Sono disponibili tre tipi di raccolte di regole:

• Regole dell'applicazione: configurare nomi di dominio completi (FQDN) a cui è possibile accedere da una rete virtuale.
• Regole di rete: configurare regole con indirizzi di origine, protocolli, porte di destinazione e indirizzi di destinazione.
• Regole NAT: configurare le regole DNAT per consentire connessioni Internet o Intranet in ingresso (anteprima).

Per altre informazioni, vedere Configurare le regole di Firewall di Azure.

Quali servizi di registrazione e analisi supportano Firewall di Azure?

Firewall di Azure si integra con Monitoraggio di Azure per la visualizzazione e l'analisi dei log. I log possono essere inviati a Log Analytics, Archiviazione di Azure o Hub eventi e analizzati usando strumenti come Log Analytics, Excel o Power BI. Per altre informazioni, vedere Tutorial: Monitorare i log Firewall di Azure.

In che modo Firewall di Azure differisce dalle appliance di rete virtuali nel marketplace?

Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che protegge le risorse della rete virtuale. È un firewall con stato completo distribuito come servizio con disponibilità elevata e scalabilità cloud senza limiti. È preintegrato con provider di sicurezza come servizio (SECaaS) di terze parti per migliorare la sicurezza per la rete virtuale e le connessioni Internet di succursale. Per altre informazioni, vedere Azure sicurezza di rete.

Qual è la differenza tra il WAF del Gateway Applicazione e Firewall di Azure?

Il WAF del gateway delle applicazioni offre una protezione in ingresso centralizzata per le applicazioni web contro exploit e vulnerabilità comuni. Firewall di Azure fornisce protezione in ingresso per i protocolli non HTTP/S (ad esempio, RDP, SSH, FTP), la protezione a livello di rete in uscita per tutte le porte e i protocolli e la protezione a livello di applicazione per HTTP/S in uscita.

Qual è la differenza tra gruppi di sicurezza di rete e Firewall di Azure?

Firewall di Azure completa i gruppi di sicurezza di rete per offrire una migliore sicurezza di rete "difesa in profondità". Gli NSG offrono un filtro del traffico a livello di rete distribuito per limitare il traffico all'interno delle reti virtuali in ogni sottoscrizione. Firewall di Azure offre una rete centralizzata e completamente con stato e una protezione a livello di applicazione tra sottoscrizioni e reti virtuali.

I gruppi di sicurezza di rete (NSG) sono supportati in AzureFirewallSubnet?

Firewall di Azure è un servizio gestito con più livelli di protezione, inclusa la protezione della piattaforma con gruppi di sicurezza di rete a livello di scheda di interfaccia di rete (non visualizzabile). I gruppi di sicurezza di rete a livello di subnet non sono necessari in AzureFirewallSubnet e sono disabilitati per evitare interruzioni del servizio.

Qual è il valore aggiunto di Firewall di Azure con endpoint privati?

Gli endpoint privati sono un componente di collegamento privato, una tecnologia che consente di interagire con i servizi PaaS Azure usando indirizzi IP privati anziché quelli pubblici. Firewall di Azure può essere usato per impedire l'accesso agli indirizzi IP pubblici, evitando quindi l'esfiltrazione di dati ai servizi Azure non sfruttando collegamento privato, nonché per implementare criteri senza attendibilità definendo chi nell'organizzazione deve accedere a tali servizi PaaS Azure, dal momento che collegamento privato Per impostazione predefinita viene aperto l'accesso alla rete per l'intera rete aziendale.

La progettazione corretta per esaminare il traffico verso endpoint privati con Firewall di Azure dipende dall'architettura di rete, è possibile trovare altri dettagli nell'articolo Firewall di Azure scenari per esaminare il traffico destinato a un endpoint privato.

Qual è il valore aggiunto di Firewall di Azure con gli endpoint del servizio di rete virtuale?

Rete virtuale gli endpoint di servizio sono un'alternativa a collegamento privato per controllare l'accesso di rete ai servizi PaaS Azure. Anche se il client usa ancora indirizzi IP pubblici per accedere al servizio PaaS, la subnet di origine viene resa visibile in modo che il servizio PaaS di destinazione possa implementare regole di filtro e limitare l'accesso per ogni subnet. È possibile trovare un confronto dettagliato tra entrambi i meccanismi in Confrontare endpoint privati ed endpoint di servizio.

Firewall di Azure regole dell'applicazione possono essere usate per assicurarsi che non venga eseguita alcuna esfiltrazione di dati ai servizi non autorizzati e implementare criteri di accesso con una maggiore granularità oltre il livello di subnet. In genere, gli endpoint servizio di rete virtuale devono essere abilitati nella subnet del client che si connetterà a un servizio Azure. Tuttavia, quando si esamina il traffico verso gli endpoint di servizio con Firewall di Azure, è necessario abilitare l'endpoint di servizio corrispondente nella subnet di Firewall di Azure e disabilitarlo nella subnet del client effettivo (in genere una rete virtuale spoke). In questo modo è possibile usare le regole dell'applicazione in Firewall di Azure per controllare a quali servizi Azure i carichi di lavoro Azure avranno accesso.

Qual è il prezzo per Firewall di Azure?

Per informazioni dettagliate sui prezzi, vedere Prezzi di Firewall di Azure.

Quali sono i limiti noti del servizio per Firewall di Azure?

Per i limiti del servizio, vedere Azure sottoscrizione e limiti del servizio, quote e vincoli.

Dove Firewall di Azure archivia i dati dei clienti?

Firewall di Azure non sposta o archivia i dati dei clienti all'esterno dell'area in cui viene distribuita.

Firewall di Azure negli hub virtuali protetti (vWAN) è supportato in Qatar?

No, Firewall di Azure negli hub virtuali protetti (vWAN) non è attualmente supportato in Qatar.

Capacità e funzionalità supportate

Firewall di Azure supporta il filtro del traffico in ingresso?

Sì, Firewall di Azure supporta sia il filtro del traffico in ingresso che quello in uscita. Il filtro in ingresso viene in genere usato per protocolli non HTTP, ad esempio RDP, SSH e FTP. Per il traffico HTTP e HTTPS in ingresso, è consigliabile usare un web application firewall come Web application firewall di Azure (WAF) o l'offload TLS e le funzionalità di ispezione approfondita dei pacchetti di Firewall di Azure Premium.

Firewall di Azure Basic supporta il tunneling forzato?

Sì, Firewall di Azure Basic supporta il tunneling forzato.

Perché un ping TCP o uno strumento simile sembra connettersi a un FQDN di destinazione anche quando nessuna regola consente il traffico?

Un ping TCP non si connette effettivamente al nome di dominio completo di destinazione. Firewall di Azure blocca le connessioni a qualsiasi indirizzo IP o FQDN di destinazione, a meno che non sia esplicitamente consentito da una regola.

Nel caso di un ping TCP, se nessuna regola consente il traffico, il firewall stesso risponde alla richiesta ping TCP del client. Questa risposta non raggiunge l'indirizzo IP o il nome di dominio completo di destinazione e non viene registrato. Se una regola di rete consente esplicitamente l'accesso all'indirizzo IP o al nome di dominio completo di destinazione, la richiesta ping raggiunge il server di destinazione e la risposta viene inoltrata al client. Questo evento viene registrato nel log delle regole di rete.

Firewall di Azure supporta il peering BGP?

No, Firewall di Azure non supporta il peering BGP in modo nativo. Tuttavia, la funzionalità Autolearn route SNAT usa indirettamente BGP tramite Server di route Azure.

È possibile Firewall di Azure passare pacchetti ESP (VPN IPSec)?

Firewall di Azure non supporta in modo nativo ESP (Incapsuling Security Payload), ma è possibile consentire il traffico ESP configurando una regola di rete come indicato di seguito:

configurazione Firewall di Azure (regola di rete):

• Protocollo: qualsiasi
• Porta di origine: * (Qualsiasi)
• Porta di destinazione: * (Qualsiasi)
• Origine/Destinazione: specificare gli indirizzi IP in base alle esigenze

Questa configurazione consente ai pacchetti ESP (numero di protocollo IP 50) e ad altri traffico non TCP/UDP di corrispondere alla regola. Si noti tuttavia che Firewall di Azure non controlla i payload ESP.

Reference: se si usa un gruppo di sicurezza di rete (gruppo di sicurezza di rete) anziché Firewall di Azure: NSG non fornisce un'opzione diretta per specificare ESP (numero di protocollo IP 50), ma i pacchetti ESP possono essere consentiti usando le impostazioni seguenti:

• Protocollo: qualsiasi
• Porta: * (Qualsiasi)
• Origine/Destinazione: specificare gli indirizzi IP in base alle esigenze

Raccomandazioni:

• Per le configurazioni VPN IPsec, è consigliabile usare Gateway VPN di Azure.
• Prendere in considerazione l'uso di un modello di appliance virtuale di rete (NVA) a seconda dei requisiti.

Gestione e configurazione

Come posso arrestare e avviare Firewall di Azure?

È possibile usare Azure PowerShell per deallocare e allocare il Firewall di Azure. Il processo varia a seconda della configurazione.

Per un firewall senza una scheda di interfaccia di rete di gestione:

# Stop the 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

Per un firewall con una scheda di interfaccia di rete di gestione:

# Stop the 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"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Per un firewall in un hub virtuale protetto:

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

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Nota

Quando si arresta e avvia il firewall, la fatturazione si arresta e inizia di conseguenza. Tuttavia, l'indirizzo IP privato può cambiare, che può influire sulla connettività se sono configurate tabelle di route.

Come è possibile configurare le zone di disponibilità dopo la distribuzione?

È consigliabile configurare le zone di disponibilità durante la distribuzione iniziale. Tuttavia, è possibile riconfigurarli dopo la distribuzione se:

• Il firewall viene distribuito in una rete virtuale (non supportato negli hub virtuali protetti).
• La regione supporta le zone di disponibilità.
• Tutti gli indirizzi IP pubblici collegati sono configurati con le stesse zone.

Per riconfigurare le zone di disponibilità:

1. Deallocare il firewall:

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

2. Aggiornare la configurazione della zona e allocare il 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"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Esistono restrizioni del gruppo di risorse firewall Azure?

Sì:

• Il Firewall di Azure e la rete virtuale devono trovarsi nello stesso gruppo di risorse.
• L'indirizzo IP pubblico può trovarsi in un gruppo di risorse diverso.
• Tutte le risorse (firewall Azure, rete virtuale, IP pubblico) devono trovarsi nella stessa sottoscrizione.

Che cosa significa lo stato di provisioning **Non riuscito**?

Uno stato di approvvigionamento non riuscito indica che un aggiornamento della configurazione non è riuscito in una o più istanze back-end. Il Firewall di Azure rimane operativo, ma la configurazione potrebbe non essere coerente. Ripetere l'aggiornamento fino a quando lo stato di provisioning non viene modificato in Operazione completata.

In che modo Firewall di Azure gestisce gli errori pianificati di manutenzione e non pianificati?

Firewall di Azure usa una configurazione attiva-attiva con più nodi di back-end. Durante la manutenzione pianificata, il drenaggio delle connessioni garantisce aggiornamenti senza interruzioni. Per gli errori non pianificati, un nuovo nodo sostituisce quello non riuscito e la connettività viene in genere ripristinata entro 10 secondi.

Esiste un limite di caratteri per un nome di firewall?

Sì, i nomi del firewall sono limitati a 50 caratteri.

Perché Firewall di Azure richiede una dimensione di subnet /26?

Una subnet /26 garantisce indirizzi IP sufficienti per il ridimensionamento, quando l'Firewall di Azure effettua il provisioning di istanze di macchine virtuali aggiuntive.

È necessario modificare la dimensione della subnet del firewall in base alla scalabilità del servizio?

No, una subnet /26 è sufficiente per tutti gli scenari di ridimensionamento.

Come è possibile aumentare la velocità effettiva del firewall?

Firewall di Azure ridimensiona automaticamente in base all'utilizzo della CPU, alla velocità effettiva e al numero di connessioni. La capacità di velocità effettiva varia da 2,5 a 3 Gbps inizialmente a 30 Gbps (SKU Standard) o da 100 Gbps (SKU Premium).

Sono previsti limiti per il numero di indirizzi IP supportati da gruppi IP?

Sì. Per informazioni dettagliate, vedere Azure sottoscrizione e limiti del servizio, quote e vincoli.

È possibile spostare un gruppo IP in un altro gruppo di risorse?

No, lo spostamento di un gruppo IP in un altro gruppo di risorse non è attualmente supportato.

Qual è il timeout di inattività TCP per Firewall di Azure?

Un comportamento standard di un firewall di rete è garantire che le connessioni TCP siano mantenute attive e chiuderle tempestivamente in assenza di attività. Il timeout di inattività TCP di Firewall di Azure è di quattro minuti. Questa impostazione non è configurabile dall'utente, ma è possibile contattare Azure supporto tecnico per aumentare il timeout di inattività per le connessioni in ingresso e in uscita fino a 15 minuti. Il timeout di inattività per il traffico est-ovest non può essere modificato.

Se un periodo di inattività è più lungo del valore di timeout, non vi sono garanzie che venga mantenuta la sessione TCP o HTTP. Una prassi comune consiste nell'usare un meccanismo TCP keep-alive. Questa pratica mantiene la connessione attiva per un periodo più lungo. Per altre informazioni, vedere gli esempi .NET.

È possibile distribuire Firewall di Azure senza un indirizzo IP pubblico?

Sì, ma è necessario configurare il firewall in modalità Tunneling forzato. Questa configurazione crea un'interfaccia di gestione con un indirizzo IP pubblico usato da Firewall di Azure per le operazioni. Tale indirizzo IP pubblico è destinato al traffico di gestione. Viene usato esclusivamente dalla piattaforma Azure e non può essere usato per altri scopi. La rete del percorso dati del tenant può essere configurata senza un indirizzo IP pubblico ed è possibile forzare il tunneling del traffico Internet verso un altro firewall o bloccarlo completamente.

Esiste un modo per eseguire automaticamente il backup di Firewall di Azure e criteri?

Sì. Per altre informazioni, vedere Backup Firewall di Azure e Firewall di Azure Policy con Logic Apps.

Connettività e routing

Come si configura Firewall di Azure con gli endpoint di servizio?

Per l'accesso sicuro ai servizi PaaS, è consigliabile usare gli endpoint di servizio. È possibile scegliere di abilitare gli endpoint di servizio nella subnet Firewall di Azure e disabilitarli nelle reti virtuali spoke connesse. In questo modo è possibile sfruttare entrambe le funzionalità, ovvero sicurezza degli endpoint di servizio e registrazione centrale per tutto il traffico.

È possibile che Firewall di Azure in una rete virtuale di hub inoltri e filtri il traffico di rete tra più reti virtuali spoke?

Sì, è possibile usare Firewall di Azure in una rete virtuale hub per instradare e filtrare il traffico tra più reti virtuali spoke. Per il corretto funzionamento di questo scenario, le subnet in ognuna delle reti virtuali spoke devono avere una route definita dall'utente (UDR) che punti all'Firewall di Azure come gateway predefinito.

Firewall di Azure può inoltrare e filtrare il traffico di rete tra le subnet nella stessa rete virtuale o in reti virtuali connesse in peering?

Sì. Tuttavia, la configurazione delle UDRs per reindirizzare il traffico tra sottoreti nella stessa rete virtuale richiede maggiore attenzione. Anche se l'uso dell'intervallo di indirizzi di rete virtuale come prefisso di destinazione per l'UDR è sufficiente, questo instrada anche tutto il traffico da una macchina a un'altra nella stessa subnet attraverso l'istanza di Firewall di Azure. Per evitare questo problema, includere una route per la subnet nel routing definito dall'utente con un tipo di hop successivo di rete virtuale. La gestione di queste route può essere complessa e soggetta a errori. Il metodo consigliato per la segmentazione della rete interna prevede l'uso di gruppi di sicurezza di rete, che non richiedono routing definiti dall'utente.

Firewall di Azure effettua SNAT in uscita tra reti private?

Firewall di Azure non esegue SNAT quando l'indirizzo IP di destinazione è un intervallo IP privato per IANA RFC 1918 o IANA RFC 6598 per le reti private. Se l'organizzazione utilizza un intervallo di indirizzi IP pubblici per le reti private, Firewall di Azure effettua il SNAT del traffico verso uno degli indirizzi IP privati del firewall in AzureFirewallSubnet. È possibile configurare Firewall di Azure per non eseguire il SNAT del vostro intervallo di indirizzi IP pubblici. Per ulteriori informazioni, vedere intervalli di indirizzi IP SNAT privati di Firewall di Azure.

Inoltre, al traffico elaborato dalle regole dell'applicazione viene sempre applicata la conversione SNAT. Se si desidera visualizzare l'indirizzo IP sorgente originale nei log relativi al traffico FQDN, è possibile utilizzare le regole di rete con il nome FQDN di destinazione.

Il tunneling forzato o il concatenamento a un'appliance virtuale di rete è supportato?

Il tunneling forzato è supportato quando si crea un nuovo firewall ed è supportato anche per i firewall esistenti aggiungendo una scheda di interfaccia di rete di gestione per il tunneling forzato. Per ulteriori dettagli sulle nuove implementazioni, vedere Firewall di Azure forced tunneling. Per i firewall esistenti, vedere Firewall di Azure Management NIC.

Firewall di Azure deve avere connettività Internet diretta. Se AzureFirewallSubnet apprende una route predefinita alla rete locale tramite BGP è necessario sostituirla con una route UDR 0.0.0.0/0 con il valore NextHopType impostato come Internet per mantenere connettività diretta a Internet.

Se la configurazione richiede il tunneling forzato in una rete locale ed è possibile determinare i prefissi IP di destinazione per le destinazioni Internet, è possibile configurare questi intervalli con la rete locale come hop successivo tramite una route definita dall'utente in AzureFirewallSubnet. In alternativa, per definire queste route, è possibile usare BGP.

Come funzionano i caratteri jolly negli URL di destinazione e nei nomi FQDN di destinazione nelle regole dell'applicazione?

• URL : gli asterischi funzionano quando vengono posizionati sul lato più a destra o a sinistra. Se si trova a sinistra, non può far parte del FQDN.
• FQDN : gli asterischi funzionano quando vengono posizionati sul lato più a sinistra.
• GENERALE - Gli asterischi sul lato sinistro indicano letteralmente che qualsiasi cosa a sinistra corrisponde, cioè vengono abbinati più sottodomini e/o possibili varianti indesiderate di nomi di dominio. Vedere gli esempi seguenti.

Esempi:

TIPO	Regola	Supportato?	Esempi positivi
URL di destinazione	www.contoso.com	Sì	www.contoso.com www.contoso.com/
URL di destinazione	*.contoso.com	Sì	any.contoso.com/ sub1.any.contoso.com
URL di destinazione	*contoso.com	Sì	example.anycontoso.com sub1.example.contoso.com contoso.com Avviso: questo utilizzo di wildcard consente anche variazioni potenzialmente indesiderate/rischiose, come th3re4lcontoso.com, quindi usare con cautela.
URL di destinazione	www.contoso.com/test	Sì	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
URL di destinazione	www.contoso.com/test/*	Sì	www.contoso.com/test/anything Nota: www.contoso.com/testnon corrisponde (ultima barra)
URL di destinazione	www.contoso.*/test/*	NO
URL di destinazione	www.contoso.com/test?example=1	NO
URL di destinazione	www.contoso.*	NO
URL di destinazione	www.*contoso.com	NO
URL di destinazione	www.contoso.com:8080	NO
URL di destinazione	*.contoso.*	NO
FQDN di destinazione	www.contoso.com	Sì	www.contoso.com
FQDN di destinazione	*.contoso.com	Sì	any.contoso.com Nota: se si vuole consentire contoso.comin modo specifico , è necessario includere contoso.com nella regola. In caso contrario, la connessione verrà interrotta per impostazione predefinita perché la richiesta non soddisfa alcuna regola.
FQDN di destinazione	*contoso.com	Sì	example.anycontoso.com contoso.com
FQDN di destinazione	www.contoso.*	NO
FQDN di destinazione	*.contoso.*	NO

Firewall di Azure consente l'accesso alle Active Directory per impostazione predefinita?

No. Firewall di Azure blocca l'accesso Active Directory per impostazione predefinita. Per consentire l'accesso, configurare il tag del servizio AzureActiveDirectory. Per altre informazioni, vedere tag del servizio Firewall di Azure.

È possibile escludere un FQDN o un indirizzo IP dal filtro basato su Threat Intelligence di Firewall di Azure?

Sì, è possibile usare Azure PowerShell per farlo:

# 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

Perché un ping TCP e strumenti simili si connettono correttamente a un FQDN di destinazione anche quando nessuna regola su Firewall di Azure consente tale traffico?

Un ping TCP non si connette effettivamente al nome di dominio completo di destinazione. Firewall di Azure non consente una connessione a un indirizzo IP/FQDN di destinazione, a meno che non esista una regola esplicita che lo consenta.

Il ping TCP è un caso d'uso univoco in cui, se non esiste alcuna regola consentita, il firewall stesso risponde alla richiesta di ping TCP del client anche se il ping TCP non raggiunge l'indirizzo IP o il nome di dominio completo della destinazione. In questo caso, l'evento non viene registrato. Se esiste una regola di rete che consente l'accesso all'indirizzo IP o al nome di dominio completo di destinazione, la richiesta di ping raggiunge il server di destinazione e la sua risposta viene inoltrata al di nuovo al client. Questo evento viene registrato nel log delle regole di rete.

Perché il ping TCP e strumenti simili si connettono correttamente a un indirizzo FQDN/IP di destinazione sulle porte 80, 443 e 1433, ma non vengono osservati nei log di Firewall di Azure?

Firewall di Azure funge da listener passivo per le porte 80, 443 e 1433. Firewall di Azure non registra i pacchetti TCP SYN su queste porte, a meno che non sia presente traffico dell'applicazione. La richiesta HTTP GET e il client hello TLS sono registrati in Firewall di Azure.

Sono previsti limiti per il numero di indirizzi IP supportati da gruppi IP?

Sì. Per ulteriori informazioni, vedere sottoscrizione di Azure e limiti del servizio, quote e vincoli

È possibile spostare un gruppo IP in un altro gruppo di risorse?

No, lo spostamento di un gruppo IP in un altro gruppo di risorse non è attualmente supportato.

Qual è il timeout di inattività TCP per Firewall di Azure?

Un comportamento standard di un firewall di rete è garantire che le connessioni TCP siano mantenute attive e chiuderle tempestivamente in assenza di attività. Il timeout di inattività TCP di Firewall di Azure è di quattro minuti. Questa impostazione non è configurabile dall'utente, ma è possibile contattare Azure supporto tecnico per aumentare il timeout di inattività per le connessioni in ingresso e in uscita fino a 15 minuti. Il timeout di inattività per il traffico est-ovest non può essere modificato.

Se un periodo di inattività è più lungo del valore di timeout, non vi sono garanzie che venga mantenuta la sessione TCP o HTTP. Una prassi comune consiste nell'usare un meccanismo TCP keep-alive. Questa pratica mantiene la connessione attiva per un periodo più lungo. Per altre informazioni, vedere gli esempi .NET.

È possibile distribuire Firewall di Azure senza un indirizzo IP pubblico?

Sì, ma è necessario configurare il firewall in modalità Tunneling forzato. Questa configurazione crea un'interfaccia di gestione con un indirizzo IP pubblico usato da Firewall di Azure per le operazioni. Tale indirizzo IP pubblico è destinato al traffico di gestione. Viene usato esclusivamente dalla piattaforma Azure e non può essere usato per altri scopi. La rete del percorso dati del tenant può essere configurata senza un indirizzo IP pubblico ed è possibile forzare il tunneling del traffico Internet verso un altro firewall o bloccarlo completamente.

Dove Firewall di Azure archivia i dati dei clienti?

Firewall di Azure non sposta o archivia i dati dei clienti dall'area in cui viene distribuita.

Esiste un modo per eseguire automaticamente il backup di Firewall di Azure e criteri?

Sì. Per altre informazioni, vedere Backup Firewall di Azure e Firewall di Azure Policy con Logic Apps.

Firewall di Azure negli hub virtuali protetti (vWAN) è supportato in Qatar?

No, attualmente Firewall di Azure negli hub virtuali protetti (vWAN) non è supportato in Qatar.

Quante connessioni parallele possono supportare Firewall di Azure?

Firewall di Azure usa Macchine virtuali di Azure sottostanti con un limite massimo di connessioni. Il numero totale di connessioni attive per ogni macchina virtuale è 250.000.

Il limite totale per ogni firewall corrisponde al limite di connessioni della macchina virtuale (250.000) x il numero di macchine virtuali nel pool back-end del firewall. Firewall di Azure inizia con due macchine virtuali e aumenta il numero di istanze in base all'utilizzo e alla velocità effettiva della CPU.

Qual è il comportamento di riutilizzo delle porte TCP/UDP SNAT in Firewall di Azure?

Firewall di Azure attualmente utilizza porte sorgente TCP/UDP per il traffico SNAT in uscita, senza tempi di inattività. Quando una connessione TCP/UDP viene chiusa, la porta TCP usata viene immediatamente visualizzata come disponibile per le connessioni future.

Come soluzione alternativa per determinate architetture, è possibile distribuire e ridimensionare con NAT Gateway con Firewall di Azure per offrire un pool più ampio di porte SNAT per la variabilità e la disponibilità.

Quali sono i comportamenti NAT in Firewall di Azure?

I comportamenti specifici di NAT dipendono dalla configurazione del firewall e dal tipo di NAT configurato. Ad esempio, il firewall dispone di regole DNAT per il traffico in ingresso, nonché di regole di rete e regole di applicazione per il traffico in uscita tramite il firewall.

Per altre informazioni, vedere Firewall di Azure Comportamenti NAT.

Timeout e ridimensionamento

Come funziona lo svuotamento delle connessioni?

Per ogni manutenzione pianificata, la logica di svuotamento delle connessioni aggiorna correttamente i nodi back-end. Firewall di Azure attende 90 secondi per la chiusura delle connessioni esistenti. Nei primi 45 secondi, il nodo back-end non accetta nuove connessioni e nel tempo rimanente risponde con RST a tutti i pacchetti in ingresso. Se necessario, i client possono ristabilire automaticamente la connettività a un altro nodo back-end.

In che modo Firewall di Azure gestisce gli arresti delle istanze di macchine virtuali durante la riduzione delle risorse del set di scalabilità di macchine virtuali o gli aggiornamenti software della flotta di macchine?

Un spegnimento dell'istanza di macchina virtuale di Firewall di Azure può verificarsi durante il ridimensionamento di un set di macchine virtuali (riduzione del ridimensionamento) o durante un aggiornamento software del gruppo. In questi casi, il carico delle nuove connessioni in ingresso viene bilanciato rispetto alle istanze del firewall rimanenti e le nuove connessioni non vengono inoltrate all'istanza del firewall inattiva. Dopo 45 secondi, il firewall inizia a rifiutare le connessioni esistenti inviando pacchetti TCP RST. Dopo altri 45 secondi, la macchina virtuale del firewall viene arrestata. Per altre informazioni, vedere Load Balancer TCP Reset and Idle Timeout.

Quanto tempo ci vuole per scalare orizzontalmente Firewall di Azure?

Firewall di Azure ridimensiona gradualmente quando la velocità effettiva media o il consumo di CPU è pari a 60%oppure il numero di connessioni è pari a 80%. Ad esempio, inizia a ridimensionarsi quando raggiunge il 60% della sua massima capacità di elaborazione. I numeri di velocità effettiva massima variano in base alla SKU di Firewall di Azure e alle funzionalità abilitate. Per altre informazioni, vedere prestazioni di Firewall di Azure.

L'aumento delle istanze richiede da cinque a sette minuti. Quando si esegue il test delle prestazioni, assicurarsi di testare almeno da 10 a 15 minuti e avviare nuove connessioni per sfruttare i vantaggi dei nuovi nodi Firewall di Azure creati.

In che modo Firewall di Azure gestisce i timeout di inattività?

Quando una connessione ha un timeout di inattività (quattro minuti di nessuna attività), Firewall di Azure termina normalmente la connessione inviando un pacchetto TCP RST.

Manutenzione controllata dal cliente

Quale tipo di manutenzione supporta la manutenzione gestita dal cliente?

Azure i servizi vengono sottoposti a aggiornamenti di manutenzione regolari per migliorare funzionalità, affidabilità, prestazioni e sicurezza. Con un periodo di manutenzione configurato, la manutenzione del sistema operativo guest e la manutenzione del servizio vengono eseguite durante tale finestra. Tuttavia, la manutenzione controllata dal cliente non include aggiornamenti dell'host o aggiornamenti critici della sicurezza.

È possibile ricevere una notifica avanzata dell'evento di manutenzione?

Le notifiche avanzate per Firewall di Azure manutenzione non sono disponibili.

È possibile configurare una finestra di manutenzione più breve di cinque ore?

No, è necessaria una finestra di manutenzione minima di cinque ore.

È possibile configurare una finestra di manutenzione diversa dalla pianificazione giornaliera?

No, le finestre di manutenzione sono attualmente configurate per ripetersi quotidianamente.

Ci sono casi in cui non è possibile controllare determinati aggiornamenti?

La manutenzione controllata dal cliente supporta gli aggiornamenti del sistema operativo e del servizio guest, che rappresentano la maggior parte degli elementi di manutenzione che interessano i clienti. Tuttavia, alcuni aggiornamenti, ad esempio gli aggiornamenti host, non rientrano nell'ambito della manutenzione controllata dal cliente. In rari casi, è possibile eseguire l'override del controllo della finestra di manutenzione per risolvere i problemi di sicurezza con gravità elevata.

Le risorse di configurazione della manutenzione devono trovarsi nella stessa area del Firewall di Azure?

Sì.

È possibile creare più configurazioni di manutenzione per un singolo Firewall di Azure?

No. Attualmente, è possibile associare una sola configurazione di manutenzione a un Firewall di Azure.

Quali SKU Firewall di Azure è possibile configurare per l'uso della manutenzione controllata dal cliente?

Tutti gli SKU Firewall di Azure- Basic, Standard e Premium supportano la manutenzione controllata dal cliente.

Quanto tempo è necessario per rendere effettivi i criteri di configurazione della manutenzione dopo l'assegnazione al Firewall di Azure?

Potrebbero passare fino a 24 ore prima che l'Firewall di Azure segua il programma di manutenzione dopo l'associazione dei criteri di manutenzione.

Ho pianificato una finestra di manutenzione per una data futura per una delle risorse Firewall di Azure. Le attività di manutenzione verranno sospese su questa risorsa fino ad allora?

Le attività di manutenzione sul Firewall di Azure non vengono sospese durante il periodo precedente alla finestra di manutenzione pianificata. Per i giorni non inclusi nella pianificazione della manutenzione, le normali operazioni di manutenzione continuano come di consueto nella risorsa.

Come faccio a scoprire di più sulla manutenzione controllata dal cliente sul Firewall di Azure?

Per altre informazioni, vedere Configurare la manutenzione controllata dal cliente.

Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che protegge le risorse Rete virtuale di Azure. È un firewall con stato completo distribuito come servizio con disponibilità elevata e scalabilità cloud senza limiti. È possibile creare, applicare e registrare criteri di connettività di applicazione e di rete in modo centralizzato tra le sottoscrizioni e le reti virtuali.

Per un elenco dettagliato delle funzionalità di Firewall di Azure, vedere Firewall di Azure features.

Firewall di Azure possono essere distribuiti in qualsiasi rete virtuale. Tuttavia, viene in genere distribuito in una rete virtuale centrale in un modello hub-spoke, con altre reti virtuali con peering. Il percorso predefinito dalle reti virtuali interconnesse è impostato per puntare a questa rete virtuale del firewall centrale. Anche se il peering di rete virtuale globale è supportato, non è consigliabile a causa di potenziali problemi di prestazioni e latenza tra aree. Per prestazioni ottimali, distribuire un firewall per area.

Questo modello consente il controllo centralizzato su più reti virtuali spoke in sottoscrizioni diverse e offre risparmi sui costi evitando la necessità di dover distribuire un firewall in ogni rete virtuale. I risparmi sui costi devono essere valutati rispetto ai costi di peering associati in base ai modelli di traffico.

Firewall di Azure possono essere distribuiti usando il portale di Azure, PowerShell, l'API REST o i modelli. Per istruzioni dettagliate, vedere Tutorial: Distribuire e configurare Firewall di Azure usando il portale di Azure.

Firewall di Azure usa regole e raccolte di regole. Una raccolta di regole è un set di regole con lo stesso ordine e priorità. Le raccolte di regole vengono eseguite in ordine di priorità. Le raccolte regole DNAT hanno priorità più alta rispetto alle raccolte di regole di rete, che a loro volta hanno priorità più alta rispetto alle raccolte di regole dell'applicazione. L'elaborazione delle regole non avviene a ciclo continuo.

Sono disponibili tre tipi di raccolte di regole:

• Regole dell'applicazione: configurare nomi di dominio completi (FQDN) a cui è possibile accedere da una rete virtuale.
• Regole di rete: configurare regole con indirizzi di origine, protocolli, porte di destinazione e indirizzi di destinazione.
• Regole NAT: configurare le regole DNAT per consentire connessioni Internet o Intranet in ingresso (anteprima).

Per altre informazioni, vedere Configurare le regole di Firewall di Azure.

Firewall di Azure si integra con Monitoraggio di Azure per la visualizzazione e l'analisi dei log. I log possono essere inviati a Log Analytics, Archiviazione di Azure o Hub eventi e analizzati usando strumenti come Log Analytics, Excel o Power BI. Per altre informazioni, vedere Tutorial: Monitorare i log Firewall di Azure.

Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che protegge le risorse della rete virtuale. È un firewall con stato completo distribuito come servizio con disponibilità elevata e scalabilità cloud senza limiti. È preintegrato con provider di sicurezza come servizio (SECaaS) di terze parti per migliorare la sicurezza per la rete virtuale e le connessioni Internet di succursale. Per altre informazioni, vedere Azure sicurezza di rete.

Il WAF del gateway delle applicazioni offre una protezione in ingresso centralizzata per le applicazioni web contro exploit e vulnerabilità comuni. Firewall di Azure fornisce protezione in ingresso per i protocolli non HTTP/S (ad esempio, RDP, SSH, FTP), la protezione a livello di rete in uscita per tutte le porte e i protocolli e la protezione a livello di applicazione per HTTP/S in uscita.

Firewall di Azure completa i gruppi di sicurezza di rete per offrire una migliore sicurezza di rete "difesa in profondità". Gli NSG offrono un filtro del traffico a livello di rete distribuito per limitare il traffico all'interno delle reti virtuali in ogni sottoscrizione. Firewall di Azure offre una rete centralizzata e completamente con stato e una protezione a livello di applicazione tra sottoscrizioni e reti virtuali.

Firewall di Azure è un servizio gestito con più livelli di protezione, inclusa la protezione della piattaforma con gruppi di sicurezza di rete a livello di scheda di interfaccia di rete (non visualizzabile). I gruppi di sicurezza di rete a livello di subnet non sono necessari in AzureFirewallSubnet e sono disabilitati per evitare interruzioni del servizio.

Gli endpoint privati sono un componente di collegamento privato, una tecnologia che consente di interagire con i servizi PaaS Azure usando indirizzi IP privati anziché quelli pubblici. Firewall di Azure può essere usato per impedire l'accesso agli indirizzi IP pubblici, evitando quindi l'esfiltrazione di dati ai servizi Azure non sfruttando collegamento privato, nonché per implementare criteri senza attendibilità definendo chi nell'organizzazione deve accedere a tali servizi PaaS Azure, dal momento che collegamento privato Per impostazione predefinita viene aperto l'accesso alla rete per l'intera rete aziendale.

La progettazione corretta per esaminare il traffico verso endpoint privati con Firewall di Azure dipende dall'architettura di rete, è possibile trovare altri dettagli nell'articolo Firewall di Azure scenari per esaminare il traffico destinato a un endpoint privato.

Rete virtuale gli endpoint di servizio sono un'alternativa a collegamento privato per controllare l'accesso di rete ai servizi PaaS Azure. Anche se il client usa ancora indirizzi IP pubblici per accedere al servizio PaaS, la subnet di origine viene resa visibile in modo che il servizio PaaS di destinazione possa implementare regole di filtro e limitare l'accesso per ogni subnet. È possibile trovare un confronto dettagliato tra entrambi i meccanismi in Confrontare endpoint privati ed endpoint di servizio.

Firewall di Azure regole dell'applicazione possono essere usate per assicurarsi che non venga eseguita alcuna esfiltrazione di dati ai servizi non autorizzati e implementare criteri di accesso con una maggiore granularità oltre il livello di subnet. In genere, gli endpoint servizio di rete virtuale devono essere abilitati nella subnet del client che si connetterà a un servizio Azure. Tuttavia, quando si esamina il traffico verso gli endpoint di servizio con Firewall di Azure, è necessario abilitare l'endpoint di servizio corrispondente nella subnet di Firewall di Azure e disabilitarlo nella subnet del client effettivo (in genere una rete virtuale spoke). In questo modo è possibile usare le regole dell'applicazione in Firewall di Azure per controllare a quali servizi Azure i carichi di lavoro Azure avranno accesso.

Per informazioni dettagliate sui prezzi, vedere Prezzi di Firewall di Azure.

Per i limiti del servizio, vedere Azure sottoscrizione e limiti del servizio, quote e vincoli.

Firewall di Azure non sposta o archivia i dati dei clienti all'esterno dell'area in cui viene distribuita.

No, Firewall di Azure negli hub virtuali protetti (vWAN) non è attualmente supportato in Qatar.

Sì, Firewall di Azure supporta sia il filtro del traffico in ingresso che quello in uscita. Il filtro in ingresso viene in genere usato per protocolli non HTTP, ad esempio RDP, SSH e FTP. Per il traffico HTTP e HTTPS in ingresso, è consigliabile usare un web application firewall come Web application firewall di Azure (WAF) o l'offload TLS e le funzionalità di ispezione approfondita dei pacchetti di Firewall di Azure Premium.

Sì, Firewall di Azure Basic supporta il tunneling forzato.

Un ping TCP non si connette effettivamente al nome di dominio completo di destinazione. Firewall di Azure blocca le connessioni a qualsiasi indirizzo IP o FQDN di destinazione, a meno che non sia esplicitamente consentito da una regola.

Nel caso di un ping TCP, se nessuna regola consente il traffico, il firewall stesso risponde alla richiesta ping TCP del client. Questa risposta non raggiunge l'indirizzo IP o il nome di dominio completo di destinazione e non viene registrato. Se una regola di rete consente esplicitamente l'accesso all'indirizzo IP o al nome di dominio completo di destinazione, la richiesta ping raggiunge il server di destinazione e la risposta viene inoltrata al client. Questo evento viene registrato nel log delle regole di rete.

No, Firewall di Azure non supporta il peering BGP in modo nativo. Tuttavia, la funzionalità Autolearn route SNAT usa indirettamente BGP tramite Server di route Azure.

Firewall di Azure non supporta in modo nativo ESP (Incapsuling Security Payload), ma è possibile consentire il traffico ESP configurando una regola di rete come indicato di seguito:

configurazione Firewall di Azure (regola di rete):

• Protocollo: qualsiasi
• Porta di origine: * (Qualsiasi)
• Porta di destinazione: * (Qualsiasi)
• Origine/Destinazione: specificare gli indirizzi IP in base alle esigenze

Questa configurazione consente ai pacchetti ESP (numero di protocollo IP 50) e ad altri traffico non TCP/UDP di corrispondere alla regola. Si noti tuttavia che Firewall di Azure non controlla i payload ESP.

Reference: se si usa un gruppo di sicurezza di rete (gruppo di sicurezza di rete) anziché Firewall di Azure: NSG non fornisce un'opzione diretta per specificare ESP (numero di protocollo IP 50), ma i pacchetti ESP possono essere consentiti usando le impostazioni seguenti:

• Protocollo: qualsiasi
• Porta: * (Qualsiasi)
• Origine/Destinazione: specificare gli indirizzi IP in base alle esigenze

Raccomandazioni:

• Per le configurazioni VPN IPsec, è consigliabile usare Gateway VPN di Azure.
• Prendere in considerazione l'uso di un modello di appliance virtuale di rete (NVA) a seconda dei requisiti.

È possibile usare Azure PowerShell per deallocare e allocare il Firewall di Azure. Il processo varia a seconda della configurazione.

Per un firewall senza una scheda di interfaccia di rete di gestione:

# Stop the 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

Per un firewall con una scheda di interfaccia di rete di gestione:

# Stop the 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"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Per un firewall in un hub virtuale protetto:

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

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Nota

Quando si arresta e avvia il firewall, la fatturazione si arresta e inizia di conseguenza. Tuttavia, l'indirizzo IP privato può cambiare, che può influire sulla connettività se sono configurate tabelle di route.

È consigliabile configurare le zone di disponibilità durante la distribuzione iniziale. Tuttavia, è possibile riconfigurarli dopo la distribuzione se:

• Il firewall viene distribuito in una rete virtuale (non supportato negli hub virtuali protetti).
• La regione supporta le zone di disponibilità.
• Tutti gli indirizzi IP pubblici collegati sono configurati con le stesse zone.

Per riconfigurare le zone di disponibilità:

1. Deallocare il firewall:

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

2. Aggiornare la configurazione della zona e allocare il 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"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Sì:

• Il Firewall di Azure e la rete virtuale devono trovarsi nello stesso gruppo di risorse.
• L'indirizzo IP pubblico può trovarsi in un gruppo di risorse diverso.
• Tutte le risorse (firewall Azure, rete virtuale, IP pubblico) devono trovarsi nella stessa sottoscrizione.

Uno stato di approvvigionamento non riuscito indica che un aggiornamento della configurazione non è riuscito in una o più istanze back-end. Il Firewall di Azure rimane operativo, ma la configurazione potrebbe non essere coerente. Ripetere l'aggiornamento fino a quando lo stato di provisioning non viene modificato in Operazione completata.

Firewall di Azure usa una configurazione attiva-attiva con più nodi di back-end. Durante la manutenzione pianificata, il drenaggio delle connessioni garantisce aggiornamenti senza interruzioni. Per gli errori non pianificati, un nuovo nodo sostituisce quello non riuscito e la connettività viene in genere ripristinata entro 10 secondi.

Sì, i nomi del firewall sono limitati a 50 caratteri.

Una subnet /26 garantisce indirizzi IP sufficienti per il ridimensionamento, quando l'Firewall di Azure effettua il provisioning di istanze di macchine virtuali aggiuntive.

No, una subnet /26 è sufficiente per tutti gli scenari di ridimensionamento.

Firewall di Azure ridimensiona automaticamente in base all'utilizzo della CPU, alla velocità effettiva e al numero di connessioni. La capacità di velocità effettiva varia da 2,5 a 3 Gbps inizialmente a 30 Gbps (SKU Standard) o da 100 Gbps (SKU Premium).

Sì. Per informazioni dettagliate, vedere Azure sottoscrizione e limiti del servizio, quote e vincoli.

No, lo spostamento di un gruppo IP in un altro gruppo di risorse non è attualmente supportato.

Un comportamento standard di un firewall di rete è garantire che le connessioni TCP siano mantenute attive e chiuderle tempestivamente in assenza di attività. Il timeout di inattività TCP di Firewall di Azure è di quattro minuti. Questa impostazione non è configurabile dall'utente, ma è possibile contattare Azure supporto tecnico per aumentare il timeout di inattività per le connessioni in ingresso e in uscita fino a 15 minuti. Il timeout di inattività per il traffico est-ovest non può essere modificato.

Se un periodo di inattività è più lungo del valore di timeout, non vi sono garanzie che venga mantenuta la sessione TCP o HTTP. Una prassi comune consiste nell'usare un meccanismo TCP keep-alive. Questa pratica mantiene la connessione attiva per un periodo più lungo. Per altre informazioni, vedere gli esempi .NET.

Sì, ma è necessario configurare il firewall in modalità Tunneling forzato. Questa configurazione crea un'interfaccia di gestione con un indirizzo IP pubblico usato da Firewall di Azure per le operazioni. Tale indirizzo IP pubblico è destinato al traffico di gestione. Viene usato esclusivamente dalla piattaforma Azure e non può essere usato per altri scopi. La rete del percorso dati del tenant può essere configurata senza un indirizzo IP pubblico ed è possibile forzare il tunneling del traffico Internet verso un altro firewall o bloccarlo completamente.

Sì. Per altre informazioni, vedere Backup Firewall di Azure e Firewall di Azure Policy con Logic Apps.

Per l'accesso sicuro ai servizi PaaS, è consigliabile usare gli endpoint di servizio. È possibile scegliere di abilitare gli endpoint di servizio nella subnet Firewall di Azure e disabilitarli nelle reti virtuali spoke connesse. In questo modo è possibile sfruttare entrambe le funzionalità, ovvero sicurezza degli endpoint di servizio e registrazione centrale per tutto il traffico.

Sì, è possibile usare Firewall di Azure in una rete virtuale hub per instradare e filtrare il traffico tra più reti virtuali spoke. Per il corretto funzionamento di questo scenario, le subnet in ognuna delle reti virtuali spoke devono avere una route definita dall'utente (UDR) che punti all'Firewall di Azure come gateway predefinito.

Sì. Tuttavia, la configurazione delle UDRs per reindirizzare il traffico tra sottoreti nella stessa rete virtuale richiede maggiore attenzione. Anche se l'uso dell'intervallo di indirizzi di rete virtuale come prefisso di destinazione per l'UDR è sufficiente, questo instrada anche tutto il traffico da una macchina a un'altra nella stessa subnet attraverso l'istanza di Firewall di Azure. Per evitare questo problema, includere una route per la subnet nel routing definito dall'utente con un tipo di hop successivo di rete virtuale. La gestione di queste route può essere complessa e soggetta a errori. Il metodo consigliato per la segmentazione della rete interna prevede l'uso di gruppi di sicurezza di rete, che non richiedono routing definiti dall'utente.

Firewall di Azure non esegue SNAT quando l'indirizzo IP di destinazione è un intervallo IP privato per IANA RFC 1918 o IANA RFC 6598 per le reti private. Se l'organizzazione utilizza un intervallo di indirizzi IP pubblici per le reti private, Firewall di Azure effettua il SNAT del traffico verso uno degli indirizzi IP privati del firewall in AzureFirewallSubnet. È possibile configurare Firewall di Azure per non eseguire il SNAT del vostro intervallo di indirizzi IP pubblici. Per ulteriori informazioni, vedere intervalli di indirizzi IP SNAT privati di Firewall di Azure.

Inoltre, al traffico elaborato dalle regole dell'applicazione viene sempre applicata la conversione SNAT. Se si desidera visualizzare l'indirizzo IP sorgente originale nei log relativi al traffico FQDN, è possibile utilizzare le regole di rete con il nome FQDN di destinazione.

Il tunneling forzato è supportato quando si crea un nuovo firewall ed è supportato anche per i firewall esistenti aggiungendo una scheda di interfaccia di rete di gestione per il tunneling forzato. Per ulteriori dettagli sulle nuove implementazioni, vedere Firewall di Azure forced tunneling. Per i firewall esistenti, vedere Firewall di Azure Management NIC.

Firewall di Azure deve avere connettività Internet diretta. Se AzureFirewallSubnet apprende una route predefinita alla rete locale tramite BGP è necessario sostituirla con una route UDR 0.0.0.0/0 con il valore NextHopType impostato come Internet per mantenere connettività diretta a Internet.

Se la configurazione richiede il tunneling forzato in una rete locale ed è possibile determinare i prefissi IP di destinazione per le destinazioni Internet, è possibile configurare questi intervalli con la rete locale come hop successivo tramite una route definita dall'utente in AzureFirewallSubnet. In alternativa, per definire queste route, è possibile usare BGP.

• URL : gli asterischi funzionano quando vengono posizionati sul lato più a destra o a sinistra. Se si trova a sinistra, non può far parte del FQDN.
• FQDN : gli asterischi funzionano quando vengono posizionati sul lato più a sinistra.
• GENERALE - Gli asterischi sul lato sinistro indicano letteralmente che qualsiasi cosa a sinistra corrisponde, cioè vengono abbinati più sottodomini e/o possibili varianti indesiderate di nomi di dominio. Vedere gli esempi seguenti.

Esempi:

TIPO	Regola	Supportato?	Esempi positivi
URL di destinazione	www.contoso.com	Sì	www.contoso.com www.contoso.com/
URL di destinazione	*.contoso.com	Sì	any.contoso.com/ sub1.any.contoso.com
URL di destinazione	*contoso.com	Sì	example.anycontoso.com sub1.example.contoso.com contoso.com Avviso: questo utilizzo di wildcard consente anche variazioni potenzialmente indesiderate/rischiose, come th3re4lcontoso.com, quindi usare con cautela.
URL di destinazione	www.contoso.com/test	Sì	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
URL di destinazione	www.contoso.com/test/*	Sì	www.contoso.com/test/anything Nota: www.contoso.com/testnon corrisponde (ultima barra)
URL di destinazione	www.contoso.*/test/*	NO
URL di destinazione	www.contoso.com/test?example=1	NO
URL di destinazione	www.contoso.*	NO
URL di destinazione	www.*contoso.com	NO
URL di destinazione	www.contoso.com:8080	NO
URL di destinazione	*.contoso.*	NO
FQDN di destinazione	www.contoso.com	Sì	www.contoso.com
FQDN di destinazione	*.contoso.com	Sì	any.contoso.com Nota: se si vuole consentire contoso.comin modo specifico , è necessario includere contoso.com nella regola. In caso contrario, la connessione verrà interrotta per impostazione predefinita perché la richiesta non soddisfa alcuna regola.
FQDN di destinazione	*contoso.com	Sì	example.anycontoso.com contoso.com
FQDN di destinazione	www.contoso.*	NO
FQDN di destinazione	*.contoso.*	NO

No. Firewall di Azure blocca l'accesso Active Directory per impostazione predefinita. Per consentire l'accesso, configurare il tag del servizio AzureActiveDirectory. Per altre informazioni, vedere tag del servizio Firewall di Azure.

Sì, è possibile usare Azure PowerShell per farlo:

# 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

Un ping TCP non si connette effettivamente al nome di dominio completo di destinazione. Firewall di Azure non consente una connessione a un indirizzo IP/FQDN di destinazione, a meno che non esista una regola esplicita che lo consenta.

Il ping TCP è un caso d'uso univoco in cui, se non esiste alcuna regola consentita, il firewall stesso risponde alla richiesta di ping TCP del client anche se il ping TCP non raggiunge l'indirizzo IP o il nome di dominio completo della destinazione. In questo caso, l'evento non viene registrato. Se esiste una regola di rete che consente l'accesso all'indirizzo IP o al nome di dominio completo di destinazione, la richiesta di ping raggiunge il server di destinazione e la sua risposta viene inoltrata al di nuovo al client. Questo evento viene registrato nel log delle regole di rete.

Firewall di Azure funge da listener passivo per le porte 80, 443 e 1433. Firewall di Azure non registra i pacchetti TCP SYN su queste porte, a meno che non sia presente traffico dell'applicazione. La richiesta HTTP GET e il client hello TLS sono registrati in Firewall di Azure.

Sì. Per ulteriori informazioni, vedere sottoscrizione di Azure e limiti del servizio, quote e vincoli

No, lo spostamento di un gruppo IP in un altro gruppo di risorse non è attualmente supportato.

Un comportamento standard di un firewall di rete è garantire che le connessioni TCP siano mantenute attive e chiuderle tempestivamente in assenza di attività. Il timeout di inattività TCP di Firewall di Azure è di quattro minuti. Questa impostazione non è configurabile dall'utente, ma è possibile contattare Azure supporto tecnico per aumentare il timeout di inattività per le connessioni in ingresso e in uscita fino a 15 minuti. Il timeout di inattività per il traffico est-ovest non può essere modificato.

Se un periodo di inattività è più lungo del valore di timeout, non vi sono garanzie che venga mantenuta la sessione TCP o HTTP. Una prassi comune consiste nell'usare un meccanismo TCP keep-alive. Questa pratica mantiene la connessione attiva per un periodo più lungo. Per altre informazioni, vedere gli esempi .NET.

Sì, ma è necessario configurare il firewall in modalità Tunneling forzato. Questa configurazione crea un'interfaccia di gestione con un indirizzo IP pubblico usato da Firewall di Azure per le operazioni. Tale indirizzo IP pubblico è destinato al traffico di gestione. Viene usato esclusivamente dalla piattaforma Azure e non può essere usato per altri scopi. La rete del percorso dati del tenant può essere configurata senza un indirizzo IP pubblico ed è possibile forzare il tunneling del traffico Internet verso un altro firewall o bloccarlo completamente.

Firewall di Azure non sposta o archivia i dati dei clienti dall'area in cui viene distribuita.

Sì. Per altre informazioni, vedere Backup Firewall di Azure e Firewall di Azure Policy con Logic Apps.

No, attualmente Firewall di Azure negli hub virtuali protetti (vWAN) non è supportato in Qatar.

Firewall di Azure usa Macchine virtuali di Azure sottostanti con un limite massimo di connessioni. Il numero totale di connessioni attive per ogni macchina virtuale è 250.000.

Il limite totale per ogni firewall corrisponde al limite di connessioni della macchina virtuale (250.000) x il numero di macchine virtuali nel pool back-end del firewall. Firewall di Azure inizia con due macchine virtuali e aumenta il numero di istanze in base all'utilizzo e alla velocità effettiva della CPU.

Firewall di Azure attualmente utilizza porte sorgente TCP/UDP per il traffico SNAT in uscita, senza tempi di inattività. Quando una connessione TCP/UDP viene chiusa, la porta TCP usata viene immediatamente visualizzata come disponibile per le connessioni future.

Come soluzione alternativa per determinate architetture, è possibile distribuire e ridimensionare con NAT Gateway con Firewall di Azure per offrire un pool più ampio di porte SNAT per la variabilità e la disponibilità.

I comportamenti specifici di NAT dipendono dalla configurazione del firewall e dal tipo di NAT configurato. Ad esempio, il firewall dispone di regole DNAT per il traffico in ingresso, nonché di regole di rete e regole di applicazione per il traffico in uscita tramite il firewall.

Per altre informazioni, vedere Firewall di Azure Comportamenti NAT.

Per ogni manutenzione pianificata, la logica di svuotamento delle connessioni aggiorna correttamente i nodi back-end. Firewall di Azure attende 90 secondi per la chiusura delle connessioni esistenti. Nei primi 45 secondi, il nodo back-end non accetta nuove connessioni e nel tempo rimanente risponde con RST a tutti i pacchetti in ingresso. Se necessario, i client possono ristabilire automaticamente la connettività a un altro nodo back-end.

Un spegnimento dell'istanza di macchina virtuale di Firewall di Azure può verificarsi durante il ridimensionamento di un set di macchine virtuali (riduzione del ridimensionamento) o durante un aggiornamento software del gruppo. In questi casi, il carico delle nuove connessioni in ingresso viene bilanciato rispetto alle istanze del firewall rimanenti e le nuove connessioni non vengono inoltrate all'istanza del firewall inattiva. Dopo 45 secondi, il firewall inizia a rifiutare le connessioni esistenti inviando pacchetti TCP RST. Dopo altri 45 secondi, la macchina virtuale del firewall viene arrestata. Per altre informazioni, vedere Load Balancer TCP Reset and Idle Timeout.

Firewall di Azure ridimensiona gradualmente quando la velocità effettiva media o il consumo di CPU è pari a 60%oppure il numero di connessioni è pari a 80%. Ad esempio, inizia a ridimensionarsi quando raggiunge il 60% della sua massima capacità di elaborazione. I numeri di velocità effettiva massima variano in base alla SKU di Firewall di Azure e alle funzionalità abilitate. Per altre informazioni, vedere prestazioni di Firewall di Azure.

L'aumento delle istanze richiede da cinque a sette minuti. Quando si esegue il test delle prestazioni, assicurarsi di testare almeno da 10 a 15 minuti e avviare nuove connessioni per sfruttare i vantaggi dei nuovi nodi Firewall di Azure creati.

Quando una connessione ha un timeout di inattività (quattro minuti di nessuna attività), Firewall di Azure termina normalmente la connessione inviando un pacchetto TCP RST.

Azure i servizi vengono sottoposti a aggiornamenti di manutenzione regolari per migliorare funzionalità, affidabilità, prestazioni e sicurezza. Con un periodo di manutenzione configurato, la manutenzione del sistema operativo guest e la manutenzione del servizio vengono eseguite durante tale finestra. Tuttavia, la manutenzione controllata dal cliente non include aggiornamenti dell'host o aggiornamenti critici della sicurezza.

Le notifiche avanzate per Firewall di Azure manutenzione non sono disponibili.

No, è necessaria una finestra di manutenzione minima di cinque ore.

No, le finestre di manutenzione sono attualmente configurate per ripetersi quotidianamente.

La manutenzione controllata dal cliente supporta gli aggiornamenti del sistema operativo e del servizio guest, che rappresentano la maggior parte degli elementi di manutenzione che interessano i clienti. Tuttavia, alcuni aggiornamenti, ad esempio gli aggiornamenti host, non rientrano nell'ambito della manutenzione controllata dal cliente. In rari casi, è possibile eseguire l'override del controllo della finestra di manutenzione per risolvere i problemi di sicurezza con gravità elevata.

Sì.

No. Attualmente, è possibile associare una sola configurazione di manutenzione a un Firewall di Azure.

Tutti gli SKU Firewall di Azure- Basic, Standard e Premium supportano la manutenzione controllata dal cliente.

Potrebbero passare fino a 24 ore prima che l'Firewall di Azure segua il programma di manutenzione dopo l'associazione dei criteri di manutenzione.

Le attività di manutenzione sul Firewall di Azure non vengono sospese durante il periodo precedente alla finestra di manutenzione pianificata. Per i giorni non inclusi nella pianificazione della manutenzione, le normali operazioni di manutenzione continuano come di consueto nella risorsa.

Per altre informazioni, vedere Configurare la manutenzione controllata dal cliente.