Attivare il rigoroso controllo DNSSEC: DNSSEC fornisce un modo per una zona per richiedere la convalida della firma rigorosa?

6

C'è un modo per un dominio good.com di promettere che firmerà tutti i suoi record DNS e che tutti i record senza firma per qualsiasi host *.good.com dovrebbero essere rifiutati? In altre parole, esiste un modo per una zona di fornire un'istruzione firmata che indica che è protetta da DNSSEC e di suggerire che i client DNSSEC possono utilizzare il controllo rigoroso della firma per i record DNS in quella zona?

Questo sarebbe analogo a un record HSTS (in cui un sito sceglie solo HTTPS e suggerisce che i browser rifiutino qualsiasi tentativo di connessione tramite HTTP non sicuro) o un criterio SPF che opta per un controllo rigoroso (affermando che le e-mail che non essere conformi alla politica SPF dovrebbe essere respinta).

Sfondo (a quanto ho capito). In linea di principio, DNSSEC fornisce protezione contro gli attacchi man-in-the-middle: il client può verificare se la risposta DNS ha una firma valida e ignorare tutte le risposte e le risposte non firmate con firme non valide. Sfortunatamente, in pratica, questo ha un costo di compatibilità inaccettabile . Se consideri tutte le risposte non firmate come non valide, allora "interroghi Internet": alcuni siti smettono di funzionare, perché il dominio non firma in modo coerente tutti i record o (mi viene detto) perché le firme vengono talvolta rimosse dai middlebox.

Di conseguenza, per motivi di implementazione pratica, molti client compatibili con DNSSEC in realtà non convalidano : guarda la firma, ma se manca la firma, accetta ancora la risposta DNSSEC. (Anche il resolver DNS pubblico di Google lo farà in alcuni casi .)

Questo apre un brutto attacco man-in-the-middle: il man-in-the-middle semplicemente spoglia tutte le firme DNSSEC e poi modifica i record come preferisce. Se il client accetta risposte DNS senza segno, questo attacco man-in-the-middle nega il valore di DNSSEC. Ovviamente l'altro lato di questa infelice situazione è che se il client rifiuta tutte le risposte DNS senza segno, allora potrebbe essere sicuro contro gli attacchi man-in-the-middle, ma molti siti legacy smetteranno di funzionare, causando costi inaccettabili di compatibilità. Almeno, questa è la mia comprensione.

Si potrebbe immaginare una soluzione migliore potrebbe essere possibile se i client DNSSEC-aware hanno un modo per dire quali zone devono utilizzare la convalida della firma rigorosa. In particolare, se google.com o good.com ha un modo per dichiarare "Garantisco che tutti i miei record DNS siano firmati e voglio che tu consideri i record non firmati come non validi", un client cooperante potrebbe applicare una convalida rigorosa a Record DNS per *.good.com , mentre non è valido per altre zone. Ciò potrebbe consentire una buona compatibilità con i domini legacy consentendo al tempo stesso un controllo rigoroso delle zone che vogliono optare per l'accesso, in altre parole, fornendo una protezione parziale contro gli attacchi man-in-the-middle senza "rompere Internet".

Esiste un tale meccanismo?

    
posta D.W. 14.04.2016 - 00:54
fonte

2 risposte

2

Ci sono tre flag in un pacchetto DNSSec che sono responsabili della comunicazione dei requisiti di convalida di un dominio.

Il bit DO

Il bit DO è impostato dal resolver per indicare che richiede la registrazione dei record di autenticazione da includere nella risposta.

Se un resolver è consapevole della sicurezza, DEVE impostare il bit DO. Se un server dei nomi riceve un messaggio senza il bit DO, DEVE eliminare tutti i record di risorse di autenticazione. A meno che non ci sia una richiesta specifica per un record di autenticazione.

Il CD bit

Questo bit consente ai server dei nomi intermedi di disabilitare la convalida della firma. Questo in pratica dice 'non preoccuparti di convalidare le cose, lo farò da solo, mandami solo i record non elaborati'

Il bit AD

Questa è la parte che risponde effettivamente alla tua domanda.

The name server side SHOULD set the AD bit if and only if the resolver side considers all RRsets in the Answer section and any relevant negative response RRs in the Authority section to be authentic.

Il bit AD dice che questi record sono autentici sono firmati.

Esecuzione di query sicure

Se www.example.com ha configurato chiavi e record di risorse corretti. Deve comunque rispondere ai clienti che non capiscono DNSSec. DNSSec è progettato per essere compatibile all'indietro, deve rispondere alle richieste che non comprendono DNSSec. Questo crea la vulnerabilità che hai evidenziato.

Tuttavia il processo esiste, usando i flag sopra riportati per assicurare che vengano ricevuti solo i record autentici, ma ciò richiede che il resolver sia configurato per farlo. Bind fornisce questo meccanismo nella convalida DNSSec flag (che è abilitato di default)

Enable DNSSec validation in named. Note DNSSec-enable also needs to be set to yes to be effective. The default is yes.

Quindi, se crei il tuo Resolver DNS e lo configuri per accettare solo risposte convalidate, non sarai in grado di risolvere domini che non hanno una catena di fiducia completa associata. Sebbene i domini che non hanno record DNSSec funzioneranno come prima.

Il motivo per cui i name server di Google si comportano come loro, è che li hanno configurati per ignorare il bit di Active Directory se il dominio è popolare. Quindi, se stackexchange avesse un problema con il loro certificato, Google si risolverebbe comunque con i loro server dei nomi. Sembra una decisione che impedisce a stackexchange di uscire da Internet per una grande percentuale di persone che utilizzano il DNS di Google.

modificato per rispondere alla domanda reale!

Se hai configurato il tuo resolver sicuro, e qualcuno a monte può dirottare le sue query, potrebbe rimuovere il bit DO, il che costringerebbe i server upstream a rimuovere tutti i record di autenticazione. Quando il tuo resolver sicuro riceve quel record, presume semplicemente che il dominio che stavi cercando non avesse alcuna autenticazione configurata.

Per eseguire questo attacco non hai nemmeno bisogno di essere completamente inserito nel mezzo, la possibilità di regolare il pacchetto DNS in uscita sarebbe sufficiente.

Questo è stato considerato come parte del design originale di DNSSec. In base a RFC3833 - Analisi delle minacce del sistema dei nomi di dominio

While it certainly would be possible to sign DNS messages using a channel security mechanism such as TSIG or IPsec, or even to encrypt them using IPsec, this would not be a very good solution for interception attacks
[...]
For heavily used name servers (such as the servers for the root zone), this cost would almost certainly be prohibitively high. Even more important, however, is that the underlying trust model in such a design would be wrong, since at best it would only provide a hop-by-hop integrity check on DNS messages and would not provide any sort of end-to-end integrity check

DNSSec è progettato per proteggere da una serie di attacchi specifici, come l'avvelenamento della cache, gli attacchi Man in the middle sono stati semplicemente scontati per il motivo sopra indicato.

    
risposta data 14.04.2016 - 01:17
fonte
0

La risposta breve è: quando si utilizza DNSSEC in una zona, tutti i record devono essere firmati. Quindi non è necessario che un meccanismo trasmetta esplicitamente questa dichiarazione poiché è la politica predefinita e unica delle zone firmate DNSSEC.

Non ci sono eccezioni con questo. Esiste un meccanismo di disattivazione NSEC3 , ma questo è più mirato alle sole zone di delega come i TLD, al fine di ridurre le dimensioni firmando solo le zone figlio che sono esse stesse abilitate DNSSEC.

Quindi se la zona è abilitata DNSSEC e il resolver sta convalidando, dovrebbe trattare tutti i record non firmati come errore di validazione e restituire SERVFAIL .

Per i dettagli, fare riferimento a "4.3 Determinazione dello stato di sicurezza dei dati" in RFC4035 e prendere nota di quest'ultimo paragrafo in sezione 5:

A resolver SHOULD expect authentication information from signed zones. A resolver SHOULD believe that a zone is signed if the resolver has been configured with public key information for the zone, or if the zone's parent is signed and the delegation from the parent contains a DS RRset.

In sintesi la presenza di una chiave nella zona e la convalida a tutta la catena di attendibilità dalla radice fino a questa chiave nella zona dovrebbero avere come conseguenza che tutti i record nella zona hanno accompagnato RRSIG record in convalidare la loro autenticità.

In questo caso, ottenere una risposta senza i record RRSIG può anche mostrare un attacco in corso, quindi questo dovrebbe essere trattato come un errore di validazione, quindi SERVFAIL .

Ora, come hai indicato tu stesso, vari risolutori scelgono per sovrascrivere il comportamento standard predefinito e lasciare passare alcuni record DNSSEC non validi o mancanti. È una decisione politica locale, fino a ciascun resolver, ma è chiaramente al di fuori dello standard.

Come hai linkato, Google lo fa per casi come "dominio molto popolare", molti ISP lo fanno di volta in volta, ad esempio Comcast, quando ottengono la colpa quando i nomi di dominio non sono configurati correttamente (vedi questo esempio: < a href="https://www.darkreading.com/risk/dnssec-error-caused-nasa-website-to-be-blocked/d/d-id/1136990"> link e puoi trovare una lista curata dei problemi correlati al link ). E ora c'è anche una RFC specifica su questo problema: RFC7646: Definizione e utilizzo delle ancore negative del DNSSEC

This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.

e

In the case of a validation failure due to misconfiguration of a Top- Level Domain (TLD) or popular domain name (such as a top 100 website), content or services in the affected TLD or domain could be inaccessible for a large number of users. In such cases, it may be appropriate to use an NTA as soon as the misconfiguration is confirmed. An example of a list of "top N" websites is the Alexa "Top 500 Sites on the Web" [Alexa] or a list of the of the most- accessed names in the resolver's cache.

Potresti anche essere interessato a questo progetto: link che si occupa delle difficoltà di convalida dei risolutori che devono essere prese in considerazione, sia per errori di configurazione che per ambienti ostili.

    
risposta data 03.04.2018 - 18:14
fonte

Leggi altre domande sui tag