Så läser du ett färskt IKE_SA_INIT-utbyte i en inspelning

Börja med en inspelning som börjar före försökets första paket, annars läser du mitten av ett samtal. En förhandling som redan pågår visar krypterade utbyten och nyckelbyten, och ingen av dem ser ut som öppningen. Öppningen är den del du kan avkoda utan nycklar, och därför svarar den så bra på tillgänglighetsfrågor. Fyra kontroller i ordning tar dig från en färsk inspelning till ett försvarbart påstående om vilken sida som slutade prata.

Först, bekräfta att inspelningen börjar vid början

En inspelning som startats efter att tunneln kom upp innehåller den inkapslade dataströmmen och periodiska keepalives, och båda är antingen krypterade eller nästan tomma. Starta om klienten och spela in själva försöket, eller framkalla medvetet en ny anslutning medan inspelningen pågår. Om du inte kan producera ett färskt försök, skriv det i dina anteckningar, för ingen avkodning återställer en öppning du aldrig spelade in.

Begränsa inspelningen till de två ändpunkterna och till UDP 500 och 4500 så att filen förblir liten nog att läsa. På en upptagen värd begraver en ofiltrerad inspelning förhandlingen under orelaterad trafik.

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

Spara filen när försöket är intressant, för samma inspelning svarar på båda följande frågor: vad utbytet var, och om något kom tillbaka. Märk den med starttiden och det ändpunktspar du filtrerade på. En inspelning utan dessa två fakta är värdelös en vecka senare, när adresserna har ändrats och ingen minns vilket försök den spelade in.

Sedan, läs huvudet före nyttolasterna

IKE-huvudet bär säkerhetsparameterindexen, utbytets typ och meddelande-ID:t, och vid en ny förhandling är dessa värden särskiljande. Initiativtagaren hittar på en SPI som inte är noll, den första begäran bär en svarande-SPI på noll eftersom inget svar ännu setts, utbytets typ är IKE_SA_INIT, och meddelande-ID:t är noll. Allt annat hör till ett senare skede av samma förhandling eller till ett helt annat försök.

Förslags-, nyckelutbytes- och nonce-nyttolasterna i detta första utbyte är läsbara i klartext. Läsbar är inte detsamma som autentiserad, och vid denna punkt har ingen av parterna bevisat sin identitet.

Det privata Diffie-Hellman-värdet korsar aldrig ledningen, så inspelningen låter dig inte härleda sessionsnycklar. Autentiseringen sker i nästa utbyte, skyddad av det som det första förhandlade fram. Om någon frågar om en part är äkta kan detta utbyte inte svara på den frågan. Det kan bara visa att båda sidor enades om ett förslag och producerade en gemensam hemlighet som filen inte innehåller.

Tredje, koppla begäran till dess svar

Koppla på SPI-paret, utbytets typ och meddelande-ID:t, kontrollera sedan svarsflaggan. En omsändning upprepar originalets meddelande-ID och är inte ett andra inloggningsförsök. Att räkna paket i stället för utbyten är hur en frisk förhandling blir en fantomslinga.

Ett svar kan också vara en avvisning: en cookie-begäran, ett meddelande om en oacceptabel grupp eller ett fel om ett förslag. Det är legitima svar, och de betyder att vägen fungerar medan policyn inte gör det. Avkoda meddelandet i stället för att behandla varje svar som en framgång. När meddelandet namnger en grupp eller ett förslag ligger rättelsen på konfigurationssidan och inte vid brandväggen.

Riktningen spelar också roll. En begäran utan svar och ett svar som aldrig når klienten är olika fel, och bara det andra ser ut som en tidsgräns på klientsidan.

Fjärde, skilj IKE från allt annat på 4500

Port 4500 bär tre saker som ser likadana ut i en översikt: IKE bakom en fyra byte lång noll-non-ESP-markör, inkapslad ESP vars markörposition håller en SPI som inte är noll, och korta keepalives. Det är markören som skiljer IKE från inkapslad ESP, så läs de byten innan du kallar trafiken IKE. En inspelningsetikett som läser 4500 är ett portnummer, inte ett protokoll.

Inkapslad ESP är krypterad nyttolast som du inte kan tolka utan nycklar, och dess närvaro kan vara tecknet på en fungerande tunnel snarare än på ett fel.

Håll koll på båda portarna för samma försök, för IKE kan flytta till 4500 efter NAT-upptäckt även om det öppnades på 500. Ett spår som filtrerats bara på 500 ser tyst ut just när förhandlingen lyckades och flyttade. Bredda filtret och läs om samma tidsfönster innan du drar någon slutsats av frånvaron.

Vad tystnad vid en observationspunkt betyder

Inget svar hos klienten bevisar bara vad den punkten observerade. Filtrering, routning, fel fjärradress, en tjänst som ligger nere och en protokollavvikelse ger alla samma tomma spår.

En relevant ICMP unreachable tillför bevis, men läs det citerade paketet inuti den och notera adressen till enheten som skickade den.

En routers avvisning är en annan händelse än ett autentiserat fel som parten returnerar, och bara det andra bevisar att tjänsten lever. Korrelera samma försök med serverloggar eller en godkänd observation för att veta om begäran kom fram och om ett svar gick ut. Håll inspelningar begränsade och privata, för läsbara handskakningsfält gör inte resten av filen ofarlig. Det resultat som är värt att ha är ett parat par av begäran och svar, eller en dokumenterad lucka med en namngiven observationspunkt.