Come leggere uno scambio IKE_SA_INIT nuovo in una cattura

Partite da una cattura che cominci prima del primo pacchetto del tentativo, altrimenti leggerete la metà di una conversazione. Una trattativa già in corso mostra scambi cifrati e rinnovi di chiavi, e nessuno dei due somiglia all’apertura. L’apertura è la parte che potete decodificare senza chiavi, ed è per questo che risponde così bene alle domande di raggiungibilità. Quattro controlli in ordine vi portano da una cattura fresca a un’affermazione difendibile su quale lato ha smesso di parlare.

Primo, verificate che la cattura inizi dall’inizio

Una cattura avviata dopo l’attivazione del tunnel conterrà il flusso di dati incapsulato e keepalive periodici, ed entrambi sono cifrati o quasi vuoti. Riavviate il client e registrate il tentativo stesso, oppure provocate deliberatamente una nuova connessione mentre la cattura è in corso. Se non riuscite a produrre un tentativo fresco, scrivetelo nelle vostre note, perché nessuna decodifica recupera un’apertura che non avete mai registrato.

Limitate la cattura ai due endpoint e a UDP 500 e 4500 perché il file resti abbastanza piccolo da leggere. Su un host occupato una cattura senza filtro seppellisce la trattativa sotto traffico estraneo.

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

Conservate il file quando il tentativo è interessante, perché la stessa cattura risponde a entrambe le domande seguenti: che cos’era lo scambio, e se è tornato qualcosa. Etichettatelo con l’ora di inizio e la coppia di endpoint su cui avete filtrato. Una cattura senza questi due fatti è inutile una settimana dopo, quando gli indirizzi sono cambiati e nessuno ricorda quale tentativo abbia registrato.

Secondo, leggete l’intestazione prima dei payload

L’intestazione IKE porta gli indici dei parametri di sicurezza, il tipo di scambio e l’ID del messaggio, e in una trattativa nuova questi valori sono distintivi. L’iniziatore inventa uno SPI diverso da zero, la richiesta iniziale porta uno SPI del risponditore pari a zero perché non è ancora stata vista alcuna risposta, il tipo di scambio è IKE_SA_INIT e l’ID del messaggio è zero. Tutto il resto appartiene a una fase successiva della stessa trattativa o a un tentativo del tutto diverso.

I payload di proposta, scambio di chiavi e nonce di questo primo scambio sono leggibili in chiaro. Leggibile non significa autenticato, e a questo punto nessuna delle due parti ha dimostrato la propria identità.

Il valore privato Diffie-Hellman non attraversa mai il cavo, quindi la cattura non vi permette di derivare chiavi di sessione. L’autenticazione avviene nello scambio successivo, protetta da ciò che il primo ha negoziato. Se qualcuno chiede se una parte è autentica, questo scambio non può rispondere a quella domanda. Può solo mostrare che entrambi i lati hanno concordato una proposta e prodotto un segreto condiviso che il file non contiene.

Terzo, abbinate la richiesta alla sua risposta

Abbinate sulla coppia di SPI, sul tipo di scambio e sull’ID del messaggio, poi controllate il flag di risposta. Una ritrasmissione ripete l’ID del messaggio dell’originale e non è un secondo tentativo di accesso. Contare i pacchetti invece degli scambi è il modo in cui una trattativa sana diventa un ciclo fantasma.

Una risposta può anche essere un rifiuto: una richiesta di cookie, una notifica di gruppo inaccettabile o un errore su una proposta. Sono risposte legittime, e significano che il percorso funziona mentre la politica no. Decodificate la notifica invece di trattare ogni risposta come un successo. Quando la notifica nomina un gruppo o una proposta, la riparazione è sul lato della configurazione e non sul firewall.

Anche la direzione conta. Una richiesta senza risposta e una risposta che non raggiunge mai il client sono guasti diversi, e solo la seconda sembra un timeout lato client.

Quarto, separate IKE da tutto il resto sulla 4500

La porta 4500 porta tre cose che in una vista sintetica sembrano uguali: IKE dietro un marcatore non-ESP nullo di quattro byte, ESP incapsulato la cui posizione del marcatore contiene uno SPI diverso da zero, e keepalive brevi. È quel marcatore a separare IKE dall’ESP incapsulato, quindi leggete quei byte prima di etichettare il traffico come IKE. Un’etichetta di cattura che legge 4500 è un numero di porta, non un protocollo.

L’ESP incapsulato è payload cifrato che non potete interpretare senza chiavi, e la sua presenza può essere il segno di un tunnel funzionante più che di un guasto.

Osservate entrambe le porte per lo stesso tentativo, perché IKE può spostarsi sulla 4500 dopo il rilevamento NAT anche se si è aperto sulla 500. Una traccia filtrata solo sulla 500 sembra silenziosa proprio quando la trattativa è riuscita e si è spostata. Allargate il filtro e rileggete la stessa finestra temporale prima di trarre qualsiasi conclusione dall’assenza.

Che cosa significa il silenzio in un punto di osservazione

Nessuna risposta presso il client dimostra solo ciò che quel punto ha osservato. Il filtraggio, l’instradamento, l’indirizzo remoto sbagliato, un servizio spento e una discrepanza di protocollo producono tutti la stessa traccia vuota.

Un ICMP unreachable pertinente aggiunge una prova, ma leggete il pacchetto citato al suo interno e annotate l’indirizzo del dispositivo che lo ha inviato.

Il rifiuto di un router è un evento diverso da un errore autenticato restituito dalla parte, e solo il secondo dimostra che il servizio è vivo. Correlate lo stesso tentativo con i log del server o con un’osservazione approvata per sapere se la richiesta è arrivata e se una risposta è uscita. Mantenete le catture limitate e private, perché i campi leggibili dell’handshake non rendono innocuo il resto del file. Il risultato che vale la pena è una richiesta e una risposta abbinate, oppure una lacuna documentata con un punto di osservazione nominato.