DNS over HTTPS (DoH): implicazioni per il filtraggio dei contenuti su reti WiFi pubbliche

Benvenuto al Technical Briefing di Purple. Sono il tuo presentatore per la sessione di oggi, e dedicheremo i prossimi dieci minuti a un argomento che sta silenziosamente compromettendo le policy di filtraggio dei contenuti in migliaia di implementazioni WiFi pubbliche proprio in questo momento: il DNS over HTTPS, o DoH. Se gestisci una rete WiFi per gli ospiti in un hotel, un'area commerciale, uno stadio o una struttura del settore pubblico e non hai affrontato specificamente il DoH nella tua architettura di rete, c'è un'alta probabilità che la tua policy di filtraggio presenti una lacuna significativa. Vediamo esattamente in cosa consiste questa lacuna, perché è importante e cosa puoi fare al riguardo. Sezione uno - contesto e definizione del problema. Iniziamo con un rapido riepilogo di come funziona il tradizionale filtraggio DNS, poiché comprendere il meccanismo di bypass richiede di capire cosa viene bypassato. Quando un dispositivo ospite si connette alla tua rete WiFi e tenta di visitare un sito web, la prima cosa che fa è inviare una query DNS - in sostanza, chiede qual è l'indirizzo IP di questo dominio. Quella query viaggia su UDP o TCP sulla porta 53. La tua infrastruttura di rete intercetta quella query, la instrada verso il resolver DNS da te scelto, e quel resolver verifica il dominio confrontandolo con la tua policy di filtraggio. Se il dominio è presente in una blocklist - malware, contenuti per adulti, gioco d'azzardo, o qualsiasi cosa preveda la tua policy di utilizzo accettabile - il resolver 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 sul throughput ed è stato l'approccio standard per i gestori di sedi fisiche per quasi un decennio. Il DNS over HTTPS rompe questo modello. Ecco come. Il DoH racchiude le query DNS all'interno del normale traffico HTTPS sulla porta 443. Dal punto di vista della tua 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 resolver DoH esterno - 8.8.8.8 di Google, 1.1.1.1 di Cloudflare o molti altri - attraverso un canale crittografato che il tuo filtro DNS non può ispezionare. Il risultato? La tua policy di filtraggio DNS accuratamente configurata viene completamente bypassata. Il dispositivo risolve il dominio direttamente, senza che il tuo resolver veda mai la query. Ora, questo non è un attacco deliberato da parte dei tuoi 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 resolver configurato lo supporta. Android 9 e versioni successive supportano il Private DNS con DNS over TLS per impostazione predefinita. iOS supporta i profili di configurazione DoH a partire da iOS 14. Si tratta di dispositivi consumer tradizionali che fanno ciò che i loro produttori hanno previsto. I tuoi ospiti non stanno cercando di bypassare il tuo filtraggio. I loro dispositivi lo fanno semplicemente in modo automatico. Sezione due - approfondimento tecnico. Entriamo nei dettagli tecnici. Ci sono due modelli principali di implementazione DoH che incontrerai sul campo. Il primo è il DoH a livello di applicazione, in cui l'applicazione - in genere un browser - mantiene la propria configurazione DoH in modo indipendente dalle impostazioni DNS del sistema operativo. Firefox è l'esempio canonico. 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 sta avendo una conversazione DNS completamente separata sulla porta 443 che non puoi vedere. Il secondo modello è il DoH a livello di sistema operativo, in cui è il sistema operativo stesso a gestire l'aggiornamento. Chrome, Windows 10 e Windows 11 adottano questo approccio. Verificano se il risolutore DNS configurato nel sistema - quello assegnato dal server DHCP - ha un endpoint DoH corrispondente. In caso positivo, passano automaticamente al DoH. Questo processo è chiamato DoH opportunistico. Se assegni 8.8.8.8 come server DNS per gli ospiti, Chrome utilizzerà automaticamente l'endpoint DoH di Google. Se assegni 1.1.1.1, utilizzerà l'endpoint DoH di Cloudflare. La distinzione è importante per la strategia di mitigazione, di cui parleremo a breve. C'è un terzo vettore che vale la pena menzionare: il DNS over TLS, o DoT. Funziona 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 il DNS privato abilitato. La tua strategia di mitigazione deve affrontare entrambi. Ora parliamo del perché questo rappresenta un rischio di conformità e operativo, non solo una curiosità tecnica. Ai sensi del GDPR, se la tua politica di utilizzo accettabile stabilisce che filtri determinate categorie di contenuti e i tuoi controlli tecnici non applicano effettivamente tale politica, si crea un divario tra i tuoi impegni dichiarati di protezione dei dati e di governance dei contenuti e l'effettiva implementazione tecnica. Questo è un problema di difendibilità nel caso in cui tu debba affrontare un'indagine normativa o un incidente. Ai sensi dell'Online Safety Act del Regno Unito, i gestori di sedi che offrono accesso pubblico a internet hanno l'obbligo di proteggere gli utenti - in particolare i minori - da contenuti dannosi. Se il DoH aggira silenziosamente il tuo filtro dei contenuti, potresti non soddisfare tali obblighi. Per le sedi che rientrano nell'ambito di applicazione dello standard PCI-DSS - in particolare quelle in cui i dati delle carte di pagamento transitano su reti adiacenti al WiFi per gli ospiti - la versione 4.0 dello standard PCI-DSS richiede il monitoraggio e il controllo del traffico DNS come parte dei controlli di sicurezza della rete. Il traffico DoH non monitorato rappresenta una lacuna in tale quadro di controllo. E dal punto di vista della pura sicurezza, il DoH è stato attivamente sfruttato dai malware. I criminali informatici hanno utilizzato il DoH come canale di comando e controllo perché si confonde con il normale traffico HTTPS. La backdoor GodLua ha utilizzato il DoH per le comunicazioni di comando e controllo. Il malware PsiXBot ha utilizzato il servizio DoH di Google. Se il tuo monitoraggio della sicurezza si affida alla visibilità del DNS per rilevare attività dannose, i punti ciechi del DoH rappresentano una minaccia reale. Sezione tre - raccomandazioni di implementazione. Bene, passiamo alla pratica. Esistono tre strategie di mitigazione principali e, nella maggior parte delle distribuzioni per locali, è consigliabile implementarle tutte e tre in combinazione. Strategia uno: bloccare gli endpoint dei resolver DoH noti sul firewall. Questa è la prima linea di difesa e l'opzione più immediatamente applicabile. Mantieni una blocklist di indirizzi IP e domini di resolver DoH noti - Google, Cloudflare, Quad9, NextDNS, AdGuard e altri - e nega il traffico HTTPS in uscita verso quegli endpoint dalla tua VLAN guest. L'IETF e vari fornitori di sicurezza pubblicano e mantengono questi elenchi. Il progetto curl su GitHub mantiene un elenco completo di resolver DoH noti che rappresenta un buon 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 è diretta verso un piccolo numero di resolver ben noti. Gli utenti che conoscono il DNS a sufficienza per configurare un resolver DoH personalizzato rappresentano una minoranza molto esigua. Il limite di questo approccio è che si tratta di una blocklist, e le blocklist richiedono manutenzione. Nuovi resolver DoH compaiono regolarmente. Ma in combinazione con le altre strategie, offre una copertura solida. Strategia due: ispezione TLS sul firewall di nuova generazione. I firewall di nuova generazione di fornitori quali Palo Alto Networks, Fortinet, Check Point e Cisco Firepower supportano l'ispezione TLS - chiamata anche ispezione SSL o deep packet inspection. Quando abilitato, il firewall agisce come man-in-the-middle per il traffico HTTPS, decrittografandolo, ispezionando il payload e crittografandolo nuovamente prima dell'inoltro. Ciò consente al firewall di identificare il traffico DoH anche quando è diretto a un resolver sconosciuto. App-ID di Palo Alto è in grado di identificare specificamente il traffico DoH e di applicarvi delle policy. FortiGate di Fortinet ha funzionalità simili. Il passaggio di configurazione chiave consiste nell'assicurarsi che il traffico della VLAN guest sia instradato attraverso la policy di ispezione. La considerazione operativa in questo caso riguarda l'affidabilità del certificato. Affinché l'ispezione TLS funzioni sui dispositivi guest, tali dispositivi devono considerare attendibile il certificato di ispezione. Sui dispositivi aziendali gestiti questo processo è semplice: si distribuisce il certificato tramite MDM. Sui dispositivi guest non gestiti è più complesso. L'approccio pratico per il WiFi guest consiste nell'utilizzare il flusso di accettazione del Captive Portal per informare gli utenti che il traffico potrebbe essere ispezionato a fini di filtraggio dei contenuti, e affidarsi alla combinazione di blocco del resolver 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. Configura il firewall o il controller wireless per intercettare tutto il traffico DNS in uscita sulle porte UDP e TCP 53 e reindirizzarlo al tuo resolver DNS conforme. Questo non ferma il DoH, ma garantisce che qualsiasi traffico DNS che ripieghi sulla porta 53 - perché il DoH non è riuscito o non era disponibile - venga catturato e filtrato. Combina questa operazione con il blocco della porta 853 in uscita dalla VLAN guest per impedire al DNS over TLS di eludere i tuoi controlli. Per gli endpoint gestiti - dispositivi aziendali, dispositivi del personale - hai un'opzione aggiuntiva: Criteri di gruppo o configurazione 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 equals 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 guest non gestiti. Sezione quattro - errori comuni di implementazione. Alcuni problemi che si verificano comunemente sul campo. La modalità di errore più frequente è l'intercettazione incompleta della porta 53. I team configurano correttamente il proprio 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 codificate - 8.8.8.8, 1.1.1.1 - aggirano completamente il filtro. Verifica sempre che questa regola sia attiva e testala configurando un dispositivo di prova con un server DNS codificato 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. Assicurati che l'intercettazione della porta 53 e le blocklist dei risolutori DoH coprano sia gli indirizzi IPv4 che IPv6. Terzo: blocklist dei risolutori DoH obsolete. Se mantieni una blocklist statica di IP di risolutori DoH, questa diventerà obsoleta. Automatizza il processo di aggiornamento o utilizza un servizio di filtraggio DNS che gestisca questa lista per te. Cloudflare Gateway, Cisco Umbrella e servizi DNS aziendali simili includono il rilevamento del bypass del DoH come funzionalità gestita. Quarto: eccessivo affidamento su un singolo livello di mitigazione. La mitigazione del DoH è un problema di difesa in profondità. 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. Applica tutti e tre i livelli. Sezione cinque - domande rapide. La mitigazione del DoH interrompe i legittimi strumenti di privacy? Potenzialmente sì. Se un utente utilizza una configurazione del browser legittima e incentrata sulla privacy, il blocco del DoH lo costringerà a utilizzare il tuo risolutore DNS. La tua politica di utilizzo accettabile deve 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 tuo firewall di nuova generazione dovrebbe includere il rilevamento di anomalie per volumi di query insolitamente elevati o pattern di query coerenti con il tunneling. Che dire delle app mobili che utilizzano DoH? Questo è il caso più complesso. Le app mobili che implementano il proprio stack DoH - invece di utilizzare le impostazioni DNS del sistema operativo - sono difficili da controllare senza TLS inspection. La migliore mitigazione consiste nella combinazione del blocco dei resolver noti e della TLS inspection. 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 diversi vettori di minaccia. Sezione sei - ROI e impatto sul business. Permettetemi di concludere con il caso aziendale per affrontare questo problema in modo adeguato. Il costo del mancato intervento sul 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 monitoraggio DNS presenta un punto cieco, un'indagine normativa sulla conformità del filtro dei contenuti - può costare molto di più rispetto all'investimento in una mitigazione adeguata. Per un gruppo alberghiero che opera in 20 proprietà, la distribuzione della mitigazione 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 sovraccarico operativo continuo per il mantenimento delle blocklist dei resolver - 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 vendita al dettaglio che operano in conformità con 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 in sede di audit PCI-DSS e i relativi costi di rimediazione. Per le sedi del settore pubblico e per quelle che operano ai sensi dell'Online Safety Act, una mitigazione DoH documentata fa parte della base di prove che attesta l'adozione di misure tecniche ragionevoli per applicare la 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 abilitate per il DoH sui dispositivi dei vostri ospiti. Se negli ultimi 12 mesi non avete sottoposto ad audit la vostra architettura di filtraggio DNS per verificare la presenza di vettori di bypass DoH, questo audit dovrebbe far parte della vostra roadmap a breve termine. Per riassumere i punti chiave del briefing 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 principali. Due: la strategia di mitigazione a tre livelli - bloccare gli IP dei resolver DoH noti, implementare la TLS inspection sul firewall di nuova generazione 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. GDPR, Online Safety Act e PCI-DSS hanno tutti implicazioni per le sedi in cui il DoH esegue silenziosamente il bypass delle policy di filtraggio dei contenuti. Quattro: l'errore di implementazione più comune è l'intercettazione incompleta della porta 53. Testatela. Verificatela. Non date per scontato che funzioni. Cinque: i servizi di filtraggio DNS gestiti - Cloudflare Gateway, Cisco Umbrella e simili - includono sempre più spesso il rilevamento del bypass DoH come funzionalità gestita, riducendo l'overhead operativo legato alla manutenzione di blacklist statiche. Per oggi è tutto con il Purple Technical Briefing. Se desiderate verificare la vostra attuale architettura di filtraggio DNS o implementare la mitigazione DoH in tutta la vostra rete di sedi fisiche, la piattaforma Purple fornisce l'intelligence di rete e il livello di gestione del guest WiFi necessari per supportare tale implementazione. Grazie per l'ascolto e ci vediamo alla prossima sessione.