Feeds:
Posts
Comments

Posts Tagged ‘DNSSEC’

Screen Shot 2014-02-16 at 16.01.39

Read Full Post »

Dopo essermi occupato –oramai parecchio tempo fa– di come configurare BIND per fungere da resolver validando DNSSEC, mi prendo finalmente il tempo per buttare giù le 4 righe relative a come dotare la vostra zona di DNSSEC.

Per questa ricetta abbiamo bisogno di:

  • un dominio appartenente ad un TLD già dotato di zona firmata e che accetti la submission dei record DS per i domini erogati (org, net, com, biz vanno bene)
  • un registrar che vi dia la possibilità di sottomettere il vostro record DS affinché vada nella zona del TLD
  • un nameserver sotto il vostro controllo, che esegua preferibilmente BIND 9.7 o superiore (per lo/gli slave il requisito è semplicemente l’esecuzione di un DNS con supporto ai tipi di record necessari a DNSSEC)
  • un tab di un browser (oltre a quello dove è aperta questa pagina) puntato sulla RFC4034, in modo da poter consultare alla bisogna le definizioni relative ai vari Resource Records utilizzati da DNSSEC

Metto le mani avanti su un fronte: DNSSEC non è banale e farete quasi certamente una lunga sequela di errori nella gestione della vostra prima zona firmata. Questi errori potrebbero rendere la vostra zona non valida e il vostro dominio irraggiungibile per chi esegua validazione DNSSEC. Ergo, evitate di fare esperimenti con un dominio in produzione, e procuratevi invece un dominio con cui spippolare in tranquillità…

Supponendo che il dominio lo abbiate già registrato con il registrar di cui sopra (se lo avevate già registrato altrove, richiedete il trasferimento ad altro registrar o prendete un nuovo dominio), procediamo dapprima al configurare il nostro DNS master, definendo la nostra zona in modo simile a questo:

zone "mydomain.tld" {
        type master;
        key-directory "/etc/bind/dnssec-keys";
        update-policy local;
        auto-dnssec maintain;
        file "zones/mydomain.tld";
        allow-query { any; };
        notify yes;
        allow-transfer {
                "slave1";
                "slave2";
        };
};

Se avete perplessità sulle definizioni qui utilizzate, riferitevi ovviamente alla documentazione di BIND.

Rispetto ad una configurazione “tradizionale“, comunque, avrete quantomeno notato un paio di definizioni in più:

  • key-directory: poichè lasceremo che della firma della zona si occupi direttamente BIND, dobbiamo indicargli dove stanno le chiavi private necessarie
  • auto-dnssec: come appena detto, lasceremo che il signing della zona sia eseguito da BIND. Con la direttiva “maintain”, BIND sarà in grado di occuparsi anche del rollover delle chiavi quando necessario (questo aspetto lo vedremo in altra sede…)

A questo punto procediamo alla creazione della zona dns iniziale, depositandola nel file sopra definito, come faremmo con qualsiasi zona DNS. Poiché però BIND dovrà occuparsi anche della manipolazione dei contenuti della zona stessa dobbiamo garantire che sia il file di zona che la directory ove esso è depositato siano scrivibili da parte di BIND. Diamo un bel “rndc reload” e verifichiamo dai log di non aver commesso errori.

Il passo successivo consiste nel generare le chiavi per la nostra zona. Saprete certamente (se non lo sapete, consiglio di cercare un po’ di paper e iniziare a studiare…) che per ciascuna zona DNSSEC prevede (in realtà consiglia) l’uso di due chiavi distinte: la KSK e la ZSK, con la prima che viene utilizzata per firmare la seconda e la seconda che viene usata per firmare i dati di zona (non a caso si chiamano Key-Signing-Key e Zone-Signing-Key…).

Procediamo dapprima con la creazione della KSK, attraverso il comando:

dnssec-keygen -f KSK -K /etc/bind/dnssec-keys mydomain.tld

La generazione della chiave richiederà un certo tempo, dato che per la KSK il default si attesta a 2048bit: andate tranquillamente a bervi un caffè. Se il vostro DNS poi non è particolarmente dotato in quanto a CPU, ci sta anche una pizza…

Quando il comando avrà terminato, comunque, troverete nella directory indicata una coppia di file, contenenti rispettivamente la chiave pubblica e privata:

-rw-r--r-- 1 skull skull  607 Aug 17 18:45 Kmydomain.tld.+005+62878.key
-rw------- 1 skull skull 1774 Aug 17 18:45 Kmydomain.tld.+005+62878.private

Attenzione al fatto che, avendo delegato la firma della nostra zona a BIND, questi avrà necessità di accedere in lettura a entrambi i file, quindi impostate i permessi di conseguenza.

Ora che abbiamo la KSK, per prima cosa la utilizziamo per ottenere i record DS (in sostanza l’hash della KSK) che andranno poi forniti al registrar affinché vengano pubblicati dalla zona del vostro TLD, come vedremo poi:

dnssec-dsfromkey -2 Kmydomain.tld.+005+62878.key >Kmydomain.tld.+005+62878.ds

Fatto ciò, provvediamo a generare anche la ZSK:

dnssec-keygen -K /etc/bind/dnssec-keys mydomain.tld

Ora abbiamo tutto il necessario; istruiamo quindi BIND affinché provveda a firmare i dati della nostra zona:

rndc sign mydomain.tld

Verifichiamo i log per verificare se tutto è andato come deve:

Aug 17 12:14:23 ns named[18394]: received control channel command 'sign mydomain.tld'
Aug 17 12:14:23 ns named[18394]: zone mydomain.tld/IN: reconfiguring zone keys
Aug 17 12:14:24 ns named[18394]: zone mydomain.tld/IN: next key event: 18-Aug-2011 00:14:24.075
Aug 17 12:14:24 ns named[18394]: zone mydomain.tld/IN: sending notifies (serial 2011081702)

Se non vi sono errori e vedete una cosa come quella qui sopra, la parte di competenza di BIND è andata come deve. Un zone transfer (“dig axfr mydomain.tld @<master>“) eseguito da uno degli slave vi confermerà che ora la zona presenta tutti i simpatici orpelli tipici di una zona firmata…

L’ultimo passo è far pubblicare il record DS relativo alla vostra nuova e fiammante KSK.

Il file .ds che abbiamo generato con il comando “dnssec-dsfromkey” contiene esattamente il record che andrà pubblicato dal TLD:

mydomain.tld. IN DS 62878 5 2 FB559ED949D1D86AB530C615DE0C944995C01A852AF77919A1891289 35857900

Esso è composto da 4 campi:

  • il KeyTag relativo alla KSK (sostanzialmente l’ID della KSK cui il DS si riferisce: se cambiate KSK, cambia l’ID e -ovviamente- il digest)
  • l’algoritmo utilizzato per le chiavi (“5” indica l’accoppiata RSA/SHA1)
  • il tipo di digest della KSK indicato dal record DS stesso (“2” significa che il digest è di tipo SHA256)
  • il digest della KSK stessa, eventualmente spezzettato alla bisogna per cacciarlo in zona

I passi per far pubblicare il record al TLD dipendono strettamente dal registrar utilizzato, sicché non posso essere troppo preciso al riguardo.

Nel mio caso ho usato come registrar GKG, che fornisce una comoda interfaccia REST per gestire le operazioni sui record DS.

Nel mio caso, quindi, tutto si è limitato alla creazione del record JSON dentro ad un file che ho denominato “DS”…

{
"digest":"FB559ED949D1D86AB530C615DE0C944995C01A852AF77919A189128935857900",
"digestType":"2",
"algorithm":"5",
"keyTag":"62878",
"maxSigLife":"3456000"
}

…per poi procedere ad inviare la richiesta al registrar attraverso una unica riga di curl, mandandogli via POST tale file:

curl -i --basic -u <myuser>:<mypassword> \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-X POST \
--data-binary @DS https://www.gkg.net/ws/domain/mydomain.tld/ds

 

Oplà. Il vostro dominio (firmato) è servito.

Per verificare che tutte le operazioni siano andate a buon fine e che il vostro dominio ora validi correttamente, la maniera più banale è quella di sottometterlo all’analisi automatizzata di http://dnscheck.iis.se/ oppure di http://dnsviz.net/ se desiderate “vedere” tutta la (lunga) catena di chiavi che valida la vostra zona.

Ora i più svegli domanderanno: “sì, ma per inserire in zona nuovi record?”. Il modo in cui abbiamo detto a BIND di gestire la zona fa sì che sia sufficiente utilizzare nsupdate(1) e tutti i record aggiunti saranno automaticamente firmati…

Read Full Post »

http://www.circleid.com/posts/coica_and_secure_dns/

Read Full Post »

http://www.ripe.net/lir-services/training/e-learning/dnssec/

Read Full Post »

https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record

Read Full Post »

TLD e DNSSEC

M’è venuto un attacco di curiosità e mi son scritto un one-liner che, prelevata la lista dei TLD da IANA, per ciascun TLD esegue una query del tipo

dig ns +dnssec ${TLD} @dns1.spin.it

per poi verificare quali risposte risultino autenticate (flag AD).

Il risultato è qui

 

Read Full Post »

Quasi, almeno…

Per semplificarvi la vita, partite installando bind >=9.7

Se usate debian, lo trovate precotto tra i backports.

Da questa versione, infatti, bind implementa il supporto ad RFC5011, ovvero il rollover automatico delle trust anchor.

Tutto quel che dobbiamo fare, pertanto, è fornire al nostro resolver la KSK della root-zone, indicandola come “managed“.

Questa è la parte fastidiosa: preleviamo la KSK dalla root-zone stessa e la smanacciamo per creare la direttiva di configurazione che serve a bind (raccomando di leggere il P.S. in coda a questo post).

Eseguiamo quindi la seguente query:

zarathustra:~ skull$ dig +multiline +noall +answer DNSKEY .
.                       86400 IN DNSKEY 256 3 8 (
AwEAAb1gcDhBlH/9MlgUxS0ik2dwY/JiBIpV+EhKZV7L
ccxNc6Qlj467QjHQ3Fgm2i2LE9w6LqPFDSng5qVq1OYF
yTBt3DQppqDnAPriTwW5qIQNDNFv34yo63sAdBeU4G9t
v7dzT5sPyAgmVh5HDCe+6XM2+Iel1+kUKCel8Icy19hR
) ; key id = 41248
.                       86400 IN DNSKEY 257 3 8 (
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
) ; key id = 19036

In risposta ad essa, otteniamo due record, relativi rispettivamente alla ZSK (riconoscibile dal flag 256) e alla KSK (flag 257).

Scartiamo la prima e teniamo solamente la KSK, riformattandola per ottenere un blocco siffatto:

managed-keys {

“.” initial-key 257 3 8 ”

AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= “;
};

Ora editiamo il nostro fido named.conf, inserendo il blocco così generato nella configurazione globale, mentre tra le opzioni inseriremo la direttiva necessaria al look-aside verso i trust-anchor ancora su DLV:

options {

[…]

dnssec-lookaside auto;

[…]

}

Configurazione terminata. Riavviate named e andate per la vostra strada…

Come verificare che DNSSEC stia funzionando come atteso?

Facile: basta verificare che i dati relativi a zone già firmate vengano correttamente autenticati, come ad esempio il sito del NIC Catalano:

zarathustra:~ skull$ dig +dnssec http://www.nic.cat @dns2.spin.it

; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec http://www.nic.cat @dns2.spin.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36096
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.nic.cat.                   IN      A

;; ANSWER SECTION:
http://www.nic.cat.            300     IN      A       195.253.31.9
http://www.nic.cat.            300     IN      RRSIG   A 10 3 300 20100901234408 20100802230001 15875 nic.cat. YaB/ZfC1qQ9LxK9CeiJCcc2jmw/5yDNqfKHeMcOhbUeIFc7cTl2Gp7KZ Erf5cvYRyZBKi9TbeBhgJ8PTUo75PW1WyqzASElkJHftxBSqo5aYwOWZ nYVFHpcPwKvTP+9RcjMHxem8gJjg9KfAGaZyQq0c1srEDXopOwtH4hQi dXU=

;; AUTHORITY SECTION:
nic.cat.                300     IN      NS      ns8.knipp.net.
nic.cat.                300     IN      NS      ns4.knipp.de.
nic.cat.                300     IN      NS      anycast1.irondns.net.
nic.cat.                300     IN      RRSIG   NS 10 2 300 20100901234408 20100802230001 15875 nic.cat. lbHUU6uIfjn0F+Cd/PoqnOEao/h6xHV2irmeL804AZSo5n0c28jvzn16 eaWM9NL1iRmvqQ+iRFVecHD3azQEdkKchRbIJym2UAwMfpMDzimohs0u BPcgnSgs1ErRjD/HrMBa0P96x92GCGQedcCL3D6Aszu3Sd6d4ZVyMSPr iDA=

;; ADDITIONAL SECTION:
ns4.knipp.de.           81793   IN      A       195.253.6.33
ns4.knipp.de.           81793   IN      AAAA    2a01:5b0:0:29::21
ns4.knipp.de.           81793   IN      RRSIG   A 5 3 86400 20201231120000 20100730103103 25716 knipp.de. r0sj/sNRLzVAXbWzbuGxkMzlo2aRN94SGM9ARDFi281IbOakNNF1CpMq KyuOXc0iMGPkkqcG4XCSNZHNLfa/Nsb2z86Zpeo88656+05qrtwACD6+ rnobtip9mBtYsR3m9Dwhdt7sbUmInOaverKtjMx7lvaFJoh7q942z+Yk t3w=
ns4.knipp.de.           81793   IN      RRSIG   AAAA 5 3 86400 20201231120000 20100730103103 25716 knipp.de. dZElZS3BaJ+1WbYAJmHAXyvXa8WHVgL+7fAznLV17K9YX8oYM//7G/Yb Xw6bhCANA2zuc3L6FtSXDN4vlm1IfkxLp36yTT2jjHUvk9dl6S2k4Y0t 8HTp0HocRym7s/xKjd12lRGmiigPIEO1MWFYGlJh6XNMHy+K6FEAEKSQ s7s=

;; Query time: 390 msec
;; SERVER: 2a02:9a8:1::ff03#53(2a02:9a8:1::ff03)
;; WHEN: Mon Aug  9 17:58:35 2010
;; MSG SIZE  rcvd: 854

La presenza, nella risposta ottenuta, del flag “ad” (Authenticated Data) indica che siamo a cavallo…

Ora siete della partita DNSSEC (almeno per il vostro resolver…)

PS: I più svegli avranno notato come non abbia effettuato alcuna verifica della validità della KSK prima di portarla in produzione.

Ovviamente, la verifica la ho fatta, ma non la documento qui perchè

  1. Preferisco essere conciso
  2. Vi renderei le cose troppo facili 😉

Una hint, però, la dò: dnssec-dsfromkey(8) vi può produrre l’hash SHA256 della KSK, da confrontare con quello pubblicato da IANA (nel file XML)

Read Full Post »

Older Posts »

%d bloggers like this: