Minimizzazione dei rischi nell'utilizzo di DoH e DoT
Protezione da DoH e DoT
Controlli il tuo traffico DNS? Le organizzazioni investono molto tempo, denaro e sforzi nella sicurezza delle proprie reti. Tuttavia, una delle aree che spesso non riceve l'adeguata attenzione è il DNS.
Una buona panoramica dei rischi legati al DNS è alla conferenza Infosecurity.
Il 31% delle famiglie di ransomware esaminate ha utilizzato il DNS per lo scambio di chiavi. I risultati della ricerca
Il 31% delle famiglie di ransomware esaminate ha utilizzato il DNS per lo scambio di chiavi.
Il problema è serio. Secondo il laboratorio di ricerca Palo Alto Networks Unit 42, circa l'85% del malware utilizza il DNS per stabilire canali di comando e controllo, consentendo agli attaccanti di inserire facilmente malware nella tua rete e rubare dati. Fin dalla sua creazione, il traffico DNS è stato principalmente non crittografato ed è stato facile da analizzare da parte dei meccanismi di sicurezza NGFW.
Sono stati introdotti nuovi protocolli per il DNS, progettati per aumentare la privacy delle connessioni DNS. Sono attivamente supportati dai principali fornitori di browser e da altri fornitori di software. Presto, nelle reti aziendali, ci sarà un aumento del traffico DNS crittografato. Il traffico DNS crittografato, che non viene analizzato correttamente dai sistemi e autorizzato, rappresenta una minaccia per la sicurezza dell'azienda. Ad esempio, una di queste minacce sono i ransomware, che usano il DNS per lo scambio delle chiavi di crittografia. Gli attaccanti ora richiedono riscatti di diversi milioni di dollari per ripristinare l'accesso ai tuoi dati. Ad esempio, l'azienda Garmin ha pagato 10 milioni di dollari.
Con la corretta configurazione, i NGFW possono vietare o proteggere l'uso del DNS-over-TLS (DoT) e possono essere utilizzati per vietare l'uso del DNS-over-HTTPS (DoH), consentendo di analizzare tutto il traffico DNS nella tua rete.
Che cos'è il DNS crittografato?
Che cos'è il DNS
Il sistema dei nomi di dominio (DNS) traduce i nomi di dominio in formato leggibile per le persone (ad esempio, l'indirizzo ) in indirizzi IP (ad esempio, 34.107.151.202). Quando un utente inserisce un nome di dominio nel browser web, il browser invia una richiesta DNS a un server DNS chiedendo l'indirizzo IP associato a quel nome di dominio. In risposta, il server DNS restituisce l'indirizzo IP che sarà utilizzato da questo browser.
Le richieste e le risposte DNS vengono trasmesse in rete come testo in chiaro e non crittografato, il che le rende vulnerabili a spionaggi o modifiche della risposta, reindirizzando il browser a server dannosi. La crittografia DNS complica il tracciamento delle richieste DNS o le modifiche durante la trasmissione. La crittografia delle richieste e risposta DNS ti protegge da attacchi Man-in-the-Middle, eseguendo comunque le stesse funzioni del tradizionale protocollo DNS (sistema dei nomi di dominio) in chiaro.
Negli ultimi anni sono stati implementati due protocolli di crittografia DNS:
DNS-over-HTTPS (DoH)
DNS-over-TLS (DoT)
Questi protocolli hanno un aspetto in comune: nascondono intenzionalmente le richieste DNS da qualsiasi intercettazione… incluso dai responsabili della sicurezza dell'organizzazione. I protocolli utilizzano principalmente il TLS (Transport Layer Security) per stabilire una connessione criptata tra il client che effettua le richieste e il server che risolve le richieste DNS, attraverso una porta che di solito non è utilizzata per il traffico DNS.
La riservatezza delle richieste DNS è un grande vantaggio di questi protocolli. Tuttavia, creano problemi ai responsabili della sicurezza che devono monitorare il traffico di rete e individuare e bloccare connessioni dannose. Poiché i protocolli variano nella loro implementazione, anche i metodi di analisi differiscono tra DoH e DoT.
DNS over HTTPS (DoH)
DNS all'interno di HTTPS
DoH utilizza la porta 443, ben nota, per l'HTTPS, per la quale l'RFC specifica chiaramente che l'obiettivo è "mescolare il traffico DoH con altro traffico HTTPS nella stessa connessione", "rendere difficile l'analisi del traffico DNS" e, in questo modo, eludere le misure di controllo aziendale ( ). Il protocollo DoH utilizza la crittografia TLS e la sintassi delle richieste fornita dai normali standard HTTPS e HTTP/2, aggiungendo richieste e risposte DNS sopra le normali richieste HTTP.
Rischi associati a DoH
Se non riesci a distinguere il traffico HTTPS normale dalle richieste DoH, le applicazioni all'interno della tua organizzazione potrebbero (e lo faranno) bypassare le impostazioni DNS locali, reindirizzando le richieste a server esterni che rispondono alle richieste DoH, il che elude qualsiasi monitoraggio, distruggendo la possibilità di controllare il traffico DNS. Idealmente, dovresti controllare DoH utilizzando le funzionalità di decrittazione HTTPS.
E nell'ultima versione dei loro browser, e entrambe le aziende stanno lavorando per utilizzare DoH come impostazione predefinita per tutte le richieste DNS. per integrare DoH nei propri sistemi operativi. Uno svantaggio è che non solo le rispettabili aziende di software, ma anche i malintenzionati hanno iniziato a utilizzare DoH come mezzo per eludere le tradizionali misure di firewall aziendale. ( Ad esempio, consulta i seguenti articoli: , e .) In ogni caso, sia il traffico buono che quello malevolo DoH rimarrà inosservato, lasciando l'organizzazione cieca all'uso malevolo di DoH come canale per la gestione del malware (C2) e il furto di dati riservati.
Garantire visibilità e controllo sul traffico DoH
Come miglior soluzione per il controllo di DoH, consigliamo di configurare nel NGFW la decrittazione del traffico HTTPS e il blocco del traffico DoH (nome dell'applicazione: dns-over-https).
Innanzitutto, assicurati che il NGFW sia configurato per la decrittazione di HTTPS, secondo .
In secondo luogo, crea una regola per il traffico dell'applicazione 'dns-over-https', come indicato di seguito:
Regola Palo Alto Networks NGFW per bloccare DNS-over-HTTPS
Come alternativa intermedia (se la tua organizzazione non ha completamente implementato la decrittazione dell'HTTPS), il NGFW può essere configurato per applicare l'azione 'vietare' all'identificatore dell'applicazione 'dns-over-https', ma l'effetto sarà limitato al blocco di alcuni noti server DoH per nome di dominio, poiché senza la decrittazione dell'HTTPS, il traffico DoH non può essere completamente verificato (vedi e cerca la frase 'dns-over-https').
DNS over TLS (DoT)
DNS all'interno di TLS
Mentre il protocollo DoH cerca di confondersi con altro traffico sulla stessa porta, il DoT utilizza invece di default una porta speciale riservata a questo scopo, vietando anche specificamente l'uso della stessa porta per il traffico DNS tradizionale non crittografato ( ).
Il protocollo DoT utilizza il protocollo TLS per garantire la crittografia, incapsulando le richieste standard del protocollo DNS, con il traffico che utilizza la ben nota porta 853 ( ). Il protocollo DoT è stato sviluppato per semplificare alle organizzazioni il blocco del traffico sulla porta o per consentirne l'uso, ma includendo la decodifica su tale porta.
Rischi associati al DoT
Google ha implementato il DoT nel proprio client , con l'impostazione per l'uso automatico del DoT attivata di default, se disponibile. Se hai valutato i rischi e sei pronto a utilizzare il DoT a livello organizzativo, è necessario che gli amministratori di rete consentano esplicitamente il traffico in uscita sulla porta 853 attraverso il proprio perimetro per questo nuovo protocollo.
Garantire visibilità e controllo sul traffico DoT
Come migliore pratica per il controllo del DoT, raccomandiamo una delle seguenti procedure, in base ai requisiti della tua organizzazione:
Configura il NGFW per la decodifica di tutto il traffico sulla porta di destinazione 853. Con la decodifica del traffico, il DoT apparirà come un'applicazione DNS, alla quale puoi applicare qualsiasi azione, come abilitare la sottoscrizione per il controllo dei domini DGA o esistente e anti-spyware.
In alternativa, è possibile bloccare completamente il traffico 'dns-over-tls' tramite il motore App-ID sulla porta 853. Di solito è bloccato per impostazione predefinita e non sono necessari ulteriori interventi (a meno che non abbiate specificamente consentito l'applicazione 'dns-over-tls' o il traffico sulla porta 853).
Fonte: habr.com
