Hogyan olvassunk friss IKE_SA_INIT-cserét egy rögzítésben

Olyan rögzítéssel kezdjünk, amely a kísérlet első csomagja előtt indul, különben egy beszélgetés közepét olvassuk. Egy már futó egyeztetés titkosított cseréket és kulcsújításokat mutat, és egyik sem hasonlít a nyitányra. A nyitány az a rész, amelyet kulcsok nélkül is dekódolhatunk, ezért válaszol olyan jól elérhetőségi kérdésekre. Négy ellenőrzés sorrendben elvezet egy friss rögzítéstől egy védhető állításig arról, melyik fél hagyta abba a beszédet.

Először igazoljuk, hogy a rögzítés az elején kezdődik

Az alagút felállása után indított rögzítés tartalmazza a beágyazott adatfolyamot és a rendszeres keepalive üzeneteket, és mindkettő vagy titkosított, vagy szinte üres. Indítsuk újra a klienst, és rögzítsük magát a kísérletet, vagy idézzünk elő szándékosan új kapcsolatot a rögzítés futása közben. Ha nem tudunk friss kísérletet előállítani, írjuk ezt meg a jegyzeteinkbe, mert semmilyen dekódolás nem hozza vissza azt a nyitányt, amelyet soha nem rögzítettünk.

Szűkítsük a rögzítést a két végpontra, valamint az UDP 500 és 4500 portra, hogy a fájl olvashatóan kicsi maradjon. Egy forgalmas gazdagépen a szűretlen rögzítés a nem kapcsolódó forgalom alá temeti az egyeztetést.

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

Tartsuk meg a fájlt, ha a kísérlet érdekes, mert ugyanaz a rögzítés válaszol a következő két kérdésre: mi volt a csere, és jött-e vissza valami. Címkézzük fel az indulás idejével és azzal a végpontpárral, amelyre szűrtünk. Két ilyen tény nélkül a rögzítés egy hét múlva hasznavehetetlen, amikor a címek megváltoztak, és senki nem emlékszik, melyik kísérletet rögzítette.

Másodszor olvassuk el a fejlécet a hasznos terhek előtt

Az IKE fejléc hordozza a biztonsági paraméter indexeket, a csere típusát és az üzenetazonosítót, és friss egyeztetésnél ezek az értékek jellegzetesek. A kezdeményező nullától eltérő SPI-t talál ki, a kezdeti kérés nullás válaszoló SPI-t hordoz, mert még nem látszott válasz, a csere típusa IKE_SA_INIT, és az üzenetazonosító nulla. Minden más ugyanazon egyeztetés későbbi szakaszához vagy egészen más kísérlethez tartozik.

Ebben az első cserében a javaslat, a kulcscsere és a nonce hasznos terhek nyíltan olvashatók. Az olvashatóság nem hitelesítés, és ezen a ponton egyik fél sem bizonyította a személyazonosságát.

A privát Diffie-Hellman érték soha nem halad át a vezetéken, ezért a rögzítésből nem vezethetők le munkamenet-kulcsok. A hitelesítés a következő cserében történik, amelyet az véd, amiről az első megállapodott. Ha valaki azt kérdezi, hiteles-e az egyik fél, ez a csere nem tud válaszolni erre a kérdésre. Csak azt mutathatja meg, hogy mindkét oldal egyetértett egy javaslatban, és létrehozott egy közös titkot, amelyet a fájl nem tartalmaz.

Harmadszor párosítsuk a kérést a válaszával

Az SPI pár, a csere típusa és az üzenetazonosító alapján párosítsunk, majd ellenőrizzük a válasz jelzőbitjét. Az újraküldés megismétli az eredeti üzenetazonosítót, és nem második bejelentkezési kísérlet. A csomagok számlálása a cserék helyett az az út, amelyen egy egészséges egyeztetés kísértetjárta hurokká válik.

A válasz elutasítás is lehet: cookie-kérés, elfogadhatatlan csoportra vonatkozó értesítés vagy egy javaslatra vonatkozó hiba. Ezek jogos válaszok, és azt jelentik, hogy az útvonal működik, miközben a szabályzat nem. Dekódoljuk az értesítést, ahelyett hogy minden választ sikernek tekintenénk. Amikor az értesítés csoportot vagy javaslatot nevez meg, a javítás a konfiguráció oldalán van, nem a tűzfalon.

Az irány is számít. A válasz nélküli kérés és a klienshez soha meg nem érkező válasz különböző hibák, és csak a második néz ki kliensoldali időtúllépésnek.

Negyedszer válasszuk külön az IKE-t minden mástól a 4500-on

A 4500 port három dolgot hordoz, amelyek összefoglaló nézetben egyformának tűnnek: IKE egy négybájtos nulla non-ESP jelölő mögött, beágyazott ESP, amelynek jelölőhelyén nullától eltérő SPI áll, és rövid keepalive üzenetek. Ez a jelölő választja el az IKE-t a beágyazott ESP-től, ezért olvassuk el azokat a bájtokat, mielőtt IKE-nek nevezzük a forgalmat. Az a rögzítés-címke, amely 4500-at olvas, portszám, nem protokoll.

A beágyazott ESP titkosított hasznos teher, amelyet kulcsok nélkül nem tudunk értelmezni, és a jelenléte inkább működő alagút jele lehet, mint hiba.

Figyeljük mindkét portot ugyanahhoz a kísérlethez, mert az IKE a NAT-felismerés után átkerülhet a 4500-ra, pedig az 500-on nyílt meg. Az csak az 500-ra szűrt nyom tűnik pontosan akkor csendesnek, amikor az egyeztetés sikerült és helyet változtatott. Szélesítsük a szűrőt, és olvassuk újra ugyanazt az időablakot, mielőtt bármilyen következtetést vonnánk le a hiányból.

Mit jelent a csend egyetlen megfigyelési ponton

A válasz hiánya a kliensnél csak azt bizonyítja, amit az a pont megfigyelt. A szűrés, az útválasztás, a rossz távoli cím, egy leállt szolgáltatás és egy protokoll-eltérés mind ugyanazt az üres nyomot adja.

Egy releváns ICMP unreachable bizonyítékot ad, de olvassuk el a benne idézett csomagot, és jegyezzük fel a küldő eszköz címét.

Az útválasztó elutasítása más esemény, mint a fél által visszaadott hitelesített hiba, és csak a második bizonyítja, hogy a szolgáltatás él. Kapcsoljuk össze ugyanazt a kísérletet szerveroldali naplókkal vagy jóváhagyott megfigyeléssel, hogy megtudjuk, megérkezett-e a kérés, és kiment-e válasz. Tartsuk a rögzítéseket szűken és privátan, mert az olvasható kézfogás-mezők nem teszik ártalmatlanná a fájl többi részét. Az az eredmény éri meg, ha egy párosított kérés és válasz van, vagy egy dokumentált hiány megnevezett megfigyelési ponttal.