DNS sicuro: DNSSEC e DNS su HTTPS (DoH)

Il Domain Name System (DNS) traduce i nomi di dominio leggibili dagli esseri umani in indirizzi IP. Progettato negli anni '80, il DNS è stato creato senza funzionalità di sicurezza: query e risposte viaggiano in chiaro sulla porta UDP/TCP 53, senza autenticazione. Questo crea due vulnerabilità principali: il DNS cache poisoning (iniezione di risposte DNS falsificate per reindirizzare gli utenti verso server dannosi) e l'intercettazione DNS (osservare i domini richiesti da un utente rivela la sua attività di navigazione). Due standard affrontano questi problemi: DNSSEC impedisce la falsificazione e DNS over HTTPS (DoH) impedisce l'intercettazione.

Il DNS cache poisoning (attacco Kaminsky) sfrutta l'assenza di autenticazione nel protocollo DNS. Un resolver invia una query a un server DNS autorevole e memorizza nella cache la risposta per la durata del TTL. Un aggressore in grado di indovinare l'ID della transazione (a 16 bit e prevedibile) e la porta di origine (utilizzata come entropia aggiuntiva a partire da RFC 5452) può inviare risposte falsificate che il resolver memorizza nella cache, reindirizzando al server dell'aggressore tutti gli utenti che utilizzano quel resolver. Una volta avvelenata la cache, gli utenti vengono indirizzati verso server falsi anche se hanno digitato il dominio corretto. DNSSEC impedisce tutto ciò firmando digitalmente le risposte DNS.

DNSSEC aggiunge firme crittografiche ai record DNS, consentendo ai resolver di verificare che le risposte provengano dall'autorità legittima della zona e non siano state manomesse. DNSSEC introduce nuovi tipi di record: RRSIG (firma del resource record, la firma effettiva su un insieme di record), DNSKEY (la chiave pubblica utilizzata per verificare le firme), DS (delegation signer, collega le chiavi della zona padre e della zona figlia) e NSEC/NSEC3 (negazione autenticata dell'esistenza: dimostra che un nome non esiste). DNSSEC crea una catena di fiducia dalla zona radice, firmata da ICANN, passando per le zone TLD e arrivando alle zone autorevoli.

DNSSEC utilizza due tipi di chiavi di firma. La Zone Signing Key (ZSK) firma i singoli insiemi di record DNS (RRSIG) e viene ruotata frequentemente, ogni mese o ogni trimestre, per garantire flessibilità operativa. La Key Signing Key (KSK) firma l'insieme di record DNSKEY e fornisce l'ancora di fiducia della zona. La KSK viene ruotata meno frequentemente, una volta all'anno, perché ogni volta che cambia è necessario aggiornare la zona padre con il nuovo record DS: un processo che richiede coordinamento. La KSK verifica la ZSK; la ZSK firma i dati. Questa struttura a due livelli bilancia la sicurezza, garantita dalla rotazione frequente della ZSK, con il carico operativo, ridotto dalla rotazione poco frequente della KSK.

DNSSEC presenta importanti limitazioni. Non cifra le query DNS: firma solo le risposte per garantirne l'integrità. Un intercettatore può ancora vedere tutte le query DNS, ma non può falsificare le risposte. Enumerazione della zona: i record NSEC, che dimostrano la non esistenza, consentono agli aggressori di esplorare la zona ed enumerare tutti i nomi di dominio al suo interno; NSEC3 mitiga il problema usando nomi sottoposti ad hashing, ma non lo risolve completamente. Complessità operativa: la gestione delle chiavi, la scadenza delle firme e il coordinamento con la zona padre creano un notevole sovraccarico operativo. L'adozione di DNSSEC rimane incompleta: molti TLD e registrar lo supportano, ma molte organizzazioni non lo hanno ancora implementato.

DNS over HTTPS (DoH) crittografa le query DNS all'interno di HTTPS (RFC 8484), nascondendone il contenuto agli osservatori della rete. Le query vengono inviate a un resolver compatibile con DoH tramite un URL HTTPS standard, rendendo il traffico DNS indistinguibile dagli altri flussi HTTPS. In questo modo si impedisce a ISP, datori di lavoro e aggressori che intercettano il traffico di vedere quali domini vengono richiesti dall'utente, colmando la lacuna di privacy lasciata da DNSSEC. Tuttavia, DoH trasferisce la fiducia dal resolver DNS della rete al provider DoH (in genere Google 8.8.8.8, Cloudflare 1.1.1.1 o il resolver DoH dell'organizzazione). Oggi DoH è supportato nativamente dalla maggior parte dei principali browser.

DNS over TLS (DoT) (RFC 7858) crittografa le query DNS usando TLS su una porta TCP dedicata, la 853, anziché incapsularle in HTTPS. DoT offre gli stessi vantaggi in termini di privacy di DoH, nascondendo il contenuto delle query agli intercettatori, ma è più facile da identificare e filtrare per gli amministratori di rete (porta 853 invece della porta 443). Si tratta di un'arma a doppio taglio: DoT è visibile e può essere bloccato dai firewall aziendali, mentre DoH è più difficile da bloccare senza influire sul traffico HTTPS generale. I resolver stub (a livello di sistema operativo) usano più comunemente DoT; i browser usano più comunemente DoH.

Il DNS crittografato crea una difficoltà negli ambienti aziendali che dipendono dal filtraggio basato sul DNS e dai sinkhole. Quando i browser usano resolver DoH esterni, i controlli DNS interni vengono aggirati. Contromisure aziendali: implementare un resolver DoH/DoT interno (Cisco Umbrella, Pi-hole con DoH) e configurare tutti i dispositivi affinché lo utilizzino; bloccare gli IP dei resolver DoH esterni sul firewall (Google 8.8.8.8, Cloudflare 1.1.1.1) sulla porta 443; usare la Group Policy per disabilitare il DoH a livello di browser sugli endpoint gestiti; e applicare regole di proxy trasparente che intercettino il DNS over TLS sulla porta 853. L'obiettivo è instradare tutto il DNS attraverso il resolver controllato senza bloccare completamente il DNS crittografato.

Una strategia completa per la sicurezza DNS combina più controlli. DNSSEC per le proprie zone autorevoli impedisce il cache poisoning del proprio dominio. Il filtraggio basato sul DNS (Cisco Umbrella, Cloudflare Gateway) blocca i domini dannosi a livello di resolver. L'uso di DoH/DoT verso un resolver controllato garantisce la privacy delle query senza perdere la visibilità necessaria al filtraggio. L'analisi dei log DNS nel SIEM registra tutte le query per la ricerca proattiva delle minacce: i log DNS rivelano il traffico C2, l'esfiltrazione di dati tramite tunneling DNS e l'attività degli algoritmi di generazione dei domini (DGA) usati dai malware. La telemetria DNS è una delle fonti di dati di sicurezza con il più alto valore informativo disponibili.

Il tunneling DNS codifica i dati all'interno delle query e delle risposte DNS per esfiltrare dati o stabilire canali C2 attraverso reti in cui altro traffico in uscita è bloccato. Strumenti come iodine, DNScat e dnscat2 codificano i payload nelle etichette dei sottodomini (con query per EXFILTRATEDDATA.evil.com) o nei record TXT. Il rilevamento si basa su nomi di query DNS insolitamente lunghi (>100 caratteri), un volume elevato di query provenienti da un singolo host, query per domini principali inesistenti, tipi di record insoliti (TXT, NULL) e sull'analisi dell'entropia delle etichette dei domini (i dati codificati presentano un'entropia di Shannon elevata). Le piattaforme di analisi della sicurezza DNS segnalano automaticamente i pattern di tunneling.

Le DNS Response Policy Zones (RPZ) consentono ai resolver DNS di applicare policy locali di override alle risposte DNS, creando di fatto un sinkhole locale a livello di resolver senza modificare l'infrastruttura DNS globale. Quando un client esegue una query per un dominio noto come dannoso, la policy RPZ restituisce NXDOMAIN, un reindirizzamento a un IP sinkhole oppure una risposta passthrough. I feed RPZ sono disponibili presso provider di threat intelligence (Spamhaus, SURBL) e possono essere importati direttamente nei resolver BIND o Unbound. RPZ è un potente strumento difensivo perché applica il filtraggio a livello DNS a tutti i dispositivi della rete senza richiedere alcuna configurazione lato client.

Verifichi la propria comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione ha imparato che: DNSSEC aggiunge firme crittografiche ai record DNS usando coppie di chiavi KSK/ZSK per impedire il cache poisoning, ma non crittografa le query; DNS over HTTPS (DoH) crittografa le query DNS all'interno di HTTPS per impedire le intercettazioni, ma crea rischi di aggiramento del filtraggio aziendale; e il tunneling DNS codifica i dati nelle query DNS e può essere rilevato analizzando lunghezza, volume ed entropia delle query. Nella prossima lezione esamineremo IPsec, i protocolli VPN e la sicurezza dell'accesso remoto.