Condividi tramite

Configurare regole di Firewall di Azure

  • Articolo

È possibile configurare regole NAT, regole di rete e regole delle applicazioni in Firewall di Azure, usando regole classiche o criteri firewall. Firewall di Azure nega tutto il traffico per impostazione predefinita, fino a quando non vengono configurate manualmente le regole per consentire il traffico. Le regole terminano, quindi l'elaborazione delle regole si arresta su una corrispondenza.

Elaborazione delle regole tramite regole classiche

Le raccolte regole vengono elaborate in base al tipo di regola in ordine di priorità, dai numeri più bassi a quelli più alti, da 100 a 65.000. Un nome di una raccolta regole può contenere solo lettere, numeri, caratteri di sottolineatura, punti o trattini. I nomi devono iniziare con una lettera o un numero e terminare con una lettera, un numero o un carattere di sottolineatura. La lunghezza massima del nome è di 80 caratteri.

Si consiglia di distanziare inizialmente i numeri di priorità della raccolta regole con incrementi di 100 (100, 200, 300 e così via) in modo da avere spazio per aggiungere altre raccolte regole, se necessario.

Elaborazione delle regole tramite i criteri firewall

Con i Criteri firewall, le regole sono organizzate all'interno di raccolte regole e gruppi di raccolta regole. I gruppi di raccolte regole contengono zero o più raccolte regole. Le raccolte regole sono di tipo NAT, Rete o Applicazioni. È possibile definire più tipi di raccolta regole all'interno di un singolo gruppo di regole. È possibile definire zero o più regole in una raccolta regole. Le regole in una raccolta regole devono essere dello stesso tipo (NAT, di rete o dell'applicazione).

Le regole vengono elaborate in base alla priorità del gruppo di raccolta regole e alla priorità della raccolta regole. La priorità è qualsiasi numero compreso tra 100 (priorità più alta) e 65.000 (priorità più bassa). I gruppi di raccolta regole con priorità più alta vengono elaborati per primi. All'interno di un gruppo di raccolte regole, le raccolte regole con priorità più alta (numero più basso) vengono elaborate per prime.

Se un Criterio firewall viene ereditato da un criterio padre, i gruppi di raccolta regole nei criteri padre hanno sempre la precedenza indipendentemente dalla priorità di un criterio figlio.

Nota

Le regole dell'applicazione vengono sempre elaborate dopo le regole di rete, che vengono elaborate dopo le regole DNAT indipendentemente dal gruppo di raccolta regole o dalla priorità di raccolta regole e dall'ereditarietà dei criteri.

Quindi, per riepilogare:

I criteri padre hanno sempre la precedenza.

  1. I gruppi di raccolta regole vengono elaborati in ordine di priorità.
  2. Le raccolte di regole vengono elaborate in ordine di priorità.
  3. Vengono elaborate le regole DNAT, quindi le regole di rete, quindi le regole dell'applicazione.

Ecco un criterio di esempio:

Supponendo che BaseRCG1 sia una priorità del gruppo di raccolte regole (200) che contiene le raccolte regole: DNATRC1, DNATRC3, NetworkRC1.
BaseRCG2 è una priorità del gruppo di raccolte regole (300) che contiene le raccolte regole: AppRC2, NetworkRC2.
ChildRCG1 è una priorità del gruppo di raccolte regole (300) che contiene le raccolte regole: ChNetRC1, ChAppRC1.
ChildRCG2 è una priorità del gruppo di raccolte regole (650) che contiene le raccolte regole: ChNetRC2, ChAppRC2,ChDNATRC3.

Come indicato nella tabella seguente:

Nome Type Priorità Regole Ereditato da
BaseRCG1 Gruppo di raccolta regole 200 8 Criterio padre
DNATRC1 Raccolta regole DNAT 600 7 Criterio padre
DNATRC3 Raccolta regole DNAT 610 3 Criterio padre
NetworkRC1 Raccolta di regole di rete 800 1 Criterio padre
BaseRCG2 Gruppo di raccolta regole 300 3 Criterio padre
AppRC2 Raccolta di regole dell'applicazione 1200 2 Criterio padre
NetworkRC2 Raccolta di regole di rete 1300 1 Criterio padre
ChildRCG1 Gruppo di raccolta regole 300 5 -
ChNetRC1 Raccolta di regole di rete 700 3 -
ChAppRC1 Raccolta di regole dell'applicazione 900 2 -
ChildRCG2 Gruppo di raccolta regole 650 9 -
ChNetRC2 Raccolta di regole di rete 1100 2 -
ChAppRC2 Raccolta di regole dell'applicazione 2000 7 -
ChDNATRC3 Raccolta regole DNAT 3000 2 -

Iterazione iniziale per le regole DNAT:

Il processo inizia esaminando il gruppo di raccolta regole (RCG) con il numero più basso, ovvero BaseRCG1 con priorità 200. All'interno di questo gruppo cerca le raccolte di regole DNAT e le valuta in base alle priorità. In questo caso, DNATRC1 (priorità 600) e DNATRC3 (priorità 610) vengono trovati ed elaborati di conseguenza.
Successivamente, passa al successivo RCG, BaseRCG2 (priorità 300), ma non trova alcuna raccolta di regole DNAT.
Successivamente, procede a ChildRCG1 (priorità 300), anche senza una raccolta di regole DNAT.
Infine, controlla ChildRCG2 (priorità 650) e trova la raccolta di regole ChDNATRC3 (priorità 3000).

Iterazione per le regole DI RETE:

Tornando a BaseRCG1, l'iterazione continua, questa volta per le regole DI RETE. Viene trovato solo NetworkRC1 (priorità 800).
Passa quindi a BaseRCG2, dove si trova NetworkRC2 (priorità 1300).
Passando a ChildRCG1, ChNetRC1 (priorità 700) viene individuata come regola DI RETE.
Infine, in ChildRCG2 trova ChNetRC2 (priorità 1100) come raccolta regole NETWORK.

Iterazione finale per le regole dell'APPLICAZIONE:

Tornando a BaseRCG1, il processo esegue l'iterazione per le regole dell'APPLICAZIONE, ma non ne viene trovata nessuna.
In BaseRCG2 identifica AppRC2 (priorità 1200) come regola dell'APPLICAZIONE.
In ChildRCG1 ChAppRC1 (priorità 900) viene trovato come regola dell'APPLICAZIONE.
Infine, in ChildRCG2 individua ChAppRC2 (priorità 2000) come regola dell'APPLICAZIONE.

In sintesi, la sequenza di elaborazione delle regole è la seguente: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.

Questo processo comporta l'analisi dei gruppi di raccolte regole in base alla priorità e, all'interno di ogni gruppo, l'ordinamento delle regole in base alle relative priorità per ogni tipo di regola (DNAT, RETE e APPLICAZIONE).

Prima di tutto, tutte le regole DNAT vengono elaborate da tutti i gruppi di raccolta regole, analizzando i gruppi di raccolta regole in base all'ordine di priorità e ordinando le regole DNAT all'interno di ogni gruppo di raccolte regole in base all'ordine di priorità. Quindi lo stesso processo per le regole DI RETE e infine per le regole dell'APPLICAZIONE.

Per altre informazioni sui set di regole dei criteri firewall, vedere Set di regole di Criteri di Firewall di Azure.

Intelligence per le minacce

Se si abilita il filtro basato sull'intelligence sulle minacce, tali regole sono prioritarie e vengono sempre elaborate per prime (prima delle regole di rete e applicazione). Il filtro di Intelligence per le minacce può negare il traffico prima che vengano elaborate regole configurate. Per altre informazioni, vedere Filtro basato sull'intelligence sulle minacce di Firewall di Azure.

IDPS

Quando IDPS è configurato in modalità Avviso, il motore IDPS funziona in parallelo alla logica di elaborazione delle regole e genera avvisi sulle firme corrispondenti per i flussi in ingresso e in uscita. Per una corrispondenza di firma IDPS viene registrato un avviso nei log del firewall. Tuttavia, poiché il motore IDPS funziona in parallelo al motore di elaborazione delle regole, il traffico negato o consentito dalle regole di applicazione/rete può comunque generare un'altra voce di log.

Quando IDPS è configurato in modalità Avviso e negazione, il motore IDPS è inline e viene attivato dopo il motore di elaborazione delle regole. Quindi entrambi i motori generano avvisi e possono bloccare i flussi corrispondenti. 

L'eliminazione della sessione eseguita da IDPS blocca il flusso in modo invisibile. Non viene quindi inviato alcun RST a livello TCP. Poiché IDPS controlla sempre il traffico dopo la corrispondenza della regola rete/applicazione (Consenti/Nega) e contrassegnato nei log, è possibile registrare un altro messaggio di rimozione in cui IDPS decide di negare la sessione a causa di una corrispondenza di firma.

Quando l'ispezione TLS è abilitata sia con crittografia che senza, viene controllato il traffico. 

Connettività in uscita

Regole di rete e di applicazione

Se si configurano regole di rete e regole dell'applicazione, le regole di rete vengono applicate in ordine di priorità prima delle regole dell'applicazione. L'elaborazione delle regole non avviene a ciclo continuo. Pertanto, se viene trovata una corrispondenza in una regola di rete, non vengono elaborate altre regole. Se configurata, la modalità IDPS viene eseguita su tutto il traffico attraversato e in caso di corrispondenza della firma, IDPS può avvisare o/e bloccare il traffico sospetto.

Le regole dell'applicazione valutano quindi il pacchetto in ordine di priorità se non esiste alcuna corrispondenza tra regole di rete e se il protocollo è HTTP, HTTPS o MSSQL.

Per HTTP, Firewall di Azure cerca una corrispondenza di una regola dell'applicazione in base all'intestazione Host. Per il protocollo HTTPS, Firewall di Azure cerca una corrispondenza con una regola dell'applicazione solo in base a SNI.

Nei casi HTTPS controllati da HTTP e TLS, il firewall ignora l'indirizzo IP di destinazione del pacchetto e usa l'indirizzo IP risolto DNS dall'intestazione Host. Il firewall prevede di ottenere il numero di porta nell'intestazione Host, altrimenti presuppone la porta standard 80. Se si verifica una mancata corrispondenza tra la porta TCP effettiva e la porta nell'intestazione host, il traffico viene eliminato. La risoluzione DNS viene eseguita da DNS di Azure o da un DNS personalizzato, se configurato nel firewall. 

Nota

Sia i protocolli HTTP che HTTPS (con ispezione TLS) vengono sempre riempiti da Firewall di Azure con intestazione XFF (X-Forwarded-For) uguale all'indirizzo IP di origine originale. 

Quando una regola dell'applicazione contiene l'ispezione TLS, il motore regole del firewall elabora SNI, Intestazione host e anche l'URL in base alla regola.

Se ancora non viene trovata una corrispondenza nelle reparto IT dell'applicazione, il pacchetto viene valutato in base alla raccolta regole dell'infrastruttura. Se non è ancora presente alcuna corrispondenza, il pacchetto viene rifiutato per impostazione predefinita.

Nota

È possibile configurare le regole di rete per il protocollo IP TCP, UDP, ICMPo Qualsiasi. Qualsiasi protocollo IP include tutti i protocolli IP definiti nel documento Numeri di protocollo IANA (Internet Assigned Numbers Authority). Se una porta di destinazione è configurata in modo esplicito, la regola viene convertita in una regola TCP+UDP. Prima del 9 novembre 2020, Qualsiasi indicava TCP, UDP o ICMP. Potrebbe quindi essere stata configurata una regola prima di tale data con Protocollo = Qualsiasi e porte di destinazione = '*'. Se non si intende consentire alcun protocollo IP come attualmente definito, modificare la regola per configurare in modo esplicito i protocolli desiderati (TCP, UDP o ICMP).

Connessioni in ingresso

Regole DNAT e regole di rete

È possibile abilitare la connettività alla rete privata (anteprima) o Internet in ingresso configurando Destination Network Address Translation (DNAT) come descritto in Filtrare il traffico della rete privata o Internet in ingresso con DNAT di Firewall di Azure tramite il portale di Azure. Le regole NAT vengono applicate in ordine di priorità prima delle regole di rete. Se viene trovata una corrispondenza, il traffico viene convertito in base alla regola DNAT e consentito dal firewall. Il traffico non è quindi soggetto a ulteriori elaborazioni da altre regole di rete. Per motivi di sicurezza, l'approccio consigliato consiste nell'aggiungere un'origine Internet specifica per consentire l'accesso DNAT alla rete evitando di usare caratteri jolly.

Le regole di applicazione non vengono applicate per le connessioni in ingresso. Per filtrare il traffico HTTP o HTTPS in ingresso è quindi necessario usare Web application firewall (WAF). Per altre informazioni, vedere Che cos'è Azure Web Application Firewall?

Esempi

Negli esempi seguenti vengono illustrati i risultati di alcune di queste combinazioni di regole.

Esempio 1

La connessione a google.com è consentita a causa di una regola di rete corrispondente.

Regola di rete

  • Azione: Consenti
name Protocollo Tipo di origine Origine Tipo destinazione Indirizzo di destinazione Porte di destinazione
Allow-web TCP Indirizzo IP * Indirizzo IP * 80,443

Regola dell'applicazione

  • Azione: nega
name Tipo di origine Origine Protocollo:Porta FQDN di destinazione
Deny-google Indirizzo IP * http:80,https:443 google.com

Risultato

La connessione a google.com è consentita perché il pacchetto corrisponde alla regola di rete Consenti-Web. A questo punto l'elaborazione della regola viene arrestata.

Esempio 2

Il traffico SSH viene negato perché una raccolta di regole di rete Nega di priorità più alta lo blocca.

Raccolta regole di rete 1

  • Nome: Allow-collection
  • Priorità: 200
  • Azione: Consenti
name Protocollo Tipo di origine Origine Tipo destinazione Indirizzo di destinazione Porte di destinazione
Allow-SSH TCP Indirizzo IP * Indirizzo IP * 22

Raccolta regole di rete 2

  • Nome: Deny-collection
  • Priorità: 100
  • Azione: nega
name Protocollo Tipo di origine Origine Tipo destinazione Indirizzo di destinazione Porte di destinazione
Deny-SSH TCP Indirizzo IP * Indirizzo IP * 22

Risultato

Le connessioni SSH vengono negate perché una raccolta di regole di rete con priorità più alta lo blocca. A questo punto l'elaborazione della regola viene arrestata.

Modifiche alle regole

Se si modifica una regola per negare il traffico consentito in precedenza, le sessioni esistenti pertinenti vengono eliminate.

Comportamento dell'handshake a tre vie

Come servizio con stato, Firewall di Azure completa un handshake TCP a tre vie per il traffico consentito, da un'origine alla destinazione. Ad esempio, da VNet-A a VNet-B.

La creazione di una regola Consenti dalla rete virtuale A alla rete virtuale B non significa che sono consentite nuove connessioni avviate dalla rete virtuale B alla rete virtuale A.

Di conseguenza, non è necessario creare una regola di negazione esplicita da VNet-B a VNet-A.

Passaggi successivi