Zo leest u een verse IKE_SA_INIT-uitwisseling in een opname

Begin met een opname die begint vóór het eerste pakket van de poging, anders leest u het midden van een gesprek. Een onderhandeling die al loopt, toont versleutelde uitwisselingen en sleutelvernieuwingen, en geen van beide lijkt op de opening. De opening is het deel dat u zonder sleutels kunt decoderen, en daarom beantwoordt het bereikbaarheidsvragen zo goed. Vier controles in volgorde brengen u van een verse opname naar een verdedigbare uitspraak over welke kant ophield met praten.

Ten eerste, bevestig dat de opname bij het begin begint

Een opname die is gestart nadat de tunnel opkwam, bevat de ingekapselde datastroom en periodieke keepalives, en beide zijn ofwel versleuteld ofwel bijna leeg. Herstart de client en leg de poging zelf vast, of lok bewust een nieuwe verbinding uit terwijl de opname loopt. Als u geen verse poging kunt produceren, noteer dat dan, want geen enkele decodering haalt een opening terug die u nooit hebt vastgelegd.

Beperk de opname tot de twee eindpunten en tot UDP 500 en 4500 zodat het bestand klein genoeg blijft om te lezen. Op een drukke host begraaft een ongefilterde opname de onderhandeling onder ongerelateerd verkeer.

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

Bewaar het bestand als de poging interessant is, want dezelfde opname beantwoordt beide volgende vragen: wat de uitwisseling was, en of er iets terugkwam. Label het met de starttijd en het eindpuntpaar waarop u hebt gefilterd. Een opname zonder die twee feiten is een week later nutteloos, wanneer de adressen zijn veranderd en niemand meer weet welke poging is vastgelegd.

Ten tweede, lees de kop vóór de payloads

De IKE-kop draagt de beveiligingsparameter-indexen, het uitwisselingstype en de bericht-ID, en bij een nieuwe onderhandeling zijn die waarden kenmerkend. De initiator verzint een SPI die niet nul is, het eerste verzoek draagt een responder-SPI van nul omdat er nog geen antwoord is gezien, het uitwisselingstype is IKE_SA_INIT, en de bericht-ID is nul. Al het andere hoort bij een latere fase van dezelfde onderhandeling of bij een heel andere poging.

De proposal-, sleuteluitwisselings- en nonce-payloads in deze eerste uitwisseling zijn leesbaar in de open lucht. Leesbaar is niet hetzelfde als geauthenticeerd, en op dit punt heeft geen van beide partijen zijn identiteit bewezen.

De private Diffie-Hellman-waarde steekt nooit de draad over, dus de opname laat u geen sessiesleutels afleiden. De authenticatie gebeurt in de volgende uitwisseling, beschermd door wat de eerste heeft onderhandeld. Als iemand vraagt of een partij echt is, kan deze uitwisseling die vraag niet beantwoorden. Hij kan alleen laten zien dat beide kanten het eens werden over een voorstel en een gedeeld geheim hebben gemaakt dat het bestand niet bevat.

Ten derde, koppel het verzoek aan zijn antwoord

Koppel op het SPI-paar, het uitwisselingstype en de bericht-ID, en controleer dan de antwoordvlag. Een hertransmissie herhaalt de bericht-ID van het origineel en is geen tweede inlogpoging. Pakketten tellen in plaats van uitwisselingen is hoe een gezonde onderhandeling een spooklus wordt.

Een antwoord kan ook een weigering zijn: een cookieverzoek, een melding over een onaanvaardbare groep of een fout over een voorstel. Dat zijn legitieme antwoorden, en ze betekenen dat het pad werkt terwijl het beleid dat niet doet. Decodeer de melding in plaats van elk antwoord als succes te zien. Als de melding een groep of een voorstel noemt, ligt de reparatie aan de configuratiekant en niet bij de firewall.

De richting is ook belangrijk. Een verzoek zonder antwoord en een antwoord dat de client nooit bereikt, zijn verschillende storingen, en alleen de tweede lijkt op een time-out aan de clientkant.

Ten vierde, scheid IKE van al het andere op 4500

Poort 4500 draagt drie dingen die er in een overzicht hetzelfde uitzien: IKE achter een vier-byte nul-non-ESP-marker, ingekapselde ESP waarvan de markerpositie een SPI bevat die niet nul is, en korte keepalives. Die marker is wat IKE van ingekapselde ESP scheidt, dus lees die bytes voordat u het verkeer IKE noemt. Een opnamelabel dat 4500 leest, is een poortnummer en geen protocol.

Ingekapselde ESP is versleutelde payload die u zonder sleutels niet kunt interpreteren, en de aanwezigheid ervan kan het teken van een werkende tunnel zijn in plaats van een storing.

Houd beide poorten in de gaten voor dezelfde poging, want IKE kan na NAT-detectie naar 4500 gaan, ook al opende het op 500. Een trace die alleen op 500 is gefilterd, lijkt precies stil wanneer de onderhandeling slaagde en verhuisde. Verbreed het filter en lees hetzelfde tijdvenster opnieuw voordat u enige conclusie uit afwezigheid trekt.

Wat stilte op één observatiepunt betekent

Geen antwoord bij de client bewijst alleen wat dat punt heeft waargenomen. Filteren, routing, het verkeerde externe adres, een dienst die uit staat en een protocolverschil leveren allemaal hetzelfde lege spoor.

Een relevante ICMP unreachable voegt bewijs toe, maar lees het geciteerde pakket erin en noteer het adres van het apparaat dat het heeft verzonden.

De weigering van een router is een andere gebeurtenis dan een geauthenticeerde fout die de partij teruggeeft, en alleen de tweede bewijst dat de dienst leeft. Correleer dezelfde poging met serverlogboeken of een goedgekeurde observatie om te weten of het verzoek aankwam en of er een antwoord uitging. Houd opnamen beperkt en privé, want leesbare handshake-velden maken de rest van het bestand niet onschadelijk. Het resultaat dat de moeite waard is, is één gekoppeld verzoek en antwoord, of één gedocumenteerde leemte met een genoemd observatiepunt.