Attacco su porta 53

[MaxT.]

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

[whiplash]

Post by MaxT.
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)

$ host 210.138.175.244
244.175.138.210.in-addr.arpa domain name pointer d.dns.jp.

Post by MaxT.
02/07/05 12:31 : deny in eth0 366 udp 20 44 192.48.79.30 122.210.106.98 53
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>.

[MaxT.]

Post by whiplash

Post by MaxT.
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)

$ host 210.138.175.244
244.175.138.210.in-addr.arpa domain name pointer d.dns.jp.

Post by MaxT.
02/07/05 12:31 : deny in eth0 366 udp 20 44 192.48.79.30 122.210.106.98 53
59823 (blocked site)

$ host 192.48.79.30
30.79.48.192.in-addr.arpa domain name pointer j.gtld-servers.net.

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

[whiplash]

Post by MaxT.

Post by whiplash

Post by MaxT.
02/07/05 12:31 : deny in eth0 219 udp 20 47 210.138.175.244
122.210.106.98
53 59967 (blocked site)

$ host 210.138.175.244
244.175.138.210.in-addr.arpa domain name pointer d.dns.jp.

Post by MaxT.
02/07/05 12:31 : deny in eth0 366 udp 20 44 192.48.79.30 122.210.106.98 53
59823 (blocked site)

$ host 192.48.79.30
30.79.48.192.in-addr.arpa domain name pointer j.gtld-servers.net.

A parte che purtroppo ho appiccicato un solo ip, ma dal RIPE Whois Database
non mi è uscito nemmeno invertendo gli ottetti.

$ whois 192.48.79.30

OrgName: VeriSign Global Registry Services
OrgID: VGRS
Address: 21345 Ridgetop Circle
City: Dulles
StateProv: VA
PostalCode: 20166
Country: US

NetRange: 192.48.79.0 - 192.48.79.255
(cut)

Post by MaxT.
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
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.

[MaxT.]

Post by whiplash

Post by MaxT.
A parte che purtroppo ho appiccicato un solo ip, ma dal RIPE Whois Database
non mi Ú uscito nemmeno invertendo gli ottetti.

$ whois 192.48.79.30
OrgName: VeriSign Global Registry Services
OrgID: VGRS
Address: 21345 Ridgetop Circle
City: Dulles
StateProv: VA
PostalCode: 20166
Country: US
NetRange: 192.48.79.0 - 192.48.79.255
(cut)

A me non lo risolve:

http://www.ripe.net/perl/whois?form_type=simple&full_query_string=&searchtext=192.48.79.30&do_search=Search

Post by whiplash
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.

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.

[Skull]

Post by MaxT.

Post by whiplash
OrgName: VeriSign Global Registry Services
OrgID: VGRS
Address: 21345 Ridgetop Circle
City: Dulles
StateProv: VA
PostalCode: 20166
Country: US
NetRange: 192.48.79.0 - 192.48.79.255
(cut)

http://www.ripe.net/perl/whois?form_type=simple&full_query_string=&searchtext=192.48.79.30&do_search=Search

Che sia perchè RIPE si occupa dei blocchi europei e Verizon sta a negli
states?!?

Post by MaxT.
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.

[ObiWan]

Post by MaxT.
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

[MaxT.]

Post by ObiWan

Post by MaxT.
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

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