Un hidden primary e dnsdist. Hardening del DNS autoritativo

Il DNS autoritativo è un amplificatore per gli attaccanti e un bersaglio frequente di flood. Due decisioni di progettazione fanno gran parte del lavoro per renderlo resiliente: tenere nascosto il primary e mettere un load balancer che capisce il DNS davanti a ogni server pubblico. Ecco come, con le regole che consideriamo il minimo.

Nascondete il primary

Il server dove si modificano le zone, dove vivono le chiavi e dove sta la copia master dei dati non deve mai rispondere a internet. Al contrario, replica verso secondari pubblici su una rete solo interna, e solo i secondari compaiono nei record NS.

Questo vi dà tre cose. Il server più prezioso non è esposto a flood o exploit. I server pubblici diventano sacrificabili: se uno viene attaccato o si guasta, i suoi pari continuano e lui può essere ricostruito dal primary. E potete distribuire i secondari su reti, siti e piattaforme diverse, così nessun singolo failure domain mette giù il dominio.

Che la replica sia il classico AXFR con NOTIFY o una replica di database sotto PowerDNS, la proprietà da proteggere è la stessa: l'indirizzo del primary non deve mai comparire in un record NS o SOA pubblico. Verificatelo:

dig +short NS example.com
dig +short SOA example.com   # the MNAME field should not be your hidden primary

Perché un load balancer generico non basta

Un load balancer TCP o UDP può distribuire le query, ma non può leggerle. Quasi ogni difesa DNS utile dipende dalla comprensione della query: il tipo, la zona richiesta, se è un UPDATE, quanti fallimenti sta generando una sorgente. dnsdist, del progetto PowerDNS, sta davanti al nameserver, tiene la porta pubblica e prende quelle decisioni prima che la query raggiunga il backend. Il server autoritativo vero e proprio ascolta allora solo su localhost.

Le regole dnsdist che consideriamo il minimo

-- backend listens on localhost only
newServer({address="127.0.0.1:5300", name="auth"})
setLocal("0.0.0.0:53")
addLocal("[::]:53")

trusted = newNMG(); trusted:addMask("10.0.0.0/8")   -- your internal replication network
ourZones = newSuffixMatchNode(); ourZones:add("example.com.")

-- ANY queries are an amplification tool; refuse them
addAction(QTypeRule(DNSQType.ANY), RCodeAction(DNSRCode.REFUSED))

-- no dynamic updates or notifies from the internet
addAction(AndRule({OpcodeRule(DNSOpcode.Update), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))
addAction(AndRule({OpcodeRule(DNSOpcode.Notify), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))

-- only answer for zones we actually serve
addAction(NotRule(SuffixMatchNodeRule(ourZones)), RCodeAction(DNSRCode.REFUSED))

-- cap queries per source address
addAction(MaxQPSIPRule(50), DropAction())

-- automatic temporary blocks for sources generating floods of failures
local dbr = dynBlockRulesGroup()
dbr:setRCodeRate(DNSRCode.NXDOMAIN, 50, 10, "NXDOMAIN flood", 60)
dbr:setRCodeRate(DNSRCode.REFUSED, 50, 10, "REFUSED flood", 60)
function maintenance() dbr:apply() end

Cosa vi dà ciascuna regola:

• Rifiutare ANY elimina la classica query di amplificazione.
• Rifiutare UPDATE e NOTIFY dall'esterno chiude le strade attraverso cui il contenuto delle zone o la replica potrebbero essere influenzati da internet.
• Rifiutare le zone che non servite prima che il backend le veda tiene del tutto lontani dal nameserver spazzatura casuale e sonde di riflessione.
• Impostate i limiti di rate per sorgente dal vostro traffico reale, abbastanza generosi per i resolver grandi.
• I blocchi dinamici sui tassi di fallimento intercettano gli attacchi a sottodomini casuali, che generano flood di risposte NXDOMAIN da molte sorgenti, senza bloccare un resolver per un solo minuto storto.

Aggiungete il response rate limiting sul backend o in dnsdist, così nemmeno risposte apparentemente legittime possono trasformarsi in un flood verso un indirizzo falsificato.

DNSSEC senza rimescolare le chiavi

Se i vostri secondari firmano le zone da soli, ognuno di loro ha bisogno delle chiavi, e distribuire le chiavi è il punto in cui i deployment DNSSEC vanno storti. Quando le chiavi vivono nello stesso database che replica verso i secondari, ogni server firma in modo identico per costruzione. Quando spostate un dominio firmato tra provider, procedete in ordine: rimuovete il vecchio record DS al registro, aspettate che le cache scadano, firmate sui nuovi server, poi pubblicate il nuovo DS. La validazione non si interrompe mai.

Il reverse DNS fa parte del lavoro

Trattate il reverse DNS come una regola: ogni indirizzo assegnato a un'interfaccia, a un servizio o a un host riceve un PTR nella stessa modifica, e ogni zona inversa è delegata a tutti i vostri nameserver. Verificate entrambe le direzioni e la delega del parent:

dig +short -x 192.0.2.25
dig +short host.example.com A
dig +short NS 2.0.192.in-addr.arpa

Il nome diretto e quello inverso devono concordare, e l'insieme NS della zona inversa deve corrispondere a quanto il registro regionale ha in archivio.

Osservate le risposte, non solo i server

Un nameserver che è su ma serve una zona stantia è peggio di uno che è giù, perché nulla suona l'allarme. Monitorate ciò che conta: confrontate il serial SOA di ogni zona su ogni server, confrontate il numero di record, osservate il ritardo di replica e avvisate se l'hidden primary compare mai nei dati pubblici. Verificare da qualche punto di osservazione esterno che ogni server pubblico risponda in modo autoritativo chiude il cerchio.

La vostra checklist

• Il vostro primary è nascosto, e assente da NS e SOA?
• I server pubblici stanno dietro un front end che capisce il DNS e rifiuta ANY, UPDATE e NOTIFY esterni, e le zone sconosciute?
• Esistono limiti per sorgente e blocchi dinamici per i flood di fallimenti?
• Tutti i server firmano in modo identico, e la procedura di rollover del DS è scritta?
• Ogni indirizzo assegnato ha un PTR corrispondente?
• Avvisate in caso di serial diversi tra i server?

Gestiamo il nostro DNS autoritativo su PowerDNS esattamente così, e costruiamo cluster dedicati per i clienti che vogliono il proprio. Se desiderate una revisione del vostro DNS, saremo lieti di aiutarvi.

Parla con un ingegnere

Related

Correlati: DNS autoritativo e reverse DNS, gestiti come infrastruttura · DNS autoritativo e ricorsivo su PowerDNS · IPv6, nativo e dual-stack