DNS Over HTTPS (DoH): implicazioni per il filtraggio del WiFi pubblico

Benvenuti al Purple Technical Briefing. Sono il vostro ospite per la sessione di oggi e nei prossimi dieci minuti parleremo di un argomento che sta silenziosamente compromettendo le policy di filtraggio dei contenuti in migliaia di installazioni di WiFi pubblico in questo momento: il DNS over HTTPS, o DoH. Se gestite il WiFi per gli ospiti in un hotel, in una catena di negozi, in uno stadio o in una struttura del settore pubblico e non avete affrontato specificamente il DoH nella vostra architettura di rete, ci sono buone probabilità che la vostra policy di filtraggio presenti una lacuna significativa. Vediamo esattamente in cosa consiste questa lacuna, perché è importante e cosa potete fare al riguardo. Prima parte: contesto e definizione del problema. Iniziamo con un rapido riepilogo di come funziona il tradizionale filtraggio DNS, perché per comprendere il meccanismo di aggiramento è necessario capire cosa viene aggirato. Quando il dispositivo di un ospite si connette al vostro WiFi e tenta di visitare un sito web, la prima cosa che fa è inviare una query DNS, chiedendo essenzialmente quale sia l'indirizzo IP di quel dominio. Tale query viaggia su UDP o TCP sulla porta 53. La vostra infrastruttura di rete intercetta la query, la instrada verso il risolutore DNS scelto e quest'ultimo verifica il dominio rispetto alla vostra policy di filtraggio. Se il dominio si trova in una blocklist (malware, contenuti per adulti, gioco d'azzardo o qualsiasi altra cosa specificata nella vostra policy di utilizzo accettabile), il risolutore si rifiuta di restituire l'indirizzo IP e la connessione non avviene mai. Questo è il fondamento di ogni implementazione di filtraggio dei contenuti basata su DNS. È conveniente, non influisce sulla velocità di trasmissione ed è l'approccio standard per i gestori di strutture da quasi un decennio. Il DNS over HTTPS rompe questo modello. Ecco come. Il DoH incapsula le query DNS all'interno del normale traffico HTTPS sulla porta 443. Dal punto di vista della vostra rete, appare identico a qualsiasi altro traffico web crittografato. Non c'è modo di distinguere una query DoH da un utente che carica una pagina web, guarda un video in streaming o accede a un'app bancaria. La query va direttamente a un risolutore DoH esterno (como l'8.8.8.8 di Google, l'1.1.1.1 di Cloudflare o molti altri) attraverso un canale crittografato che il vostro filtro DNS non può ispezionare. Il risultato? La vostra policy di filtraggio DNS accuratamente configurata viene completamente aggirata. Il dispositivo risolve il dominio direttamente, senza che il vostro risolutore veda mai la query. Ora, questo non è un attacco deliberato da parte dei vostri ospiti. Nella maggior parte dei casi, è del tutto passivo. Firefox ha il DoH abilitato per impostazione predefinita dal 2020. Chrome aggiorna automaticamente le query DNS a DoH se il risolutore configurato lo supporta. Android 9 e versioni successive supportano il DNS privato con DNS over TLS per impostazione predefinita. iOS supporta i profili di configurazione DoH a partire da iOS 14. Si tratta di dispositivi di consumo di massa che fanno ciò che i produttori hanno previsto. I vostri ospiti non stanno cercando di aggirare il filtraggio. I loro dispositivi lo fanno semplicemente in modo automatico. Seconda parte: approfondimento tecnico. Entriamo nei dettagli tecnici. Esistono due modelli principali di implementazione del DoH che incontrerete sul campo. Il primo è il DoH a livello applicativo, in cui l'applicazione (in genere un browser) mantiene la propria configurazione DoH indipendentemente dalle impostazioni DNS del sistema operativo host. Firefox è l'esempio classico. Quando Firefox è installato e il DoH è abilitato, ignora completamente il risolutore DNS di sistema e invia tutte le sue query DNS al provider DoH configurato, che per impostazione predefinita è Cloudflare. Il server DNS assegnato tramite DHCP è irrilevante. Le regole di intercettazione sulla porta 53 sono irrilevanti. Firefox avvia una conversazione DNS completamente separata sulla porta 443 che non potete vedere. Il secondo modello è il DoH a livello di sistema operativo, in cui è il sistema operativo stesso a gestire l'aggiornamento. Chrome e Windows 10 e 11 adottano questo approccio. Verificano se il risolutore DNS configurato nel sistema (quello assegnato dal server DHCP) ha un endpoint DoH corrispondente. Se lo trova, aggiornano automaticamente la connessione a DoH. Questo è chiamato DoH opportunistico. Se assegnate 8.8.8.8 come server DNS per gli ospiti, Chrome utilizzerà automaticamente l'endpoint DoH di Google. Se assegnate 1.1.1.1, utilizzerà l'endpoint DoH di Cloudflare. La distinzione è importante per la strategia di mitigazione, che vedremo a breve. C'è un terzo vettore che vale la pena menzionare: il DNS over TLS, o DoT. Questo opera sulla porta 853 e crittografa le query DNS utilizzando TLS anziché incapsularle in HTTPS. È più facile da bloccare rispetto al DoH perché utilizza una porta dedicata, ma è sempre più comune sui dispositivi Android con l'opzione DNS privato abilitata. La vostra strategia di mitigazione deve affrontare entrambi. Ora parliamo del perché questo rappresenti un rischio operativo e di conformità, e non solo una curiosità tecnica. Ai sensi del GDPR, se la vostra policy di utilizzo accettabile dichiara che filtrate determinate categorie di contenuti e i vostri controlli tecnici non applicano effettivamente tale policy, si crea un divario tra i vostri impegni dichiarati in materia di protezione dei dati e governance dei contenuti e l'effettiva implementazione tecnica. Questo rappresenta un problema di difendibilità in caso di indagini normative o incidenti. Ai sensi dell'Online Safety Act del Regno Unito, i gestori di strutture che forniscono l'accesso pubblico a Internet hanno l'obbligo di proteggere gli utenti (in particolare i minori) da contenuti dannosi. Se il DoH aggira silenziosamente il filtraggio dei contenuti, potreste non soddisfare tali obblighi. Per le strutture che rientrano nell'ambito del PCI DSS (in particolare quelle in cui i dati delle carte di pagamento transitano su reti adiacenti al WiFi degli ospiti), la versione 4.0 del PCI DSS richiede di monitorare e controllare il traffico DNS come parte dei controlli di sicurezza della rete. Il traffico DoH non monitorato rappresenta una lacuna in tale framework di controllo. E da un punto di vista puramente di sicurezza, il DoH è stato attivamente sfruttato dai malware. I criminali informatici hanno utilizzato il DoH come canale di Command-and-Control perché si confonde con il normale traffico HTTPS. La backdoor GodLua ha utilizzato il DoH per le comunicazioni di Command-and-Control. Il malware PsiXBot ha utilizzato il servizio DoH di Google. Se il vostro monitoraggio della sicurezza si affida alla visibilità del DNS per rilevare attività dannose, i punti ciechi del DoH rappresentano una minaccia reale. Terza parte: raccomandazioni di implementazione. Bene, passiamo alla pratica. Esistono tre strategie di mitigazione principali e, nella maggior parte delle installazioni, è consigliabile implementarle tutte e tre in combinazione. Strategia uno: bloccare gli endpoint dei risolutori DoH noti sul firewall. Questa è la prima linea di difesa e l'opzione più immediatamente implementabile. Gestite una blocklist di indirizzi IP e domini di risolutori DoH noti (Google, Cloudflare, Quad9, NextDNS, AdGuard e altri) e bloccate il traffico HTTPS in uscita verso tali endpoint dalla VLAN degli ospiti. L'IETF e vari fornitori di sicurezza pubblicano e aggiornano queste liste. Il progetto curl su GitHub mantiene un elenco completo di risolutori DoH noti che rappresenta un ottimo punto di partenza. Questo approccio gestisce la maggior parte del traffico DoH perché, come dimostrato dalle ricerche del Software Engineering Institute della Carnegie Mellon, la maggior parte del traffico DoH si dirige verso un numero limitato di risolutori noti. Gli utenti che hanno competenze sufficienti per configurare un risolutore DoH personalizzato rappresentano una minoranza molto ridotta. Il limite di questo approccio è che si tratta di una blocklist, e le blocklist richiedono manutenzione. Nuovi risolutori DoH compaiono regolarmente. Ma in combinazione con le altre strategie, fornisce una copertura solida. Strategia due: ispezione TLS sul vostro Next-Generation Firewall. I Next-Generation Firewall di produttori come Palo Alto Networks, Fortinet, Check Point e Cisco Firepower supportano l'ispezione TLS, chiamata anche ispezione SSL o ispezione profonda dei pacchetti. Quando è abilitata, il firewall agisce come man-in-the-middle per il traffico HTTPS, decrittografandolo, ispezionando il payload e crittografandolo nuovamente prima dell'invio. Ciò consente al firewall di identificare il traffico DoH anche quando è diretto a un risolutore sconosciuto. L'App-ID di Palo Alto può identificare specificamente il traffico DoH e applicarvi delle policy. Il FortiGate di Fortinet ha funzionalità simili. Il passaggio chiave della configurazione consiste nell'assicurarsi che il traffico della VLAN degli ospiti sia instradato attraverso la policy di ispezione. La considerazione operativa in questo caso riguarda la attendibilità dei certificati. Affinché l'ispezione TLS funzioni sui dispositivi degli ospiti, questi devono considerare attendibile il vostro certificato di ispezione. Sui dispositivi aziendali gestiti questo è semplice: si distribuisce il certificato tramite MDM. Sui dispositivi degli ospiti non gestiti è più complesso. L'approccio pratico per il WiFi degli ospiti consiste nell'utilizzare il flusso di accettazione del Captive Portal per informare gli utenti che il traffico potrebbe essere ispezionato a scopo di filtraggio dei contenuti, e affidarsi alla combinazione di blocco dei risolutori DoH e intercettazione DNS come controlli primari, con l'ispezione TLS come livello secondario per gli ambienti a rischio più elevato. Strategia tre: forzare l'intercettazione e il reindirizzamento del DNS. Configurate il firewall o il controller wireless per intercettare tutto il traffico DNS in uscita sulla porta UDP e TCP 53 e reindirizzarlo al vostro risolutore DNS conforme. Questo non ferma il DoH, ma garantisce che qualsiasi traffico DNS che torni alla porta 53 (perché il DoH non è riuscito o non era disponibile) venga catturato e filtrato. Combinate questo con il blocco della porta 853 in uscita dalla VLAN degli ospiti per impedire al DNS over TLS di aggirare i vostri controlli. Per gli endpoint gestiti (dispositivi aziendali, dispositivi del personale), avete un'opzione aggiuntiva: la configurazione di Criteri di gruppo o MDM per disabilitare il DoH a livello di browser e sistema operativo. In Firefox, la preferenza network.trr.mode impostata su 5 disabilita completamente il DoH. In Chrome, il flag disable-features uguale a DnsOverHttps ottiene lo stesso risultato. Windows 10 e 11 dispongono di impostazioni di Criteri di gruppo per controllare il comportamento del DoH. Questo è il controllo più affidabile per i dispositivi gestiti, ma non è applicabile ai dispositivi degli ospiti non gestiti. Quarta parte: errori comuni di implementazione. Alcune cose che comunemente vanno storte sul campo. L'errore più frequente è l'intercettazione incompleta della porta 53. I team configurano correttamente il servizio di filtraggio DNS ma dimenticano di aggiungere la regola del firewall che reindirizza tutto il traffico in uscita sulla porta 53. I dispositivi con impostazioni DNS hardcoded (8.8.8.8, 1.1.1.1) aggirano completamente il filtro. Verificate sempre che questa regola sia attiva e testatela configurando un dispositivo di prova con un server DNS hardcoded e confermando che i domini filtrati siano ancora bloccati. Il secondo errore comune è non considerare l'IPv6. Le query DNS su IPv6 sono sempre più frequenti e molte regole del firewall sono scritte solo per l'IPv4. Assicuratevi che l'intercettazione della porta 53 e le blocklist dei risolutori DoH coprano sia gli indirizzi IPv4 che quelli IPv6. Terzo: blocklist dei risolutori DoH non aggiornate. Se gestite una blocklist statica di IP di risolutori DoH, diventerà obsoleta. Automatizzate il processo di aggiornamento o utilizzate un servizio di filtraggio DNS che gestisca questa lista per voi. Cloudflare Gateway, Cisco Umbrella e servizi DNS aziendali simili includono il rilevamento dell'aggiramento DoH como funzionalità gestita. Quarto: eccessivo affidamento su un singolo livello di mitigazione. La mitigazione del DoH è un problema di difesa approfondita. Nessun controllo singolo è sufficiente. Il blocco dei risolutori noti gestisce la maggior parte dei casi. L'ispezione TLS gestisce i casi limite. L'intercettazione DNS fornisce una rete di sicurezza. Applicate tutti e tre i livelli. Quinta parte: domande a raffica. La mitigazione del DoH interrompe i legittimi strumenti di privacy? Potenzialmente sì. Se un utente utilizza una configurazione del browser incentrata sulla privacy, il blocco del DoH lo costringerà a utilizzare il vostro risolutore DNS. La vostra policy di utilizzo accettabile dovrebbe chiarire che il risolutore DNS della struttura viene utilizzato a scopo di filtraggio dei contenuti. Questa è una pratica standard e legalmente difendibile. Il DoH può essere utilizzato per esfiltrare dati dalla mia rete? Sì, e questo è un vettore di minaccia reale. Il tunneling DNS su DoH è stato dimostrato sul campo. La funzionalità di rilevamento DoH del vostro Next-Generation Firewall dovrebbe includere il rilevamento di anomalie per volumi di query insolitamente elevati o modelli di query coerenti con il tunneling. E per quanto riguarda le app mobili che utilizzano il DoH? Questo è il caso più difficile. Le app mobili che implementano il proprio stack DoH (anziché utilizzare le impostazioni DNS del sistema operativo) sono difficili da controllare senza l'ispezione TLS. La vostra migliore mitigazione è la combinazione di blocco dei risolutori noti e ispezione TLS. Il WPA3 è rilevante in questo contesto? Il WPA3 migliora la crittografia via etere e fornisce la forward secrecy, il che è eccellente per la privacy degli ospiti. Ma il WPA3 non affronta il DoH: si tratta di un problema di protocollo applicativo di livello 7, non di un problema di sicurezza wireless di livello 2. Sono controlli complementari che affrontano vettori di minaccia diversi. Sesta parte: ROI e impatto aziendale. Vorrei concludere con il caso aziendale per affrontare questo problema in modo corretto. Il costo del non affrontare il DoH è asimmetrico. Un singolo incidente (un ospite che accede a contenuti illegali sulla vostra rete, un callback di malware che non viene rilevato perché il vostro monitoraggio DNS presentava un punto cieco, un'indagine normativa sulla conformità del filtraggio dei contenuti) può costare significativamente di più rispetto all'investimento in una mitigazione adeguata. Per un gruppo alberghiero che opera in 20 proprietà, l'implementazione della mitigazione del DoH comporta in genere un impegno di configurazione una tantum da due a quattro ore per proprietà per le regole del firewall e la configurazione dell'intercettazione DNS, oltre a un costo operativo continuo per il mantenimento delle blocklist dei risolutori, che è ampiamente automatizzato se si utilizza un servizio di filtraggio DNS gestito. L'investimento totale è modesto rispetto alla riduzione del rischio. Per le catene di negozi che operano nell'ambito del PCI DSS, il vantaggio in termini di conformità è direttamente quantificabile. Dimostrare che i controlli di sicurezza della rete includono la mitigazione del DoH riduce il rischio di rilievi durante un audit PCI DSS e i relativi costi di risoluzione. Per le strutture del settore pubblico e quelle che operano ai sensi dell'Online Safety Act, una mitigazione del DoH documentata fa parte delle prove che dimostrano che avete adottato misure tecniche ragionevoli per applicare la vostra policy di filtraggio dei contenuti. In conclusione: il DoH non è un problema futuro. È un problema attuale. Firefox, Chrome, Android e iOS stanno già distribuendo configurazioni compatibili con il DoH sui dispositivi dei vostri ospiti. Se non avete verificato la vostra architettura di filtraggio DNS per i vettori di aggiramento DoH negli ultimi 12 mesi, tale verifica dovrebbe essere inserita nella vostra roadmap a breve termine. Per riassumere i punti chiave della sessione di oggi. Uno: il DoH crittografa le query DNS all'interno di HTTPS sulla porta 443, rendendole invisibili al tradizionale filtraggio DNS sulla porta 53. Questo avviene per impostazione predefinita sui browser e sui sistemi operativi più diffusi. Due: la strategia di mitigazione a tre livelli (bloccare gli IP dei risolutori DoH noti, implementare l'ispezione TLS sul Next-Generation Firewall e applicare l'intercettazione sulla porta 53) fornisce una copertura di difesa approfondita sia per i dispositivi degli ospiti gestiti che per quelli non gestiti. Tre: si tratta di una questione di conformità, non solo tecnica. Il GDPR, l'Online Safety Act e il PCI DSS hanno tutti implicazioni per le strutture in cui il DoH aggira silenziosamente le policy di filtraggio dei contenuti. Quattro: l'errore di implementazione più comune è l'intercettazione incompleta della porta 53. Testatela. Verificatela. Don't assume it's working. Cinque: i servizi di filtraggio DNS gestiti (Cloudflare Gateway, Cisco Umbrella e simili) includono sempre più spesso il rilevamento dell'aggiramento DoH come funzionalità gestita, riducendo l'onere operativo di mantenere blocklist statiche. Con questo si conclude il Purple Technical Briefing di oggi. Se desiderate verificare la vostra attuale architettura di filtraggio DNS o implementare la mitigazione del DoH nelle vostre proprietà, la piattaforma Purple fornisce l'intelligenza di rete e il livello di gestione del WiFi per gli ospiti necessari a supportare tale implementazione. Grazie per l'ascolto e ci vediamo alla prossima sessione.