Di seguito alcuni appunti sull'utilizzo di Wireshark e sul protocollo TCP.

Conviene avviare la capture su di un'interfaccia che non faccia traffico; ad es. su di un notebook si può settare la porta RJ45 così:

/etc/network/interfaces

# Setta l'interfaccia di rete usata da Wireshark come passiva
auto enp1s0
iface enp1s0 inet manual
up ip link set $IFACE promisc on arp off up
down ip link set $IFACE promisc off down
post-up ethtool -G $IFACE rx 512; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done
post-up echo 1> /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6

Nell'header IPv4 viene specificato il TTL (Time to Leave); è un contatore che parte da un valore che è quasi sempre 255, 128 o 64 e che decrementa ad ogni transito da un router. Da ciò si può desumere da che versante il trace di Wireshark è stato preso; tale lato infatti presenterà un valore integro (o quasi) di TTL:

Di seguito un TTL decrementato:

[]

Per evitare la frammentazione dei pacchetti IP si usa la MSS, spiegata sotto. Questo meccanismo però funziona solo tra i due endpoint di una connessione TCP; se tra gli endpoint esistono apparati intermedi con una MTU più piccola, la frammentazione avverrebbe comunque.

In questo caso interviene il Path MTU Discovery (PMTUD); è attivo di default su tutti gli host, vale solo per i transport layer TCP e UDP ed è il responsabile che setta il flag DF sui pacchetti IP:

[]

Se un router cerca di inoltrare un datagram IP che ha il bit DF su di un link con una MTU più bassa, il router effettua il drop del pacchetto ed invia al mittente un messaggio (ICMP) “Destination Unreachable fragmentation needed and DF set”, indicando nello stesso messaggio anche la MTU desiderata per il next hop.

Il mittente aggiorna la sua routing table aggiungendo il valore di MTU per quella destinazione.

Durante questa fase vengono stabiliti quelli che possono essere assimilati ai termini iniziali della futura comunicazione TCP. Di seguito vengono evidenziati alcuni particolari di questa fase.

Da un'analisi della 3-way handshake si può immediatamente capire da che lato (se vicino al client o al server) è stata effettuata la cattura di un trace. Qui di seguito si vede la stessa conversazione da ambo i lati.

Il server riceve una SYN e, immediatamente dopo (18 microsecondi), invia i flag di SYN-ACK al client. Dopo poco (1 millisecondo) riceve l'ACK dal client.

Il client invia una SYN e, dopo poco (quasi 2 millisecondi), riceve il SYN-ACK dal server. Immediatamente dopo il client risponde con ACK.

Già dalla 3-way handshake si può stabilire la latenza di una rete. Nel caso di un trace effettuato dal client, dopo il SYN, c'è il SYN-ACK del server, che quindi dà un valore di latenza tra client-server prima e tra server-client poi. E' il cosiddetto iRTT (initial round trip time).

Durante la 3-way handshake, anche se non c'è scambio di dati, l'ACK viene comunque settato a 1 in entrambi i versi. Tale payload (inesistente) viene definito ghost byte:

Il MSS (Maximum Segment Size) corrisponde al payload, cioè la parte dei dati, di un segmento TCP che l'host che l'annuncia, in fase di 3-way handshake, si aspetta di ricevere. Dipende dalla MTU (Maximum Transfer Unit), cioè dal payload di un frame. Di seguito un esempio classico con un frame Ethernet:

Quindi:

Come detto, il MSS viene stabilito durante la fase di 3-way handshake, da parte di ciascuno dei due host (client e server); può essere diverso nei due casi e, anzi, solitamente lo è. Nel caso del server, che deve spedire i dati richiesti dal client, il MSS dovrebbe corrispondere alla lunghezza (Len) del payload dei segmenti TCP successivi da parte del server.

In realtà si vede che, in questo caso, il MSS è 1452:

mentre Len dallo stesso host è 1440:

Quindi il Len è inferiore di 12 bytes, come spesso capita; si spiega perchè quei 12 bytes corrispondono agli Enhanced Timestamps nelle TCP Options, che vanno a diminuire il payload TCP:

Bisogna prestare particolare attenzione a dove si effettua la capture; se la si effettua su di un host che vogliamo monitorare possono insorgere alcuni problemi. In casi come questi può succedere di vedere valori di MSS, cioè del payload TCP, di questo tipo:

Com'è possibile che ci siano questi valori doppi o tripli rispetto all'MSS di cui il server ha fatto l'advertisement, supponendo che questi abbia annunciato un MSS da 1452, che tolti i 12 byte dei timestamps, corrisponde a 1440 byte?

In questi casi entrano in gioco il TCP Segmentation Offload (TSO) (detto anche Large Send Offload) e il Large Receive Offload (LRO), che sono meccanismi che lavorano a livello di scheda di rete (NIC), quindi hardware, per sgravare la CPU dell'host nell'esecuzione di alcune operazioni TCP/IP.

Supponiamo appunto di avere un server che annuncia un MSS di 1452 byte (1440 effettivi); i pacchetti transitano sulla rete per raggiungere il client; ma passano prima dal driver della NIC di questi, che si attiva per assemblare in autonomia alcuni di questi segmenti, senza farlo fare allo stack TCP/IP dell'O.S. Ne verranno fuori dei segmenti da 2880 o 4320 byte.

Siccome Wireshark usa le librerie Pcap, che si mettono in mezzo tra NIC e stack TCP/IP, Wireshark vedrà i pacchetti solo dopo che sono stati manipolati dal driver della NIC. Quindi alcuni di questi, in Wireshark, risulteranno doppi o tripli rispetto all'MSS, grazie all'intervento del LRO

[]

Il meccanismo del TSO (TCP Segmentation Offload) / LSO (Large Send Offload) agisce nel verso opposto: supponiamo che un'applicazione (ad esempio un browser), che gira su di un host (ad es. il client in figura sopra), debba spedire uno stream di dati (un comando GET) all'applicazione sua omologa sul server (un web server).

In questi casi solitamente il TCP si preoccupa di spezzettare lo stream in segmenti TCP, ciascuno con un MSS pari a quanto stabilito dal server durante la 3-way handshake; con il TSO questo compito viene demandato alla NIC, per cui se vedessimo i pacchetti transitare in Wireshark sul client, li vedremmo più grandi del MSS.

Qui di seguito viene evidenziato lo stesso pacchetto (perchè ha lo stesso Sequence nr.) come viene catturato sull'host interessato (a sinistra) e su di un pc con Wireshark che si frappone (TAP):

A sinistra, sull'host, il pacchetto con Seq 15288403 ha una TCP Length di 5760 (perchè è intervenuto l'LRO della NIC), mentre a destra lo stesso pacchetto contiene 1440 byte, che sono quelli effettivamente spediti dal server.

La SACK (Selective Acknowledgement) è un parametro stabilito in fase di 3-way handshake. E' necessario che venga negoziato da entrambi gli host, altrimenti non viene utilizzato:

Tramite esso, a seguito di una perdita di uno o più segmenti TCP, un host può effettuare l'ACK dei segmenti ricevuti anche dopo quelli persi. Se il SACK viene usato, in presenza di una rete instabile, si avranno meno ritrasmissioni e quindi un aumento di banda.

In Wireshark le perdite di pacchetti vengono evidenziate come 'TCP Dup ACK' dal ricevente (per maggiori dettagli sul funzionamento del SACK vedi qui).

E' un buffer indipendente per l'host client o server, con dimensioni che possono variare dinamicamente nel corso di tutta la comunicazione TCP, quindi non solo durante la 3-way handshake.

Tale quantità è indipendente dal MSS.

Può essere pensato come ad un secchio, col fondo che si abbassa o si solleva, per tenere, rispettivamente, più o meno dati; ciò è fatto in funzione di quanto velocemente gli strati applicativi superiori (livelli OSI 5-7) 'pescano' i dati da esso:

Nell'immagine sopra i tubi rappresentano i valori di MSS, cioè il payload che un host può ricevere in un singolo segmento TCP. I secchi invece sono i buffer riceventi di ciascun host, che servono gli strati OSI applicativi superiori.

Se la window size si riduce fino a diventare più piccola del MSS, il server interromperà l'invio di dati al client. Di seguito è stata aggiunta una colonna custom per la Calculated window size. Si vede come questa continua a decrescere fino ad arrivare a zero:

In questa condizione il client non può più ricevere! E ci resta per più di 32 secondi (vedi time reference a sinistra)!

Andando in Statistics - TCP Stream Graphs - (tcptrace) si può ottenere un grafico in cui c'è una prima curva in alto che rappresenta la dimensione della window size e quella in basso che rappresenta i bytes inviati; tra la prima e la seconda curva dovrà sempre esserci un gap, non si dovranno mai incontrare.

Di seguito un trace in cui si vede che la window size del client si riduce progressivamente fino a raggiungere i 536 byte. Dopodichè la comunicazione si interrompe per 2,7 secondi, fino a quando il client non avvisa il server tramite due TCP Window Update:

Dopo una richiesta HTTP solitamente non segue il traffico HTTP, ma quello TCP; infatti l'HTTP si appoggia al TCP, sfruttando le sue caratteristiche per inviare stream di dati in maniera affidabile e orientata alla connessione. Il motivo è la risposta del server sarà divisa tra più segmenti TCP:

Nell'immagine sopra si vede nel segmento 28 la richiesta 'HTTP GET / HTTP/1.1' dal client e successivamente lo stream TCP dal server, con i suoi SEQ che incrementano, in funzione dei dati spediti al client. L'indicazione “TCP segment of a reassembled PDU” significa che Wireshark sa qual è il protocollo che gira sopra al TCP (è l'HTTP) e che quel segmento TCP non contiene tutto il PDU (Protocol Data Unit), dove protocol sta per il protocollo applicativo superiore HTTP.

Ad esempio, una HTTP response non sta solitamente in un singolo segmento TCP, quindi sarà divisa tra segmenti multipli, ciascuno marcato come “TCP segment of a reassembled PDU”. Nell'immagine la response HTTP ('HTTP/1.1 200 OK') è al segmento 85, ed è proprio data dal riassemblaggio dei precedenti segmenti TCP, come indicato anche da Wireshark:

[]

Questo comportamento di default si può modificare andando in Edit - Preferences… - Protocols - TCP e togliendo il flag da 'Allow subdissector to reassemble TCP stream'.

Così facendo, in una connessione HTTP, dopo una request GET si ha subito l'HTTP 200 OK, con i successivi pacchetti TCP che la compongono:

In altri casi, quando i dati da spedire sono pochi, invece dopo una request HTTP segue subito una response. Evidentemente il payload di quest'ultima sta nel MSS stabilito all'inizio:

[]

Quelle sopra infatti sono request di immagini di piccole dimensioni; le immagini si possono visualizzare così:

• espandendo la response, andando sul protocollo HTTP e facendo tasto dx sul suo payload, in questo caso un file immagine PNG:

• selezionando la voce 'Show Packet Bytes…'. Comparirà un'anteprima dell'immagine (in questo caso un quadrato nero, che è un elemento decorativo della pagina web):

che corrisponde a quanto servito dal server e che sarà anche possibile salvare.

La stessa procedura ovviamente si può seguire anche per le response HTTP riassemblate da vari segmenti TCP. Di seguito un esempio; l'immagine JPEG risultante (visibile in basso a destra) è più grossa:

Nel caso di un response HTTP 200 relativa ad un file, ad es. PDF bisognerà fare tasto destro su 'Media Type' e poi 'Export Packet Bytes…':

e salvare il file per successiva visualizzazione col programma predefinito:

Può essere utile sapere l'indicazione della provenienza geografica di un pacchetto elencato in Whireshark. Per avere questa informazione si può procedere così:

• scaricare e scompattare in una cartella i file, reperibile dal sito MaxMind, GeoLite
• configurare Wireshark perchè recuperi i file da questa cartella, andando in Edit - Preferences - Name Resolution - MaxMind database directories
• dopodichè nei dettagli IP di ogni pacchetto sarà presente un campo source GeoIP:

Spesso capita di vedere connessioni verso questi indirizzi IPv4 (e protocolli) nei trace:

In entrambi i casi si tratta di indirizzi multicast; l'IP multicast è un metodo per inviare pacchetti IP a più host in una singola trasmissione (uno-a-molti).

L'indirizzamento avviene per gruppi; gli host mittenti usano l'indirizzo di destinazione di gruppo (ad esempio 224.0.0.251) per inviare pacchetti; gli host riceventi interessati informeranno la rete che sono interessati a ricevere pacchetti inviati al gruppo 224.0.0.251. I riceventi effettuano un join al gruppo 224.0.0.251, usando anche il protocollo IGMP.

E' un servizio di DNS zero-configuration, per mappare host name e indirizzi IP. In Windows 10 viene usato per scoprire le stampanti in rete.

Il protocollo SSDP può effettuare il discover di dispositivi Plug & Play, tramite uPnP (Universal Plug and Play). Si tratta di un protocollo HTTP-like, che lavora con metodi NOTIFY e M-SEARCH.

Si può ricercare un testo all'interno di un trace così.

Cliccando sul pulsante con la lente compare una barra di ricerca:

Qui si può stabilire:

• in quale pane effettuare la ricerca: Packet list, Packet details o Packet bytes
• che tipo di ricerca effettuare: in questo caso String (il default è Display filter)
• e ovviamente cosa ricercare (“netflix”)

Il cursore si posizionerà sulla prima occorrenza nel trace.

La seguente ricerca avviene ignorando il case (quindi fornisce i risultati anche per “Pippo”, “PIPPO”, …):

frame matches "pippo"

Questo comando invece ricerca esattamente “pippo”, tenendo conto di maiuscole/minuscole:

frame contains "pippo"

Può essere utile eseguire la cattura di un trace da riga di comando, perchè ad es. Wireshark può essere sovraccarico e possono comparire errori tipo questi.

In questi casi si può usare dumpcap; l'eseguibile di strova nella directory di Wireshark. Di seguito un esempio di cattura:

dumpcap -c 100 -i Ethernet
Capturing on 'Ethernet'
File: C:\Users\carraror\AppData\Local\Temp\wireshark_Ethernet_20190822104208_a21048.pcapng
Packets captured: 100
Packets received/dropped on interface 'Ethernet': 100/0 (pcap:0/dumpcap:0/flushed:0/ps_ifdrop:0) (100.0%)

Un altro esempio in cui si stabilisce di creare un ringbuffer di 3 trace file, in cui i più vecchi vengono cancellati (in questa maniera non si satura il disco):

dumpcap -i3 -w SI-7066-trace.pcapng -b filesize:102400 -b files:3
File: SI-7066-trace_00001_20190919181518.pcapng
Packets: 127355 File: SI-7066-trace_00002_20190919181955.pcapng
Packets: 231459 File: SI-7066-trace_00003_20190919182012.pcapng
Packets: 334589 File: SI-7066-trace_00004_20190919182022.pcapng
...

Tramite dumpcap -h vengono visualizzate varie altre opzioni.

Tshark offre alcune funzionalità in più, rispetto a dumpcap.

>tshark -D
1. \Device\NPF_{85F53E5B-0751-44A4-AD59-6C44F3AA039F} (Npcap Loopback Adapter)
2. \Device\NPF_{D0D26550-D456-41ED-9E05-8E81747E530F} (Connessione alla rete locale (LAN)* 7)
3. \Device\NPF_{63E09439-4973-441A-B51E-C7750914A09F} (Connessione alla rete locale (LAN)* 6)
4. \Device\NPF_{BF7D7277-5E9A-43C1-A5F7-4A326E5DE1CD} (Ethernet)
5. \Device\NPF_{B4AC505B-8D96-46A3-AB58-4EB4C81E04F2} (Connessione alla rete locale (LAN)* 8)
6. \Device\NPF_{FBEF1017-DE34-4CE1-B24F-77F983AE5857} (VirtualBox Host-Only Network)

>tshark -i4 -w "m:\capture-tshark.pcapng"
Capturing on 'Ethernet'
9619
317 packets dropped from Ethernet

Per catturare il traffico in una rete VMware bisogna settare il Port Group del vSwitch in modalità Promiscuous:

Solitamente è una cattiva idea farlo per tutto il Port Group di produzione, perchè trasforma il vSwitch a tutti gli effetti in un Ethernet hub; è quindi possibile creare un nuovo Port Group di test con gli stessi parametri di quello di produzione e inserirvi:

• la v.m. di cui si vuole effettuare lo sniffing
• la v.m. con Wireshark

Tratto da qui.

Solo dopo aver catturato il traffico, abilitare la risoluzione dei nomi da 'View - Name Resolution - Resolve Network Addresses'.

Andare su 'Statistics - Conversations'; sulla finestra che si apre abilitare nuovamente 'Name Resolution'.

Adesso cliccando sull'intestazione 'Bytes' due volte in testa comparirà la 'conversazione' che ha utilizzato più byte:

Facendo tasto dx su di essa e poi 'Apply as a filter - Selected - A↔B' il filtro sulla finestra principale di Wireshark sarà relativo a questa conversazione, di cui si potrà analizzare il traffico.

Di default la colonna 'Time' è impostata per visualizzare i secondi dopo che è iniziata una capture. Per effettuare un'analisi conviene visualizzare il cosiddetto 'delta time', cioè la differenza di tempo rispetto al precedente pacchetto. Tale valore si può ottenere in due modi.

Si può attivare tale visualizzazione andando in 'View - Time Display Format - Seconds Since Previous Displayed Packet'; converrà quindi filtrare la conversazione con 'Analyze - Follow - TCP Stream', in modo che il pacchetto precedentemente sia relativo alla conversazione a cui siamo interessati.

Un'alternativa è quella di espandere la selezione di qualsiasi segmento TCP e selezionare 'Time since previous frame in this TCP stream':

Conviene inoltre aggiungere tale parametro come colonna (tasto dx, 'Apply as a column').

Sarà ad esempio possibile ordinare i pacchetti per questo valore e verificare se qualche TCP stream impiega troppo tempo:

[]

Per ulteriore chiarezza, conviene aggiungere anche la colonna che identifica il TCP stream, espandendo la selezione di qualsiasi segmento TCP e facendo tasto dx su '[Stream Index: x]' e 'Apply as a column'. Si avrà così un elenco degli stream nel trace.

Un tool di analisi molto potente è il tcptrace; si può eseguire da Statistics - TCP Stream Graphs - (tcptrace). Si aprirà il seguente grafico:

[]

In questo caso la direzione, come indicata dal titolo del grafico, è dal server 94.130.73.100 verso il client 192.168.64.44. Inoltre la legenda è come segue:

• riga blu in basso: byte inviati dal server
• riga beige in basso: byte di cui il client ha inviato l'acknowledge
• riga verde in alto: la Window size del client (ricevente)

Zoomando il grafico si notano diversi particolari. Di seguito alcuni esempi.

Nel grafico sopra la Windows size del ricevente è rappresentata dalla differenza tra la linea blu dei dati inviati dal server e la linea verde.

Questo zoom è effettuato all'inizio della comunicazione TCP. Dal grafico si riconosce il seguente pattern:

• il server manda (in blu) pochi pacchetti e, dopo l'ACK del client, attende un certo tempo prima di inviarne altri
• poi manda più dati e, dopo l'ACK del client, attende un tempo inferiore rispetto a prima
• poi manda ancora più dati e, dopo l'ACK del client, attende un tempo ancora inferiore
• tale pattern si ripete, fino a che le attese sostanzialmente si azzerano e il grafico cresce secondo una linea retta

Tale comportamento è voluto ed è l'implementazione del meccanismo di slow start, tramite il quale viene effettuato il controllo della congestione: un host mittente, in questa fase, verifica che il ricevente non invii pacchetti con indicazione del fatto che la sua Window size è piena e quindi tara l'invio iniziale di pacchetti, aumentandolo progressivamente.

Di seguito un grafico di un altro trace, ottenuto con iperf3, in cui è visibile lo slow start iniziale, dove vengono inviati 10 byte, poi 20, poi 40, poi circa 80 (quindi andamento esponenziale), per proseguire poi con andamento lineare:

Le due barre blu verticali corrispondono a due pacchetti inviati dal server; il client ne fa l'acknowledge cumulativo con la barra, successiva temporalmente, beige.

Cliccando sul grafico vengono visualizzati i pacchetti corrispondenti nel trace. Da qui si vede che quello che visualizza il grafico corrisponde al trace; infatti i pacchetti 156 e 157 vengono inviati dal server e ne viene effettuato l'acknowledge dal client nel pacchetto 158:

[]

Per trovare il proverbiale ago nel pagliaio è utile predisporre dei filtri ed eventualmente associarli a pulsanti, come di seguito spiegato.

Nel trace compaiono spesso righe nere con scritte rosse; si tratta di pacchetti che Wireshark vuole evidenziare, perchè potrebbero indicare problemi di perdita di pacchetti o legati alla window size.

All'inizio di un'analisi di un trace conviene evidenziarle. Si può preparare un filtro così. Digitare sulla finestra di testo intitolata 'Apply a display filter…' la stringa 'tcp.analysis.flags' e premere sul pulsante '+' a destra. Si potrà nominare questo nuovo pulsante ('Bad TCP' nell'immagine), che sarà poi possibile richiamare successivamente:

[]

Per togliere dal filtro le segnalazioni dei Keep-Alive (maggiori info su questi pacchetti sotto) si può editare il filtro non considerandoli. Il filtro 'Bad TCP' diventerà quindi:

(((tcp.analysis.flags)) && !(tcp.analysis.keep_alive)) && !(tcp.analysis.keep_alive_ack)

dando come risultato:

Conviene tenere d'occhio se il traffico TCP e HTTP supera certi valori e quindi creare filtri appositi. Ad esempio conviene creare due filtri/pulsanti che misurano 'tcp.time_delta > 1' e 'http.time > 1'; con essi vengono evidenziati ritardi superiori a 1 secondo all'interno di una comunicazione.

Per cercare una stringa in qualsiasi punto del trace digitare:

tcp contains stringa_da_cercare

Wireshark visualizzerà i pacchetti che la contengono. Ad esempio nel seguente trace viene ricercata la stringa 'admin', digitata durante un logon:

Il primo pacchetto evidenziato è un HTTP POST dal client; dovrebbe corrispondere all'input di credenziali per l'accesso ad un sito. Infatti espandendo il contenuto HTML del pacchetto si possono visualizzare lo username 'admin' e la password, solitamente codificata in base64 (che non vuol dire criptata!).

Possiamo quindi fare tasto dx sulla riga della password, e fare Copy - Value.

A volte può essere utile seguire il flusso dei SYN ed ACK, soprattutto quando bisogna analizzare problemi di banda. Si può quindi aggiungere delle colonne con questi parametri:

Di seguito viene estrapolato parte di una connessione per spiegare il meccanismo dei sequence/acknowledge:

Partendo dal pacchetto 287, l'host 192.168.64.44 invia una richiesta HTTP GET che:

• parte dal Seq (relativo, non assoluto) nr. 1
• invia 335 byte di dati (TCP Len 335)
• il suo Next Seq sarà quindi 336
• fa l'Ack del Next Seq del precedente pacchetto (286) dall'host 192.168.64.253; cioè il .44 si aspetterà di ricevere dal .253 un Next Seq pari a 1

Nel successivo pacchetto 288 l'host .253, non avendo byte da inviare al momento:

• parte dal proprio Seq 1
• non ha dati (TCP Len 0)
• quindi il prossimo Seq resterà 1
• fa l'Ack del Next Seq del precedente pacchetto (287) dall'host .44; cioè il .253 si aspetterà di ricevere dal .44 un Next Seq pari a 336

Nel successivo pacchetto 289 l'host .253 invia una HTTP Response:

• parte dal proprio Seq 1
• invia 504 byte di dati
• il suo Next Seq sarà quindi 505
• fa l'Ack del Next Seq (sempre 336) che si aspetterà dall'host .44

… e così via.

E' da evidenziare come i numeri di SYN ed ACK sono numeri relativi; è anche possibile visualizzare gli assoluti (può essere utile in fase di analisi avanzata, dove un firewall, ad es., cambia questi valori) andando in 'Edit - Preferences - Protocols - TCP' e facendo l'uncheck di 'Relative sequence numbers'.

Prima il trace:

Il pacchetto 69286 viene marcato come “TCP spurious retransmission”. Innanzitutto è da sottolineare il fatto che la capture è stata effettuata lato host 192.168.64.44; tale host aveva già ricevuto questi byte, nel pacchetto 69260. Quindi per lui si tratta di un doppione, che viene marcato come spurious retransmission.

L'host .44 ne prende atto e, nel pacchetto successivo 69287, re-invia un ACK (l'aveva già fatto nel 69260) per 5308; tale comunicazione viene sottolineata da Wireshark come “TCP Dup Ack”.

E' un problema? In questo caso no, perchè dopo la comunicazione riprende normalmente. Bisognerebbe capire lato host 52.94.240.125 cosa è successo (e quindi avere il trace lato suo); probabilmente il server non ha ricevuto un ACK per 5308 e quindi ha reinviato il segmento.

Di seguito un trace in cui compaiono dei keep-alive:

Come si vede, l'host 192.169.64.44 nel pacchetto 2714 invia 397 byte e incrementa il proprio Next Sequence nr. a 398; l'altro host ne fa l'Acknowledge (398). Fino a qui tutto ok.

Poi però passiamo al pacchetto 2766; trascorrono 10 secondi e ciò fa scattare il TCP Keep-Alive da parte dell'host .44, che consiste in

• l'host .44 non invia byte e setta il proprio Next Sequence a 397, cioè un byte di meno rispetto a prima
• l'host remoto fa l'ACK del 398 (non del 397) e questo è il TCP Keep-Alive ACK
• dopo altri 10 secondi c'è un altro scambio di TCP Keep-Alive-TCP Keep-Alive ACK
• …

Di seguito un altro esempio:

Ma a cosa serve il TCP Keep-Alive?

Ogni host periodicamente manda un pacchetto TCP di questo tipo alla sua controparte nella comunicazione per sollecitare una sua risposta (ACK). Se un host A manda un certo numero di Keep-Alive e l'host remoto B non invia l'ACK allora l'host A terminerà la connessione dal suo lato. Se l'host B alla fine manda un pacchetto riusando la vecchia connessione, l'host A invierà un reset (RST) per indicare che la vecchia connessione non è più attiva; questo forzerà l'host B a terminarla anche lato suo, in modo che una nuova connessione possa essere stabilita.

Se viene visualizzato 'TCP ACKed unseen segment' dipende probabilmente dal fatto che l'interfaccia di rete da cui si esegue il capture non è abbastanza veloce per catturare tutti i pacchetti. Non è indice quindi di un problema lato comunicazione TCP in sè, quanto piuttosto dell'host da cui si è effettuato il capture (TAP client).

Può anche essere un problema di GUI di Wireshark, che non riesce a stare dietro alla capture; in questi casi si può provare ad usare i tool a riga di comando, che sono meno pesanti dal punto di vista computazionale per l'host su cui viene eseguito Wireshark.

Di seguito un trace:

Si può notare come l'info del pacchetto 5713 dia 'TCP Out-Of-Order'; sembra proprio quello che è successo, cioè l'invio di un pacchetto fuori sequenza.

Infatti, si può vedere come, nel pacchetto 5710, l'host .41 fa l'ACK del prossimo valore che si aspetta dalla sua controparte, cioè 1269860. In realtà da essa riceve il 1271228, che viene quindi marcato come TCP previous segment not captured'; allora l'host .41 invia un Dup ACK sempre di 1269860.

Magicamente il 1269860 compare, dopo pochissimo, al 5713; non si tratta di una Retransmission, ma del fatto che il pacchetto sia rimasto 'imbottigliato' per qualche centinaio di microsecondi e abbia impiegato un po' di più ad arrivare rispetto a quello che lo avrebbe dovuto seguire. Morale: in questo caso nessun problema di cui preoccuparsi.

Di seguito parte di un trace preso tra un client e un host remoto via TAP, dopo che è stato scollegato il link verso Internet:

[]

Si vede che il client (.31) attende 7.4 secondi prima di inviare un pacchetto; si è evidentemente accorto che il server non risponde più. Poi invia una serie di pacchetti con flag PSH (Push) secondo un pattern: inizia da 230 ms, per poi attendere un tempo che che è il doppio di quello precedente e reinviare il pacchetto al server.

Alla fine manda un flag FIN per interrompere ordinatamente la connessione, ma il server non può rispondere, in quanto il cavo è scollegato. Ne rimanda un altro e, se avessimo aspettato ancora prima di chiudere il trace, avremmo visto che il client avrebbe inviato un flag RST (Reset), per interrompere del tutto la connessione e liberare così risorse.

Per farsi un'idea dei protocolli che girano sulla rete può essere utile eseguire il comando Statistics - Protocol Hierarchy:

Portare particolare attenzione se compare un generico Data; questo succede quando l'host è compromesso e su di esso girano protocolli non riconosciuti dai dissectors di Wireshark.

Andando in Statistics - IO Graphs si apre questo grafico:

Sono state aggiunte delle righe custom con display filter per alcuni IP ed è stata abilitata anche la scala logaritmica (Log scale); questo perchè tramite essa si sono potuti evidenziare i TCP errors che altrimenti sarebbero stati troppo bassi ed invisibili. Così facendo si è evidenziato la contemporaneità di errori TCP in corrispondenza del traffico verde.

Nel seguente grafico viene messo a raffronto, tramite righe con due display filter, traffico broadcast (tipicamente ARP) e tutto l'altro traffico. Il primo è nettamente minoritario:

L'interfaccia di rete wi-fi deve consentire il monitoring. Non tutti i chipset lo supportano; le schede migliori in questo campo sono le Alfa Network.

Abilitare il monitoring sulla scheda di rete così. Prima di tutto individuare il nome dell'interfaccia:

$ iwconfig 
wlx00c0ca980771  IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          
enp7s0    no wireless extensions.

lo        no wireless extensions.

Abilitare quindi il monitoring con:

# airmon-ng start wlx503eaa267e9b
Found 5 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to run 'airmon-ng check kill'

  PID Name
 1004 avahi-daemon
 1011 avahi-daemon
 1024 wpa_supplicant
 1026 NetworkManager
 1500 dhclient

PHY	Interface	Driver		Chipset

phy0	wlx00c0ca980771	ath9k_htc	Atheros Communications, Inc. AR9271 802.11n

Verificare le reti wi-fi visibili con:

# airodump-ng wlx00c0ca980771

per ottenere:

 CH  5 ][ Elapsed: 18 s ][ 2019-10-14 19:36                                         
                                                                                                                                                                                                            
 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                                                                                                                                            
 B4:A5:EF:42:15:8B  -47       65        8    0   1  54e  WPA2 CCMP   PSK  TIM-10963318                                                                                                                      
 AE:E2:D3:BD:73:61  -39       13        0    0   1  54e  WPA2 CCMP   PSK  DIRECT-61-HP OfficeJet Pro 8210                                                                                                   
 90:35:6E:86:BD:88  -77       35        1    0   6  54e  WPA2 CCMP   PSK  Vodafone-30134944                                                                                                                 
 CC:40:D0:68:5C:6F  -65       15        6    2  13  54e  WPA2 CCMP   PSK  NETGEAR01                                                                                                                         
 C4:A8:1D:39:80:EC  -81        6        0    0   6  54e  WPA2 CCMP   PSK  LANEROSSI                                                                                                                         
 60:E3:27:79:63:EC  -85        6        0    0  11  54e  WPA2 CCMP   PSK  <length:  6>                                                                                                                      
 60:31:97:0E:B9:FC  -86        5        2    0   6  54e  WPA2 CCMP   PSK  Home&Life SuperWiFi-B9FC                                                                                                          
 B0:2A:43:DB:AE:38  -88        5        0    0  11  54e. WPA2 CCMP   PSK  Googlewifi                                                                                                                        
 E0:E6:2E:49:00:E1  -87        8        0    0   8  54e. WPA2 CCMP   PSK  WebPocket-00E1                                                                                                                    
 A4:91:B1:21:E4:C7  -88        4        0    0   6  54e  WPA2 CCMP   PSK  TIM-18998471                                                                                                                      
 90:35:6E:B1:D5:28  -88        6        0    0   7  54e  WPA2 CCMP   PSK  Vodafone-30340170                                                                                                                 
 E4:8F:34:C1:8A:CE  -87        3        0    0   5  54e  OPN              Vodafone-WiFi                                                                                                                      
 E4:8F:34:C1:8A:CC  -88        4        0    0   5  54e  WPA2 CCMP   PSK  Vodafone-44848483                                                                                                                  
 C8:3A:35:FE:0C:30  -90        2        0    0   7  54e  WPA  CCMP   PSK  Telemar_WiFi                                                                                                                       
 00:1E:2A:F6:41:7A  -90        6        0    0  11  54e  WPA  TKIP   PSK  INTERNET                                                                                                                           
 30:91:8F:4F:34:EC  -91        3        0    0  11  54e  WPA2 CCMP   PSK  Telecom-56849132                                                                                                                   
                                                                                                                                                                                                             
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe                                                                                                                                   
                                                                                                                                                                                                             
 (not associated)   DA:A1:19:95:85:42  -69    0 - 1     17       19                                                                                                                                          
 (not associated)   44:07:0B:5D:56:90  -84    0 - 1      0        4  Googlewifi                                                                                                                              
 B4:A5:EF:42:15:8B  00:04:20:2B:1F:A9  -56   36e- 1e     0        9  TIM-10963318                                                                                                                            
 CC:40:D0:68:5C:6F  D4:11:A3:58:F7:A7   -1    0e- 0      0        6                 

Ci interessa la prima rete, quindi rilanciamo il comando con i seguenti parametri:

# airodump-ng -c 1 -w wpa2 --bssid B4:A5:EF:42:15:8B wlx00c0ca980771

Riavviando un client si dovrebbe riuscire ad ottenere la WPA handshake (in alto a destra):

 CH  1 ][ Elapsed: 1 min ][ 2019-10-14 19:41 ][ WPA handshake: B4:A5:EF:42:15:8B                     
                                                                                                     
 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                                     
 B4:A5:EF:42:15:8B  -13   0      876     1639   33   1  54e  WPA2 CCMP   PSK  TIM-10963318           
                                                                                                     
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe                           
                                                                                                     
 B4:A5:EF:42:15:8B  54:25:EA:59:27:F3  -37    0e- 0e   539      680                                   
 B4:A5:EF:42:15:8B  AC:E2:D3:BD:F3:61  -37    0e- 0e     0       28                                   
 B4:A5:EF:42:15:8B  A8:0C:63:1E:CF:20  -56    1e- 6      0      275                                   
 B4:A5:EF:42:15:8B  A8:0C:63:1E:C9:E9  -59    0e- 6    189      559                                   
 B4:A5:EF:42:15:8B  00:04:20:2B:1F:A9  -73   24e-54e     0       88                              

Ciò significa che si è catturato una four-stage handshake.

Il tool dovrebbe quindi generare un file wpa2-01.cap, che può essere aperto da Wireshark; verificare che sia presente la four-stage handshake usando il seguente filtro:

Per visualizzare il traffico è necessario inserire la password WPA, andando su di un frame 802.11 e facendo tasto dx-Protocol Preferences-Decryption keys….

Bisongerà quindi aggiungere una chiave WPA-Pwd, specificando la password wi-fi così: <password wifi>:<nome rete>.

Dopodichè si potrà decodificare il traffico in Wireshark.