Domande frequenti su Firewall di Azure

Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che consente di proteggere le risorse della 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 informazioni sulle funzionalità di Firewall di Azure, vedere Funzionalità di Firewall di Azure.

È possibile distribuire Firewall di Azure in qualsiasi rete virtuale, ma i clienti distribuiscono in genere Firewall di Azure in una rete virtuale centrale e configurano il peering di altre reti virtuali verso tale rete in un modello di tipo hub-spoke. È quindi possibile impostare la route predefinita dalle reti virtuali con peering verso la rete virtuale centrale del firewall. Il peering di rete virtuale globale è supportato, ma non è consigliato a causa di potenziali problemi di prestazioni e di latenza tra le aree. Per ottenere prestazioni ottimali, distribuire un firewall per ogni area.

Il vantaggio offerto da questo modello consiste nella possibilità di esercitare il controllo centralizzato su più reti virtuali spoke tramite diverse sottoscrizioni. È inoltre possibile usufruire di un risparmio sui costi perché non è necessario distribuire un firewall separatamente in ogni rete virtuale. Il risparmio sui costi deve essere misurato rispetto al costo di peering associato in base ai modelli di traffico dei clienti.

È possibile configurare Firewall di Azure tramite il portale di Azure, PowerShell o l'API REST oppure usando modelli. Per istruzioni dettagliate, vedere Esercitazione: Distribuire e configurare Firewall di Azure tramite il portale di Azure.

Firewall di Azure supporta regole e raccolte di regole. Una raccolta di regole è un set di regole con lo stesso ordine e la stessa priorità. Le raccolte di regole vengono eseguite in ordine di priorità. Le raccolte di regole DNAT sono raccolte di regole di rete con priorità più alta, che hanno priorità più alta rispetto alle raccolte di regole dell'applicazione e tutte le regole terminano.

Sono disponibili tre tipi di raccolte di regole:

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

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

Firewall di Azure supporta i filtri in ingresso e in uscita. La protezione in ingresso viene in genere usata per protocolli non HTTP come protocolli RDP, SSH e FTP. Per la protezione HTTP e HTTPS in ingresso, usare un web application firewall, ad esempio Web application firewall (WAF) di Azure o le funzionalità di offload TLS e analisi approfondita dei pacchetti di Firewall di Azure Premium.

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

Firewall di Azure è integrato con Monitoraggio di Azure per la visualizzazione e l'analisi dei log di firewall. I log possono essere inviati a Log Analytics, Archiviazione di Azure o Hub eventi e possono essere analizzati in Log Analytics o con strumenti diversi, ad esempio Excel e Power BI. Per altre informazioni, vedere Esercitazione: Monitorare i log di Firewall di Azure.

Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che consente di proteggere le risorse della rete virtuale. È un firewall con stato completo distribuito come servizio con disponibilità elevata e scalabilità cloud senza limiti. È preintegrata con provider di sicurezza come servizio (edizione Standard CaaS) di terze parti per fornire sicurezza avanzata per la rete virtuale e le connessioni Internet di succursale. Per altre informazioni sulla sicurezza di rete di Azure, vedere Sicurezza di rete di Azure.

Web application firewall (WAF) è una funzionalità del gateway applicazione che offre una protezione centralizzata delle applicazioni Web da exploit e vulnerabilità comuni. Firewall di Azure fornisce la 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 tutti i protocolli e la protezione a livello di applicazione per HTTP/S in uscita.

Il servizio Firewall di Azure si integra con la funzionalità dei gruppi sicurezza di rete offrendo una migliore sicurezza di rete con strategie di difesa avanzate. I gruppi di sicurezza di rete consentono di filtrare il traffico al livello rete distribuito per limitare il traffico indirizzato alle risorse all'interno delle reti virtuali in ogni sottoscrizione. Firewall di Azure è un firewall di rete centralizzato con stato completo, distribuito come servizio, che fornisce protezione a livello di rete e di applicazione in diverse 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 NIC (non visualizzabili). I gruppi a livello di subnet non sono necessari in AzureFirewallSubnet e sono disabilitati per evitare interruzioni del servizio.

Per l'accesso sicuro ai servizi PaaS, è consigliabile usare gli endpoint di servizio. È possibile scegliere di abilitare gli endpoint di servizio nella subnet di 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.

Vedere Prezzi del servizio Firewall di Azure.

È possibile usare i metodi di deallocazione e allocazione di Azure PowerShell. Per un firewall configurato per il tunneling forzato, la procedura è leggermente diversa.

Ad esempio, per un firewall NON configurato per il tunneling forzato:

# Stop an existing firewall

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

# Start the firewall

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

Set-AzFirewall -AzureFirewall $azfw

Per un firewall configurato per il tunneling forzato, la procedura di arresto è la stessa. Ma per l'avvio è necessario che l'indirizzo IP pubblico di gestione venga riassociato al firewall:

# Stop an existing firewall

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

# Start the firewall

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

Per un firewall in un'architettura di hub virtuale protetta, l'arresto è lo stesso, ma l'avvio deve usare l'ID dell'hub virtuale:

# Stop and existing firewall

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

# Start the firewall

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

Quando si alloca e si dealloca, la fatturazione del firewall viene interrotta e avviata di conseguenza.

Si consiglia di configurare le zone di disponibilità durante la distribuzione iniziale del firewall. Tuttavia, in alcuni casi è possibile modificare le zone di disponibilità dopo la distribuzione. Devono essere soddisfatti i prerequisiti seguenti:

• Il firewall viene distribuito in una rete virtuale. Non è supportato con i firewall distribuiti in un hub virtuale protetto.
• L'area del firewall supporta le zone di disponibilità.
• Tutti gli indirizzi IP pubblici collegati vengono distribuiti con le zone di disponibilità. Nella pagina delle proprietà di ogni indirizzo IP pubblico verificare che il campo delle zone di disponibilità esista e sia configurato con le stesse zone configurate per il firewall.

La riconfigurazione delle zone di disponibilità può essere eseguita solo quando si riavvia il firewall. Dopo aver allocato il firewall e subito prima di avviare il firewall con Set-AzFirewall, usare azure PowerShell seguente per modificare la proprietà Zones del firewall:

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

Per i limiti del servizio Firewall di Azure, vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi

Sì, è possibile usare il Firewall di Azure in una rete virtuale hub per instradare e filtrare il traffico tra due reti virtuali spoke. Per il corretto funzionamento di questo scenario, alle subnet in ognuna delle reti virtuali spoke deve essere associato il routing definito dall'utente che punta verso il Firewall di Azure come gateway predefinito.

Sì. Tuttavia, la configurazione delle route definite dall'utente per reindirizzare il traffico tra subnet nella stessa rete virtuale richiede maggiore attenzione. Anche se l'uso dell'intervallo di indirizzi della rete virtuale come prefisso di destinazione per il routing definito dall'utente è sufficiente, in questo modo si instrada tutto il traffico da un computer a un altro computer nella stessa subnet tramite l'istanza di Firewall di Azure. Per evitare questo problema, includere una route per la subnet nel routing definito dall'utente con un hop successivo di tipo VNET. 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 usa SNAT quando l'indirizzo IP di destinazione è un intervallo di indirizzi IP privati, in conformità allo standard IANA RFC 1918. Se l'organizzazione usa un intervallo di indirizzi IP pubblici per le reti private, Firewall di Azure invierà il traffico tramite SNAT a uno degli indirizzi IP privati firewall in AzureFirewallSubnet. È possibile configurare Firewall di Azure in modo da non usare SNAT per l'intervallo di indirizzi IP pubblici. Per altre informazioni, vedere Intervalli di indirizzi IP privati SNAT di Firewall di Azure.

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

Il tunneling forzato è supportato quando si crea un nuovo firewall. Non è possibile configurare un firewall esistente per il tunneling forzato. Per altre informazioni, vedere Tunneling forzato di Firewall di Azure.

Connettività diretta al Firewall di Azure. 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.

Sì. Il firewall, la rete virtuale e l'indirizzo IP pubblico devono trovarsi nello stesso gruppo di risorse.

• URL: gli asterischi funzionano se posizionati all'estrema destra o all'estrema sinistra. Se si trovano a sinistra, non possono far parte del nome FQDN.
• FQDN: gli asterischi funzionano se posizionati sul lato più a sinistra.
• GENERALE : gli asterischi sul lato sinistro indicano letteralmente qualsiasi elemento alla corrispondenza a sinistra, vale a dire più sottodomini e/o varianti di nomi di dominio potenzialmente indesiderati. Vedere gli esempi seguenti.

Esempi:

Ogni volta che viene applicata una modifica alla configurazione, Firewall di Azure tenta di aggiornare tutte le istanze back-end sottostanti. In rari casi, una di queste istanze back-end potrebbe non riuscire ad eseguire l'aggiornamento con la nuova configurazione e il processo di aggiornamento si arresta con uno stato di provisioning non riuscito. Il Firewall di Azure è ancora operativo, ma la configurazione applicata potrebbe essere in uno stato incoerente, in cui alcune istanze hanno la configurazione precedente in cui altri hanno il set di regole aggiornato. In tal caso, provare ad aggiornare la configurazione ancora una volta fino a quando l'operazione non ha esito positivo e il firewall si trova in uno stato di provisioning Riuscito.

Firewall di Azure è costituito da diversi nodi back-end in una configurazione attiva-attiva. Per ogni manutenzione pianificata, è disponibile la logica di svuotamento delle connessioni per aggiornare correttamente i nodi. Aggiornamenti sono pianificati durante le ore non lavorative per ognuna delle aree di Azure per limitare ulteriormente il rischio di interruzioni. Per i problemi non pianificati, viene creata un'istanza di un nuovo nodo per sostituire il nodo in cui si è verificato l'errore. La connettività al nuovo nodo viene in genere ristabilita entro 10 secondi dal momento in cui si è verificato l'errore.

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.

Sì. È previsto un limite di 50 caratteri per il nome di un firewall.

Firewall di Azure deve effettuare il provisioning di più istanze di macchine virtuali in base alle dimensioni. Uno spazio indirizzi /26 garantisce che il firewall disponga di un numero sufficiente di indirizzi IP per la scalabilità.

No. Firewall di Azure non ha bisogno di una subnet maggiore di/26.

la capacità di velocità effettiva iniziale di Firewall di Azure è di 2,5 - 3 Gbps e aumenta fino a 30 Gbps per SKU Standard e 100 Gbps per SKU Premium. Aumenta automaticamente il numero di connessioni in base all'utilizzo della CPU, alla velocità effettiva e al numero di connessioni.

Firewall di Azure ridimensiona gradualmente quando la velocità effettiva media o il consumo di CPU è pari al 60%, oppure il numero di connessioni è pari all'80%. Ad esempio, inizia a aumentare il numero di istanze quando raggiunge il 60% della velocità effettiva massima. I numeri di velocità effettiva massima variano in base agli SKU del firewall e alle funzionalità abilitate. Per altre informazioni, vedere Firewall di Azure prestazioni.

L'aumento delle istanze richiede da cinque a sette minuti.

Quando si esegue il test delle prestazioni, verificare di eseguirlo per almeno 10-15 minuti e avviare nuove connessioni per sfruttare i vantaggi offerti dai nodi firewall appena 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.

Un Firewall di Azure arresto dell'istanza di macchina virtuale può verificarsi durante la scalabilità del set di scalabilità di macchine virtuali (riduzione) o durante l'aggiornamento software della flotta. In questi casi, le nuove connessioni in ingresso vengono bilanciate per le istanze del firewall rimanenti e 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 Reimpostazione TCP e timeout di inattività di Load Balancer.

No. Firewall di Azure blocca l'accesso ad 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 eseguire questa operazione:

# 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 risponde alla richiesta ping TCP del client anche se il ping TCP non raggiunge l'indirizzo IP di destinazione/FQDN. In questo caso, l'evento non viene registrato. Se è presente una regola di rete che consente l'accesso all'indirizzo IP/FQDN di destinazione, la richiesta ping raggiunge il server di destinazione e la risposta viene inoltrata al client. Questo evento viene registrato nel log Regole di rete.

Sì. Per altre informazioni, vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi.

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 il supporto tecnico di Azure per aumentare il timeout di inattività per le connessioni in ingresso e in uscita fino a 30 minuti. Il timeout di inattività per il traffico east-west 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 una connessione TCP keep-alive per mantenere la connessione attiva per un periodo più lungo. Per altre informazioni, vedere gli esempi per .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. Questo 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 tenant può essere configurata senza un indirizzo IP pubblico e il traffico Internet può essere sottoposto a tunneling forzato a un altro firewall o completamente bloccato.

Firewall di Azure non sposta o archivia i dati dei clienti al di fuori dell'area in cui è distribuito.

Sì. Per altre informazioni, vedere Backup Firewall di Azure e criteri di Firewall di Azure con App per la logica.

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

Firewall di Azure usa Azure Macchine virtuali sottostante con un numero rigido di connessioni. Il numero totale di connessioni attive per macchina virtuale è 250.000.

Il limite totale per firewall è il limite di connessione 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 della CPU e alla velocità effettiva.

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

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

I comportamenti NAT specifici dipendono dalla configurazione del firewall e dal tipo di NAT configurato. Ad esempio, il firewall ha regole DNAT per il traffico in ingresso, regole di rete e regole dell'applicazione per il traffico in uscita attraverso il firewall.

Per altre informazioni, vedere Firewall di Azure comportamenti NAT.