No more maintained.
Now just a test in a lab.
DNS Security
Il DNS e le sue problematiche di sicurezza. Breve rassegna della security history di Bind, problematiche attuali
Nuovi bug di Bind e antichi vizi sul DNS
Tipo Infobox: ARTICLES - Skill: 2- JUNIOR
Sono state scoperte nuove serie vulnerabilità sulle versioni 4 e 8 di Bind, il server DNS più usato in rete, e continuano ad esistere diffusi errori di configurazione e settaggio sulla maggior parte dei name server in rete.
Il DNS, Domain Name System, è probabilmente il protocollo Internet più trascurato e bistrattato fra quelli fondamentali per una felice e proficua esperienza in rete.
Serve per convertire in nomi di dominio (www.punto-informatico.it) facilmente ricordabili, gli indirizzi IP (62.152.117.47) degli host in rete.
Esiste un software, Bind, dell'Internet Software Consortium ( http://www.isc.org/products/BIND/ ) che viene usato sulla stragrande maggioranza dei server DNS in rete: dai possenti ROOT-SERVERS che stanno alla base dell'intera gerarchia del Domain Name System, al server DNS del nostro provider, che gestisce e definisce gli indirizzi IP dei suoi domini locali e permette ai computer dei suoi abbonati di eseguire richieste (query) DNS e risolvere indirizzi (ottenere l'IP del dominio cercato).
Sebbene non esistano statistiche precise su quali server DNS sono più utilizzati in rete, perchè a differenza di un server Web, per esempio, un DNS non comunica al client la sua identità e versione, è risaputo che Bind viene utilizzato nella maggior parte dei casi, anche perchè le alternative languono:
Djbdns ( http://www.tinydns.org/ ) è apprezzato per la sua leggerezza e sicurezza, ma per alcuni risulta difficile da configurare e non dispone di tutte le feature di Bind (in realtà il suo problema è probabilmente di essere arrivato con vari anni di ritardo);
il server DNS di Windows probabilmente non viene usato nemmeno da Microsoft: di fatto, dopo un imbarazzante down di oltre un giorno di www.microsoft.com per problemi sulla rete che ospitava TUTTI i suoi server DNS pubblici, Redmond fa gestire il servizio DNS per i suoi domini in outsourcing (chiediamo scusa per aver tirato in ballo anche in questo caso il Gigante, questa volta proprio non c'entra niente, ma il caso sui suoi DNS fu emblematico e piuttosto clamoroso);
esistono altri progetti ( http://dmoz.org/Computers/Software/Internet/Servers/Address_Management/ ) ma per quanto ne sappiamo quasi nessuno li usa.
Insomma, Bind fa la parte del padrone, probabilmente con percentuali ben superiori al 60% di Apache nel mondo Web, e il 12 Novembre sono state rese pubbliche ( http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21469 ) alcune serie vulnerability sulle attuali versioni 4.x e 8.x, ancora largamente in uso, di Bind (le versioni 5, 6, 7 non sono mai esistite, la 9.x è la più recente ed è immune da questo problema).
Già qualcuno prevede che a questa vulnerability disclosure seguirà relativo exploit utilizzabile in casi reali e poi, visto che è inutile ripetere a mano ciò che si può automatizzare, potrà apparire l'immancabile worm, con potenziali nefaste conseguenze su molti server in rete per i suoi effetti a catena.
Il dado è tratto e la valanga pare destinata a staccarsi dalla montagna, sia perchè tradizionalmente i tempi di update dei sistemi da parte di sysadmin pigri, troppo impegnati o poco informati tendono ad essere lunghi, sia perchè il DNS è il classico "servizio dimenticato" che richiede poca manutenzione e, in genere beneficia di poche attenzioni.
A questo proposito sono piuttosto interessanti le ricerche di Men&Mice ( http://www.menandmice.com/ ) società di consulting che pubblica regolari disarmanti report sulle (mis)configurazioni dei server DNS in rete.
Ad Agosto 2002 (http://www.menandmice.com/dnsplace/healthsurvey.html), per esempio, su un campione di 5000 domini .com, si sono trovati errori di configurazione nel DNS sul 70.1% dei casi.
Non male come numero, anche se si deve considerare che molti degli errori segnalati si riferiscono ad aspetti secondari relativamente non critici. Vediamone alcuni, tanto per farci sorprendere:
- il 27.6% dei domini analizzati ha tutti i propri server autoritari sullo stesso segmento di rete: se cade quello cade la possibilità di risolvere gli indirizzi dei relativi domini. Ne sa qualcosa Microsoft, come abbiamo visto.
- il 7.4% ha un solo server autoritativo, se quello cade, non esiste un server di backup che possa essere usato per risolvere gli IP del dominio.
- il 20.2% ha errori di configurazione nelle deleghe (con cui i server DNS gestiscono in modo gerarchico chi deve risolvere gli IP di un dato dominio) che possono comportare problemi e ritardi di varia natura nelle query.
- il 14.18% non ha configurato record PTR in corrispondenza di un record A, in pratica non permette il reverse lookup, l'operazione inversa a quella che normalmente si fa: ottenere il nome di un host di cui si sa l'IP.
- il 18.68% dei domini non ha configurato un record MX che indichi quale server di posta deve ricevere mail per il relativo dominio.
La criticità del sistema DNS è nota, quantomeno a chi fa colazione con pane e Internet.
A prescidere dai dati qui riportati e dalla notizia di un nuovo, inevitabile, security hole su un software largamente diffuso in rete, il Domain Name System per sua natura si basa su pochi server principali che gestiscono le deleghe per tutti i domini in rete: i 13 ROOT-SERVERS (http://www.root-servers.org/) gestiti da entità eterogenee come l'esercito degli Stati Uniti, il Department of Defence americano, la NASA, Verisign Inc., il RIPE europeo e altri, dislocati per la gran parte in USA.
Lo sa bene chi ha recentemente provato a mettere in ginocchio Internet con una serie di attacchi DDOS proprio sui ROOT-SERVERS ( http://punto-informatico.it/p.asp?i=41884 ), ma non c'è riuscito.
Tutto questo può dare la sensazione di una baracca che sta in piedi per miracolo, con miliardi di pacchetti che ogni microsecondo fluiscono come spermatozoi frenetici e spericolati fra le maglie di una rete che cresce tumultuosa a colpi di patch, upgrade, bugs, worms, ddos in quella grandiosa danza tecnologica quotidiana che mormora incessante, e ogni tanto singhiozza, in ogni secondo del nostro tempo.
Overview delle problematiche di sicurezza con il DNS
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
La funzione dei server DNS è fondamentale per il funzionamento di Internet e spesso una mancanza di servizio da parte di server DNS si tramuta in un blocco, di fatto, di qualiasi altra attività in rete.
Le problematiche di sicurezza che riguardano il protocollo DNS e il relativo servizio sono di varia natura:
- Riservatezza e sensibilità delle informazioni.
Tramite il DNS si possono fornire varie informazioni su una macchina, oltre al semplice nome. La qualità e la quantità delle informazioni esposte dipende di fatto da come si configurano le proprie zone (i domini per cui si è autoritari) e quante informazioni vengono date sui singoli host.
In linea di massima è consigliabile dare alle macchine nomi di fantasia (es: giove.dominio.com) che non siano strettamente collegate alla loro funzione e associarli con un CNAME al nome di un servizio (es: www.dominio.com o upload.dominio.com).
A prescindere dalla quantità di informazioni configurate per un dominio sul suo server DNS autoritativo, è anche opportuno limitare il zone transfer della zona solo ai server DNS secondari o a IP fidati.
- Vulnerabilità del servizio DNS.
Come per altri protocolli anche i software che vengono usualmente utilizzati per gestire il DNS possono avere buchi ed essere suscettibili di attacchi. In particolare BIND ha una security history relativamente tormentata per cui è importante averne sempre una versione aggiornata per i servizi pubblici.
L'intrusione su un server DNS, oltre alle problematiche tipiche di ogni intrusione, è particolarmente critica, perchè sul server violato è possibile modificare facilmente le configurazione del DNS dando via libera ad una vasta varietà di problematiche per tutti i servizi dei domini per cui il server DNS è autoritario.
- Funzionamento del servizio
Attacchi DOS a server DNS o guasti su linee o sistemi, compresi i ROOT-SERVERS, possono mettere a repentaglio la risoluzione dei nomi su diverse scale.
E' prassi comune, anche perchè semplice da implementare, prevedere almeno un server DNS secondario per ogni server primario. I server secondari devono risiedere su reti diverse e possibilmente in zone geografiche differenti.
Generalmente il DNS non è un servizio che impegna troppo un sistema per cui può essere tranquillamente implementato su macchine che forniscono altri servizi primari.
- DNS poisoning e attacchi sul protocollo
La comunicazione fra client-server e server-server DNS, a meno che non venga usato DNSSEC, non viene validata, autenticata o criptata e può essere soggetta ad una varietà di attacchi con diverse caratteristiche.
Il loro punto in comune è quello di fornire risposte DNS arbitrariamente errate e quindi potenzialmente foriere di ogni tipo di attacco a legittime richieste di client ignari.
Di fatto il modo migliore per proteggersi dalla intrinseca "buona fede" delle risposte del protocollo DNS sarebbe quella di usare DNSSEC, ma la sua diffusione è ancora troppo lenta e parziale per essere veramente utile.
Configurazioni di BIND relative alla sicurezza
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Le precauzioni di massima per evitare abusi comuni su un server DNS non sono molte e soprattutto non comportano particolari complicazioni per cui vale la pena implementarle appena possibile.
Elenchiamo alcune configurazioni e accorgimenti raccomandabili quando si configura BIND.
NEGARE LO ZONE TRANSFER
Il trasferimento di zona avviene esclusivamente fra due server DNS (può farlo anche un client, ma solo per raccogliere informazioni non necessarie) quando viene aggiornata una zona sul master e trasferita agli slave.
Si può configurare BIND per limitare gli zone transfer solo ai server autorizzati. In /etc/named.conf ci dovrebbero essere righe come:
options {
directory "/var/named";
allow-transfer {
192.168.0.0 / 24 ; Si permette uno zone transfer a tutta la rete 192.168.0.0/24
172.16.1.6 ; Si permette uno zone transfer all'host 172.16.1.6
};
};
In caso di richieste di zone transfer non autorizzate, sul file di log, generalmente /var/log/messages si trovano entry del tipo:
Mar 4 11:48:31 ns named[2762]: client 193.0.0.63#46935: zone transfer 'openskills.info/IN' denied
Mar 4 11:48:54 ns named[2762]: client 193.0.0.63#47815: zone transfer 'openskill.info/IN' denied.
Fondamentalmente su un server DNS slave non è necessario permettere lo zone transfer ad alcun IP, su un server DNS master è necessario permetterlo a tutti gli indirizzi dei server slave.
LIMITARE LE POSSIBILITA' DI QUERY
Quando si imposta un server DNS come resolver su un client, ogni richiesta fatta dal client al server viene completamente processata dal server stesso, se il server non ha la risposta nella sua cache o fra le zone di cui è autoritativo, il server DNS richiede per conto del client, le informazioni ai server DNS autoritativi. Questa operazione si definisce Query Ricorsiva e viene generalmente permessa sui server DNS che forniscono il loro servizio come resolver ad un dato range di client.
Se il proprio server DNS funge solo da resolver e non è autoritativo per alcun dominio (quindi non deve ricevere query da altri server DNS) è può configurare Bind per limitare query solo da dati IP:
acl "trusted" {
213.198.151.0/24; 10.0.0.0/8; Definisce una acl, chiamata "trusted"
};
options {
directory "/var/named";
allow-query { "trusted"; }; Permette le query solo agli IP indicati nella acl "trsuted"
};
Se invece il proprio server è autoritativo per alcune zone ma non viene utilizzato come resolver è opportuno disabilitare la possibilità di fare query-ricorsive e si deve lasciare aperta la possibilità di eseguire query da ogni parte di Internet, almeno per i domini di cui è autoritativo:
options {
recursion no; Diabilita la possibilità di fare query ricorsive
};
SEPARARE DNS RESOLVER DA DNS DELEGATED
Se un server DNS ha la delega per un dominio, deve poter rispondere a query DNS di tutti i client su Internet per le zone di cui è autoritario. Se viene utilizzato come resolver da un dato numero di client (i PC di una rete locale, gli utenti di un provider, ecc) deve poter eseguire query ricorsive per conto di tutti i suoi client.
Queste sono due funzionalità separate che in linea di massima sarebbe opportuno implementare su 2 macchine separate:
- Un server delegato, che permette query da tutta Internet, non permette query ricorsive e permette zone transfer solo ai suoi slave.
- Un server resolver, che permette l'accesso solo da un range di IP definito, permette query ricorsive e nega ogni zone transfer.
Molti tipi di attacchi di DNS poisoning, infatti, si basano sulla funzionalità di recursive query, che quindi andrebbe limitata per quanto possibile.
Se, come spesso accade, il proprio server DNS deve essere sia autoritativo per alcuni propri domini che fare da resolver per i propri client, è possibile configurarlo per cercare di espletare entrambe le funzioni limitando i rischi di sicurezza:
acl "trusted" {
213.198.151.0/24; 10.0.0.0/8; Definisce una acl, chiamata "trusted"
};
acl "slave" {
192.253.253.9; 193.205.245.8;
};
options {
directory "/var/named";
allow-query { "trusted"; }; Di default permette query solo dagli IP trasted
};
zone "openskills.info" {
type master;
file "openskills.info";
allow-query { any; }; Per il dominio openskills.info, di cui è autoritario, accetta query da tutti
allow-transfer { "slave"; }; Permette zon transfer per il dominio openskills.info solo agli IP indicati nell'acl "slave"
};
zone "151.198.213.in-addr.arpa" {
type master;
file "213.198.141";
allow-query { any; };
allow-transfer { "slave"; };
};
NASCONDERE LA VERSIONE DI BIND
Tramite il comando dig è possibile scoprire la versione di Bind che gira sul server interrogato:
dig version.bind chaos txt - Visualizza la versione di Bind sul server DNS correntemente utilizzato:
; <<>> DiG 9.2.1 <<>> version.bind chaos txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41822
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "9.2.1" Sul server gira Bind 9.2.1
dig @ns.dominio.it version.bind chaos txt - Visualizza la versione di Bind sul server DNS ns.dominio.it.
Notare che se sul server non gira Bind, l'ANSWER SECTION risulta vuota.
Per nascondere la versione di Bind che si sta utilizzando basta scrivere nel file di configurazione:
options {
version "Ignota";
};