Newsgroup: it.comp.os.linux.sys
Titolo: Attacco DDOS in corso e open recursive DNS resolver

Inizia a girare per le mailing list di sicurezza questa segnalazione
(relativa all'attacco DDOS in corso in questi giorni) che vi riporto.
 
L'attacco DDOS in corso fa uso di server DNS mal configurati che
rispondono a query ricorsive anche a client esterni al proprio dominio;
falsificando il mittente della query (inserendo cioe' la vittima come
mittente), con una piccola query ad un server DNS mal configurato si
ottiene una grossa amplificazione.
 
Questi open resolver sono, di fatto, complici dell'attacco per cui e'
bene che ogni SysAdmin verifichi la situazione dei propri server.
 
Collegatevi da una postazione esterna e tentate il dig prepotente: 
 
# dig . @ip.del.server.dns
 
# dig host.sconosciuto @ip.del.server.dns
 
La risposta DEVE essere NEGATIVA
 
  ;; ->>HEADER<<- opcode: QUERY, status: REFUSED
 
Info su 
http://openresolverproject.org/
 
 
 
Nel caso in cui un server non sia configurato correttamente, google e'
ovviamente vostro amico ma, visto che oggi sembra un po' piu' lento del
solito, i primi risultati sono di seguito:
 
www.us-cert.gov/sites/default/files/publications/DNS-recursion033006.pdf
 
 
http://csrc.nist.gov/groups/SMA/fasp/documents/network_security/NISTSecu
 
ringDNS/NISTSecuringDNS.htm
 
http://technet.microsoft.com/en-us/library/cc771738.aspx
 
 
www.cymru.com/Documents/secure-bind-template.html
 
 
Jey
-- 
Non prendere la vita troppo sul serio... non ne uscirai mai vivo
http://www.joram.it/servizi/consulente.htm
 


 
mmm.. io ho la recursion chiusa ma mi risponde in altro modo:
 dig 
pippo.it
 @
dns.tosnet.it
 
 
; <<>> DiG 9.4.1 <<>> 
pippo.it
 @
dns.tosnet.it
 
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55009
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5
;; WARNING: recursion requested but not available
 
;; QUESTION SECTION:
;
pippo.it
.                      IN      A
 
;; AUTHORITY SECTION:
it.                     170683  IN      NS      
c.dns.it
.
it.                     170683  IN      NS      
a.dns.it
.
it.                     170683  IN      NS      
nameserver.cnr.it
.
it.                     170683  IN      NS      
m.dns.it
.
it.                     170683  IN      NS      
dns.nic.it
.
it.                     170683  IN      NS      
r.dns.it
.
 
;; ADDITIONAL SECTION:
c.dns.it
.               10496   IN      A       194.0.1.22
m.dns.it
.               10496   IN      A       217.29.76.4
r.dns.it
.               10496   IN      A       193.206.141.46
dns.nic.it
.             10496   IN      A       192.12.192.5
nameserver.cnr.it
.      86096   IN      A       194.119.192.34
 
mentre se chiedo il dominio in quanto tale (giustamente) lo risolve.
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

 it.                     170683  IN      NS      
r.dns.it
.
 
 
Perch� hai la recursion chiusa ma l'accesso in query aperto, sicch� non
accetta di eseguire recursion, ma se ha i dai in cache li fornisce.
Devi chiudere anche quello, o sei utilizzabile ugualmente per DDoS...
 
 

 Devi chiudere anche quello, o sei utilizzabile ugualmente per DDoS...
 
Se chiudi anche l'accesso in query ti si smontano anche tutte le zone per il quale il server è autoritario... O mi son perso un pezzo?

 per il quale il server ï¿œ autoritario... O mi son perso un pezzo?
 
allow-query-cache (9.4)
 
... ma ovviamente il tuo server ricorsivo non ï¿œ autoritativo per nessuna 
zona. E viceversa. Quindi l'autoritativo non avrï¿œ in cache altre zone se 
non le sue. GIUSTO?
 
 
Fabio

> # dig host.sconosciuto @ip.del.server.dns
 
Uhmm... mi sembra poco esaustiva. Farei piï¿œ un:
 
$ dig @ip.del.server.dns
 
Che, poi, alla fine, puoi comunque amplificare anche con gli 
autoritativi, che magari c'hanno pure piï¿œ banda.
 
 
Fabio
 
(ma di queste cose non se ne parlava una dozzina d'anni fa?)

 non le sue. GIUSTO?
 
E' venerdì, quindi sono più rincoglionito del solito.
Ragioniamo per punti:
 - NS autoritativo: no ricorsione, query aperte al mondo ma per i domini che gestisce
 - NS ricorsivo: si ricorsione, query aperte solo per un dato range di IP
 
Giusto ? Perchè se così è giusto, ignorate pure il mio vecchio post. :)

 (ma di queste cose non se ne parlava una dozzina d'anni fa?)
 
Sono tornate di moda ;-)


 - NS ricorsivo: si ricorsione, query aperte solo per un dato range di IP
 
Io li ho configurati cosi' a parte un particolare: NS cache davanti al
ricorsivo con un firestarter sul mittente per uccidere qualsiasi
traffico inaspettato (o non voluto) ma io sono un po' paranoico e posso
permettermelo perche' ho un numero di query/day ridicolo



Il server ï¿œ primario per i miei domini ma fa da resolver per i server locali 
(posta in primis).
ï¿œ "male"?


 ï¿œ "male"?
 
In linea di massima, sï¿œ; soprattutto se non lo conosci abbastanza da
averne il pieno controllo...
 
 
Cmq, la spiegazione completa ï¿œ:
 
nella tua configurazione, allow-query accetta tutto, dato che il
nameserver ï¿œ autoritativo e quindi deve accettare domande da chiccessia[1].
 
Non accetta di eseguire ricorsione per chiunque, ma solo per chi
soddisfa "allow-recursion".
 
Tuttavia, se la risposta ï¿œ giï¿œ in cache non vi ï¿œ alcuna ricorsione, ergo
allow-recursion non si applica, e la risposta viene fornita ugualmente.
Sicchï¿œ, per un attacco di tipo DNS reflection il tuo server sarebbe
utilizzabile piï¿œ o meno alla stessa stregua di un open resolver.
 
Per evitare che ciï¿œ avvenga, c'ï¿œ una ulteriore direttiva implementata
nelle versioni decentemente aggiornate di BIND, denominata appunto
"allow-query-cache", che consente di definire a chi vanno forniti i dati
provenienti dalla cache.
 
Di default, tuttavia, se esiste una definizione per allow-recursion,
allow-query-cache prende lo stesso valore.
 
Ma dato che il tuo DNS sta fornendo allegramente i dati della cache al
primo che passa (ho verificato io pure), ci sono due possibilitï¿œ:
 
 
1) la configurazione ï¿œ da rivedere profondamente
 
2) la versione di bind ï¿œ antidiluviana e non implementa
allow-query-cache, che ï¿œ stato introdotto da BIND 9.4
 
 
Il risultato di un
 
dig txt chaos version.bind @
dns.tosnet.it
 +short
 
mi porta ad escludere la seconda...
 
 
 
[1] In realtï¿œ, devi accettare domande da chiccessia solamente per i
domini che gestisci, non per tutto; ergo potresti avere un "allow-query"
globale che consente interrogazione ai soli sistemi autorizzati a
recursion, e una direttiva "allow-query { any; };" nella stanza relativa
ad ogni dominio per cui il nameserver ï¿œ autoritativo... E' "come si
faceva una volta"...

 [1] In realtï¿œ, devi accettare domande da chiccessia
 
Usenet rule nï¿œ247-ter.
Mai usare il copia-incolla senza aver verificato che quel che hai
copiato sia almeno scritto giusto...
 

 forwarda ad altri o rifiuta, secondo chi fa la query)
 
Sto cercando un fattore di amplificazione, e il ricorsivo me lo da anche
nell'erogazione di risoste nella propria zona. E, per, definizione deve
essere aperto a tutti.
 
 
Fabio

 ï¿œ "male"?
 
Come puoi immaginare, concordo con quanto scritto da skull.
 
Come approccio, in generale, penso sia meglio gestire piï¿œ sistemi distinti 
con configurazioni piï¿œ semplici che un solo sistema che faccia tutto ma con 
configurazioni piï¿œ complesse. Nel caso specifico dei dns, l'autoritativo e 
il ricorsivo fanno lavori piuttosto diversi, perchï¿œ mischiarli? Non che non
si possa in assoluto (vedi post precedenti), ma, se ï¿œ possibile, lo evito.
 
Ciao
 
 
Fabio


C'era un bellissimo allow-query-cache any :(
 
Adesso da refused.
 
grazie delle info e della tirata d'orecchi


 ottiene una grossa amplificazione.
 
Mi sono ritrovato un daemon.log pieno (>2Gb) di
 
Apr  7 02:32:46 s1 named[7640]: client 41.191.13.156#25345: query
(cache) '
isc.org/ANY/IN
' denied
 
Secondo voi sono sotto attacco? :P A quanto pare il mio DNS si sta
comportando bene, ma come faccio ad evitare di loggare Gb e Gb di roba?
 
Grazie
g4b0

comportando bene, ma come faccio ad evitare di loggare Gb e Gb di roba?
 
Be', intanto per cominciare direi che se non ti interessa servire questi
client d'Egitto, potresti tagliare fuori 41.191.10.0 - 41.191.19.255 via
firewall.
 
Leonardo per le spicce
 
-- 
Were I Glenallan's Earl this tide, and were you Roland Cheyne,
My spur would be in my horse's side, the bridle upon his mane.
If they hae twenty thousand blades and we twice ten times ten,
Yet they hae but their tartan plaids, and we're mail-clad men.

 firewall.
 
Era solo un esempio, in realtą le richieste arrivano da ip random, č un
DDOS bello distribuito... Il problema č che chi non "collabora" viene
spammato!!!
 
g4b0