Newsgroup: it.comp.sicurezza.varie
Titolo: Attacco su porta 53

Oggi per circa due ore non siamo riusciti ad uscire a causa di una mancanza 
di risoluzione dell'Ip.
Nello stesso momento, dal traffic monitor del mio Watchguard, vedevo 
migliaia di tentativi di query sulla mia porta di ingresso 53. naturalmente 
l'ip viene messo in blocked list. Ho sentito Telecom Interbusiness e loro 
hanno negato problemi.
Volevo sapere se c'è in giro  un DoS da parte di server zombie-
..
02/07/05 12:31 :  deny in eth0 219 udp 20 47 210.138.175.244 122.210.106.98 
53 59967 (blocked site)
02/07/05 12:31 :  deny in eth0 366 udp 20 44 192.48.79.30 122.210.106.98 53 
59823 (blocked site)
02/07/05 12:31 :  deny in eth0 247 udp 20 44 192.48.79.30 122.210.106.98 53 
59823 (blocked site)
02/07/05 12:31 :  deny in eth0 212 udp 20 44 192.48.79.30 122.210.106.98 53 
59823 (blocked site)
02/07/05 12:31 :  deny in eth0 212 udp 20 44 192.48.79.30 122.210.106.98 53 
59823 (blocked site)
02/07/05 12:31 :  deny in eth0 212 udp 20 44 192.48.79.30 122.210.106.98 53 
59823 (blocked site)
Saluti
Max

 59823 (blocked site)
$ host 192.48.79.30
30.79.48.192.in-addr.arpa domain name pointer 
j.gtld-servers.net
.
Per la serie: security off the shelf <beg>.
-- 
No more tradition's chains shall bind us;
Arise, ye slaves! No more in thrall!
The Earth shall stand on new foundations;
We have been naught - We shall be All!


A parte che purtroppo ho appiccicato un solo ip, ma dal  RIPE Whois Database 
non mi č uscito nemmeno invertendo gli ottetti.
Ad ogni modo non ho detto che stamattina ho avuto molti tentativi di accesso 
da vari ip con traceroute. Pero'  lě non mi sono preoccupato piů di tanto.
Comunque ... c'č questo comunicato che dice che la Symantec ha rilevato un 
ingiustificato aumento di traffico relativo al servizio DNS:
http://news.zdnet.com/2100-1009_22-5086013.html
 

 
http://news.zdnet.com/2100-1009_22-5086013.html
Sì, ma non mi pare molto rilevante, ad occhio e croce.
La mia osservazione era relativa, piuttosto, al fatto che non mi
pare molto saggio che il firewall o quel che è sia proattivo in
maniera poco oculata: "chiudere fuori" i root server, ad esempio, se
si usa una cache dns interna, equivale a negarsi la possibilità di
risolvere i nomi.
E 192.48.79.30 *è* un root server, ad esempio.


 E 192.48.79.30 *Ã¨* un root server, ad esempio.
Un paio di anni fa', incaricammo la IBM di eseguirci un test di intrusione, 
e valutarono tutti i nostri sistemi di protezione. Relativamente al DNS, 
riporto una loro affermazione, che è scritta sul documento finale:
"There is no reverse resolution in DNS for the tested IP address 
xxx.xxx.xxx.xxx. There are two group within the security community. Many 
(like me) thinks it's better to have a reverse DNS resolution to be able to 
do cross-check. There are exploids that won't work if DNS reverse resolution 
is there. Tho ofter groupe ends to not using reverse DNS resolution because 
if you have a hacker could identify IPs just by looking for a valid DNS 
resolution. Whitin IBM we use forward and backward resolution."
Io ho chiuso la 53 in ingresso per evitare problemi. E comunque stamattina 
prima dei tentativi di DNS, sono arrivate una sacco di richieste di 
traceroute.

 Io ho chiuso la 53 in ingresso per evitare problemi. E comunque stamattina 
Che però non c'entra nulla con le affermazioni del consultant che hai 
citato.
-- 
cat: .signature: No such file or directory

> Io ho chiuso la 53 in ingresso per evitare problemi.
Ehm ... la "chiusura" dovrebbe riguardare i pacchetti
in ingresso con destination_port=53 e NON quelli con
source_port=53 altrimenti sarà dura che il DNS interno
possa funzionare e risolvere indirizzi internet; detto ciò
un qualsiasi firewall SPI dovrebbe essere in grado di
gestire correttamente il traffico DNS generato dal tuo
DNS interno senza bisogno di particolari regole
Saluti

 ha scritto nel messaggio 
news:36pd3mF...@individual.net...

Ho guardato sui Servizi del Dns del mio firewall e prevede gli incoming e 
outgoing;
per quanto riguarda gli incoming sono in Denied, mentre allowed in uscita.
Guardando nelle properties, c'è indicato solo che puo' utilizzare l'Udp e il 
Tcp.
Ad ogni modo, sono almeno 4 annii che funziona in questo, ed il ns server ha 
risposto sempre correttamente alle queries.
Solo stamattina non riusciva a risolvere il problema! Adesso tutto è normale 
e funzionante.
Nei log trovo solo occasionali blocchi dovuti ai normali tentativi sulla 
porta 135, 137, 1433 etc.etc
Tnx Massi