Miks tcpdump näitab IPseci lihtteksti ainult ühes suunas

Käivitate tcpdumpi Linuxi IPsec-lüüsi välisliidesel ja näete korraga kahte asja: sissetulevaid ESP-kaadreid ja kohe nende järel dekrüpteeritud sisemisi pakette. Väljuvas suunas ilmub ainult ESP. Loomulik järeldus on, et vastuseid ei saadeta või et IPsec krüpteerib ühe suuna ja unustab teise. Kumbki pole tõsi.

See, mida te vaatate, on püüdmispunkt. Kernel teisendab väljuvaid pakette enne, kui seadme saatmise tee annab need paketisoklile, nii et sokk ei näe kunagi väljuvat sisemist kuju. Sissetuleval suunal püütakse pakk enne ESP-na ja dekapsuleeritud koopia muutub nähtavaks, kui see uuesti virna siseneb. Sama liiklus, kaks erinevat vaatlusakent.

Püüdmispunkt otsustab, mida te näete

Tavalisel liidesel asub AF_PACKET-sokk seadme kihi lähedal. Hosti lahkuvad paketid läbivad kõigepealt IPseci väljundtöötluse, mis muudab sisemise TCP-segmendi ESP- või UDP-4500-datagrammiks, ja jõuavad alles seejärel sellesse kihti. Saabuvad paketid kopeeritakse sokki traadilt tulles, ikka krüpteeritult, ja dekrüpteeritud tulemus muutub nähtavaks hiljem, kui virn selle kohapeal kohale toimetab või edasi suunab.

See järjekord seletab asümmeetria täielikult. See ei ole tõestus suuna, poliitika ega rakenduse käitumise kohta, ja nii koheldes aetakse taga vastust, mis oli kogu aeg õigesti saadetud. See on üks väheseid võrgu mõistatusi, kus anomaalia loob tööriist, mitte võrk.

Sobitage filter kihiga, mida mõtlete

Väljend nagu tcp port 443 valib sisemise TCP-ühenduse. Väljuvas suunas on see ühendus sokki küsides juba ESP-ks saanud, seega filter ei vasta millelegi. Kui soovite kaitstud liiklust lugeda, filtreerige hoopis välimise kuju järgi: protokoll 50 töötlemata ESP jaoks või UDP-port 4500, kui NAT-i läbimine on mängus. Mõlemad filtrid annavad paketiarvu, mida saab kahe partneri vahel võrrelda, mis on tavaliselt üldse loendamise põhjus. Kumbki neist ei ütle, kas sisemisele päringule vastati.

Ärge kohelge UDP 4500 arvu ESP pakettide arvuna. IKE kasutab seda porti ka NAT-T elushoidmiste ja kapseldatud vahetuse jaoks, seega sisaldab arv liiklust, mis ei ole andmed, mida te mõõta tahtsite. Esialgne IKE-vahetus UDP 500 juures vajab oma filtrit, kui küsimus on selles. Arv, mis segab juhtimisliiklust andmetega, teeb ka iga ribalaiuse hinnangu tundmatu marginaali võrra valeks. Eraldi loendused vastavad eraldi küsimustele.

Kirjutage filter selle küsimuse kõrvale, millele see vastab. „Kui palju ESP-d lahkus kastist“ ja „kas veebipäring lahkus kastist“ on erinevad mõõtmised erinevate filtritega ning üks püüdmine ei saa mõlemat otsustada. Ilma selle märkmeta võrdlevad kaks inimest arve, mis ei loendanud kunagi sama asja.

Jälgige enne teisendust, mitte pärast

Kui peate nägema väljuvat lihtteksti, liigutage vaatluspunkt varasemaks, enne IPseci väljundtöötlust. NFLOG annab teile Netfilteri konksu, kus reegel saab kopeerida valitud paketid kasutajaruumi sokki, mida tcpdump oskab lugeda. strongSwnani liikluse dumpimise juhend kirjeldab seda lähenemist just sel põhjusel.

Poliitika vastavus piirab reegli liiklusega, mis on tunnelisse sisenemas. Just -m policy --pol ipsec --dir out muudab reegli konkreetseks, selle asemel et logida iga paketti, mille kast saadab. Seejärel lugege logigruppi piiratud püüdmisega: väike hetktõmmiste arv ja suuruse piirang hoiavad diagnoosimise liiklusarhiiviks muutumast. Piiratud püüdmist on ka kergem ülevaatajale anda, ilma et peaksite kaasa vedama mittevajalikku koormust. Otsustage arv enne alustamist, mitte pärast seda, kui näete, kui palju saabus.

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'

Valige konks vastavalt voolule. OUTPUT katab liikluse, mille lüüs ise genereerib; LAN-kliendi transiit läbib hoopis FORWARD-ahela ja OUTPUT-i reegel ei näe seda kunagi. Ülaltoodud aadress ja port on kohahoidjad kinnitatud testsihtkoha jaoks.

Mida vaatlus tõestab

NFLOG on logimissiht, mitte vastuvõtmisotsus. Seal ilmuv pakett näitab, et see jõudis konksuni ja vastas reeglile. See ei näita, et hilisem filter lubas selle, et seade selle edastas või et partner midagi vastu võttis.

Tühi logi on sama mitmetähenduslik. Kontrollige reegli paketiloendurit, kinnitage suund, kinnitage, et vool vastas tõesti IPsec-poliitikale, ja kinnitage sihtkoht. Ainult mõlemal partneril ühtiv loendur muudab vaatluse järelduseks. Seejärel võrrelge turvaassotsiatsiooni loendureid mõlemal partneril sama kontrollitud katse jaoks, sest SA loendurid on autoriteetne kirje sellest, mis oli kaitstud ja saadetud.

Veel üks lõks: „lihttekst“ tähendab selles kontekstis väljaspool IPsec-krüpteerimiskihti. Sisemisel HTTPS-seansil on endiselt oma TLS. Dekapsuleeritud paketi püüdmine ei dekrüpteeri rakenduse TLS-i ja loetava HTTP nägemine seal tähendab, et rakendus ei kasutanud üldse HTTPS-i.

Koristage ja võrrelge mõlemat otsa

Eemaldage täpselt see reegel, mille lisasite, selle omaniku järgi, nii pea kui vaatlus on tehtud. Logimisreegli allesjätmine kulutab protsessorit iga vastava paketi peale ja tekitab vaikselt andmete säilitamise probleemi. Kustutage, korrates reeglit -D-ga, mitte tühjendades ahelat, mis ei kuulu teile.

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

Kui juurutus kasutab kasutajaruumi IPsecit, XFRM-liidest või riistvaralist mahalaadimist, liiguvad vaatluspunktid ja see retsept ei pruugi üldse kehtida. Libipseciga on sisemise liikluse jälgimise dokumenteeritud koht TUN-seade. Tehke kindlaks tee, valige seejärel punkt, mis vastab küsimusele, ja oodake, et kaks suunda näevad erinevad välja ainult siis, kui vaatate teisenduse valele poolele.