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 hanno una priorità più alta delle raccolte di regole di rete, che a loro volta hanno una priorità più alta delle raccolte di regole di applicazione. Inoltre, tutte le regole sono di terminazione.

Sono disponibili tre tipi di raccolte di regole:

• Regole di applicazione: configurano i nomi di dominio completi (FQDN) accessibili da una rete virtuale.
• Regole di rete: configurano le regole che contengono indirizzi di origine, protocolli, porte di destinazione e indirizzi di destinazione.
• Regole NAT: configurano le regole DNAT per consentire connessioni Internet o Intranet (anteprima) 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 i protocolli non HTTP, ad esempio 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 DPI (Deep Packet Inspection) 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. È preintegrato con i provider di SECaaS (Security as a Service) di terze parti per offrire sicurezza avanzata alle connessioni tramite rete virtuale e Internet branch. 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 configurato con la scheda di interfaccia di rete di gestione NON abilitata:

# 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 con la scheda di interfaccia di rete di gestione abilitata, l'arresto è lo stesso. 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 nell'architettura di un hub virtuale protetto, l'arresto avviene nello stesso modo, ma per l'avvio è necessario 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.

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

• Il firewall è distribuito in una rete virtuale. La modifica non è supportata con i firewall distribuiti in un hub virtuale protetto.
• L'area del firewall supporta le zone di disponibilità.
• Tutti gli indirizzi IP pubblici collegati sono distribuiti con 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 avviarlo con Set-AzFirewall, usare l'istanza di 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 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, 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ì. La configurazione delle route definite dall'utente per il reindirizzamento del traffico tra subnet della stessa rete virtuale richiede tuttavia 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 esegue SNAT quando l'indirizzo IP di destinazione è un intervallo IP privato per ogni IANA RFC 1918 o IANA RFC 6598 per reti private. 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 e la rete virtuale devono trovarsi nello stesso gruppo di risorse.
• L'indirizzo IP pubblico può appartenere a qualsiasi gruppo di risorse.
• Il firewall, la rete virtuale e l'indirizzo IP pubblico devono far parte della stessa sottoscrizione.

• 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: se si usano gli asterischi nella parte sinistra, qualsiasi elemento che si trova a sinistra corrisponde, quindi anche più sottodomini e/o varianti di nomi di dominio potenzialmente indesiderate. 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, è possibile che una di queste istanze back-end non venga aggiornata con la nuova configurazione e che il processo di aggiornamento venga interrotto con uno stato che indica che il provisioning non è riuscito. Firewall di Azure è comunque operativo, ma la configurazione applicata potrebbe avere uno stato incoerente, perché alcune istanze hanno la configurazione precedente mentre altre 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. Gli aggiornamenti vengono pianificati durante le ore non lavorative per ogni area 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 di back-end non accetta nuove connessioni, mentre nel tempo rimanente risponde a tutti i pacchetti in ingresso con RST. 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 Azure Firewall è di 2,5 - 3 Gbps e può raggiungere 30 Gbps per lo SKU Standard e 100 Gbps per lo SKU Premium. Tale aumento si verifica in modo automatico in base all'utilizzo della CPU, alla velocità effettiva e al numero di connessioni.

Firewall di Azure viene ridimensionato gradualmente quando la velocità effettiva media o l'utilizzo della CPU medio è pari al 60% oppure il numero di connessioni è pari all'80%. Il ridimensionamento inizia ad esempio quando Firewall di Azure raggiunge il 60% della sua velocità effettiva massima. I valori della velocità effettiva massima variano in base agli SKU del firewall 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, 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 raggiunge un timeout di inattività (quattro minuti di inattività), Firewall di Azure termina normalmente la connessione inviando un pacchetto TCP RST.

Durante la riduzione del set di scalabilità di una macchina virtuale o durante l'aggiornamento del software della flotta, è possibile che si verifichi l'arresto dell'istanza di una macchina virtuale di Firewall di Azure. 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 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 ad alcun indirizzo IP o nome di dominio completo di destinazione, a meno che non esista una regola esplicita che lo autorizzi.

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.

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 può essere configurata dall'utente, ma è possibile contattare il supporto tecnico di Azure per aumentare il timeout di inattività delle 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 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 sue operazioni. Tale indirizzo IP pubblico è destinato al traffico di gestione. Viene usato esclusivamente dalla piattaforma di Azure e non è possibile utilizzarlo 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 al di fuori dell'area in cui è distribuito.

Sì. Per altre informazioni, vedere Eseguire il backup di Firewall di Azure e dei 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 Macchine virtuali di Azure sottostanti che dispongono di un numero di connessioni con un limite rigido. 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 macchine virtuali in base all'utilizzo e alla velocità effettiva della CPU.

Firewall di Azure usa attualmente porte di origine TCP/UDP per il traffico SNAT in uscita, senza tempi di attesa inattivi. 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 tramite il gateway NAT 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 Comportamenti di NAT di Firewall di Azure.