Problemi di timestamp PCAP: quando controllare, normalizzare o riscrivere il tempo di acquisizione

I timestamp fanno parte della prova nell'acquisizione di un pacchetto. Spiegano l'ordine, la latenza, i tempi di ritrasmissione, le lacune tra richiesta e risposta e se un problema corrisponde a un registro dell'applicazione. Quando i timestamp sono errati, l’intera indagine può andare alla deriva.

Ma la riparazione del timestamp è delicata. La modifica dell'ora di acquisizione può semplificare l'analisi e allo stesso tempo rendere il file meno fedele all'evento originale.

Problemi comuni di timestamp

I problemi relativi al timestamp PCAP includono:

• i pacchetti appaiono fuori ordine
• i timestamp saltano indietro
• i timestamp sono tutti zero
• la risoluzione è inferiore al previsto
• l'acquisizione abbraccia un intervallo di tempo impossibile
• L'orologio della VM o dell'host cambia durante l'acquisizione
• le acquisizioni unite utilizzano orologi diversi
• le ipotesi sul fuso orario confondono i rapporti umani

Alcuni di questi sono problemi di visualizzazione. Alcuni sono problemi di acquisizione. Alcuni sono problemi di unione. La strategia di riparazione dipende da quale sia.

Ordine separato dal significato dell'orologio da parete

L'ordine dei pacchetti e l'orario dell'orologio da parete sono correlati ma non identici. Un'acquisizione può preservare l'ordine dei pacchetti mantenendo valori inutili. Un'altra acquisizione può avere valori di clock plausibili ma includere flussi uniti da diversi punti di acquisizione che rendono pericolosi i confronti temporali.

Prima di riscrivere i timestamp, chiedi:

• l'ordine dei pacchetti è affidabile?
• la tempistica relativa è affidabile?
• è necessario il tempo assoluto dell'orologio da parete?
• l'acquisizione è unita da più fonti?
• i log dell'applicazione forniscono un ancoraggio esterno?
• gli strumenti downstream interpreteranno erroneamente i timestamp attuali?

Tali domande determinano se l'ispezione, l'annotazione, la normalizzazione o la riscrittura sono appropriate.

Quando la normalizzazione aiuta

La normalizzazione del timestamp può essere utile quando l'ora assoluta originale non è importante, ma lo sono l'ordine relativo e la spaziatura. Ad esempio, un'acquisizione lab con un orologio di sistema errato potrebbe comunque mostrare tempi di richiesta-risposta validi. La normalizzazione dell'ora di inizio può rendere i report più facili da leggere senza modificare il comportamento relativo.

L'output dovrebbe registrare:

• primo timestamp originale
• primo timestamp normalizzato
• se i delta sono stati preservati
• pacchetti interessati
• motivo della normalizzazione

Senza quella registrazione, un futuro ingegnere non potrà dire se le prove temporali siano originali o modificate.

Quando riscrivere è rischioso

Riscrivere i timestamp è rischioso quando l'acquisizione deve essere correlata con:

• registri del server
• registri della fotocamera
• Tracce USB o seriali
• tempistiche degli incidenti
• prove legali o di conformità
• acquisizioni di rete multipunto

In questi casi, la modifica dei timestamp può rendere il file più facile da ispezionare ma più difficile da fidarsi. Un primo passo migliore potrebbe essere l'annotazione: documentare il problema dell'orologio e lasciare intatta l'acquisizione non elaborata.

Dove si adatta la chirurgia PCAP

La PCAP Surgery si basa su modifiche controllate, non su mutazioni casuali. Il lavoro sul timestamp dovrebbe seguire la stessa regola del checksum o del packet trimming: prima ispezionare, poi decidere, riscrivere solo quando le prove lo supportano.

Un buon flusso di lavoro chirurgico PCAP dovrebbe aiutare a rispondere a:

• quale anomalia di timestamp esiste?
• quanti pacchetti sono interessati?
• l'ordine è ancora affidabile?
• il timing relativo è ancora utile?
• quale riscrittura o normalizzazione è stata applicata?
• è possibile riprodurre il cambiamento?

Per gli ingegneri del protocollo, il valore non sta semplicemente nel modificare un file. Il valore sta producendo un'acquisizione e una traccia di ragionamento che un altro ingegnere può convalidare.