In molti articoli su questo blog abbiamo visto come il protocollo DNS sia ampiamente utilizzato per pubblicare al mondo informazioni riguardo i servizi distribuiti dai nostri domini, tuttavia è importante tenere presente che i client potrebbero subire un attacco “man in the middle” in qualsiasi momento e il protocollo DNS, complice la mancanza di un metodo di autenticazione, è uno di quelli più bersagliati. Se poi consideriamo che tramite esso ormai vengono pubblicate anche informazioni che incrementano la sicurezza di molti altri protocolli (MTA-STS, DMARC, etc.), proteggere i nostri domini da questa tipologia di attacchi diventa una priorità. In questo articolo vedremo come attivare questo “scudo digitale” sulle nostre zone DNS.
Il problema: DNS MITM
Il rischio si manifesta nel fatto che, di base, i client DNS non hanno modo di verificare che la risposta ottenuta da un server sia veritiera.
Se un malintenzionato riuscisse a redirigere le richieste DNS di un computer verso un server sotto il suo controllo sarebbe in grado di manipolare le risposte, rimandando così l’utente verso un sito web di phishing; oppure, nel mondo della posta elettronica, potrebbe far credere ai mail server che i record DMARC o MTA-STS non esistano, abbattendo così due forti difese contro l’impersonificazione dei domini stessi e l’esfiltrazione dei dati (SMTP MITM).
Il rimedio: protocollo DNSSEC
Questo protocollo estende le funzionalità base del DNS, consentendo ai client di verificare che le risposte ottenute dal loro server DNS siano veritiere. Il processo di verifica si basa su una “catena di fiducia” il quale primo anello è costituito da una coppia di chiavi di cui una privata ed un pubblica, quest’ultima è conosciuta globalmente ed è utilizzata da tutti i client DNS a livello mondiale per la verifica delle risposte con DNSSEC, essa è conosciuta come “Root KSK”.
Tuttavia bisogna considerare con non esiste un rapporto diretto tra il record che otteniamo dal server DNS e la Root KSK, analizziamo quindi quali sono gli step intermedi.
Partiamo con il dire che:
- ogni zona DNS dovrà avere una coppia di chiavi “Zone Signing Key” (ZSK);
- la firma dei record non avviene individualmente ma per gruppi “Resource Record Set” (RRset), un RRset si compone di tutti i record DNS nella stessa zona che condividono sia il nome che il tipo, ad es. tutti i record “mail” di tipo MX.
Per ogni RRset deve essere generato un record RRsig, quest’ultimo dovrà contenere la firma digitale dell’RRset ottenuta con la chiave privata ZSK.
Per fare in modo che il client possa verificare che l’RRset ricevuto sia effettivamente quello firmato dal server avrà bisogno della Public ZSK. La pubblicazione di quest’ultima avviene grazie ad un record DNSKEY, che dovrà essere richiesto dal client per effettuare la verifica.
Grazie a questo controllo siamo in grado di verificare che la risposta ottenuta non sia stata manipolata nel percorso tra il server ed il client, tuttavia non possiamo ancora essere sicuri che il server mittente sia effettivamente quello legittimo.
Per avere anche questa garanzia è necessario introdurre un’altra coppia di chiavi detta “Key Signing Key” (KSK), la quale verrà usata per validare la ZSK e per stabilire un rapporto di fiducia (che può essere visto come anello della catena) con la zona DNS di livello superiore.
L’RRset DNSKEY potrà così essere verificato con il relativo RRsig, con la particolarità che esso non è stato firmato dalla Private ZSK, contrariamente agli altri RRsig.
A questo punto il client può essere sicuro che anche RRset ed RRsig DNSKEY non siano stati manipolati sul tragitto.
L’ultimo record DNS che ci permetterà di raggiungere il nostro obiettivo è di tipo Delegation Signer e dovrà essere creato nella zona DNS di livello superiore al nostro dominio; ad esempio se stiamo implementando DNSSEC per il dominio “esempio.net”, dovremo comunicare (tramite il nostro registrar) alla zona TLD i dettagli per la creazione del record DS. Quest’ultimo conterrà, assieme ad altri dettagli, l’hash della public KSK.
Il processo di verifica è analogo per le certificazioni delle risposte tra la zona DNS Root e la zona del TLD, arrivando ad effettuare una verifica con la Root KSK citata prima, completando così la “catena di fiducia”.
Attivare DNSSEC su Azure DNS
Come prima cosa bisogna considerare che al momento l’estensione DNSSEC su Azure DNS è in preview, pertanto non è consigliabile affidarci zone DNS di produzione.
Da poco è disponibile, nelle risorse DNS Zone di Azure un nuovo blade “DNSSEC”, se aprendo la pagina non viene visualizzato, sarà necessario pulire la cache del browser.
Una volta aperto tale blade con un semplice flag potremo attivare il DNSSEC nella nostra zona:
Fatto ciò ci saranno presentati i vari dettagli da comunicare al nostro registrar per fargli creare il record DS:
Inserendo tutti questi dettagli nella relativa form fornita dal nostro registrar sarà creato il record DS per la nostra zona all’interno del TLD.
Ogni registrar ha propria interfaccia ed ogni TLD potrebbe avere delle nomenclauture diverse che contraddistingono i vari campi pertanto bisognerà consultare le loro guide per completare l’implementazione, di seguito un immagine a titolo esemplificativo:
Una volta completata l’operazione ed aver atteso un po’ di tempo (minimo 15 minuti, ma che potrebbe protrarsi in base al registrar ed al TLD) potremo verificare con DNS Debugger che non ci siano errori:
La gestione del DNSSEC su Azure DNS può essere fatta anche tramite gli appositi comandi PowerShell dei quali trovate la documentazione ufficiale nei riferimenti esterni.
N.B.: una volta completata la configurazione del DNSSEC sul nostro dominio di secondo livello sarà necessario completare i passaggi analoghi per le varie sotto-zone che potremmo aver creato nel tempo; purtroppo al momento se creiamo una sotto-zona DNS dal portale Azure, essa non verrà automaticamente firmata con DNSSEC e dovremo provvedere manualmente.
Conclusioni
Il protocollo DNSSEC colma un’enorme lacuna che affliggeva il servizio DNS, visto che l’effort per la sua attivazione non è molto grande è consigliabile configurarlo per garantire ai nostri utenti un layer di sicurezza aggiuntivo.
Riferimenti esterni
Approfondimento tecnico sul protocollo DNSSEC
Articolo su GitHub che aiuta a capire i concetti del DNSSEC con esempi pratici
Caso d’uso: protezione della posta elettronica supportato da DNSSEC
Approfondimento sul servizio DNS Pubblico su Azure
Maggiori informazioni sulla Root KSK
Documentazione Microsoft – Introduzione al DNSSEC