Wireshark è il posto dove una cattura presa sul gateway diventa una diagnosi. È anche il posto dove è più facile ingannarsi, perché l’interfaccia grafica aggiunge alla cattura due cose che nella cattura non ci sono: un colore e un’interpretazione.

Le regole di colorazione, e perché la prima vince

Il colore di una riga nell’elenco pacchetti non è una proprietà del pacchetto: è il risultato della prima regola di colorazione che lo intercetta. Le regole permanenti si gestiscono in View, voce Coloring Rules: la finestra permette di aggiungerne, eliminarne e duplicarne, di rinominarle e modificarne il filtro con un doppio clic, e di scegliere colore di primo piano e di sfondo.

L’ordine è la parte che conta. Vale la prima corrispondenza, quindi le regole specifiche vanno sopra quelle generiche: una regola per DNS messa sotto quella per UDP non colorerà mai niente, perché il DNS viaggia su UDP e la regola generica lo cattura prima. Esistono anche regole temporanee, che valgono solo per la sessione in corso: si creano con Ctrl e un numero su un pacchetto selezionato, oppure dal menu contestuale con Colorize with Filter. Dal menu View si accende e si spegne la colorazione dell’elenco: quando un colore non torna, spegnere tutto e guardare i campi è spesso la mossa più rapida.

Salvare e consegnare: la metodologia dei file

Il formato nativo di Wireshark è pcapng, successore estensibile del vecchio libpcap e predefinito da tempo. Wireshark legge anche pcap (quello che producono tcpdump e cppcap) e il formato snoop di Oracle, che è esattamente quello che scrive fw monitor con l’opzione di salvataggio su file: la cattura ai punti di ispezione si apre quindi senza conversioni.

Da qui discende la metodologia. Salva la cattura nel formato che conserva ciò che ti serve: passando da pcapng a un altro formato si perdono informazioni come i commenti, la risoluzione dei nomi e la risoluzione del timestamp. File, voce Save As, salva tutto; Export Specified Packets salva solo un sottoinsieme, per esempio i pacchetti marcati o un intervallo, ed è il modo giusto per consegnare a un collega dieci pacchetti invece di un file da due gigabyte. Quando le catture sono più di una (due interfacce, due punti della catena, oppure i file ruotati da una cattura con rotazione attiva) usa File, voce Merge, che offre tre modi: anteporre i pacchetti, unirli in ordine cronologico, accodarli. Il trascinamento di più file sulla finestra unisce in ordine cronologico, e da riga di comando mergecap è l’opzione più ricca. Attenzione però agli orologi: unire cronologicamente catture prese su macchine non sincronizzate produce una sequenza plausibile e falsa.

Analizzare: filtri, flussi, Expert Information

Il filtro di visualizzazione è lo strumento principale, e non si scrive a memoria: dal pacchetto si usa Apply as Filter sul campo che interessa e poi si modifica l’espressione nella barra. Find Packet cerca dentro i byte o i campi; marcare i pacchetti interessanti serve poi all’esportazione selettiva. Follow Stream ricompone la conversazione applicativa e riscrive il filtro su quel flusso solo.

Per il quadro d’insieme c’è il menu Statistics: Protocol Hierarchy dice di che cosa è fatto il traffico, Conversations ed Endpoints ordinano per volume, Flow Graph disegna la sequenza degli scambi, IO Graphs mostra la forma nel tempo. Expert Information raccoglie ciò che Wireshark ha giudicato anomalo, e l’analisi TCP segnala ritrasmissioni, ACK duplicati e finestre a zero: sono indizi forti, ma restano interpretazioni del dissector. L’esempio classico sono gli errori di checksum, che su una cattura presa sulla macchina che trasmette sono quasi sempre l’effetto del checksum offloading della scheda di rete, non un pacchetto corrotto.

Trappole tipiche d’esame

  • Salvare la cattura in un formato che non conserva i punti di ispezione. Una cattura presa ai punti di ispezione e salvata come snoop mostra in Wireshark lo stesso pacchetto più volte, una riga per punto attraversato, ed è quella ripetizione a permettere il confronto. Una cattura presa sull’interfaccia non contiene quell’informazione e nessun formato di salvataggio gliela restituisce: se esporti solo i pacchetti visualizzati dopo un filtro stretto, puoi buttare via proprio i punti che servivano al confronto.
  • Fidarsi del colore invece che del contenuto. Le regole di colorazione sono configurazione dell’utente, valutate a prima corrispondenza: una regola aggiunta da qualcun altro può oscurare quella standard, e una riga rossa può essere solo checksum offloading. Prima di rispondere apri il pacchetto e leggi i campi; il colore è un suggerimento, non una prova.
  • Analizzare una cattura di interfaccia credendo che mostri l’effetto delle regole. Sull’interfaccia vedi ciò che è arrivato e ciò che è partito, non ciò che il gateway ha deciso. Un pacchetto presente nella cattura di ingresso e assente in quella di uscita dice soltanto che non è uscito da lì: quale regola lo abbia scartato si legge nei log, e a quale passo dell’ispezione si perda si vede solo confrontando i punti i, I, o e O.