Gli errori di checksum PCAP non sono sempre pacchetti errati: comprendere le prove di offload

Le acquisizioni di pacchetti spesso mostrano errori di checksum TCP, UDP o IP. A volte questi errori significano vera corruzione. A volte significano che l'acquisizione è stata eseguita prima che l'adattatore di rete compilasse il checksum. Se gli ingegneri trattano ogni avviso di checksum come un pacchetto danneggiato, possono individuare il problema sbagliato o riscrivere prove valide.

L'offload del checksum è una delle fonti più comuni di interpretazione PCAP fuorviante.

Perché Offload crea acquisizioni confuse

I moderni adattatori di rete possono calcolare i checksum nell'hardware. Il sistema operativo può consegnare un pacchetto all'adattatore con campi checksum segnaposto. Se l'acquisizione avviene prima del completamento dell'hardware, il PCAP può mostrare un checksum non valido anche se il pacchetto inserito nella rete era corretto.

Ciò è particolarmente comune nelle acquisizioni in uscita locali. Il file di acquisizione registra ciò che l'host ha preparato, non necessariamente l'esatta immagine finale del cavo dopo lo scaricamento.

Chiedi dove è stato catturato il pacchetto

L'interpretazione del checksum dipende dalla posizione di cattura:

• catturato sull'host mittente prima dello scaricamento della scheda NIC
• catturato su una porta mirror o toccare dopo la trasmissione
• catturato sull'host ricevente
• catturato all'interno di una VM o di un contenitore
• catturato su un adattatore virtuale

Un avviso di checksum in uscita sul mittente non è la stessa cosa di un errore di checksum osservato su un tocco indipendente. Il punto di cattura fa parte delle prove.

Non riscrivere i checksum troppo presto

Potrebbe essere forte la tentazione di ricalcolare immediatamente i checksum. Ciò può rendere gli strumenti a valle più silenziosi, ma cambia anche le prove. Prima della modifica, decidi a quale domanda deve rispondere l'acquisizione.

Se l'obiettivo è il debug a livello di applicazione, il ricalcolo dei checksum per la leggibilità può essere accettabile se chiaramente documentato. Se l’obiettivo è dimostrare la corruzione telematica, la riscrittura dei checksum può cancellare proprio le prove sotto indagine.

Un flusso di lavoro controllato registra:

• quali campi del checksum sono stati contrassegnati
• direzione del pacchetto
• punto di cattura
• se è probabile lo scarico
• se il file di output ha riscritto i byte del checksum
• quali pacchetti sono cambiati

La modifica dovrebbe essere deliberata, non automatica.

Distinguere l'offload dalla vera corruzione

Segni che potrebbero essere coinvolti l'offload del checksum:

• per lo più pacchetti in uscita sull'host di acquisizione
• molti checksum contrassegnati in uno schema coerente
• il traffico funziona nonostante gli avvisi
• il punto di cattura indipendente non mostra gli stessi errori
• ambiente virtualizzato o con carichi pesanti

Segni che potrebbero essere coinvolti casi di vera corruzione:

• cadute lato ricevitore
• il tocco indipendente conferma i checksum non validi
• la perdita o la ritrasmissione di pacchetti è in linea con gli errori di checksum
• gli errori compaiono in entrambe le direzioni senza una spiegazione di offload
• il livello di collegamento o l'hardware di acquisizione segnalano errori

Il punto non è ignorare gli avvisi di checksum. Il punto è interpretarli nel contesto.

Dove si adatta la chirurgia PCAP

PCAP Surgery è progettato per il lavoro di acquisizione di pacchetti basato sull'evidenza. Dovrebbe aiutare gli ingegneri a ispezionare i metadati dei pacchetti, capire perché un'acquisizione sembra sbagliata e applicare operazioni di riscrittura controllata solo quando sono giustificate.

Per i casi di checksum, il confine del prodotto è importante. Non dovrebbe "correggere" silenziosamente le acquisizioni e far finta che nulla sia cambiato. Un utile strumento chirurgico spiega:

• origine dell'avviso di checksum
• probabilmente scaricare il contesto
• set di pacchetti interessato
• valori prima e dopo la riscrittura
• se il cambiamento è normalizzazione o riparazione

Ciò offre agli ingegneri del protocollo un'acquisizione che possono difendere, non solo un file che si apre silenziosamente.