Vulnerabilità e Soluzione di BIND 9 - Patchare BIND per Evitare il Cache Poisoning (Fedora/CentOS)

Sono abbastanza sicuro che la maggior parte di voi abbia sentito parlare della vulnerabilità in BIND. Dan Kaminsky all’inizio di questo mese ha annunciato un problema massiccio e multi-vendor con il DNS che potrebbe consentire agli attaccanti di compromettere qualsiasi server di nomi - anche i client.

Ho pensato di condividere con tutti voi una delle soluzioni più rapide che gli amministratori di sistema che eseguono BIND 9 possono utilizzare per aiutare a risolvere questa vulnerabilità nel caso in cui i loro sistemi siano vulnerabili.

Dopo 3 giorni di test e sperimentazioni con i miei server DNS, ho scoperto qualcosa che sembrava risolvere il mio problema, quindi ho deciso di condividerlo con tutti voi.

Non sono sicuro se questo abbia davvero risolto il problema, anche se ha funzionato per me poiché i risultati dei test sono ottimi. Ma i vostri suggerimenti e commenti sono benvenuti.

La mia scoperta, per quanto semplice possa sembrare, si applica solo a coloro che eseguono BIND 9 su Centos 4 o 5 e sistemi Fedora core e superiori… Ho testato su tutte queste macchine nel mio ufficio.

Iniziamo… vero?

Prerequisiti e Assunzioni

Il tuo firewall (iptables NAT/PAT o PIX) deve avere la porta 53 aperta in modo tale da consentire la selezione casuale delle porte.
Devi eseguire BIND 9 su Centos 4 o 5 o su qualsiasi sistema Fedora core.
BIND deve essere in esecuzione in modalità chrooted, anche se non è un prerequisito, ma è una buona pratica.
Nei tuoi file /etc/named/named.conf O /etc/named.conf…. Devi disabilitare le query ricorsive e anche aggiungere un acl per consentire solo alle tue reti di effettuare richieste ricorsive. Con questo, l’amministratore di sistema avrà ridotto le possibilità di cache poisoning alle proprie reti conosciute.

acl "mynetworks" {
         127/8;  172.16.0.0/12;  10.0.0.0/8;  192.168.0.0/16

view "internal" {
         match-clients { mynetwork; };
         allow-query { mynetwork; };
         allow-recursion { mynetwork; };
         match-recursive-only yes;

view "external" {
         match-clients { any; };
         allow-query { any; };
         allow-recursion { none; };
         match-recursive-only no;

E Ora Per Risolvere La Vulnerabilità Di BIND

Il primo passo è controllare se il proprio sistema è vulnerabile… eseguendo i comandi qui sotto sostituendo ns1.youdomain.co.tz con il TLD o ccTLD della propria organizzazione.

dig +short @ns1.youdomain.co.tz porttest.dns-oarc.net
TXT

z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“192.168.1.3 è POOR: 26 query in 20.0 secondi da 1 porte con std dev 0.00”

POOR —–> indica sicuramente che il server di nomi o il sistema in questione è vulnerabile e, naturalmente, il software BIND in esecuzione è anche obsoleto e deve essere PATCHATO …

Soluzione

Per coloro che eseguono sistemi CentOS O Fedora….. si può utilizzare yum per patchare i sistemi. Gli sviluppatori di CentOS 5 hanno già rilasciato una patch per il software BIND e l’attuale è: bind-9.3.4-6.0.2.P1.el5_2. P1 indica che il pacchetto è stato patchato.

Sui miei sistemi, dopo la patch, ho ottenuto questo risultato..

rpm -q bind

bind-9.3.4-6.0.2.P1.el5_2 —-> se la tua versione di bind non è patchata.. allora patchala.

Si dovrebbe fare questo per ottenere il software più recente e la patch.

yum update bind bind-chroot -y

Si dovrebbe modificare il file named.conf e aggiungere quanto segue. Salva e ricarica BIND.

 vi /etc/named.conf

options {
         directory "/var/named";
         allow-transfer {192.168.1.4 ;};
         query-source   address * port 53; ##COMMENTA o RIMUOVI QUESTA RIGA.

Questo consentirà la selezione casuale delle porte. Fai questo solo se questo parametro è abilitato sotto le opzioni nel tuo file named.conf.

         dnssec-enable yes;                        ## AGGIUNGI QUESTA OPZIONE PER ABILITARE DNS-SEC.

La riga sopra, quando aggiunta al tuo file named.conf, abiliterà DNS-SEC. Procedi e configura DNS-SEC, ma ricorda che DNS-SEC non è una soluzione definitiva a questa vulnerabilità. **

Ricarica o Riavvia BIND.

/etc/init.d/named reload

Poi testa di nuovo per vedere se ottieni un risultato migliore.

dig +short @ns1.youdomain.co.tz porttest.dns-oarc.net TXT

Solo per confermare… :-)

z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“192.168.1.3 è GOOD: 26 query in 19.6 secondi da 26 porte con std dev 16515.27”

GOOD indica che il server di nomi in questione a 192.168.1.3 sembra essere al sicuro, ma bisogna assicurarsi che le porte elencate non seguano un modello ovvio. cioè le porte con deviazione standard.. 16515.27… Ma se il tuo test segna (10000.00 std dev) allora il tuo server DNS è più sicuro e i tuoi clienti o utenti non dovrebbero preoccuparsi.

La stessa procedura dovrebbe essere eseguita su tutti i server DNS nella tua organizzazione.