Newsgroup: it.comp.sicurezza.varie
Titolo: [sniffer] Come interpretare questo risultato?

Salve,
vi racconto il mio problema, che mi ha indotto ad usare uno sniffer:
Ho un router Zyxel 650R. 
Da qualche settimana sto cercando di capire perchč nella normale
navigazione web, quando digito su Explorer un URL (+invio), la spia
PPPoE/ACT lampeggia,
Exporer mostra quasi istantaneamente "Sito Web Rilevato...": da questo
momento passano almeno 3-6 secondi (che si notano!) in cui la spia
PPPoe/ACT non lampeggia, poi riparte e la pagina si carica.
Questo per qualsiasi sito, *anche accedendo con IP diretto*.
Ho effettuato un sacco di prove:
Ho provato con Win98 SE, XP (con e senza fireawll di xp) su un altro PC
(nuovo, pulitissimo), altra scheda di rete... nisba.
Ho anche cambiato browser: Opera e Netscape.
Ho provato con e senza DHCP.
Ho aggiornato il firmware del router all'ultima versione.
Ho eliminato gli spyware con Ad-Aware.
Nessuna ha dato risultati, tranne se ATTIVO Zone Alarm: con ZA inizia a
caricare immediatamente la pagina, su tutti i PC che ho provato!
Inoltre anche usando FTP con e senza ZA tutto funziona bene, parte
subito.
-----------------------
Ho fatto delle prove con uno sniffer: WinPcap + Analyzer
Prove effettuate monitorando con lo sniffer:
Caricamento di una pagina web banale ( <html>prova</html> ), solito
problema:
- Senza Zone Alarm attivo --> Latenza 3/6 secondi
- Con Zone Alarm attivo   --> Non c'č latenza
La differenza sostanziale che salta subito all'occhio, č che quando si
verifica la latenza, c'č un pacchetto che viene inviato 2 volte, proprio
a
cavallo del periodo di latenza (4 secondi in questo caso):
Pkt|Time (h:m:s)| Dest. MAC    | Src. MAC     | Network| Description
6  |11:19:47.21 |00A0C5-5D28E6 |525400-EA57D1 |IP:192.168.1.2 =>
XX.XX.XXX.XXX (256) |TCP: Port (1591 => 80) Data (SN 12640021, ACK
4181356195, WIN 8760) HTTP: Client Request
7  |11:19:51.16 |00A0C5-5D28E6 |525400-EA57D1 |IP:192.168.1.2 =>
XX.XX.XXX.XXX (256) |TCP: Port (1591 => 80) Data (SN 12640021, ACK
4181356195, WIN 8760) HTTP: Client Request
Tra il pacchetto 6 e 7 passano di solito dai 3 ai 6 secondi.
Questi due pacchetti sono assolutamente identici, eccetto 2 byte dell'
header IPv4: uno nell'identification e l'altro nel checksum.
So di essermi addentrato molto nel tecnico, ma non so veramente piů che
prove fare e dove sbattere la testa.
Spero che qualcuno sappia dare un'interpretazione.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 header IPv4: uno nell'identification e l'altro nel checksum.
Potresti postare anche l'handshaking includendo quindi la sequenza
syn-syn/ack-ack?
Il client da quello che hai postato rimanda un ack al server in quanto il
server non risponde...oppure qualcosa blocca la risposta prima che arrivi al
client...
Quindi dicevi che dopo i 3-6 il server risponde normalmente... strano...
K
--
"It is always possible to agglutenate multiple separate problems into a
 single complex interdependent solution.  In most cases this is a bad
 idea."  -- RFC 1925

 syn-syn/ack-ack?
Grazie per la risposta. Premetto che per me questo è Greco... Spero che
sia quello che mi hai chiesto.
CON Zone Alarm (tutto ok)
1 | 11:29:01.903256  | FFFFFF-FFFFFF  | 525400-EA57D1  | ARP: Hardware
type= 1, Protocol Type = IP (0800h)   | ARP Request  [Who has
192.168.1.1 tell 192.168.1.2]
2 | 11:29:01.903756  | 525400-EA57D1  | 00A0C5-5D28E6  | ARP: Hardware
type= 1, Protocol Type = IP (0800h)   | ARP Reply  [Host 192.168.1.1 is
00A0C5-5D28E6]
3 | 11:29:01.903915  | 00A0C5-5D28E6  | 525400-EA57D1  | IP:
192.168.1.2 => XX.XXX.XXX.XXX  (48)  | TCP:  Port (1597 => 80)  Data (SN
13194986, ACK 0, WIN 8192)  HTTP: Client Request
4 | 11:29:02.094829  | 525400-EA57D1  | 00A0C5-5D28E6  | IP:
XX.XXX.XXX.XXX => 192.168.1.2  (48)  | TCP:  Port (80 => 1597)  Data (SN
488965074, ACK 13194987, WIN 5840)
5 | 11:29:02.095231  | 00A0C5-5D28E6  | 525400-EA57D1  | IP:
192.168.1.2 => XX.XXX.XXX.XXX  (40)  | TCP:  Port (1597 => 80)  Data (SN
13194987, ACK 488965075, WIN 8760)  HTTP: Client Request
6 | 11:29:02.183510  | 00A0C5-5D28E6  | 525400-EA57D1  | IP:
192.168.1.2 => XX.XXX.XXX.XXX  (256)  | TCP:  Port (1597 => 80)  Data
(SN 13194987, ACK 488965075, WIN 8760)  HTTP: Client Request
7 | 11:29:02.380393  | 525400-EA57D1  | 00A0C5-5D28E6  | IP:
XX.XXX.XXX.XXX => 192.168.1.2  (40)  | TCP:  Port (80 => 1597)  Data (SN
488965075, ACK 13195203, WIN 5840)  HTTP: Server Reply
8 | 11:29:02.461062  | 525400-EA57D1  | 00A0C5-5D28E6  | IP:
XX.XXX.XXX.XXX => 192.168.1.2  (470)  | TCP:  Port (80 => 1597)  Data
(SN 488965075, ACK 13195203, WIN 5840)  HTTP: Server Reply
9 | 11:29:02.597753  | 00A0C5-5D28E6  | 525400-EA57D1  | IP:
192.168.1.2 => XX.XXX.XXX.XXX  (40)  | TCP:  Port (1597 => 80)  Data (SN
13195203, ACK 488965505, WIN 8330)  HTTP: Client Request
SENZA Zone Alarm (latenza tra pacchetto 6 e 7)
1 | 11:19:47.025033 | FFFFFF-FFFFFF | 525400-EA57D1 | ARP: Hardware
type= 1, Protocol Type = IP (0800h) | ARP Request [Who has 192.168.1.1
tell 192.168.1.2]
2 | 11:19:47.025550 | 525400-EA57D1 | 00A0C5-5D28E6 | ARP: Hardware
type= 1, Protocol Type = IP (0800h) | ARP Reply [Host 192.168.1.1 is
00A0C5-5D28E6]
3 | 11:19:47.025660 | 00A0C5-5D28E6 | 525400-EA57D1 | IP: 192.168.1.2 =>
XX.XXX.XXX.XXX (48) | TCP: Port (1591 => 80) Data (SN 12640020, ACK 0,
WIN 8192) HTTP: Client Request
4 | 11:19:47.215709 | 525400-EA57D1 | 00A0C5-5D28E6 | IP: XX.XXX.XXX.XXX
=> 192.168.1.2 (48) | TCP: Port (80 => 1591) Data (SN 4181356194, ACK
12640021, WIN 5840)
5 | 11:19:47.216082 | 00A0C5-5D28E6 | 525400-EA57D1 | IP: 192.168.1.2 =>
XX.XXX.XXX.XXX (40) | TCP: Port (1591 => 80) Data (SN 12640021, ACK
4181356195, WIN 8760) HTTP: Client Request
6 | 11:19:47.217420 | 00A0C5-5D28E6 | 525400-EA57D1 | IP: 192.168.1.2 =>
XX.XXX.XXX.XXX (256) | TCP: Port (1591 => 80) Data (SN 12640021, ACK
4181356195, WIN 8760) HTTP: Client Request
7 | 11:19:51.160594 | 00A0C5-5D28E6 | 525400-EA57D1 | IP: 192.168.1.2 =>
XX.XXX.XXX.XXX (256) | TCP: Port (1591 => 80) Data (SN 12640021, ACK
4181356195, WIN 8760) HTTP: Client Request
8 | 11:19:51.357759 | 525400-EA57D1 | 00A0C5-5D28E6 | IP: XX.XXX.XXX.XXX
=> 192.168.1.2 (40) | TCP: Port (80 => 1591) Data (SN 4181356195, ACK
12640237, WIN 5840) HTTP: Server Reply
9 | 11:19:51.372631 | 525400-EA57D1 | 00A0C5-5D28E6 | IP: XX.XXX.XXX.XXX
=> 192.168.1.2 (470) | TCP: Port (80 => 1591) Data (SN 4181356195, ACK
12640237, WIN 5840) HTTP: Server Reply
10 | 11:19:51.380214 | 525400-EA57D1 | 00A0C5-5D28E6 | IP:
XX.XXX.XXX.XXX => 192.168.1.2 (52) | TCP: Port (80 => 1591) Data (SN
4181356625, ACK 12640237, WIN 5840)
11 | 11:19:51.560292 | 00A0C5-5D28E6 | 525400-EA57D1 | IP: 192.168.1.2
=> XX.XXX.XXX.XXX (40) | TCP: Port (1591 => 80) Data (SN 12640237, ACK
4181356625, WIN 8330) HTTP: Client Request


 4181356625, WIN 8330) HTTP: Client Request
Hai detto che hai provato con diversi browser e sistemi
operativi...Ovviamente avrai anche provato con altri server per controllare
se il problema e' del server...
Quello che proprio non capisco e' come faccia zonealarm a risolvere il
delay...
Be, mi dispiace di non essere riuscito a capire il motivo di questo strano
comportamento, ma almeno hai imparato come funziona l'handshaking... ;-)
K
--
"La disumanità del computer sta nel fatto che, una volta programmato
e messo in funzione, si comporta in maniera perfettamente onesta" Isaac
Asimov

 comportamento, ma almeno hai imparato come funziona l'handshaking... ;-)
Caspita, mi hai dato una bella lezione, ti ringrazio!


> La butto li': non e' che ZA ha una sorta di sua cache DNS e/o web?
Ho provato a leggere sul sito e non ne parlano, ma tieni presente che vado a
fare prove anche su siti dove non sono mai andato, quindi non ci può essere
niente in cache.

 12640237, WIN 5840) HTTP: Server Reply
Apparentemente e' una normale ritrasmissione dovuta a una eccessiva
latenza del server _o_ del "terzo" che sta mediando la connessione.
Potrebbe, infatti, esserci un proxy trasparente che sta mediando le
tue connessioni sulla porta 80 che, per motivi che mi sfuggono, non
ti invia l'ACK per la tua GET finche' non ha ricevuto, a sua volta,
la risposta dal vero server web o qualche cosa di simile. Non penso
che sia un comportamento corretto e mi sembra poco probabile.
Quello che e' comunque inspiegabile e' che, in ogni caso, il tuo PC
non ha nessun grado di controllo su una situazione di questo genere
qualunque essa sia: la ritrasmissione e' dovuta ad una latenza lato 
server, e tu non ci puoi fare niente. Tanto meno dovrebbe poter far
qualcosa l'installazione di ZA. Non e' che stai traendo conclusioni
basate sulla analisi di troppe poche prove? Prova ad accedere anche
sulla porta 80 di qualche host di cui puoi controllare il log, od a
qualche servizio on-line che ti consenta di verificare quale sia il
vero ip con cui ti presenti al server, cosi' da poter verificare se
c'e' di mezzo un transparent proxy.
Ti consiglierei d'usare uno sniffer diverso: analyzer e' rimasto un
po' indietro e non viene aggiornato da anni.
Fabio

 po' indietro e non viene aggiornato da anni.
Pensi che Ethereal possa andare bene? Se no quale altro free/shareware?
Ciao e Grazie per l'aiuto!


 puoi controllare il log
Fatto, al server web arriva 1 sola richiesta GET.
Inizio a pensare che la prima se la "mangi" il router, visto che il
traffico che riesco a monitorare con lo sniffer è quello della cheda di
rete.
Se vuoi/puoi ti invio tutto i dettagli di ogni singolo pacchetto.
Ciao, Paolo


 Se vuoi/puoi ti invio tutto i dettagli di ogni singolo pacchetto.
Se riesci, e non l'hai gia' fatto, potresti mandare il log dello sniffer
sia lato server sia lato client, dove il server potrebbe anche essere un
qualsiasi computer di un tuo amico che esegua un 'nc -l -p 80'.
Fabio

 Pensi che Ethereal possa andare bene? Se no quale altro free/shareware?
Io preferisco comunque ethereal, ma in effetti sono andato a vedere 
e pare che il progetto analyzer sia ripreso: e' di novembre la 3.0,
anche se in alfa. Vedremo.
Fabio

 qualsiasi computer di un tuo amico che esegua un 'nc -l -p 80'.
Scusami ma sono parecchio ignorante in materia, mi puoi spiegare meglio
quest'ultimo punto ?
Paolo.
