Newsgroup: it.comp.reti.ip-admin
Titolo: entry arp assurde

Ciao a tutti, ho un bel problemino.
Una linux box con una vecchia distro (redhat 6.0) che fa da router/gw per 2
mie subnet.
A un certo punto mi trovo gli switch della mia rete freezati, e centinaia di
messaggi sulla linux box di
"neighbor table overflow". Dopo un po' di googling, ho visto che le mie
entry arp sull'interfaccia eth1 (la mia lan interna) sono quasi 2000, di due
classi di indirizzi :
7.226.x.x e 134.68.x.x
Con ethereal vedo una marea di traffico arp broadcast cosi' :
---------------------------------
source                    dest
192.168.1.1         broadcast                who has 134.75.226.59?
192.168.1.1         broadcast                who has 134.75.226.58?
192.168.1.1         broadcast                who has 134.75.226.57?
192.168.1.1         broadcast                who has 134.75.226.56?
192.168.1.1         broadcast                who has 134.75.226.55?
192.168.1.1         broadcast                who has 7.227.139.196?
192.168.1.1         broadcast                who has 7.227.139.195?
192.168.1.1         broadcast                who has 7.227.139.194?
e adesso la super-sorpresa , nelle entry ho beccato l'ip 134.75.226.5
OrgName:    System Engineering Research Institute
OrgID:      SERI-1
Address:    Korea Advanced Institute of Science and Technology
Address:     207-43, Cheongryangri-Dong, Dongdaemonn-Ku
Address:     Seoul
City:
StateProv:
PostalCode:
Country:    KR
-------------------------------------
sospetto un arp-poisoning, voi che fareste ?

 sospetto un arp-poisoning, voi che fareste ?
Hai provato a ripulire tutte le macchine con i vari anti-trojan / antivirus
e a mettere Knoppix sulla linuxbox, come ci eravamo detti?
Com'e' andata?
Ciao
Luca
-- 
Luca Sasdelli
Microsoft MVP - Networking, Windows NT/2000/XP
http://mvp.support.microsoft.com

 Com'e' andata?
è andata bene, anche se ho seguito una procedura diversa : mi sono recato di
buon mattino :-) e ho verificato che - come sospettavo - non vi era traccia
del traffico .
A quel punto ho fatto accendere le macchine una per una, creato uno
scriptino per controllare la tabella ARP, e ho beccato in fretta il
"colpevole" : un maledetto client con una versione di Blaster che ha creato
una situazione riportata in questa lista (tra l'altro creata in lab) :
http://archives.neohapsis.com/archives/incidents/2003-08/0195.html
ovviamente questo client, per una ragione ancora da scoprire, aveva il
Norton che falliva gli update da 3 mesi!!
La cosa pazzesca era la sequenza randomica di ARP broadcast request del mio
gateway, generati ovviamente da ping o dal pacchetto SYN descritto dagli
analisti del worm : per "coincidenza" (ma io sospetto una scelta non
casuale) erano dirette a tutte le subnet 7.227.x.x.,7.228.x.x e 134.78.x.x ,
cioè rispettivamente alla rete della Difesa americana, alla Stanford
university, a un istituto di ricerca coreano e ai costruttori del
bombardiere B2 :-)))) mi trovavo nella arp table un sacco di
xxxxx.xxx.army.mil
 :-&
Tutto ciò portava a uno storm di ARP che quasi sicuramente freezava gli
switch.
Nota che gogglando qua e là ho trovato qualcuno che ha avuto freezati degli
apparati da AS, cioè aggeggini da svariate decine di migliaia di verdoni :-|
Saluti
n3tgan3sh

 
http://archives.neohapsis.com/archives/incidents/2003-08/0195.html
scusate, il msg corretto era questo :
http://archives.neohapsis.com/archives/incidents/2003-08/0187.html

 Norton che falliva gli update da 3 mesi!!
Cosi' a sentore: la route table di quel pc e' andata a donnine?
forse il default gateway non impostato? oppure la net mask non corretta?
E' strano, infatti, che vi siano quelle arp request, in quanto la
macchina dovrebbe inviare i pacchetti al default gateway, poiche' non
appartengono alla sottorete locale, anziche' cercare di inviarli da soli
(ecco i lperche' degli arp request).
my 2 eurocents
-- 
HappyCactus - Linux User #209744 - 
 
www.google.com
 - 
groups.google.com

 (ecco i lperche' degli arp request).
mi sono spiegato male : č proprio il gateway che sparava migliaia di arp
request , perche' nell'architettura che ho questo gw separa 2 tratti di
rete, e le richieste per l'esterno passano prima per questo gw e poi al
firewall.
Il fatto č che anche la distro e la configurazione evidentemente sono fatti
male (la sto ricostruendo 'sta macchina), parliamo di una RedHat 6.0 e altre
tavanate che sto notando nella conf.
Sai com'č, di default la neigh table (i valori in /proc etc.etc.
gc_thresh1,2,3) ne ospita al max qualche centinaio, qui c'era un client che
ne sparava decine al secondo, quindi l'effetto era gateway rallentato,
errori vari tra le due subnet, e gli arp broadcast che poi hanno messo a
sedere gli switch.
Saluti

 tavanate che sto notando nella conf.
ovviamente 'sti arp dal gw sono causati da una non corretta conf soprattutto
dei DNS (vedi msg della lista), anzi reverse DNS

 Quindi perche' sparare arp?
bella domanda ! :-)
ho verificato la conf  e ancora non l'ho capito.... :-*
qualche suggerimento su cosa controllare ?