Zakaj tcpdump prikazuje odprto besedilo IPsec le v eni smeri

Zaženete tcpdump na zunanjem vmesniku linuxovega prehoda IPsec in vidite dve stvari hkrati: dohodne okvire ESP in takoj za njimi dešifrirane notranje pakete. V odhodni smeri se pojavi samo ESP. Naravni sklep je, da se odgovori ne pošiljajo ali da IPsec šifrira eno smer in pozabi na drugo. Nobeno ni res.

To, kar gledate, je mesto zajema. Jedro preoblikuje odhodne pakete, preden jih pot prenosa naprave preda paketnemu vtiču, zato vtič nikoli ne vidi notranje oblike pri odhodu. Pri vhodu se paket najprej zajame kot ESP in dekapsulirana kopija postane vidna, ko znova vstopi v sklad. Isti promet, dve različni opazovalni okni.

Mesto zajema odloči, kaj vidite

Na običajnem vmesniku vtič AF_PACKET sedi blizu plasti naprave. Paketi, ki zapustijo gostitelja, najprej gredo skozi izhodno obdelavo IPsec, ki notranji segment TCP spremeni v datagram ESP ali UDP-4500, in šele nato dosežejo to plast. Dohodni paketi se kopirajo v vtič, ko prihajajo z žice, še vedno šifrirani, dešifrirani rezultat pa postane viden pozneje, ko ga sklad dostavi lokalno ali ga posreduje naprej.

Ta vrstni red popolnoma pojasni asimetrijo. To ni dokaz o smeri, politiki ali vedenju aplikacije, in če ga tako obravnavate, ljudje lovijo odgovor, ki je bil ves čas poslan pravilno. To je ena redkih omrežnih ugank, kjer anomalijo ustvari orodje, ne omrežje.

Uskladite filter s plastjo, ki jo mislite

Izraz, kot je tcp port 443, izbere notranjo povezavo TCP. V odhodni smeri je ta povezava ob vprašanju vtiča že postala ESP, zato filter ne ujame ničesar. Če želite šteti zaščiten promet, filtrirajte po zunanji obliki: protokol 50 za surov ESP ali vrata UDP 4500, ko se uporablja prehod NAT. Oba filtra dajeta število paketov, ki ga je mogoče primerjati med obema stranema, kar je običajno razlog za štetje. Nobeden od njiju ne pove, ali je bila notranja zahteva odgovorjena.

Števila UDP 4500 ne obravnavajte kot število paketov ESP. IKE ta vrata uporablja tudi za sporočila za ohranjanje NAT-T in za zapakirano izmenjavo, zato število vključuje promet, ki ni podatki, ki ste jih želeli izmeriti. Začetna izmenjava IKE na UDP 500 potrebuje svoj filter, če je to vprašanje. Število, ki meša nadzorni promet s podatki, tudi vsako oceno pasovne širine naredi napačno za neznano mero. Ločena štetja odgovarjajo na ločena vprašanja.

Filter zapišite poleg vprašanja, na katero odgovarja. „Koliko ESP je zapustilo škatlo“ in „ali je spletna zahteva zapustila škatlo“ sta različni meritvi z različnimi filtri, en zajem pa ne more razrešiti obeh. Brez te opombe bosta dve osebi primerjali števila, ki nikoli niso štela iste stvari.

Opazujte pred preobrazbo, ne po njej

Če morate videti odhodno odprto besedilo, premaknite opazovalno točko prej, pred izhodno obdelavo IPsec. NFLOG vam da kavelj Netfilter, kjer lahko pravilo kopira izbrane pakete v vtič v uporabniškem prostoru, ki ga tcpdump zna brati. Vodnik strongSwan za izpis prometa dokumentira ta pristop prav zaradi tega razloga.

Ujemanje s politiko omeji pravilo na promet, ki bo vstopil v tunel. -m policy --pol ipsec --dir out je tisto, kar naredi pravilo določno, namesto da bi beležilo vsak paket, ki ga škatla pošlje. Nato berite skupino dnevnika z omejenim zajemom: majhno število posnetkov in omejitev velikosti preprečita, da bi diagnoza postala arhiv prometa. Omejen zajem je tudi lažje predati pregledovalcu brez vlečenja nepomembnega tovora. Število določite pred začetkom, ne po tem, ko vidite, koliko je prišlo.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Izberite kavelj, ki ustreza toku. OUTPUT pokriva promet, ki ga ustvari sam prehod; tranzit od odjemalca LAN gre skozi verigo FORWARD, pravilo na OUTPUT pa ga ne bo nikoli videlo. Naslov in vrata zgoraj so nadomestni znaki za odobreni preskusni cilj.

Kaj dokazuje opazovanje

NFLOG je cilj beleženja, ne odločitev o sprejemu. Paket, ki se tam pojavi, kaže, da je dosegel kavelj in se ujemal s pravilom. Ne kaže, da ga je poznejši filter spustil, da ga je naprava prenesla ali da je druga stran kaj prejela.

Prazen dnevnik je enako dvoumen. Preverite števec paketov pravila, potrdite smer, potrdite, da se je tok res ujemal s politiko IPsec, in potrdite cilj. Samo ujemajoč se števec na obeh straneh spremeni opazovanje v sklep. Nato primerjajte števce varnostne zveze na obeh straneh za isti nadzorovani poskus, ker so števci SA verodostojen zapis o tem, kaj je bilo zaščiteno in poslano.

Še ena past: „odprto besedilo“ tukaj pomeni zunaj šifrirne plasti IPsec. Notranja seja HTTPS ima še vedno svoj TLS. Zajem dekapsuliranega paketa ne dešifrira TLS aplikacije, in če je tam videti berljiv HTTP, to pomeni, da aplikacija ni nikoli uporabljala HTTPS.

Počistite in primerjajte oba konca

Odstranite natanko tisto pravilo, ki ste ga vstavili, po njegovem lastniku, takoj ko je opazovanje končano. Puščeno pravilo beleženja stane CPU pri vsakem ujemajočem se paketu in tiho ustvari težavo s hrambo podatkov. Izbrišite ga s ponovitvijo pravila z -D, namesto da bi izpraznili verigo, ki ni vaša.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Če uvedba uporablja IPsec v uporabniškem prostoru, vmesnik XFRM ali strojno razbremenitev, se opazovalne točke premaknejo in ta recept morda sploh ne velja. Pri libipsec je dokumentirano mesto za opazovanje notranjega prometa naprava TUN. Najprej določite pot, nato izberite točko, ki odgovarja na vprašanje, in pričakujte, da bosta smeri videti različni le, ko gledate na napačno stran preobrazbe.