Kāpēc tcpdump rāda IPsec atklāto tekstu tikai vienā virzienā

Jūs palaižat tcpdump Linux IPsec vārtejas ārējā interfeisā un redzat divas lietas vienlaikus: ienākošos ESP kadrus un tūlīt pēc tiem atšifrētos iekšējos paketus. Izejošā virzienā parādās tikai ESP. Dabiskais secinājums ir, ka atbildes netiek sūtītas vai ka IPsec šifrē vienu virzienu un aizmirst otru. Neviens nav patiess.

Tas, ko jūs redzat, ir uztveršanas punkts. Kodols pārveido izejošos paketus pirms tam, kad ierīces pārraides ceļš tos nodod paketes ligzdai, tāpēc ligzda nekad neredz izejošo iekšējo formu. Ienākot pakets vispirms tiek uztverts kā ESP, un dekapsulētā kopija kļūst redzama, kad tas atkal nonāk stekā. Tā pati satiksme, divi dažādi novērošanas logi.

Uztveršanas punkts nosaka, ko jūs redzat

Parastā interfeisā AF_PACKET ligzda atrodas tuvu ierīces slānim. Paketi, kas atstāj resursdatoru, vispirms iziet cauri IPsec izvades apstrādei, kas iekšējo TCP segmentu pārvērš ESP vai UDP-4500 datagrammā, un tikai pēc tam sasniedz šo slāni. Ienākošie paketi tiek kopēti ligzdā, kad tie nāk no kabeļa, vēl šifrēti, un atšifrētais rezultāts kļūst redzams vēlāk, kad steks to piegādā lokāli vai pārsūta.

Šī secība pilnībā izskaidro asimetriju. Tas nav pierādījums par virzienu, politiku vai lietojumprogrammas uzvedību, un, to tā uztverot, cilvēki dzenas pēc atbildes, kas visu laiku tika sūtīta pareizi. Šī ir viena no nedaudzajām tīkla mīklām, kur anomāliju rada instruments, nevis tīkls.

Saskaņojiet filtru ar slāni, ko domājāt

Izteiksme, piemēram, tcp port 443 atlasa iekšējo TCP savienojumu. Izejošā virzienā šis savienojums jau ir kļuvis par ESP, kad ligzdai jautā, tāpēc filtrs neatbilst nekam. Ja vēlaties skaitīt aizsargāto satiksmi, filtrējiet pēc ārējās formas: protokols 50 neapstrādātam ESP vai UDP 4500 ports, ja tiek izmantota NAT caureja. Abi filtri dod paketu skaitu, ko var salīdzināt starp abām pusēm, un parasti tas ir skaitīšanas iemesls. Neviens no tiem nepaskaidro, vai iekšējais pieprasījums saņēma atbildi.

Neuzskatiet UDP 4500 skaitu par ESP paketu skaitu. IKE arī izmanto šo portu NAT-T dzīvības signāliem un inkapsulētajai apmaiņai, tāpēc skaitlis ietver satiksmi, kas nav tie dati, ko gribējāt izmērīt. Sākotnējai IKE apmaiņai UDP 500 ir vajadzīgs savs filtrs, ja tas ir jautājums. Skaitlis, kas sajauc vadības satiksmi ar datiem, arī padara jebkuru joslas platuma novērtējumu nepareizu ar nezināmu rezervi. Atsevišķi skaitījumi atbild uz atsevišķiem jautājumiem.

Pierakstiet filtru blakus jautājumam, uz kuru tas atbild. „Cik ESP atstāja kasti“ un „vai tīmekļa pieprasījums atstāja kasti“ ir dažādi mērījumi ar dažādiem filtriem, un viena uztveršana nevar atrisināt abus. Bez šīs piezīmes divi cilvēki salīdzinās skaitļus, kas nekad nav skaitījuši vienu un to pašu.

Novērojiet pirms transformācijas, nevis pēc

Ja jums jāredz izejošais atklātais teksts, pārvietojiet novērošanas punktu agrāk, pirms IPsec izvades apstrādes. NFLOG dod jums Netfilter āķi, kur noteikums var kopēt atlasītos paketus lietotāja telpas ligzdā, ko tcpdump var lasīt. strongSwan satiksmes izgāšanas rokasgrāmata dokumentē šo pieeju tieši šī iemesla dēļ.

Politikas atbilstība ierobežo noteikumu ar satiksmi, kas gatavojas iekļūt tunelī. -m policy --pol ipsec --dir out ir tas, kas padara noteikumu konkrētu, nevis reģistrē katru kastes sūtīto paketi. Pēc tam lasiet žurnāla grupu ar ierobežotu uztveršanu: mazs momentuzņēmumu skaits un izmēra ierobežojums neļauj diagnostikai kļūt par satiksmes arhīvu. Ierobežotu uztveršanu arī ir vieglāk nodot pārskatītājam, nevelkot līdzi nesaistītu kravu. Izlemiet skaitu pirms sākšanas, nevis pēc tam, kad redzējāt, cik daudz ieradās.

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'

Izvēlieties āķi atbilstoši plūsmai. OUTPUT aptver satiksmi, ko ģenerē pati vārteja; tranzīts no LAN klienta iet caur FORWARD ķēdi, un OUTPUT noteikums to nekad neredzēs. Iepriekš norādītā adrese un ports ir vietturi apstiprinātam testa galamērķim.

Ko pierāda novērojums

NFLOG ir reģistrēšanas mērķis, nevis pieņemšanas lēmums. Tur parādījies pakets parāda, ka tas sasniedza āķi un atbilda noteikumam. Tas neparāda, ka vēlāks filtrs to atļāva, ka ierīce to pārraidīja vai ka puse kaut ko saņēma.

Tukšs žurnāls ir tikpat divdomīgs. Pārbaudiet noteikuma paketu skaitītāju, apstipriniet virzienu, apstipriniet, ka plūsma patiešām atbilda IPsec politikai, un apstipriniet galamērķi. Tikai abās pusēs sakrītošs skaitītājs pārvērš novērojumu secinājumā. Pēc tam salīdziniet drošības asociācijas skaitītājus abās pusēs vienam un tam pašam kontrolētajam mēģinājumam, jo SA skaitītāji ir autoritatīvs ieraksts par to, kas tika aizsargāts un nosūtīts.

Vēl viena lamata: „atklātais teksts“ šajā kontekstā nozīmē ārpus IPsec šifrēšanas slāņa. Iekšējai HTTPS sesijai joprojām ir savs TLS. Dekapsulētā paketa uztveršana neatšifrē lietojumprogrammas TLS, un lasāma HTTP redzēšana tajā nozīmē, ka lietojumprogramma nekad nav izmantojusi HTTPS.

Sakopiet un salīdziniet abus galus

Noņemiet tieši to noteikumu, kuru ievietojāt, pēc tā īpašnieka, tiklīdz novērošana ir pabeigta. Atstāts reģistrēšanas noteikums patērē CPU katram atbilstošajam paketam un klusi rada datu saglabāšanas problēmu. Dzēsiet, atkārtojot noteikumu ar -D, nevis iztukšojot ķēdi, kas jums nepieder.

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

Ja izvietojums izmanto lietotāja telpas IPsec, XFRM interfeisu vai aparatūras atslogošanu, novērošanas punkti pārvietojas un šī recepte var vispār nepiemēroties. Ar libipsec dokumentētā vieta iekšējās satiksmes novērošanai ir TUN ierīce. Vispirms nosakiet ceļu, pēc tam izvēlieties punktu, kas atbild uz jautājumu, un gaidiet, ka divi virzieni izskatīsies atšķirīgi tikai tad, kad skatāties uz nepareizo transformācijas pusi.