Newsgroup: it.comp.sicurezza.varie
Titolo: Una situazione anomala che si ripete, voi che fareste?

Questo post potrebbe essere il seguito del mio precedente "ICMP Type 8 Code
0".
Il fenomeno descritto proprio in quel post si ripete tutti i giorni,
soprattutto nella fascia oraria tra le 10:00 e le 12:30 del mattino.
Gli ip sono sempre tutti diversi, ma il numero delle rischieste e le
modalità sono sempre le stesse (15 ip che prima pingano due volte e a
distanza di 10 secondi dal ping stesso provano la porta 53 in UDP).
Ho provato a chiedere al servizio clienti di Tiscali, il mio provider, e mi
hanno consigliato di inviare l'estratto del log all'abuse oppure di
rivolgermi alla polizia postale.
Senza discutere dell'efficacia del suggerimento, voi cosa fareste al posto
mio?
Considerate anche che non offro servizi all'esterno, navigo, scarico la
posta e basta, quindi il mio più che un problema è solo un fastidio, però
trovarsi il log ingrassato con queste attività che si ripetono ad intervalli
regolari mi urta.
Come mi consigliate di comportarmi?
Grazie a tutti quelli che sopporteranno questo post.

 Come mi consigliate di comportarmi?
Dipende cosa vuoi ottenere...
Ne fai questione di curiosità? Armati ed inizia ad indagare di tuo, che in
fondo è divertente.
Inizia a monitorare il comportamento di 'sto coso, individuane le
variazioni, ecc...)
La cosa non ti interessa?
Mantieni le orecchie alte e sbattitene..
Uno skull che è solo IMHO...
-- 
wash the blood from your hands
bury your secrets in the sand
and forget

 distanza di 10 secondi dal ping stesso provano la porta 53 in UDP).
Potrebbe essere un load balancer geografico di qualche servizio
che usi, che cerca di capire a che distanza sei dai vari server
del cluster per servirti da quello migliore. 
Prova a loggare il traffico sulla 53/udp e vedi checc'e' dentro
quei datagrammi.
Fabio


se da una parte c'è la curiosità, dall'altra c'è il fatto che tutto viene
fermato e quindi non mi dà proccupazioni.
Stiamo a vedere quanto durerà 'sta cosa!


 e vedi checc'e' dentro quei datagrammi.
Dubbio :-) ...
supponiamo che qualcuno abbia un dynamic
dns domain e che si sia installato anche il suo
"bravo" DNS locale.. a quel punto l'IP del tizio
cambia (DHCP) ... che succede ;-) ??


Hai qualche suggerimento per loggarli? Io uso CHX-I Packet Filter, quindi ho
solo il resoconto delle attività, non il contenuto dei pacchetti che vengono
fermati.

 secondi. A distanza di due ore la cosa si ripete.
E *dentro* le richieste udp cosa c'è?
Provato a sniffarle?


 fermati.
Uhm .. hai un DNS locale ???

 ha scritto nel messaggio
news:c6ln6o$dedoi$1...@ID-180886.news.uni-berlin.de...

Si, quello di IIS 5, ma essendo a solo scopo didattico la sua attivitą č
limitata all'interno della lan dalle regole del packet filter, quindi non č
reggiungibile dall'esterno.

 reggiungibile dall'esterno.
Uhm .. scusa .. cosa c'entra IIS5 con il DNS ?!?

 fermati.
Winpcap piu' windump o ethereal o tethereal o snort ecc ecc
Ethereal e' il piu' facile da usare e installare. Cattura i
datagrammi sulla 53/udp e anche gli echo request, in cui, a
volte, i load balancer inseriscono qualche info.
Guarda, per subito, se sono sempre gli stessi ip. Magari:
1) postali;
2) fai una ricerca su google con gli ip per vedere che cosa
   salta fuori.
Fabio

 l'IP del tizio cambia (DHCP) ... che succede ;-) ??
Questo potrebbe fornire una possibile spiegazione per il
traffico udp, ma i ping avrebbero poco senso, a meno che
non ci sia un tentativo di trasferimento di zona da host
che facciano path mtu discovery... tutto poco probabile,
IMHO. Tuute le richieste insieme da ip diversi, poi...
L'ipotesi del load balancer mi sembra ancora quella piu'
probabile e penso che vedere il traffico potrebbe essere
risolutivo.
Fabio


No, non ho provato. Prima perņ devo modificare lo sniffer in modo da loggare
anche su file gli eventi, cmq lo farņ, sarebbe interessante sapere cosa
contengono quei pacchetti.

 IMHO. Tuute le richieste insieme da ip diversi, poi...
Beh ... tempo addietro alcuni dei root-servers ICANN
_pingavano_ i client che li interrogavano per più di N
volte, non so se il comportamento sia rimasto lo stesso
ma sarei curioso di sapere gli IP da cui provengono
quelle richieste ICMP/DNS ... senza considerare che
alcuni dynamic DNS utilizzano proprio un meccanismo
del genere (ping+query) ed è quello che mi ha fatto
nascere il sospetto...
Ciao


Purtroppo gli ip sembrano essere generati casualmente e neanche una ricerca
su 
http://www.whois.sc/
 ha dato risultati.
Ti posto comunque un riassunto del log
Time Direction Protocol Flags Source IP Source Port Dest. IP Dest. Port
Reason
12h:13min:09sec Incoming - UDP   64.41.192.103 54001 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   203.89.210.82 33329 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   208.185.54.14 55195 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   63.166.13.66 62199 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   202.160.241.130  3638 82.84.88.29    53
Deny Filter
12h:13min:09sec Incoming - UDP   205.158.108.194 38656 82.84.88.29    53
Deny Filter
12h:13min:09sec Incoming - UDP   208.185.219.166 30941 82.84.88.29    53
Deny Filter
12h:13min:09sec Incoming - UDP   64.0.96.12 24459 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   64.28.86.226 63215 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   65.169.170.131 10788 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   208.254.18.130 58462 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   210.224.186.4 24207 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   64.14.117.10  2022 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   64.37.246.2 63996 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   212.162.1.194 48120 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   212.187.170.2 22474 82.84.88.29    53 Deny
Filter
12h:13min:09sec Incoming - UDP   4.78.20.2 53713 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   203.89.210.82 33329 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   64.41.192.103 54001 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   63.166.13.66 62199 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   202.160.241.130  3638 82.84.88.29    53
Deny Filter
12h:12min:59sec Incoming - UDP   208.185.54.14 55195 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   205.158.108.194 38656 82.84.88.29    53
Deny Filter
12h:12min:59sec Incoming - UDP   208.185.219.166 30941 82.84.88.29    53
Deny Filter
12h:12min:59sec Incoming - UDP   64.0.96.12 24459 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   64.28.86.226 63215 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   65.169.170.131 10788 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   208.254.18.130 58462 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   210.224.186.4 24207 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   64.14.117.10  2022 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   64.37.246.2 63996 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   212.162.1.194 48120 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   212.187.170.2 22474 82.84.88.29    53 Deny
Filter
12h:12min:59sec Incoming - UDP   4.78.20.2 53713 82.84.88.29    53 Deny
Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  203.89.210.82 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  202.160.241.130 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  64.41.192.103 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  63.166.13.66 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  208.185.54.14 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  64.28.86.226 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  64.0.96.12 ~ NA ~ 82.84.88.29
~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  65.169.170.131 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  208.254.18.130 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  205.158.108.194 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  210.224.186.4 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  208.185.219.166 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  64.37.246.2 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  212.162.1.194 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  64.14.117.10 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  212.187.170.2 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:49sec Incoming - ICMP Type:8 Code:0  4.78.20.2 ~ NA ~ 82.84.88.29
~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  203.89.210.82 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  202.160.241.130 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  63.166.13.66 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  64.28.86.226 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  64.41.192.103 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  64.0.96.12 ~ NA ~ 82.84.88.29
~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  208.254.18.130 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  65.169.170.131 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  208.185.54.14 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  205.158.108.194 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  210.224.186.4 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  64.37.246.2 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  208.185.219.166 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  212.187.170.2 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  4.78.20.2 ~ NA ~ 82.84.88.29
~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  64.14.117.10 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter
12h:12min:39sec Incoming - ICMP Type:8 Code:0  212.162.1.194 ~ NA ~
82.84.88.29 ~ NA ~ Deny Filter

 ha scritto nel messaggio
news:c6lomv$cqvp9$1...@ID-180886.news.uni-berlin.de...

Scusa la ca@@ta, volevo dire che sullo stesso pc c'è IIS 5 che uso in
accoppiata con il dns server di win 2k server per i miei pasticci in rete
locale.

 [...]
E' un load balancer speedera. 
Fabio

> E' un load balancer speedera.
Battuto di qualche minuto :-) .. ma sei
sicuro che sia un "load balancer" ?!?
In ogni caso non si capisce il perchč
dovrebbe "prendersela" con l'IP di
"iw7" ... mah ... :-)
Cmq ecco alcuni dei "ptr" ...
194.108.158.205.in-addr.arpa, type=ptr, data=
x194.cd9e6c.sj.concentric.net
166.219.185.208.in-addr.arpa, type=ptr, data=
reserved.above.net
14.54.185.208.in-addr.arpa, type=ptr, data=
208.185.54.14.speedera.com
12.96.0.64.in-addr.arpa, type=ptr, data=
64.0.96.12.ptr.us.xo.net
Ciao


almeno so da dove proviene quel traffico, rimane cmq l'interrogativo su cosa
cerchino dalla mia connessione.
Devo rettificare ciò che ho scritto qualche riga più su, l'ip di
speedera.com
 è presente in ongi scorribanda, nel frattempo vedo di reperire
quanlche info su questa società.


può essere pertinente?
http://www.speedera.com/primary/services/authdns.htm

 "iw7" ... mah ... :-)
Questo lo dovrebbe sapere lui. Potrebbe essere
un sito su cui lui naviga tutti i di', o media
player 9, un sistema di autoupdate antivirus o
di qualche altro software. Propenderei per gli
autoupdate (vista l'apparente periodicita') ma
anche media player 9 non e' da sottovalutare.
Comunque e' facile... al posto di loggare solo
il traffico dns in ingresso, gli basta loggare
tutto il traffico sulla porta 53/udp. Prima di
vedere i ping e i probe sulla 53/udp, trovera'
le query dns incriminate e, subito dopo, anche
le ripsoste.
Fabio

 un range di ip dinamici?
Perche' probabilmente sei _tu_ a richiederne i servizi.
Per la precisione, uno dei software che hai installato.
Leggi l'altro post in risposta a ObiWan. 
Comunque... siamo sempre li: guarda cosa c'e' dentro al
traffico dns (anche in uscita) e scoprirai l'arcano.
Fabio

 le ripsoste.
Si direi che usare uno sniffer dovrebbe permettere
di chiarire cosa sta succedendo .. basterebbe dare
un'occhiata ai pacchetti in ingresso .. certo che anche
un honeypot potrebbe essere divertente :-)))

 (o appartentemente tali) .. _in_ingresso_ .....
Non sono query. Sono probe per sollecitare un
icmp unreachable su cui misurare il RTT ed il
numero di hop. Gia' che ci sono, e' una query
well formed, in generale, cosi' da non romper
troppo le balle con errori strani nei log nel
caso chi li riceva abbia un server dns. Viene
usata la porta 53 perche' "passa" facilmente,
visto che gli echo (e gli icmp in genere) non
sempre arrivano a destinazione (o ricevon una
risposta).
Fabio

 well formed, in generale, cosi' da non romper
... ma non sempre.
Fabio


qui viene il bello: per quello che ho potuto osservare qualsiasi query dns
viene inoltrata da una porta N verso la 53, di conseguenza la risposta
proviene dalla 53 verso la porta di partenza.
Le regole che ho imposto funzionano alla stessa maniera, dal pc può uscire
solo ciò che è diretto verso la 53 e può entrare solo ciò che proviene da
quella porta. Idem per http, dhcp, pop3, smtp e nntp.
Non sono ammessi neanche i ping da è verso l'esterno, in pratica il gateway
mi fa da fosso, perchè non accetta niente che sia diverso da http, posta,
neanche dall'interno della rete.
Ho regolamentato sia il traffico entrante che quello uscente.
I pacchetti incriminati invece puntano alla 53 del mio pc, dove trovano la
porta chiusa per le regole sumenzionate.
Spero di essermi spiegato decentemente e che se ne venga a capo, ora la cosa
si fa intrigante.


afferrato il concetto, quindi nessuna attività pericolosa, resta cmq il
dubbio del perchè puntino alla mia connessione.
Per scrupolo ho bloccato tutto tutto il traffico, ma a parte netbios sulla
rete interna non c'è altro movimento.
Domani quando rientro modifico lo sniffer e procedo con i controlli.

 porta chiusa per le regole sumenzionate.
Forse ti e' sfuggito come funziona un load balancer.
1) ti colleghi con il browser a una risorsa che si trova su x;
2) fai una query dns per trovare l'ip di x;
3) il dns _prima_ di risponderti cerca di capire in quale parte
   del mondo ti trovi e quale server e' piu' indicato per te;
4) dopo aver trovato la tua posizione rispetto a uno dei server
   che possono soddisfare la tua richiesta, ti viene inviato in
   risposta l'ip del server piu' vicino;
5) finalmente ti colleghi a <ip piu' vicino> e godi a risorsa a
   cui volevi accedere.
Ora, il traffico anomalo che vedi, viene generato nella fase 3.
Prima di risponderti i vari server speedera sparsi per il mondo
t'inviano del traffico (ping e 53/udp) il cui unico scopo e' di
verificare la tua distanza. Misurano l'RTT (il round trip time)
e/o il numero di hop (router) tra te e tutti i server che hanno
la risorsa che richiedi e poi ti servono da quello piu' vicino,
rispondendo con il suo ip alla tua query dns per la risorsa x.
Ti vengono inviati sia i ping, sia i probe sulla porta 53 cosi'
da aumentare le probabilita' di ottenere delle risposte. Se non
ricevono nulla, come nel tuo caso, verrai servito dal primo che
capita o da ip trovatri secondo degli algoritmi di fallback che
speedera ha ritenuto piu' opportuni. In pratica, verrai servito
peggio.
Ti e' piu' chiaro, cosi'?
Fabio

 2) fai una query dns per trovare l'ip di x;
<snop>
Dubbio .. supponiamo che io apra una pagina web sul sito
aaa.bbb.cc
 il sito è in "load balance" (o in cluster, scegli tu)
per cui, mentre alcune delle richieste che io faccio vengono
servite dall'IP di 
aaa.bbb.cc
 altre mi tornano indietro da un
indirizzo IP differente, a questo punto il bravo SPI "sega"
queste ultime dato che per quanto ne sa non esiste alcuna
conversazione in atto con quest'ultimo indirizzo IP
come ti suona ?


Come già detto, la cosa non mi preoccupa, al massimo mi infastidisce e
comunque ora è una questione di principio per me conoscerne la causa e a
quanto pare se ne sta venendo a capo.


saresti potuto essere piů chiaro solo con una proiezione in sala
cinematografica.
Ripeto, sono agli inizi quindi ogni cosa che faccio mi presenta tante
situazioni REALI a me del tutto sconosciute o cmq conosciute a livello
scolastico.
Continuerň con i controlli e le prove, ma adesso tutto ha assunto un'altro
aspetto.
Merçi beaucoup, sia per la pazienza che per il tempo dedicatomi.
Ciao ciao e alla prossima.


Non so perchè mi sa di domanda a trabocchetto, cmq sono curioso di conoscere
la risposta.

 come ti suona ?
Se capisco correttamente dalla spiegazione di Fabio, non può mai capitare:
il balancing effettivo viene fatto a livello di dns, per cui ti risponde
solo la macchina che tu contatti, per le altre non esisti...
-- 
wash the blood from your hands
bury your secrets in the sand
and forget

 altre non esisti...
Si .. e no... accennavo anche al "clustering" e in ogni caso il
balancing _può_ essere fatto sia a livello di DNS sia usando
dell' h/w s/w apposito, detto questo, il mio dubbio verteva su
un meccanismo di clustering/balancing mal configurato per
cui invece di ottenere la risposta da un'unico IP "pubblico"
al quale corrisponde il cluster/balancer la risposta ad una
certa richiesta torna direttamente dalla macchina "utilizzata"
dal balancer per la query, questo è _profondamente_ errato
ma .. appunto, il dubbio era quello di una config errata
Ciao

 scolastico.
Tutti siamo agli inizi in qualcosa :-)
Fabio

 conversazione in atto con quest'ultimo indirizzo IP
Questo, ancor prima che per SPI, sarebbe un problema per lo stack
tcp/ip dell'host. E' una situazione anomala che, pero', non ha, a
mio parere, attinenza col caso. Nel caso di questi load balancer,
dal punto di vista dell'host che richiede i servizi 1) l'ip a cui
fare la richiesta e' uno e solo uno, e 2) il server risponde alle
richieste del client, quindi non c'e' motivo di inviare al client
traffico con ip diverso da parte d'altri server. Considera che si
parla praticamente sempre di socket tipo stream (tcp), quindi...
Lo scopo principale e' servire il client dal server piu' vicino e
non bilanciare il carico tra piu' server.
Fabio

 non bilanciare il carico tra piu' server.
Si e no, tu parli di balancing geografico, io parlo di balancing
fatto tramite clustering, in pratica, supponi di avere 10 servers
"dietro" un load balancer per cui una query all'indirizzo IP 1.2.3.4
verrà indirizzata dal load balancer ad uno dei servers (di norma
il più "scarico" in quel momento) il server in questione elaborerà
la richiesta e (di norma) invierà la risposta attraverso il balancer
per cui il client "vedrà" la risposta provenire da 1.2.3.4 .. ora, se
uno dei servers in "balance" è mal configurato sarebbe (ripeto
sarebbe) possibile che tale server alla ricezione di una richiesta
invii la risposta direttamente _senza_ passare dal balancer, in
questo caso vedresti una risposta arrivare da un'indirizzo IP con
il quale non hai alcuna "conversazione attiva" ed ovviamente
il firewall bloccherebbe i pacchetti in arrivo

 ma .. appunto, il dubbio era quello di una config errata
Questo succede abbastanza di frequente alla fine delle sessioni,
ma quando sono in gioco load balancer non "geografici". I casi a
cui fai riferimento, ho notato, ricorrono frequentemente con dei
server in cluster che forniscono banner pubblicitari. Il cluster
e' mascherato da un nat che fa load balancing sui server reali e
quando il server reale ha comunque la possibilita' di uscire dal
load balancer con il suo vero ip, puo' succedere che:
1) ti colleghi all'ip del servizio, che in realta' e' quello del
   load balancer (ip1);
2) il load balancer fa DNAT verso uno dei server del cluster che
   gli sta alle spalle (ip2), che e' comunque un ip pubblico;
3) il connection tracking del load balancer del cluster gestira'
   correttamente la traduzione degli indirizzi ip1 <> ip2 per la
   sessione e permettera' la comunicazione tra client e server;
ora, puo' accadere che:
4) il client o il server chiudano la sessione (con FIN);
5) per i motivi piu' impescrutabili il load balancer, in questa
   fase, perde lo stato della sessione (bug o troppo traffico o
   ACK del client al FIN del server che passa il nat ma poi non
   arriva al server...);
6) a questo punto se sono necessarie delle ritrasmisisoni accade
   che quelle provenienti dal client non raggiungono il server e
   soprattutto che quelle del server non subiranno il NAT, ma ti
   arriveranno con porte e numeri di SEQ ed ACK corrispondenti a
   quelli attesi, ma da ip2, quello del vero server. 
Ovviamente queste ritrasmissioni non appartengono a sessioni tcp
valide ne per il tuo firewall ne per il tuo stack tcp/ip.
Poi vado a spulciare nei log e tiro fuori qualche riga d'esempio
(se la trovo).
Fabio

 il firewall bloccherebbe i pacchetti in arrivo
Vero, e' il caso che ho presentato nell'altra risposta (la stavo
scrivendo mentre tu postavi, quindi non avevo letto questa).
Fabio

 ma .. appunto, il dubbio era quello di una config errata
Per accadere accade, (come riporta fabio nella seguente e come ho avuto
modo di notare da esperimenti passati... anzi... a qualcuno interessano
appliance con lvs-nat?) ma accade dove usi balancing via nat.
Se il balance lo fai sul dns non può capitare... (e il caso descritto da
fabio era questo, se non ho mal compreso...)
Hola


 descritto da fabio era questo, se non ho mal compreso...)
Si, ma avevo sbagliato. lw7 usa il server dns del suo provider e
quindi non puo' essere quello il meccanismo: i probe  andrebbero
dal server autoritativo per la risorsa richiesta (che implementa
i servizi di load balancing), al server dns che esegue la query,
e non al client che ha inoltrato la query originaria (lw7).
Tra l'altro il caching porterebbe a probe piuttosto infrequenti,
mentre lui vede spesso questo traffico. Piu' probabile l'ipotesi
del redirect della risorsa.
Per evitare di far confusioni sui termini (forse "load balancer"
puo' essere improprio, per certe funzioni) si puo' usare "global
trafic management system" (GTMS), che e' il termine che speedera
usa per i suoi servizi. Ci si potrebbe registrare e ricevere dei
white paper sui dettagli tecnici dei loro servizi, ma non vorrei
esser poi assillato dai loro commerciali.
Fabio

 e non al client che ha inoltrato la query originaria (lw7).
Appunto... l'unico dubbio che rimane è quello relativo al fatto
che in effetti "Iw7" ha detto di avere un DNS sulla macchina
win2000; ora il problema _potrebbe_ essere dovuto anche
ad una errata config di tale DNS ... ma qui sto veramente
sparando nel buio; oltretutto mi suona strano che i probe
abbiano _dest_port_ 53 !! Capirei se fosse source port...
Ciao


Se mi permetti l'eccezione io invece spero di essere alla fine di qualcosa,
infatti oggi ho superato il penultimo esame della buona trentina che mi
separavano da un pezzettino di carta chiamato laurea, "ei fu Teoria dei
segnali e Comunicazioni elttriche". Tra stasera e domani mi metto sotto a
fare un po di test con log, sniffer e quant'altro possa tornare utile e poi
vi informo dei risultati.
Cmq siete un pozzo di informazioni, sto seguendo la discussione con molta
attenzione.
Mi faccio vivo subito dopo i test per aggiornarvi, ok?
Ciao ciao

 ha scritto nel messaggio
news:c6o1pp$e78js$1...@ID-180886.news.uni-berlin.de...

Si, in server dns c'è, ma ha in sè solo il nome del server e quello di
diversi "siti web" che il server ospita, ma come già detto non è
raggiungibile dall'esterno come non lo sono neanche quelli che ho chiamato
siti che altro non sono che le mie scorribande didattiche con php e my-sql.
Per la porta di destinazione di quei pacchetti anche io brancolo nel buio.

 anche io brancolo nel buio.
Smettila di brancolare 
http://netgroup-serv.polito.it/netgroup/tools.html
prenditi analyzer (per win32 ti servirà anche il driver) e fai un pochino
di sniffing del traffico, al limite, se hai un'altro computer, connettilo
fuori
dal firewall con un cavo tipo
http://www.linuxjournal.com/article.php?sid=6985
poi OVVIAMENTE facci sapere :-) !!!
Ciao


MINIMO!!!! Se ne vengo a capo e grazie a voi, quindi il minio che posso fare
è comunicare i risultati ottenuti!

 connetto (attacco fisicamente il cavo di rete) solo quando occorre.
Uhm ... lo potresti fare lo stesso, basterebbe ...
modem adsl
|
HUB ---- sniffer (cavo readonly)
|
server (condivisione)
|
switch
|
LAN
sempre che il modem ... non sia USB :-PPP
Ciao


Ecco, ci hai preso in pieno!!!! Purtroppo è proprio usb, cmq ci voglio
provare lo stesso a vedere ciò che passa sulla rete, sono curioso di sapere
se lo sniffer riesce a piazzarsi prima del chx-i!

 ha scritto nel messaggio
news:c6pa00$u11$1...@lacerta.tiscalinet.it...

Niente da fa, lo sniffer non funge.
Se non fosse che dovrei andare in giro per la rete col popò di fuori potrei
anche disattivare chx-i, però poi non vorrei trovarmi qualche brutta
sorpresa.
Magari ci dormo un po' su e vediamo domani cosa ne viene fuori!