Ethereal per sniffare traffico

[enzo85]

Qualcuno sa dove potrei trovare una guida su come leggere la schermata dello sniffing di ethereal? (per intenderci quella della consolle principale con i tempi, la sorgente, la destinazione, il protocollo e le informazioni aggiuntive)
Grazie mille!

[BTS]

... sul sito di etheral?

io l'ho usato un po' all'università... non mi sembra complesso

[enzo85]

Originariamente inviato da BTS

... sul sito di etheral?

io l'ho usato un po' all'università... non mi sembra complesso

Fia tutto in inglse e poi non mi spiega esattamente quello che voglio...vorrei capire cosa fa da una schermata...
(anche a me serve per un esame...)

[BTS]

prova a chiedere con me

[enzo85]

Originariamente inviato da BTS

prova a chiedere con me

Mah...più che altro se puoi darmi qualche consiglio su come fare a riconoscere cosa fa in una tal schermata...
Ti spiego: il prof ci darà una schermata di ethereal da commentare dicendo che tipo di traffico ha sniffato sulla rete.
Per spiegarti meglio ti scrivo il testo di un tema d'esame:
"Esaminare la schermata del software Ethereal relativa allo sniffing di alcune operazioni effettuate sulla rete:
1. individuare e descrivere in generale le possibili operazioni eseguite a livello utente
2. descrivere i dettagli della comunicazione catturata sia a livello tcp/ip che a livello di protocolli applicativi
3. descrivere i due protocolli applicativi utilizzati nella comunicazione."

In questo esempio nella figura c'era dei protocolli dns (credo per il dns name per visitare il sito - www.repubblica.it - ), dei tcp e degli hhtp (in questi ultimi due la sorgente e la destinazione è sempre l'host e il sito www.repubblica.it

Sai darmi qualche consiglio in generale (non solo in questo specifico esempio) come fare a rispondere alle domande proposte?

[BTS]

allora, punto 2 : ci dovrebbe essere un campo protcoll... basta leggere, ci sarà scritto TCP,UCP... punto 3 di conseguenza

punto 1.... in funzione delle porte del TCP.... 8080 navigazione...

[enzo85]

Originariamente inviato da BTS

allora, punto 2 : ci dovrebbe essere un campo protcoll... basta leggere, ci sarà scritto TCP,UCP... punto 3 di conseguenza

punto 1.... in funzione delle porte del TCP.... 8080 navigazione...

Ok per il punto 2 e 3 (me lo aspettavo)
Per il punto 1...è quello che alla fine non capisco bene...
Ad esempio dove c'è un tcp (nell'esempio) nelle info c'è:
http > 24364 [ACK] Seq=1 Ack=129 Win=5840 Len=0
La porta in questo caso è la 24364? Come faccio a sapere cosa fa? Dimmi se sbaglio, ma può essere che a livello utente si stia scaricando un file?

[BTS]

così non capisco nemmeno io... posta una facciata di ethereal

[hmetal]

8080 navigazione...

80 non 8080. L'8080 è un espediente per un determinato motivo.

http > 24364 [ACK] Seq=1 Ack=129 Win=5840 Len=0

e no ma allora qua se nn sai cosa vuol dire...mi sa che un ripassino dell'handshake tcp ci vuole.

Ci sono gli ack giusto? cosa vuol dire quando ci sono gli ack? (rispondi!)

Se gira un protocollo http gli ack ci sono? Si/no e perche?(rispondi!!!)

Se tu analizzi la porta sorgente in un datagram appena uscito da un host, cosa dovresti vedere? che numero? (rispondi!)

eeeeeeee ma queste sono le basi del protocollo tcp/ip ragassi!

non puoi leggere ethereal se non le sai...

ciaooooo

[BTS]

ack è acknolegdement... vuol dire che la trasmissione è settata bene
http & ack... non lo so... penso di sì perchè non è sincrono

[hmetal]

le domande erano rivolte a enzo

ack è acknolegdement... vuol dire che la trasmissione è settata bene

no

http & ack... non lo so... penso di sì perchè non è sincrono

nooooo

Anche per bts un bel ripassino del tcp/ip



studiare studiare

ciao

[enzo85]

Originariamente inviato da hmetal

Ci sono gli ack giusto? cosa vuol dire quando ci sono gli ack? (rispondi!)

Se gira un protocollo http gli ack ci sono? Si/no e perche?(rispondi!!!)

Se tu analizzi la porta sorgente in un datagram appena uscito da un host, cosa dovresti vedere? che numero? (rispondi!)

Vediamo se ci azzecco...
Gli ack dovrebbero essere dei messaggi che si ricevono come conferma dal destinatario di un datagramma ricevuto.

Ma il protocollo http che io sappia non dovrebbe avere le ack...però non voglio dire una stupidata (tra l'altro il prof ci da gli esercizi nei quali ci potrebbe essere qualche errore..potrebbe essere questo?)

La terza domanda non l'ho capita molto bene...si dovrebbe vedere la porta da dove esce il datagramma? In questo caso la 80?

[enzo85]

Originariamente inviato da hmetal

Ci sono gli ack giusto? cosa vuol dire quando ci sono gli ack? (rispondi!)

Se gira un protocollo http gli ack ci sono? Si/no e perche?(rispondi!!!)

Se tu analizzi la porta sorgente in un datagram appena uscito da un host, cosa dovresti vedere? che numero? (rispondi!)

Vediamo se ci azzecco...
Gli ack dovrebbero essere dei messaggi che si ricevono come conferma dal destinatario di un datagramma ricevuto.

Ma il protocollo http che io sappia non dovrebbe avere le ack...però non voglio dire una stupidata (tra l'altro il prof ci da gli esercizi nei quali ci potrebbe essere qualche errore..potrebbe essere questo?)

La terza domanda non l'ho capita molto bene...si dovrebbe vedere la porta da dove esce il datagramma? In questo caso la 80?

(ho paura di aver detto una marea di stupidate...)

[hmetal]

ah rieccomi dopo un finesettimana del tubo!

Gli ack dovrebbero essere dei messaggi che si ricevono come conferma dal destinatario di un datagramma ricevuto.

esattamente.

Ma il protocollo http che io sappia non dovrebbe avere le ack...però non voglio dire una stupidata (tra l'altro il prof ci da gli esercizi nei quali ci potrebbe essere qualche errore..potrebbe essere questo?)

No. Il protocollo http (livello 7) si appoggia sul protocollo di trasporto (livello 4) TCP. Il tcp è un protocollo connection-oriented, a differenza dell'udp connectionless. Il tcp instaura un canale logico, molto simile concettualmente al canale fisico creato da una telefonata pstn, tra un sorgente ed un destinatario. Il tcp, a differenza dell'udp, utilizza un sistema di controllo degli errori. Tra i vari sistemi di controllo, c'è l'ack.

La seconda domanda ti deve far riflettere su una cosa: quando tu vedi gli ack, significa che stai usando un protocollo di livello superiore che li utilizza. L'http si appoggia sul tcp per cui sai a priori che ci saranno gli ack. ok?

Ultima domanda: quando un protocollo invia un pacchetto, e il protocollo poi si aspetta di riceverne uno in risposta, mette come porta sorgente nel datagram un indirizzo random superiore alle well known port, quindi superiore al 1024. Come destinazione vedrai la porta legata ad un specifico servizio, come ad esempio per il protocollo http, la porta 80.

Il fatto che non ci sia la porta sorgente, ti fa dedurre che stai utilizzando un protocollo che non si basa sul tcp (tipo udp) o che non ha bisogno di una risposta (tipo il servizio tftp, cioè l'ftp su protocollo udp).

ciao

per qualsiasi dubbio perplessita, posta!

[enzo85]

Originariamente inviato da hmetal

No. Il protocollo http (livello 7) si appoggia sul protocollo di trasporto (livello 4) TCP. Il tcp è un protocollo connection-oriented, a differenza dell'udp connectionless. Il tcp instaura un canale logico, molto simile concettualmente al canale fisico creato da una telefonata pstn, tra un sorgente ed un destinatario. Il tcp, a differenza dell'udp, utilizza un sistema di controllo degli errori. Tra i vari sistemi di controllo, c'è l'ack.

La seconda domanda ti deve far riflettere su una cosa: quando tu vedi gli ack, significa che stai usando un protocollo di livello superiore che li utilizza. L'http si appoggia sul tcp per cui sai a priori che ci saranno gli ack. ok?

Ultima domanda: quando un protocollo invia un pacchetto, e il protocollo poi si aspetta di riceverne uno in risposta, mette come porta sorgente nel datagram un indirizzo random superiore alle well known port, quindi superiore al 1024. Come destinazione vedrai la porta legata ad un specifico servizio, come ad esempio per il protocollo http, la porta 80.

Il fatto che non ci sia la porta sorgente, ti fa dedurre che stai utilizzando un protocollo che non si basa sul tcp (tipo udp) o che non ha bisogno di una risposta (tipo il servizio tftp, cioè l'ftp su protocollo udp).

ciao

per qualsiasi dubbio perplessita, posta!

Fantastico...
Sai, ero un po' indietro con lo studio, ma adesso che ho studiato il tcp e l'udp (tra l'atro già fatto in reti, ma non era così chiaro) e mi hai spiegato meglio, ho capito benissimo!!!

[enzo85]

http > 24364 [ACK] Seq=1 Ack=129 Win=5840 Len=0

Ma quindi il 24364 è la porta del destinatario?
Ack=129 è il numero di datagramma che si aspetta?
E Win=5840 è il numero di datagramma che invierà?
...mmm...forse ho fatto un po' di casino anche quì...

[BTS]

DOHDOHDOH!
Cacchio, son cose che ho fatto troppo tempo fa...
comunque la prima mi ero espresso male, ma la sapevo, volevo scrivere dell'handshaking ma pensavo di sembrare troppo intelligente!
Grazie hmetal, una rinfrescatina non fa mai male

[hmetal]

Ma quindi il 24364 è la porta del destinatario?

Non si capisce, ma a occhio è la porta sorgente.

Ack=129 è il numero di datagramma che si aspetta?

No. Quel numero è un numero di indentificazione dell'ack. Siccome potenzialmente i pacchetti potrebbero fare un giro diverso al ritorno (Ricordo che è una connessione logica e non fisica), potrebbe arrivare un ack relativo ad un altro pacchetto che magari è arrivato prima perche ha fatto in quel momento un percorso piu breve o su un link piu veloce. Indica semplicemente la sequenza dell'ack che poi corrisponde ad una sequenza di pacchetti.

E Win=5840 è il numero di datagramma che invierà?

No è la grandezza della finestra . No a parte gli scherzi si chiama proprio cosi è la windows size, e serve a questo:

durante l'handshake tcp, viene stabilita dal destinatario la grandezza massima dei dati che possono essere trasmessi tra un ack e un altro. Quella grandezza è la window size. Man mano che la trasmissione continua, la window size tendenzialmente aumenta in modo tale da poter trasmettere piu dati possibili tra un ack e un altro, aumentando cosi anche la velocità di trasmissione dei dati a parità di banda. Se per qualche motivo la sorgente non riceve piu ack, perche il destinatario è sovraccarico e non riesce piu a gestirli, la sorgente ritrasmette i dati (in base agli ack non ricevuti), con una window size progressivamente piu piccola fino a che non si stabilizza.
Il destinatario puo anche lui forzare l'abbassamento della grandezza della window size sfruttando gli algoritmi del tcp.

ciao!

Grazie hmetal, una rinfrescatina non fa mai male

mi hai spiegato meglio, ho capito benissimo!!!

[BTS]

adesso non esageriamo... se me le chiedevi un anno fa le sapevo meglio di te

[enzo85]

Originariamente inviato da hmetal

Non si capisce, ma a occhio è la porta sorgente.



No. Quel numero è un numero di indentificazione dell'ack. Siccome potenzialmente i pacchetti potrebbero fare un giro diverso al ritorno (Ricordo che è una connessione logica e non fisica), potrebbe arrivare un ack relativo ad un altro pacchetto che magari è arrivato prima perche ha fatto in quel momento un percorso piu breve o su un link piu veloce. Indica semplicemente la sequenza dell'ack che poi corrisponde ad una sequenza di pacchetti.



No è la grandezza della finestra . No a parte gli scherzi si chiama proprio cosi è la windows size, e serve a questo:

durante l'handshake tcp, viene stabilita dal destinatario la grandezza massima dei dati che possono essere trasmessi tra un ack e un altro. Quella grandezza è la window size. Man mano che la trasmissione continua, la window size tendenzialmente aumenta in modo tale da poter trasmettere piu dati possibili tra un ack e un altro, aumentando cosi anche la velocità di trasmissione dei dati a parità di banda. Se per qualche motivo la sorgente non riceve piu ack, perche il destinatario è sovraccarico e non riesce piu a gestirli, la sorgente ritrasmette i dati (in base agli ack non ricevuti), con una window size progressivamente piu piccola fino a che non si stabilizza.
Il destinatario puo anche lui forzare l'abbassamento della grandezza della window size sfruttando gli algoritmi del tcp.

ciao!

Dovresti venire tu a insegnare protocolli quì da noi!! Almeno si capirebbe meglio!! Quì nessuno ci spiega niente e dobbiamo capire tutto noi...bah!