Bakit ang tcpdump ay nagpapakita ng plaintext ng IPsec sa isang direksyon lamang

Pinapatakbo mo ang tcpdump sa panlabas na interface ng isang Linux IPsec gateway at nakikita mo ang dalawang bagay nang sabay: papasok na ESP frames at, agad pagkatapos, ang mga na-decrypt na panloob na packet. Palabas, ESP lamang ang lumalabas. Ang natural na konklusyon ay hindi ipinapadala ang mga tugon o ini-encrypt ng IPsec ang isang direksyon at nakakalimutan ang isa. Wala sa dalawa ang totoo.

Ang tinitingnan mo ay isang capture point. Binabago ng kernel ang papalabas na packet bago pa ito ibigay ng transmit path ng device sa packet socket, kaya hindi kailanman nakikita ng socket ang panloob na anyo sa paglabas. Sa pagpasok, ang packet ay nahuhuli muna bilang ESP at ang decapsulated na kopya ay nakikita kapag muli itong pumasok sa stack. Parehong trapiko, dalawang magkaibang bintana ng obserbasyon.

Ang capture point ang nagtatakda kung ano ang nakikita mo

Sa normal na interface, ang AF_PACKET socket ay nakaupo malapit sa device layer. Ang mga packet na lumalabas sa host ay dumadaan muna sa IPsec output processing, na ginagawang ESP o UDP-4500 datagram ang panloob na TCP segment, at pagkatapos lamang makarating sa layer na iyon. Ang mga papasok na packet ay kinokopya sa socket habang lumalabas mula sa kable, naka-encrypt pa rin, at ang na-decrypt na resulta ay makikita mamaya kapag inihatid ito ng stack nang lokal o ipinasa ito.

Ang pagkakasunod-sunod na iyon ang ganap na nagpapaliwanag ng asimetriya. Hindi ito ebidensya tungkol sa direksyon, patakaran o pag-uugali ng application, at ang pagtrato dito nang ganoon ay nagtutulak sa mga tao na habulin ang tugon na matagal nang ipinadala nang tama. Isa ito sa kakaunting palaisipan sa network kung saan ang instrumento, hindi ang network, ang lumilikha ng anomalya.

Itugma ang filter sa layer na tinutukoy mo

Ang ekspresyong gaya ng tcp port 443 ay pumipili ng panloob na TCP connection. Palabas, ang connection na iyon ay naging ESP na sa oras na tanungin ang socket, kaya wala itong tinutugma sa filter. Kung nais mong bilangin ang protektadong trapiko, i-filter ang panlabas na anyo: protocol 50 para sa raw ESP, o UDP port 4500 kapag ginagamit ang NAT traversal. Ang parehong filter ay nagbibigay ng bilang ng packet na maihahambing sa dalawang panig, na karaniwang dahilan ng pagbilang. Wala sa kanila ang nagsasabi kung sinagot ang panloob na kahilingan.

Huwag ituring ang bilang ng UDP 4500 bilang bilang ng ESP packet. Ginagamit din ng IKE ang port na iyon para sa NAT-T keepalive at sa encapsulated na palitan, kaya kasama sa bilang ang trapikong hindi ang data na nais mong sukatin. Ang paunang palitan ng IKE sa UDP 500 ay nangangailangan ng sariling filter kung iyon ang tanong. Ang bilang na humahalo ng control traffic at data ay ginagawang mali rin ang anumang tantya ng bandwidth sa hindi alam na margin. Ang magkahiwalay na bilang ay sumasagot sa magkahiwalay na tanong.

Isulat ang filter sa tabi ng tanong na sinasagot nito. «Gaano karaming ESP ang lumabas sa kahon» at «lumabas ba ang web request sa kahon» ay magkaibang pagsukat na may magkaibang filter, at hindi kayang lutasin ng isang capture ang dalawa. Kung wala ang tala na iyon, dalawang tao ang maghahambing ng mga bilang na hindi kailanman nagbilang ng parehong bagay.

Mag-obserba bago ang transformation, hindi pagkatapos

Kung kailangan mong makita ang palabas na plaintext, ilipat ang observation point nang mas maaga, bago ang IPsec output processing. Binibigyan ka ng NFLOG ng Netfilter hook kung saan maaaring kopyahin ng rule ang mga piling packet sa socket sa user space, na kayang basahin ng tcpdump. Dokumentado ng strongSwan traffic-dump guide ang pamamaraang ito dahil mismo sa kadahilanang ito.

Nililimitahan ng policy match ang rule sa trapikong malapit nang pumasok sa tunnel. -m policy --pol ipsec --dir out ang gumagawa sa rule na tiyak sa halip na i-log ang bawat packet na ipinapadala ng kahon. Pagkatapos, basahin ang log group gamit ang limitadong capture: maliit na bilang ng snapshot at limitasyon sa laki ang pumipigil sa diagnosis na maging archive ng trapiko. Ang limitadong capture ay mas madali ring ibigay sa isang reviewer nang hindi kinakaladkad ang walang kaugnayang payload. Magpasya sa bilang bago magsimula, hindi pagkatapos makita kung gaano karami ang dumating.

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'

Piliin ang hook na umaangkop sa flow. Sinasaklaw ng OUTPUT ang trapikong nililikha ng gateway mismo; ang transit mula sa LAN client ay dumadaan sa FORWARD chain, at hindi ito makikita ng rule sa OUTPUT. Ang address at port sa itaas ay placeholder para sa aprubadong test destination.

Ano ang pinatutunayan ng obserbasyon

Ang NFLOG ay target ng pag-log, hindi desisyon ng pagtanggap. Ang packet na lumilitaw doon ay nagpapakita na naabot nito ang hook at tumugma sa rule. Hindi nito ipinapakita na pinayagan ito ng susunod na filter, na ipinadala ito ng device, o na may natanggap ang kabilang panig.

Ang walang laman na log ay parehong malabo. Suriin ang packet counter ng rule, kumpirmahin ang direksyon, kumpirmahin na tumugma talaga ang flow sa isang IPsec policy, at kumpirmahin ang destination. Tanging ang counter na tumutugma sa dalawang panig ang nagbabago ng obserbasyon tungo sa konklusyon. Pagkatapos, ihambing ang mga counter ng security association sa dalawang panig para sa parehong kontroladong pagtatangka, dahil ang mga SA counter ang awtoritatibong talaan ng kung ano ang protektado at ipinadala.

Isa pang patibong: ang «plaintext» sa kontekstong ito ay nangangahulugang labas ng IPsec encryption layer. Ang panloob na HTTPS session ay may sariling TLS. Ang paghuli sa decapsulated packet ay hindi nagde-decrypt ng TLS ng application, at ang makakita ng mababasang HTTP doon ay nangangahulugang hindi kailanman gumamit ng HTTPS ang application.

Linisin at ihambing ang dalawang dulo

Alisin ang eksaktong rule na ipinasok mo, ayon sa may-ari nito, sa sandaling matapos ang obserbasyon. Ang pag-iwan ng logging rule ay kumakain ng CPU sa bawat tumutugmang packet at tahimik na lumilikha ng problema sa pagpapanatili ng data. Burahin sa pamamagitan ng pag-uulit ng rule gamit ang -D sa halip na i-flush ang chain na hindi sa iyo.

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

Kung gumagamit ang deployment ng user-space IPsec, XFRM interface o hardware offload, gumagalaw ang mga observation point at maaaring hindi ito applicable. Sa libipsec, ang dokumentadong lugar para obserbahan ang panloob na trapiko ay ang TUN device. Tukuyin muna ang landas, pagkatapos piliin ang puntong sumasagot sa tanong, at asahan na ang dalawang direksyon ay magmumukhang magkaiba lamang kapag tinitingnan mo ang maling bahagi ng transformation.