Firewall e diagnostica stanno insieme per un motivo pratico: quasi tutti i «non passa» non sono il firewall, e quasi tutti i «passa e non dovrebbe» sono un ordine di valutazione che non avevi in testa.

Tre SKU, e la differenza non è il prezzo

Azure Firewall esiste in Basic, Standard e Premium, e non è una scala graduale. Basic è pensato per le piccole e medie imprese, con limiti da conoscere prima di proporlo: threat intelligence solo in modalità di segnalazione, scale unit fisso a due istanze di backend, throughput raccomandato di 250 Mbps. Non è un perimetro per un ambiente regolato.

Standard fa filtraggio L3-L7 e riceve i feed di threat intelligence da Microsoft Cyber Security: segnala e blocca IP e domini noti come malevoli, in tempo reale.

Premium aggiunge le quattro cose che l’esame associa a questo SKU: ispezione TLS, IDPS a firme, filtro per URL e categorie web valutate sull’URL intero. Un vincolo che passa inosservato: lo SKU della firewall policy deve corrispondere a quello dell’istanza, e una firewall Premium richiede una policy Premium.

La gerarchia delle regole, e l’ordine che sorprende

La firewall policy ha tre livelli: rule collection group, rule collection, rule. Il gruppo è la prima unità valutata e segue la priorità numerica. Ne esistono tre predefiniti, con priorità fissa:

Default DNAT rule collection group         priorità 100
Default Network rule collection group      priorità 200
Default Application rule collection group  priorità 300

Non puoi cancellarli né cambiarne la priorità: se ti serve un ordine diverso, crei gruppi personalizzati e usi solo quelli, senza mescolarli con i predefiniti.

La rule collection, seconda unità valutata, ha una propria priorità e una sola azione, allow o deny, valida per tutte le regole che contiene. Le regole, terzo livello, non hanno priorità: si valutano dall’alto verso il basso, e se nessuna consente il traffico questo viene negato per impostazione predefinita.

La conseguenza è il classico errore di progetto. Le regole di rete si valutano prima di quelle applicative: una regola di rete che consente 443 verso Internet fa passare il traffico prima che una regola applicativa possa filtrare l’FQDN, e il filtro per nome a dominio non entra mai in gioco. Se vuoi il controllo L7, il traffico non deve essere già ammesso a L4. Le DNAT gestiscono l’ingresso dagli IP pubblici del firewall, quelle di rete lavorano su indirizzi, porte e protocolli, quelle applicative su FQDN e URL.

Premium: che cosa l’ispezione TLS vede e che cosa no

L’ispezione TLS termina la connessione e ne apre due, una verso il server e una verso il client, generando al volo un certificato con la CA intermedia che fornisci tu. I casi supportati sono due: in uscita ed est-ovest, incluso il traffico da e verso l’on-premises. L’ispezione TLS in ingresso non è Azure Firewall, la fa il Web Application Firewall su Application Gateway: è una distinzione che l’esame sa fare.

Il filtro per URL vale su HTTP e HTTPS, ma su HTTPS solo se l’ispezione TLS è abilitata a livello di regola applicativa. E quattro categorie web non supportano la terminazione TLS per ragioni di privacy: Education, Finance, Government, Health and medicine. Per quelle aggiungi i singoli URL alle regole applicative a mano.

L’IDPS è a firme: oltre 67.000 in più di 50 categorie, con 20-40 nuove regole al giorno. Ogni firma ha una modalità — Disabled, Alert oppure Alert and Deny — e puoi personalizzarne fino a 10.000. Rileva su tutte le porte e tutti i protocolli per il traffico non cifrato: su HTTPS serve l’ispezione TLS, altrimenti guarda un tunnel opaco. Un dettaglio che si paga caro: per decidere se un flusso è in ingresso, in uscita o interno l’IDPS usa gli intervalli IP privati, e per impostazione predefinita considera privati solo quelli della RFC 1918. Se il tuo spazio interno esce da lì, le firme si applicano nella direzione sbagliata finché non modifichi la lista.

Quando il traffico non passa: le due lenti di Network Watcher

Le regole di sicurezza efficaci mostrano, per scheda di rete, l’aggregazione fra il NSG della NIC, quello della subnet e le regole amministrative di Azure Virtual Network Manager. Sono divise fra ingresso e uscita, si scaricano in CSV e per ogni regola vedi i prefissi coinvolti. È la lente dell’audit periodico: confronti l’insieme prescritto con quello effettivo, macchina per macchina.

NSG diagnostics è la lente dell’incidente singolo: simula un flusso e dice se è consentito o negato, e per quale regola.

Target resource type: Virtual machine
Protocol: TCP | UDP | ICMP | Any
Direction: Inbound | Outbound
Source type: IPv4 address/CIDR | Service Tag
Destination IP address, Destination port

Il risultato elenca ogni NSG valutato con la regola che ha fatto match: vedi subito dove ti fermi. L’esempio della documentazione è il caso più frequente: una regola DenyVnetInBound con origine il tag di servizio VirtualNetwork blocca Azure Bastion, perché la subnet di Bastion sta dentro quel tag. E VirtualNetwork è più largo di quanto si creda: VNet in peering, spazi on-premises connessi, IP virtuale dell’host e prefissi delle route definite dall’utente.

I target supportati sono macchine virtuali, schede di rete, schede di rete di scale set e Application Gateway v2 tranne i deployment privati. E la limitazione da ricordare: entrambe le lenti valutano NSG e regole di Virtual Network Manager, non Azure Firewall. Se il verdetto è «consentito» e il pacchetto non arriva, la risposta sta nei log del firewall, non qui.