Slik leser du en fersk IKE_SA_INIT-utveksling i et opptak

Start med et opptak som begynner før den første pakken i forsøket, ellers leser du midten av en samtale. En forhandling som allerede går, viser krypterte utvekslinger og nøkkelfornyelser, og ingen av dem ser ut som åpningen. Åpningen er den delen du kan dekode uten nøkler, og derfor svarer den så godt på tilgjengelighetsspørsmål. Fire kontroller i rekkefølge tar deg fra et ferskt opptak til en forsvarlig påstand om hvilken side som sluttet å snakke.

Først, bekreft at opptaket begynner ved begynnelsen

Et opptak startet etter at tunnelen kom opp, vil inneholde den innkapslede datastrømmen og periodiske keepalives, og begge er enten krypterte eller nesten tomme. Start klienten på nytt og ta opp selve forsøket, eller utløs bevisst en ny tilkobling mens opptaket kjører. Hvis du ikke kan produsere et ferskt forsøk, skriv det i notatene dine, for ingen dekoding gjenoppretter en åpning du aldri tok opp.

Begrens opptaket til de to endepunktene og til UDP 500 og 4500, slik at filen holder seg liten nok til å leses. På en travel vert begraver et ufiltrert opptak forhandlingen under urelatert trafikk.

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

Ta vare på filen når forsøket er interessant, for det samme opptaket svarer på begge de følgende spørsmålene: hva utvekslingen var, og om noe kom tilbake. Merk det med starttiden og endepunktparet du filtrerte på. Et opptak uten disse to fakta er ubrukelig en uke senere, når adressene er endret og ingen husker hvilket forsøk det tok opp.

Deretter, les hodet før nyttelastene

IKE-hodet bærer sikkerhetsparameterindeksene, utvekslingstypen og meldings-ID-en, og ved en ny forhandling er disse verdiene særegne. Initiativtakeren finner opp en SPI ulik null, den første forespørselen bærer en responder-SPI på null fordi ingen svar er sett ennå, utvekslingstypen er IKE_SA_INIT, og meldings-ID-en er null. Alt annet hører til et senere trinn i samme forhandling eller til et helt annet forsøk.

Forslags-, nøkkelutvekslings- og nonce-nyttelastene i denne første utvekslingen er lesbare i klartekst. Lesbar er ikke det samme som autentisert, og på dette tidspunktet har ingen av partene bevist identiteten sin.

Den private Diffie-Hellman-verdien krysser aldri ledningen, så opptaket lar deg ikke utlede sesjonsnøkler. Autentiseringen skjer i den neste utvekslingen, beskyttet av det den første forhandlet frem. Hvis noen spør om en part er ekte, kan denne utvekslingen ikke svare på det spørsmålet. Den kan bare vise at begge sider ble enige om et forslag og produserte en felles hemmelighet som filen ikke inneholder.

Tredje, koble forespørselen til svaret

Koble på SPI-paret, utvekslingstypen og meldings-ID-en, og kontroller deretter svarflagget. En retransmisjon gjentar meldings-ID-en til originalen og er ikke et andre innloggingsforsøk. Å telle pakker i stedet for utvekslinger er måten en sunn forhandling blir en fantomløkke.

Et svar kan også være en avvisning: en cookie-forespørsel, en melding om en uakseptabel gruppe eller en feil om et forslag. Det er legitime svar, og de betyr at veien virker mens policyen ikke gjør det. Dekod meldingen i stedet for å behandle hvert svar som en suksess. Når meldingen nevner en gruppe eller et forslag, er rettelsen på konfigurasjonssiden og ikke ved brannmuren.

Retningen betyr også noe. En forespørsel uten svar og et svar som aldri når klienten, er forskjellige feil, og bare det andre ser ut som en tidsavbrudd på klientsiden.

Fjerde, skill IKE fra alt annet på 4500

Port 4500 bærer tre ting som ser like ut i en oversikt: IKE bak en fire-byte null-non-ESP-markør, innkapslet ESP der markørposisjonen holder en SPI ulik null, og korte keepalives. Det er markøren som skiller IKE fra innkapslet ESP, så les de bytene før du kaller trafikken IKE. En opptaksmerkelapp som leser 4500, er et portnummer og ikke en protokoll.

Innkapslet ESP er kryptert nyttelast du ikke kan tolke uten nøkler, og tilstedeværelsen kan være tegnet på en fungerende tunnel snarere enn en feil.

Følg med på begge portene for det samme forsøket, for IKE kan flytte til 4500 etter NAT-deteksjon selv om det åpnet på 500. Et spor filtrert bare på 500 ser tyst ut nettopp når forhandlingen lyktes og flyttet seg. Utvid filteret og les det samme tidsvinduet på nytt før du trekker noen konklusjon av fravær.

Hva taushet på ett observasjonspunkt betyr

Uten svar hos klienten beviser bare det punktet observerte. Filtrering, ruting, feil fjernadresse, en tjeneste som er nede og en protokollavvik gir alle det samme tomme sporet.

En relevant ICMP unreachable tilfører bevis, men les den siterte pakken inni den og noter adressen til enheten som sendte den.

En ruteres avvisning er en annen hendelse enn en autentisert feil som parten returnerer, og bare den andre beviser at tjenesten lever. Korreler det samme forsøket med serverlogger eller en godkjent observasjon for å vite om forespørselen kom og om et svar gikk ut. Hold opptak begrenset og private, for lesbare håndtrykksfelt gjør ikke resten av filen ufarlig. Resultatet som er verdt å ha, er ett paret forespørsel og svar, eller ett dokumentert hull med et navngitt observasjonspunkt.