DNSSEC è immune alle firme di stripping?

Question

DNSSEC è immune alle firme di stripping?

#1 da (6 voti)

5

A mio parere, dovrebbe essere possibile falsificare la risposta DNS in modo che non includa le parti di DS / RRSIG / ... per qualsiasi richiesta, evitando così la convalida DNSSEC del dominio risolto.

Il sistema DNSSEC è immune da questo tipo di attacco?
Unbound con file di ancoraggio DLV e ROOT memorizzati localmente fa la differenza?

dns man-in-the-middle dns-spoofing dnssec

posta Marek Sebera 12.04.2014 - 23:11

fonte

1 risposta

Leggi altre domande sui tag dns man-in-the-middle dns-spoofing dnssec

Problemi nell'evitare il dirottamento di JSON con la convalida AntiForgeryToken di MVC3 o con un token simile Come posso recuperare i file crittografati dopo la reinstallazione del sistema

score 6 · Accepted Answer

Sì, DNSSEC è immune da questo tipo di attacco. A partire da un'ancora (di solito la radice, a volte DLV), ogni delega è esplicitamente sicura (presenza di DS impostata sulla delega):

powerdns.com.       172800  IN  NS  powerdnssec1.ds9a.nl.
powerdns.com.       172800  IN  NS  powerdnssec2.ds9a.nl.
powerdns.com.       86400   IN  DS  44030 8 3 7DD75AE1565051F9563CF8DF976AC99CDCA51E3463019C81BD2BB083 82F3854E
powerdns.com.       86400   IN  DS  44030 8 2 D4C3D5552B8679FAEEBC317E5F048B614B2E5F607DC57F1553182D49 AB2179F7
powerdns.com.       86400   IN  DS  44030 8 1 B763646757DF621DD1204AD3BFA0675B49BE3279

o esplicitamente insicuri (la bitmap NSEC [3] dimostra l'assenza di DS sulla delega):

gov-1l.us.      7200    IN  NS  HNS1.BEYONDHOSTING.NET.
gov-1l.us.      7200    IN  NS  HNS2.BEYONDHOSTING.NET.
gov-1l.us.      86400   IN  NSEC    GOV-ABUSE.us. NS RRSIG NSEC

o implicitamente insicuri (NSEC3 opt-out):

stackexchange.com.  172800  IN  NS  brad.ns.cloudflare.com.
stackexchange.com.  172800  IN  NS  roxy.ns.cloudflare.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
4OTDAP6T1E8VS8BHMCK8CDHSGE3GCOBM.com. 86400 IN NSEC3 1 1 0 - 4OTJJUP7OGM6C149HPOE7O9M1L9LS1OP NS DS RRSIG

( stackexchange.com hash a 4otjehvpu9q5tm1d5v0ec302rcbll9um che è coperto dal secondo rifiuto, quindi non esiste una delega sicura).

In tutti questi casi, SE esiste una delega sicura, il record NSEC [3] per il nome in questione dimostrerà la presenza di DS. Pertanto, se le firme vengono eliminate, un client di convalida può rilevarlo.

Per ulteriori letture, consiglio vivamente RFC7129: negazione autenticata dell'esistenza nel DNS e sezione 5.2 (Autenticazione dei riferimenti) di RFC4035 (Modifiche del protocollo per le estensioni di sicurezza DNS)