DNSSEC e sicurezza DNS sulla rete locale

Informatec Digital » Risorse » DNSSEC e sicurezza DNS sulla rete locale

Internet si basa su una serie di componenti chiave che quasi mai vediamo, ma che sono presenti ogni volta che apriamo un browser. Uno dei più importanti è il Domain Name System (DNS) e, quando parliamo di DNSSEC e sicurezza su una rete locale , ci riferiamo in realtà al rafforzamento di queste fondamenta per prevenire reindirizzamenti fraudolenti, spoofing e altri attacchi gravi.

In passato, la priorità era semplicemente garantire il corretto funzionamento di tutto; oggi sappiamo che non è sufficiente. Il DNS è nato negli anni '80 senza considerare i massicci attacchi informatici, ma ora è necessario che non solo risolva i nomi, ma che convalidi anche l'autenticità e l'integrità di ogni risposta . È qui che entra in gioco DNSSEC e, più recentemente, proposte come E-DNSSEC, che mirano ad aggiungere anche la riservatezza, un fattore chiave se si ha a cuore la sicurezza della propria rete locale o aziendale.

Cos'è il DNS e perché è così fondamentale per la sicurezza?

Il Domain Name System (DNS ) è l'elenco telefonico di Internet: traduce nomi facili da ricordare (come www.example.com) in indirizzi IP numerici comprensibili ai computer (ad esempio, 192.168.2.15 o un indirizzo IPv6). Senza questo meccanismo, dovremmo memorizzare numeri anziché nomi, il che è del tutto impraticabile.

Questa infrastruttura è organizzata come un database distribuito con una struttura ad albero , con una zona radice in cima, seguita dai domini di primo livello (TLD come .es, .com, .org) e, al di sotto di questi, dai domini e sottodomini. Ciascuna parte di questo database è chiamata " zona " ed è ospitata su uno o più server dei nomi autorevoli, che pubblicano le informazioni "ufficiali" per ciascun dominio.

Quando il tuo computer, telefono cellulare o qualsiasi altro dispositivo desidera accedere a un sito web, inizia interrogando un resolver stub , che fa parte del sistema operativo. Questo resolver invia la query a un server DNS ricorsivo (di solito quello del tuo provider di servizi Internet, della tua azienda o un server pubblico come Google Public DNS , OpenDNS o Quad9). Questo server ricorsivo cerca quindi la risposta interrogando diversi server autorevoli fino a trovare l'indirizzo IP corretto.

I resolver ricorsivi memorizzano nella cache le risposte ricevute per velocizzare le query successive. Questo è molto efficiente, ma apre anche la porta a un malintenzionato che può "avvelenare la cache DNS" e inserire dati falsi , in modo che molte richieste successive vengano risolte con queste informazioni manipolate senza che l'utente se ne accorga.

Il problema principale è che, nella sua concezione originale, il DNS non dispone di un metodo affidabile per verificare l'autenticità delle risposte . Il resolver si limita a controllare che la risposta sembri provenire dallo stesso indirizzo IP interrogato, ma tale indirizzo IP di origine può essere falsificato con relativa facilità. Questo permette attacchi di reindirizzamento silenzioso verso siti fraudolenti che imitano, ad esempio, il sito web della vostra banca.

Limitazioni di sicurezza del DNS tradizionale

Il protocollo DNS è stato creato in un'epoca in cui la sicurezza non era una priorità. Per questo motivo, oggi sappiamo che le query e le risposte DNS viaggiano in chiaro , senza crittografia, e che i dati dei record possono essere falsificati senza ulteriori protezioni.

Questo apre la porta a diverse tipologie di attacchi, in particolare all'avvelenamento della cache DNS e agli attacchi man-in-the-middle. In entrambi i casi, l'attaccante inietta risposte falsificate lungo il percorso, facendo sì che gli utenti finiscano su siti web sotto il suo controllo senza accorgersi di nulla di insolito, poiché il nome di dominio visualizzato nel browser rimane legittimo.

Immaginate di accedere al sito web della vostra banca: il vostro computer richiede l'indirizzo IP del dominio della banca al server ricorsivo, ma un hacker ha ingannato il server inducendolo ad accettare una falsa risposta con l'indirizzo IP di un sito web identico controllato da lui . L'utente inserisce le proprie credenziali, pensando che tutto sia normale, e il cybercriminale le riceve in chiaro per utilizzarle in seguito sul sito reale.

Meccanismi come le firme di transazione (TSIG) , definite nella RFC 2845, servono a proteggere determinate operazioni tra server DNS (ad esempio, trasferimenti di zona tra server master e slave e aggiornamenti dinamici). Le TSIG consentono a due macchine che condividono una chiave segreta di verificare l'identità dell'altra estremità e l'integrità dei messaggi in transito.

Tuttavia, TSIG ha un ambito di applicazione molto limitato: non autentica l'origine "reale" dei dati DNS ; garantisce solo che lo scambio tra due server specifici non sia stato manomesso. Se le informazioni originali in una zona sono state compromesse o manipolate prima di raggiungere quei server, TSIG non lo rileverà. Pertanto, sebbene sia comunemente utilizzato per i trasferimenti di zona, non risolve il problema di fondo dell'autenticità dei dati DNS pubblicati.

Cos'è DNSSEC e qual è il suo contributo alla sicurezza?

In risposta a tutte queste debolezze, sono state sviluppate le estensioni di sicurezza del sistema dei nomi di dominio (DNSSEC) . Il DNSSEC non sostituisce il DNS classico, ma lo estende con un livello di sicurezza che consente di verificare che i dati ricevuti siano legittimi e non siano stati alterati.

DNSSEC si basa sulla crittografia a chiave pubblica (crittografia asimmetrica) . Ogni zona DNS ha una coppia di chiavi: una chiave privata, che viene mantenuta segreta, e una chiave pubblica, che viene pubblicata sul server DNS stesso. Il proprietario della zona utilizza la chiave privata per firmare digitalmente i record in quella zona; la chiave pubblica viene utilizzata per verificare tali firme.

Quando un server ricorsivo interroga un dominio utilizzando DNSSEC, oltre alle informazioni usuali (ad esempio, l'indirizzo IP associato a un nome), riceve anche le firme digitali e le chiavi pubbliche necessarie per la convalida . Il server ricorsivo convalida le firme confrontandole con le chiavi pubbliche pubblicate; se la verifica ha esito positivo, i dati vengono considerati autentici e invariati rispetto al momento della firma.

Se la convalida fallisce, il resolver capisce che qualcosa non va (ad esempio, un tentativo di spoofing o di manomissione durante la trasmissione) e risponde al client con un codice di errore, in genere SERVFAIL . In questo modo, l'utente non riceve dati potenzialmente dannosi, anche se dal suo punto di vista tutto ciò che vedrà è che la pagina "non si carica" ​​o visualizza un errore.

DNSSEC introduce anche il concetto di catena di fiducia , che sfrutta la gerarchia DNS esistente. La zona radice firma le chiavi dei domini di primo livello (come .es, .com), questi a loro volta firmano le chiavi dei loro domini figli e così via, in modo che qualsiasi dominio possa essere convalidato utilizzando un unico punto di fiducia: la chiave pubblica della zona radice.

Chiavi KSK e ZSK, registri e catena di fiducia

Per una migliore organizzazione della sicurezza, DNSSEC utilizza due diversi tipi di chiavi: la Chiave di Firma della Chiave (KSK) e la Chiave di Firma della Zona (ZSK) . Sebbene tecnicamente siano identiche (dal punto di vista crittografico), la loro funzione all'interno del sistema è diversa.

La chiave ZSK viene utilizzata per firmare tutti i record delle risorse nella zona (A, AAAA, MX, ecc.). In genere viene ruotata frequentemente per minimizzare il rischio, poiché qualsiasi compromissione di questa chiave avrebbe ripercussioni su tutti i record della zona. La chiave KSK, invece, viene utilizzata principalmente per firmare la chiave di zona (ZSK) stessa, e il suo hash viene pubblicato come record DS (Delegation Signer) nella zona padre.

Grazie a questa separazione dei ruoli, la modifica della ZSK è più semplice: basta generare una nuova ZSK, firmarla con la KSK, pubblicarla nei record DNSKEY della zona e lasciare che i resolver aggiornino le proprie informazioni. Non è necessario intervenire sulla zona padre, poiché il DS continua a puntare alla stessa KSK, che rimane stabile più a lungo.

DNSSEC aggiunge al protocollo DNS diversi tipi di record specifici, progettati per supportare la firma e la convalida dei dati. Tra i più importanti figurano DNSKEY, RRSIG, DS, NSEC/NSEC3 e NSEC3PARAM . Tutti questi record consentono di implementare una logica di autenticazione senza modificare il funzionamento di base delle query.

Il record DNSKEY memorizza la chiave pubblica della zona , necessaria per verificare le firme. Il record RRSIG contiene la firma digitale associata a uno specifico insieme di record (un "Resource Record Set"). Il record DS è un hash del DNSKEY della zona figlia, che viene pubblicato nella zona padre e funge da anello nella catena di fiducia.

I record NSEC e NSEC3 vengono utilizzati per fornire una negazione autenticata dell'esistenza ; ovvero, per dimostrare crittograficamente che un nome di dominio o un record non esiste, prevenendo attacchi che tentano di inserire risposte false indicando che qualcosa non esiste quando in realtà esiste (o viceversa).

Catena di fiducia e convalida della risposta DNSSEC

La cosiddetta catena di fiducia in DNSSEC si costruisce collegando i record DNSKEY e DS dalla radice al dominio che si desidera validare . Il punto di partenza è la chiave pubblica della zona radice, che funge da ancora di fiducia e viene solitamente configurata direttamente nei resolver ricorsivi.

Ad esempio, se si desidera convalidare un dominio come mywebsite.es, il processo logico sarebbe il seguente: il resolver si fida della chiave pubblica della radice, che firma la chiave .es; la zona .es pubblica un record DS corrispondente alla chiave KSK di mywebsite.es; convalidando tale record DS con la chiave .es, il resolver si fida della DNSKEY di mywebsite.es e, da lì, può verificare i record RRSIG su tutti i suoi record.

Se in qualsiasi punto della catena manca una firma valida, o se la DS (Data Signature) non è presente dove dovrebbe, la catena di fiducia si interrompe. In tal caso, il server ricorsivo che esegue la convalida non considera i dati sicuri e, a seconda della sua configurazione, non risponde con i record richiesti oppure contrassegna la risposta come non valida.

Questa relazione gerarchica implica anche che, affinché DNSSEC sia veramente efficace, non è sufficiente firmare solo la propria zona : anche la zona padre (ad esempio, .es) e la zona radice devono essere firmate e avere i relativi record DNS correttamente pubblicati. Attualmente, la zona radice DNS e praticamente tutti i domini di primo livello generici (gTLD) e molti domini di primo livello nazionali (ccTLD) sono già firmati.

Quando un server ricorsivo con la convalida DNSSEC abilitata rileva che la firma non corrisponde o che manca un link, la risposta che restituisce al client è solitamente accompagnata da un codice di errore RCODE SERVFAIL. Questo può essere fonte di confusione per l'utente finale ("il sito web non funziona"), ma dal punto di vista della sicurezza, rappresenta una misura di protezione contro dati potenzialmente manipolati.

DNSSEC introduce inoltre due funzionalità chiave: l'autenticazione dell'origine dei dati , che consente di verificare che i record provengano effettivamente dalla zona prevista, e la protezione dell'integrità , che garantisce che le informazioni non siano state modificate da quando sono state firmate dal proprietario della zona con la sua chiave privata.

Attacchi mitigati da DNSSEC e la loro relazione con TLS/HTTPS

L'implementazione di DNSSEC contribuisce a proteggere da diverse minacce comuni. In primo luogo, rende estremamente difficile lo spoofing delle risposte DNS , poiché l'attaccante dovrebbe generare firme valide senza conoscere la chiave privata della zona, il che è crittograficamente impossibile se le chiavi sono gestite correttamente.

Inoltre, DNSSEC riduce il rischio di avvelenamento della cache sui server ricorsivi impedendo l'accettazione di risposte manipolate che non superano la convalida della firma. Complica anche gli attacchi man-in-the-middle (MITM) sul traffico DNS, in cui un aggressore modifica le risposte in transito: se la risposta non supera la convalida, il resolver la scarta.

È importante però capire cosa non fa DNSSEC. Queste estensioni non sono progettate per crittografare il contenuto delle query o delle risposte . Tutto il traffico DNS, anche con DNSSEC, viaggia comunque in chiaro a meno che non si utilizzino altre tecnologie complementari (come DoT, DoH o soluzioni di tipo E-DNSSEC). DNSSEC si concentra sul garantire che ciò che si riceve sia autentico e non sia stato alterato, non sul nascondere ciò che si sta chiedendo.

Questo lo differenzia nettamente da protocolli come TLS e HTTPS . Mentre HTTPS crittografa il traffico tra il browser e il server web per impedire a terzi di spiare o modificare la comunicazione, DNSSEC si limita a firmare i dati DNS per rilevare lo spoofing. Un sito può utilizzare HTTPS senza DNSSEC o DNSSEC senza HTTPS, ma la combinazione di entrambi offre una protezione molto più completa contro lo spoofing e lo spionaggio.

Organizzazioni come ICANN e IETF promuovono da anni l'adozione diffusa di DNSSEC da parte di registri, registrar, ISP e operatori di rete. L'obiettivo è che sempre più zone DNSSEC vengano firmate e che un numero crescente di resolver le convalidi attivamente, in modo che l'utente medio possa beneficiare di queste garanzie crittografiche senza dover intraprendere alcuna azione particolare.

DNSSEC nei domini .es e obblighi del proprietario

Nel caso specifico della Spagna, l'unità ".es" gestita da Red.es ha da tempo integrato tecnologie e procedure aggiuntive per migliorare la qualità e la sicurezza del servizio DNS con il codice paese .es. Tra queste misure rientra l'implementazione del protocollo di sicurezza DNSSEC in conformità con le specifiche IETF.

I domini .es sono responsabili della firma della zona di primo livello .ES e dell'ottenimento dell'autorizzazione dalla radice DNS, integrandosi così nella catena di fiducia globale. Ciò significa che, se possiedi un dominio .es, puoi sfruttare questa infrastruttura per proteggere il tuo dominio con DNSSEC.

In qualità di proprietario di un dominio, la procedura generale per abilitare DNSSEC prevede di assicurarsi che i server DNS autorevoli pubblichino la zona firmata. In genere, ciò comporta la generazione di una chiave pubblica per la propria zona, la firma dei record, la pubblicazione della chiave DNS e l'invio del materiale della chiave (o del record DS stesso) al registro o al registrar affinché possano creare il record DS corrispondente nella zona padre.

In pratica, molti provider di hosting DNS e registrar offrono già un'opzione piuttosto semplice per abilitare DNSSEC, a volte basta spuntare una casella nel pannello di controllo. Tuttavia, a seconda del provider e del livello di servizio, potrebbe essere previsto un piccolo costo annuale per questa funzionalità.

Una volta firmata la zona e pubblicato correttamente il Domain Name System (DNS), il tuo dominio entra a far parte della catena di fiducia DNSSEC. Da quel momento in poi, le risoluzioni DNS per il tuo dominio possono essere validate crittograficamente dai resolver che hanno la validazione DNSSEC abilitata, aumentando la fiducia degli utenti e riducendo il rischio di attacchi di spoofing.

DNSSEC sulla rete locale: convalida lato utente

Dal punto di vista di un utente finale o di un'azienda preoccupata per la sicurezza della propria rete locale, la domanda chiave è: cosa serve per trarre vantaggio da DNSSEC? La buona notizia è che non è necessario configurare nulla su ogni singolo computer , a condizione che il server DNS ricorsivo (quello utilizzato dai computer) convalidi DNSSEC.

Per fare ciò, è sufficiente che il tuo provider DNS (il tuo ISP, un resolver pubblico o il DNS interno della tua organizzazione) disponga di un server ricorsivo con la convalida DNSSEC abilitata e configurata correttamente . Praticamente tutti i resolver moderni supportano DNSSEC da anni; l'abilitazione di solito richiede solo poche modifiche al loro file di configurazione e l'aggiunta dell'ancora di fiducia radice.

Una volta abilitata la convalida, quando uno dei computer della rete locale interroga un dominio firmato, il resolver ricorsivo verifica tutte le firme e la catena di fiducia prima di restituire la risposta. Se qualcosa non corrisponde, non restituisce alcun risultato e l'utente visualizza un messaggio di errore, impedendogli di fatto di connettersi a un sito potenzialmente fraudolento.

Per verificare se il tuo dominio è protetto da DNSSEC, sono disponibili diversi strumenti online, come DNSSEC Analyzer e altre utility di validazione . Inserendo il tuo dominio, dovresti visualizzare record come RRSIG (firme crittografiche), DNSKEY (chiavi pubbliche) e DS (hash della DNSKEY nella zona padre). Se lo strumento indica che non è presente alcuna firma digitale associata ai record, il tuo dominio verrà considerato "non firmato" o "non sicuro".

Se, dopo questa verifica, scoprite che il vostro dominio o i server DNS che utilizzate sulla vostra rete locale non sfruttano DNSSEC, è consigliabile contattare il vostro provider di servizi Internet (ISP) per richiederne l'attivazione. Se non offrono questa opzione, potrebbe essere opportuno valutare il passaggio a un provider che supporti la convalida DNSSEC, aumentando così il livello di sicurezza sia per la vostra azienda che per i vostri clienti.

Limitazioni di DNSSEC: privacy e altri aspetti

Nonostante tutti i suoi vantaggi, DNSSEC non è la soluzione a tutti i problemi di sicurezza DNS. Un problema fondamentale è che non garantisce la riservatezza delle query . I pacchetti DNS, anche con DNSSEC, viaggiano comunque in chiaro, quindi chiunque abbia accesso al traffico (ad esempio, su una rete Wi-Fi pubblica non protetta ) può vedere quali domini vengono interrogati.

Inoltre, non offre alcun controllo degli accessi né una difesa specifica contro gli attacchi denial-of-service (DoS o DDoS) . Anzi, aggiungendo ulteriori dati (firme, chiavi, record aggiuntivi), aumenta le dimensioni delle risposte DNS, il che può essere sfruttato in attacchi di amplificazione se l'infrastruttura non è configurata e protetta correttamente.

D'altro canto, DNSSEC introduce una certa complessità operativa: è necessario gestire le coppie di chiavi , ruotare ZSK e KSK, coordinare la pubblicazione del DS nella zona padre e assicurarsi che non vi siano discrepanze che interrompano la catena di fiducia. Un errore in queste procedure può causare l'interruzione della corretta validazione di un dominio, generando apparenti interruzioni del servizio.

All'interno del processo DNSSEC stesso, i messaggi contengono bit di controllo (come il bit CD nelle query e il bit AD nelle risposte) che influenzano le modalità di esecuzione e segnalazione della convalida. Un utente malintenzionato in grado di manipolare questi bit in un ambiente non sicuro potrebbe tentare di compromettere la protezione offerta da un resolver ricorsivo. Pertanto, si raccomanda che la comunicazione tra resolver e client che utilizzano DNSSEC avvenga tramite canali sicuri.

Nonostante questi limiti, DNSSEC rimane un componente essenziale per rafforzare l'autenticità e l'integrità del DNS. Tuttavia, per fare un ulteriore passo avanti e garantire anche la riservatezza delle query, è necessario combinarlo con altre tecnologie o evolvere verso soluzioni più avanzate.

E-DNSSEC: Verso un DNS autenticato e crittografato

Per colmare la lacuna di privacy lasciata da DNSSEC, è stato proposto il concetto di E-DNSSEC (DNSSEC crittografato) . L'idea alla base di questo approccio è quella di aggiungere la crittografia alle query DNSSEC in modo che, oltre ad essere autenticate e firmate, siano anche protette dall'ispezione di terzi durante il loro transito su Internet o attraverso la rete locale.

L'obiettivo di E-DNSSEC è combinare le proprietà di DNSSEC (autenticità e integrità) con meccanismi di crittografia che garantiscono la riservatezza delle query tra il client DNSSEC e il server DNSSEC . Ciò aumenta la sicurezza complessiva del servizio DNS, impedendo a osservatori esterni di visualizzare quali nomi di dominio vengono risolti.

Il processo concettuale prevederebbe l'analisi della query sul server ricorsivo, la sua crittografia prima dell'invio al server autorevole e la successiva decrittazione ed elaborazione standard tramite DNSSEC . La risposta, a sua volta, potrebbe essere restituita firmata e crittografata al server ricorsivo o al client, garantendo la riservatezza durante l'intero processo.

Questa combinazione garantirebbe la sicurezza del messaggio DNS dall'inizio alla fine del processo di risoluzione: autenticato e integro grazie a DNSSEC, e protetto da occhi indiscreti grazie a un'ulteriore crittografia. In un contesto di rete locale o aziendale, un approccio di questo tipo potrebbe essere integrato con altre soluzioni di sicurezza perimetrale.

Oggi, proposte come E-DNSSEC si inseriscono in un più ampio sforzo volto a rafforzare la privacy del DNS , insieme a tecnologie come DNS over TLS (DoT) e DNS over HTTPS (DoH). L'obiettivo di fondo è chiaro: il DNS del futuro deve essere autentico e riservato, e non è sufficiente risolvere i nomi rapidamente; è necessario farlo anche in modo sicuro.

In un contesto in cui attacchi informatici, furti d'identità e minacce alle infrastrutture di base diventano sempre più sofisticati, l'utilizzo di DNSSEC rappresenta già un requisito di sicurezza fondamentale per qualsiasi dominio serio, e il passaggio a soluzioni crittografate come E-DNSSEC o simili si sta configurando come un logico passo successivo per rafforzare ulteriormente la protezione delle reti, comprese quelle locali.

L'intero ecosistema, dal DNS classico al DNSSEC e alle soluzioni crittografate come E-DNSSEC, dimostra che la sicurezza DNS non è un optional, ma una componente fondamentale dell'architettura di Internet e di qualsiasi moderna rete locale. Disporre di resolver che convalidano le zone firmate, di catene di fiducia ben mantenute e, in futuro, di canali crittografati per le query, fa la differenza tra una rete esposta e un'infrastruttura preparata ad affrontare le sfide attuali e future.