რატომ აჩვენებს tcpdump IPsec-ის ღია ტექსტს მხოლოდ ერთი მიმართულებით

თქვენ უშვებთ tcpdump-ს Linux IPsec-ის კარიბჭის გარე ინტერფეისზე და ერთდროულად ორ რამეს ხედავთ: შემავალ ESP კადრებს და, მათთან დაუყოვნებლივ, გაშიფრულ შიდა პაკეტებს. გამავალი მიმართულებით მხოლოდ ESP ჩანს. ბუნებრივი დასკვნაა, რომ პასუხები არ იგზავნება, ან IPsec ერთ მიმართულებას შიფრავს და მეორეს ივიწყებს. არც ერთი არ არის მართალი.

ის, რასაც ხედავთ, დაჭერის წერტილია. ბირთვი გამავალ პაკეტებს ცვლის მანამ, სანამ მოწყობილობის გადაცემის გზა მათ პაკეტის სოკეტს გადასცემს, ამიტომ სოკეტი გარეთ გამავალ შიდა ფორმას არასოდეს ხედავს. შემოსვლისას პაკეტი ჯერ ESP-ად იჭერს და დეკაფსულირებული ასლი მაშინ ჩანს, როცა ის კვლავ სტეკში შედის. იგივე ტრაფიკი, დაკვირვების ორი სხვადასხვა ფანჯარა.

დაჭერის წერტილი წყვეტს, რას ხედავთ

ჩვეულებრივ ინტერფეისზე AF_PACKET სოკეტი მოწყობილობის ფენასთან ახლოს ზის. ჰოსტს გარეთ გამავალი პაკეტები ჯერ IPsec-ის გამავალი დამუშავების გზას გადიან, რომელიც შიდა TCP სეგმენტს ESP ან UDP-4500 დატაგრამად აქცევს, და მხოლოდ ამის შემდეგ აღწევენ ამ ფენას. შემომავალი პაკეტები სოკეტში კოპირდება ჯერ კიდევ დაშიფრული სახით, ხოლო გაშიფრული შედეგი მოგვიანებით ჩანს, როცა სტეკი მას ლოკალურად აწვდის ან გადაუგზავნის.

ეს თანმიმდევრობა სრულად ხსნის ასიმეტრიას. ეს არ არის მტკიცებულება მიმართულების, პოლიტიკის ან აპლიკაციის ქცევის შესახებ, და ასე მოპყრობა ადამიანებს ამაოდ აგდებს იმ პასუხის კვალდაკვალ, რომელიც მთელი დრო სწორად იგზავნებოდა. ეს ერთ-ერთი იშვიათი ქსელური გამოცანაა, სადაც ანომალიას ინსტრუმენტი ქმნის და არა ქსელი.

შეუსაბამეთ ფილტრი იმ ფენას, რომელიც გულისხმობთ

tcp port 443-ის მსგავსი გამოსახულება შიდა TCP კავშირს ირჩევს. გამავალი მიმართულებით ეს კავშირი უკვე ESP გახდა იმ მომენტისთვის, როცა სოკეტს ეკითხებიან, ამიტომ ფილტრი არაფერს ემთხვევა. თუ გსურთ დაცული ტრაფიკის დათვლა, სამაგიეროდ გარე ფორმით გაფილტრეთ: პროტოკოლი 50 ნედლი ESP-ისთვის, ან UDP პორტი 4500, როცა NAT-ის გადაკვეთა გამოიყენება. ორივე ფილტრი იძლევა პაკეტების რაოდენობას, რომლის შედარებაც ორ მხარეს შორის შეიძლება, და ჩვეულებრივ სწორედ ეს არის დათვლის მიზეზი. არც ერთი არ გეუბნებათ, პასუხი მიიღო თუ არა შიდა მოთხოვნამ.

UDP 4500-ის რაოდენობას ნუ მიიღებთ ESP პაკეტების რაოდენობად. IKE ასევე იყენებს ამ პორტს NAT-T-ის ცოცხლად შენარჩუნების შეტყობინებებისა და კაფსულირებული გაცვლისთვის, ამიტომ რიცხვი მოიცავს ტრაფიკს, რომელიც არ არის ის მონაცემები, რომელთა გაზომვაც გსურდათ. UDP 500-ზე საწყის IKE გაცვლას საკუთარი ფილტრი სჭირდება, თუ სწორედ ეს არის კითხვა. რიცხვი, რომელიც კონტროლის ტრაფიკს მონაცემებთან ურევს, ნებისმიერი გამტარობის შეფასებასაც უცნობი ზღვრით ამახინჯებს. ცალკე დათვლები ცალკე კითხვებს პასუხობს.

ფილტრი ჩაწერეთ იმ კითხვის გვერდით, რომელსაც ის პასუხობს. «რამდენი ESP გავიდა ყუთიდან» და «გავიდა თუ არა ვებ-მოთხოვნა ყუთიდან» სხვადასხვა გაზომვებია სხვადასხვა ფილტრით, და ერთი დაჭერა ორივეს ვერ გადაწყვეტს. ამ ჩანაწერის გარეშე ორი ადამიანი შეადარებს რიცხვებს, რომლებსაც არასოდეს დაუთვლიათ ერთი და იგივე.

დააკვირდით გარდაქმნამდე და არა შემდეგ

თუ გჭირდებათ გამავალი ღია ტექსტის ნახვა, დაკვირვების წერტილი უფრო ადრე, IPsec-ის გამავალი დამუშავების წინ გადაიტანეთ. NFLOG გაძლევთ Netfilter-ის კაუჭს, სადაც წესს შეუძლია შერჩეული პაკეტები მომხმარებლის სივრცის სოკეტში დააკოპიროს, რომლის წაკითხვაც tcpdump-ს შეუძლია. strongSwan-ის ტრაფიკის ამონაწერის სახელმძღვანელო სწორედ ამ მიზეზით აღწერს ამ მიდგომას.

პოლიტიკის დამთხვევა წესს მხოლოდ იმ ტრაფიკზე ზღუდავს, რომელიც გვირაბში შესვლას აპირებს. -m policy --pol ipsec --dir out არის ის, რაც წესს კონკრეტულს ხდის იმის ნაცვლად, რომ ყუთის მიერ გაგზავნილი ყოველი პაკეტი ჩაიწეროს. შემდეგ წაიკითხეთ ლოგის ჯგუფი შეზღუდული დაჭერით: მცირე რაოდენობის სნაპშოტი და ზომის ზღვარი ხელს უშლის დიაგნოსტიკას ტრაფიკის არქივად გადაქცევაში. შეზღუდული დაჭერა უფრო ადვილად გადასაცემია რეცენზენტისთვისაც, ზედმეტი ტვირთის გარეშე. რაოდენობა გადაწყვიტეთ დაწყებამდე და არა მას შემდეგ, რაც ნახავთ, რამდენი ჩამოვიდა.

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'

აირჩიეთ ნაკადის შესაბამისი კაუჭი. OUTPUT ფარავს იმ ტრაფიკს, რომელსაც თავად კარიბჭე წარმოქმნის; LAN კლიენტიდან გავლა სამაგიეროდ FORWARD ჯაჭვზე გადის, და OUTPUT-ზე არსებული წესი მას ვერასოდეს დაინახავს. ზემოთ მოცემული მისამართი და პორტი დამტკიცებული სატესტო დანიშნულების ადგილმჭერებია.

რას ამტკიცებს დაკვირვება

NFLOG ლოგირების სამიზნეა და არა მიღების გადაწყვეტილება. იქ გამოჩენილი პაკეტი გვიჩვენებს, რომ ის კაუჭს მიაღწია და წესს დაემთხვა. ის არ გვიჩვენებს, რომ მოგვიანებით ფილტრმა დაუშვა, მოწყობილობამ გაგზავნა, ან მეორე მხარემ რამე მიიღო.

ცარიელი ლოგიც თანაბრად ორაზროვანია. შეამოწმეთ წესის პაკეტების მრიცხველი, დაადასტურეთ მიმართულება, დაადასტურეთ, რომ ნაკადი ნამდვილად დაემთხვა IPsec პოლიტიკას, და დაადასტურეთ დანიშნულება. მხოლოდ ორივე მხარეს დამთხვეული მრიცხველი აქცევს დაკვირვებას დასკვნად. შემდეგ შეადარეთ უსაფრთხოების გაერთიანების მრიცხველები ორივე მხარეს იმავე კონტროლირებული მცდელობისთვის, რადგან SA მრიცხველები ავტორიტეტული ჩანაწერია იმისა, რაც იყო დაცული და გაგზავნილი.

კიდევ ერთი ხაფანგი: «ღია ტექსტი» ამ კონტექსტში ნიშნავს IPsec-ის შიფრაციის ფენის გარეთ. შიდა HTTPS სესიას მაინც აქვს საკუთარი TLS. დეკაფსულირებული პაკეტის დაჭერა არ ხსნის აპლიკაციის TLS-ს, და იქ წაკითხვადი HTTP-ის დანახვა ნიშნავს, რომ აპლიკაცია თავიდანვე არ იყენებდა HTTPS-ს.

გაასუფთავეთ და შეადარეთ ორივე ბოლო

დაკვირვების დასრულებისთანავე წაშალეთ ზუსტად ის წესი, რომელიც ჩასვით, მისი მფლობელის მიხედვით. დარჩენილი ლოგირების წესი ყოველ დამთხვეულ პაკეტზე CPU-ს ხარჯავს და ჩუმად ქმნის მონაცემთა შენახვის პრობლემას. წაშალეთ წესის -D-ით გამეორებით და არა თქვენთვის არ ეკუთვნის ჯაჭვის გაწმენდით.

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

თუ განლაგება იყენებს მომხმარებლის სივრცის IPsec-ს, XFRM ინტერფეისს ან აპარატულ განტვირთვას, დაკვირვების წერტილები იძვრება და ეს რეცეპტი შეიძლება საერთოდ არ გამოდგეს. libipsec-ის შემთხვევაში შიდა ტრაფიკის დაკვირვების დოკუმენტირებული ადგილი TUN მოწყობილობაა. ჯერ განსაზღვრეთ გზა, შემდეგ აირჩიეთ კითხვას პასუხის მომცემი წერტილი, და მოელოდეთ, რომ ორი მიმართულება განსხვავებულად მხოლოდ მაშინ გამოჩნდება, როცა გარდაქმნის არასწორ მხარეს უყურებთ.