{"id":97349,"date":"2020-10-17T14:42:14","date_gmt":"2020-10-17T12:42:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh"},"modified":"2020-10-17T14:42:14","modified_gmt":"2020-10-17T12:42:14","slug":"minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","title":{"rendered":"Minimizzazione dei rischi nell'utilizzo di DNS-over-TLS (DoT) e DNS-over-HTTPS (DoH)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MinimizzazioneMinimizzazione dei rischi nell'uso di DoH e DoT<\/p>\n

Protezione da DoH e DoT<\/h2>\n

Controlli il traffico DNS? Le organizzazioni investono molto tempo, denaro e risorse per garantire la sicurezza delle proprie reti. Tuttavia, una delle aree che spesso riceve poca attenzione \u00e8 il DNS. <\/p>\n

Una buona panoramica dei rischi associati al DNS \u00e8 la presentazione di Verisign<\/a><\/noindex> alla conferenza Infosecurity. <\/p>\n

\"MinimizzazioneIl 31% delle famiglie di ransomware esaminate ha utilizzato il DNS per lo scambio di chiavi. Le conclusioni della ricerca<\/p>\n

Il 31% delle famiglie di ransomware esaminate ha utilizzato il DNS per lo scambio di chiavi.<\/p>\n

Il problema \u00e8 serio. Secondo il laboratorio di ricerca Palo Alto Networks Unit 42, circa l'85% dei malware utilizza il DNS per stabilire canali di comando e controllo, consentendo agli attaccanti di infiltrare facilmente il malware nella tua rete e rubare dati. Sin dalla sua creazione, il traffico DNS \u00e8 stato principalmente non crittografato e facilmente analizzabile dai meccanismi di sicurezza NGFW. <\/p>\n

Sono emersi nuovi protocolli per il DNS volti a migliorare la riservatezza delle connessioni DNS. Sono attivamente supportati dai principali fornitori di browser e da altri fornitori di software. Presto si assister\u00e0 a una crescita del traffico DNS crittografato nelle reti aziendali. Il traffico DNS crittografato, che non viene adeguatamente analizzato e consentito, rappresenta una minaccia per la sicurezza dell'azienda. Un esempio di tale minaccia sono i cryptolocker, che usano il DNS per scambiare chiavi di crittografia. Gli attaccanti ora richiedono riscatto di milioni di dollari per ripristinare l'accesso ai tuoi dati. In un caso, l'azienda Garmin ha pagato 10 milioni di dollari.<\/p>\n

Se configurato correttamente, gli NGFW possono vietare o proteggere l'uso di DNS-over-TLS (DoT) e possono essere utilizzati per vietare l'uso di DNS-over-HTTPS (DoH), consentendo di analizzare l'intero traffico DNS nella tua rete.<\/p>\n

Che cos'\u00e8 il DNS crittografato?<\/h2>\n

Che cos'\u00e8 il DNS<\/p>\n

Il sistema dei nomi a dominio (DNS) traduce i nomi a dominio leggibili per l'uomo (ad esempio, l'indirizzo www.paloaltonetworks.com<\/a><\/noindex> ) all'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, richiedendo l'indirizzo IP associato a quel nome di dominio. In risposta, il server DNS restituisce l'indirizzo IP che il browser utilizzer\u00e0.<\/p>\n

Le richieste e le risposte DNS vengono trasmesse attraverso la rete come testo semplice in chiaro, il che le rende vulnerabili a spionaggio, alterazione delle risposte e a reindirizzamenti del browser verso server dannosi. La crittografia DNS rende pi\u00f9 difficile tracciare o modificare le richieste DNS durante il trasporto. La crittografia delle richieste e risposte DNS ti protegge dagli attacchi Man-in-the-Middle, mantenendo comunque le stesse funzionalit\u00e0 del tradizionale protocollo DNS in chiaro. <\/p>\n

Negli ultimi anni sono stati introdotti due protocolli di crittografia DNS:<\/p>\n

    \n
  1. \n

    DNS-over-HTTPS (DoH)<\/p>\n<\/li>\n

  2. \n

    DNS-over-TLS (DoT) <\/p>\n<\/li>\n<\/ol>\n

    Questi protocolli hanno un comune denominatore: nascondere intenzionalmente le richieste DNS da qualsiasi intercettazione... incluso quelle degli addetti alla sicurezza delle organizzazioni. I protocolli utilizzano principalmente il protocollo TLS (Transport Layer Security) per stabilire una connessione crittografata tra il client che effettua le richieste e il server che risolve le richieste DNS, attraverso una porta normalmente non utilizzata per il traffico DNS.<\/p>\n

    La privacy delle richieste DNS \u00e8 un grande vantaggio di questi protocolli. Tuttavia, creano problemi per i responsabili della sicurezza che devono monitorare il traffico di rete e rilevare e bloccare le connessioni dannose. Poich\u00e9 i protocolli si differenziano per la loro implementazione, anche i metodi di analisi varieranno tra DoH e DoT.<\/p>\n

    DNS over HTTPS (DoH)<\/h2>\n

    \"MinimizzazioneDNS all'interno di HTTPS<\/p>\n

    DoH utilizza la nota porta 443 per HTTPS, per la quale \u00e8 specificamente indicato nel RFC che l'obiettivo \u00e8 \"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 ( RFC 8484 DoH, Sezione 8.1<\/a><\/noindex> ). Il protocollo DoH utilizza la crittografia TLS e la sintassi delle richieste fornita dagli standard comuni di HTTPS e HTTP\/2, aggiungendo le richieste e le risposte DNS sopra le normali richieste HTTP.<\/p>\n

    I rischi associati a DoH<\/h2>\n

    Se non riesci a distinguere il traffico HTTPS normale dalle richieste DoH, le applicazioni all'interno della tua organizzazione possono (e lo faranno) aggirare le impostazioni DNS locali, reindirizzando le richieste a server esterni che rispondono alle richieste DoH, eludendo cos\u00ec qualsiasi monitoraggio, ovvero annullando la possibilit\u00e0 di controllare il traffico DNS. In un mondo ideale, dovresti controllare DoH utilizzando le funzionalit\u00e0 di decrittazione di HTTPS. <\/p>\n

    E Google e Mozilla hanno implementato funzionalit\u00e0 DoH<\/a><\/noindex> nell'ultima versione dei loro browser, e entrambe le aziende stanno lavorando per utilizzare DoH come impostazione predefinita per tutte le richieste DNS. Microsoft sta anche sviluppando piani<\/a><\/noindex> per integrare DoH nei suoi sistemi operativi. Una delle problematiche \u00e8 che non solo aziende di software rispettabili, ma anche attaccanti hanno iniziato ad utilizzare DoH come mezzo per aggirare le misure tradizionali del firewall aziendale. ( Ad esempio, consulta i seguenti articoli: PsiXBot ora utilizza Google DoH<\/a><\/noindex> , PsiXBot continua a evolversi con un'infrastruttura DNS aggiornata<\/a><\/noindex> e analisi del backdoor Godlua<\/a><\/noindex> .) In ogni caso, sia il traffico buono che quello malevolo di DoH rimarranno inosservati, lasciando l'organizzazione cieca all'uso malevolo di DoH come canale per il controllo del malware (C2) e il furto di dati sensibili.<\/p>\n

    Assicurare visibilit\u00e0 e controllo sul traffico DoH<\/h2>\n

    Come migliore soluzione per controllare DoH, ti consigliamo di configurare nel NGFW la decrittazione del traffico HTTPS e il blocco del traffico DoH (nome dell'applicazione: dns-over-https). <\/p>\n

    In primo luogo, assicurati che il NGFW sia configurato per decrittare l'HTTPS, secondo le linee guida delle migliori pratiche di decrittazione<\/a><\/noindex>.<\/p>\n

    In secondo luogo, crea una regola per il traffico dell'applicazione \"dns-over-https\", come mostrato di seguito:<\/p>\n

    \"MinimizzazioneRegola Palo Alto Networks NGFW per bloccare DNS-over-HTTPS<\/p>\n

    Come alternativa intermedia (se la tua organizzazione non ha implementato completamente la decrittazione HTTPS), il NGFW pu\u00f2 essere configurato per applicare l'azione \"nega\" all'ID dell'applicazione \"dns-over-https\", ma l'effetto sar\u00e0 limitato al blocco di alcuni ben noti server DoH per il loro nome di dominio, poich\u00e9 senza la decrittazione dell'HTTPS il traffico DoH non pu\u00f2 essere verificato completamente (vedi.  Applipedia di Palo Alto Networks<\/a><\/noindex>   ed esegui una ricerca per la frase \"dns-over-https\").<\/p>\n

    DNS over TLS (DoT)<\/h2>\n

    \"MinimizzazioneDNS all'interno di TLS<\/p>\n

    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 unico scopo, vietando esplicitamente l'uso della stessa porta per il tradizionale traffico DNS non crittografato ( RFC 7858, Sezione 3.1<\/a><\/noindex> ).<\/p>\n

    Il protocollo DoT utilizza il protocollo TLS per garantire la crittografia, incapsulando le richieste standard del protocollo DNS, con traffico che utilizza la ben nota porta 853 ( RFC 7858, sezione 6<\/a><\/noindex> ).  Il protocollo DoT \u00e8 stato sviluppato per semplificare alle organizzazioni il blocco del traffico sulla porta, oppure accettarne l'uso, ma includendo la decrittazione su questa porta.<\/p>\n

    I rischi associati a DoT<\/h2>\n

    Google ha implementato DoT nel suo client Android 9 Pie e versioni successive<\/a><\/noindex> , con l'impostazione per l'uso automatico di DoT attivata per default, se disponibile. Se hai valutato i rischi ed sei pronto a utilizzare DoT a livello organizzativo, \u00e8 necessario che gli amministratori di rete autorizzino esplicitamente il traffico in uscita sulla porta 853 attraverso il loro perimetro per questo nuovo protocollo.<\/p>\n

    Garantire visibilit\u00e0 e controllo del traffico DoT<\/h2>\n

    Come miglior prassi per il controllo di DoT, ti consigliamo di adottare una delle seguenti opzioni, in base ai requisiti della tua organizzazione:<\/p>\n