Ridurre al minimo i rischi derivanti dall’utilizzo di DoH e DoT
Protezione DoH e DoT
Controlli il tuo traffico DNS? Le organizzazioni investono molto tempo, denaro e sforzi per proteggere le proprie reti. Tuttavia, un'area che spesso non riceve sufficiente attenzione è il DNS.
Una buona panoramica dei rischi che il DNS comporta è alla conferenza Infosecurity.
Il 31% delle classi di ransomware intervistate ha utilizzato il DNS per lo scambio di chiavi.Risultati dello studio
Il 31% delle classi di ransomware intervistate utilizzava il DNS per lo scambio di chiavi.
Il problema è serio. Secondo il laboratorio di ricerca dell’Unità 42 di Palo Alto Networks, circa l’85% dei malware utilizza il DNS per stabilire un canale di comando e controllo, consentendo agli aggressori di iniettare facilmente malware nella rete e rubare dati. Fin dal suo inizio, il traffico DNS è stato in gran parte non crittografato e può essere facilmente analizzato dai meccanismi di sicurezza NGFW.
Sono emersi nuovi protocolli per DNS volti ad aumentare la riservatezza delle connessioni DNS. Sono attivamente supportati dai principali fornitori di browser e altri fornitori di software. Il traffico DNS crittografato inizierà presto a crescere nelle reti aziendali. Il traffico DNS crittografato che non viene adeguatamente analizzato e risolto dagli strumenti rappresenta un rischio per la sicurezza di un'azienda. Ad esempio, una tale minaccia è rappresentata dai cryptolocker che utilizzano il DNS per scambiare chiavi di crittografia. Gli aggressori chiedono ora un riscatto di diversi milioni di dollari per ripristinare l'accesso ai vostri dati. Garmin, ad esempio, ha pagato 10 milioni di dollari.
Se configurati correttamente, gli NGFW possono negare o proteggere l'uso di DNS-over-TLS (DoT) e possono essere utilizzati per negare l'uso di DNS-over-HTTPS (DoH), consentendo l'analisi di tutto il traffico DNS sulla rete.
Cos'è il DNS crittografato?
Che cos'è il DNS
Il Domain Name System (DNS) risolve i nomi di dominio leggibili dall'uomo (ad esempio, indirizzo ) agli indirizzi IP (ad esempio, 34.107.151.202). Quando un utente inserisce un nome di dominio in un browser web, il browser invia una query DNS al server DNS, chiedendo l'indirizzo IP associato a quel nome di dominio. In risposta, il server DNS restituisce l'indirizzo IP che utilizzerà questo browser.
Le query e le risposte DNS vengono inviate attraverso la rete in formato testo normale, non crittografato, rendendola vulnerabile allo spionaggio o alla modifica della risposta e reindirizzando il browser a server dannosi. La crittografia DNS rende difficile il tracciamento o la modifica delle richieste DNS durante la trasmissione. La crittografia delle richieste e delle risposte DNS ti protegge dagli attacchi Man-in-the-Middle eseguendo al tempo stesso le stesse funzionalità del tradizionale protocollo DNS (Domain Name System) in testo normale.
Negli ultimi anni sono stati introdotti due protocolli di crittografia DNS:
-
DNS-over-HTTPS (DoH)
-
DNS su TLS (DoT)
Questi protocolli hanno una cosa in comune: nascondono deliberatamente le richieste DNS da qualsiasi intercettazione... e anche dalle guardie di sicurezza dell'organizzazione. I protocolli utilizzano principalmente TLS (Transport Layer Security) per stabilire una connessione crittografata tra un client che effettua query e un server che risolve query DNS su una porta che normalmente non viene utilizzata per il traffico DNS.
La riservatezza delle query DNS è un grande vantaggio di questi protocolli. Tuttavia, pongono problemi alle guardie di sicurezza che devono monitorare il traffico di rete e rilevare e bloccare connessioni dannose. Poiché i protocolli differiscono nella loro implementazione, i metodi di analisi differiranno tra DoH e DoT.
DNS su HTTPS (DoH)
DNS all'interno di HTTPS
DoH utilizza la nota porta 443 per HTTPS, per la quale la RFC afferma espressamente che l'intento è quello di "mescolare il traffico DoH con altro traffico HTTPS sulla stessa connessione", "rendere difficile l'analisi del traffico DNS" ed eludere così i controlli aziendali ( ). Il protocollo DoH utilizza la crittografia TLS e la sintassi della richiesta fornita dagli standard comuni HTTPS e HTTP/2, aggiungendo richieste e risposte DNS oltre alle richieste HTTP standard.
Rischi associati alla DoH
Se non riesci a distinguere il traffico HTTPS regolare dalle richieste DoH, le applicazioni all'interno della tua organizzazione possono (e lo faranno) ignorare le impostazioni DNS locali reindirizzando le richieste a server di terze parti che rispondono alle richieste DoH, ignorando qualsiasi monitoraggio, ovvero distruggendo la capacità di controllare il traffico DNS. Idealmente, dovresti controllare DoH utilizzando le funzioni di decrittografia HTTPS.
И nell'ultima versione dei loro browser ed entrambe le società stanno lavorando per utilizzare DoH per impostazione predefinita per tutte le richieste DNS. sull’integrazione del DoH nei loro sistemi operativi. Lo svantaggio è che non solo le società di software rinomate, ma anche gli aggressori hanno iniziato a utilizzare la DoH come mezzo per aggirare le tradizionali misure firewall aziendali. (Ad esempio, consulta i seguenti articoli: , и .) In entrambi i casi, sia il traffico DoH buono che quello dannoso non verranno rilevati, lasciando l'organizzazione cieca rispetto all'uso dannoso del DoH come canale per controllare il malware (C2) e rubare dati sensibili.
Garantire visibilità e controllo del traffico DoH
Come migliore soluzione per il controllo DoH, consigliamo di configurare NGFW per decrittografare il traffico HTTPS e bloccare il traffico DoH (nome dell'applicazione: dns-over-https).
Innanzitutto, assicurati che NGFW sia configurato per decrittografare HTTPS, secondo .
In secondo luogo, crea una regola per il traffico dell'applicazione "dns-over-https" come mostrato di seguito:
Regola NGFW di Palo Alto Networks per bloccare DNS-over-HTTPS
Come alternativa provvisoria (se l'organizzazione non ha implementato completamente la decrittografia HTTPS), NGFW può essere configurato per applicare un'azione "nega" all'ID applicazione "dns-over-https", ma l'effetto sarà limitato al blocco di determinati server DoH conosciuti tramite il loro nome di dominio, quindi senza la decrittografia HTTPS il traffico DoH non può essere completamente ispezionato (vedi e cercare "dns-over-https").
DNS su TLS (DoT)
DNS all'interno di TLS
Mentre il protocollo DoH tende a mescolarsi con altro traffico sulla stessa porta, DoT utilizza invece per impostazione predefinita una porta speciale riservata a quell'unico scopo, impedendo anche specificatamente che la stessa porta venga utilizzata dal tradizionale traffico DNS non crittografato ( ).
Il protocollo DoT utilizza TLS per fornire la crittografia che incapsula le query del protocollo DNS standard, con il traffico che utilizza la nota porta 853 ( ). Il protocollo DoT è stato progettato per rendere più semplice per le organizzazioni bloccare il traffico su una porta o accettare il traffico ma abilitare la decrittografia su quella porta.
Rischi associati al DoT
Google ha implementato DoT nel suo client , con l'impostazione predefinita per utilizzare automaticamente DoT se disponibile. Se hai valutato i rischi e sei pronto a utilizzare DoT a livello organizzativo, è necessario che gli amministratori di rete consentano esplicitamente il traffico in uscita sulla porta 853 attraverso il loro perimetro per questo nuovo protocollo.
Garantire visibilità e controllo del traffico DoT
Come best practice per il controllo DoT, consigliamo quanto sopra, in base ai requisiti della tua organizzazione:
-
Configura NGFW per decrittografare tutto il traffico per la porta di destinazione 853. Decrittografando il traffico, DoT apparirà come un'applicazione DNS a cui puoi applicare qualsiasi azione, come abilitare l'abbonamento per controllare domini DGA o uno esistente e anti-spyware.
-
Un'alternativa è fare in modo che il motore App-ID blocchi completamente il traffico "dns-over-tls" sulla porta 853. Di solito è bloccato per impostazione predefinita, non è richiesta alcuna azione (a meno che non si consenta specificatamente l'applicazione "dns-over-tls" o il traffico della porta 853).
Fonte: habr.com