კარიბჭე თუ გადაგზავნილი კლიენტი? წყაროს მისამართის კითხვა
დანიშნულება ხედავს თარგმნილ წყაროს და არა კლიენტის კერძო მისამართს. TTL-ით გამოცნობის ნაცვლად გამოიყენეთ კარიბჭის მდგომარეობა, იდენტობა და იარლიყიანი დასკვნა.
ვებსერვერი ერთ მისამართს აღრიცხავს და ყველა თვლის, რომ ის თავად კარიბჭის პროცესს ეკუთვნის. ის შეიძლება ეკუთვნოდეს გადაგზავნილ კლიენტს, რომლის კერძო მისამართი თარგმნის საფეხურზე გაქრა. დანიშნულება ხედავს მხილებულ ქსელურ წყაროს და მეტს არაფერს. ეს საზღვრის შესახებ განცხადებაა და არა მტკიცება, რომ წარმომავლობის დადგენა არასოდეს შეიძლება.
რას ხედავს დანიშნულება სინამდვილეში
აიღეთ კლიენტი 10.20.0.7-ზე, კარიბჭე, რომლის გარე მისამართია 198.51.100.10, და დანიშნულება ინტერნეტში. თუ კარიბჭე კლიენტის წყაროს თარგმნის, დანიშნულების სოკეტი აღრიცხავს 198.51.100.10-ს. კერძო მისამართი პაკეტიდან ქრება და დანიშნულება ვერ წაიკითხავს მას იმ თავსართიდან. ეს რიცხვები საილუსტრაციოა და არა თქვენი ქსელიდან აღებული ჩანაწერი.
დაკვირვება მაინც სასარგებლოა: ის განსაზღვრავს ქსელურ წყაროს, რომლის დაშვება ან დაბლოკვა დანიშნულებას სჭირდება. უბრალოდ არ განსაზღვრავს მის უკან მდგარ ადამიანს ან პროცესს. დანიშნულების ოპერატორისთვის ეს განსხვავება წყვეტს, დაბლოკვა ქსელური გადაწყვეტილებაა თუ ანგარიშის გადაწყვეტილება.
თარგმნის მდგომარეობა დანიშნულებისთვის ხილვადი არ არის
კარიბჭე ინახავს თარგმნილ კავშირსა და თავდაპირველ კლიენტს შორის შესაბამისობას და სწორედ ეს მდგომარეობა აკლია დანიშნულებას. NAT-ის ტრადიციული აღწერა გამოყოფს თარგმნის ჩანაწერს შემდგომ ხილვადი თავსართებისგან. ერთი მხარის კითხვა მეორეს არ გაძლევთ.
სხვადასხვა დიზაინი სხვადასხვა მტკიცებულებას იძლევა. შენარჩუნებული წყაროს მისამართებით მარშრუტიზებული ტრაფიკი აჩვენებს კლიენტის რეალურ მისამართს, ხოლო აპლიკაციის პროქსი წყვეტს კავშირს და ქმნის ახალს. შენარჩუნებული წყაროს მარშრუტი ასევე მოითხოვს, რომ კლიენტის მისამართი დანიშნულებიდან უკან მარშრუტიზებადი იყოს, რასაც ყოველი განლაგება არ გვთავაზობს. ჰკითხეთ, რომელი დიზაინია განლაგებული, სანამ ჟურნალის სტრიქონს განმარტავთ.
conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10
TTL და თითის ანაბეჭდები მინიშნებაა და არა მტკიცება
IPv4-ში TTL დამოკიდებულია გამომგზავნის მიერ არჩეულ საწყის მნიშვნელობაზე და პაკეტის მიერ გავლილ ნახტომთა რაოდენობაზე. ორივე ფაქტის გარეშე მნიშვნელობა ვერ დაამტკიცებს, რომ VPN ნახტომი მოხდა. ცნობილი დამატებითი მარშრუტიზებული ნახტომი ასევე ვერ განასხვავებს LAN მარშრუტიზატორს, გვირაბის გზას ან სხვა გადაგზავნის წყობას. TTL-ის განსხვავებას მოეკიდეთ როგორც კითხვას და არა დასკვნას.
სხვა სიგნალები იგივენაირად იქცევიან. User-Agent თავსართი შეიძლება აპლიკაციამ დააყენოს და დროის მსგავსება შეიძლება ასახავდეს საერთო ინფრასტრუქტურას და არა საერთო ადამიანს. რამდენიმე მომხმარებელს შეუძლია ერთი გასასვლელის გაზიარება და ერთ მომხმარებელს შეუძლია სესიებს შორის მარშრუტის შეცვლა. ერთად თავმოყრილი, რამდენიმე სუსტი სიგნალი შეიძლება ამართლებდეს კარიბჭის ჩანაწერებზე უფრო ახლო ხედს, მაგრამ დაგროვებით ისინი ძლიერ მტკიცებულებად არ იქცევიან.
ავტორიზაცია იდენტობით და არა მისამართით
თუ დანიშნულებას კარიბჭის ადმინისტრირება უნდა გამოჰყოს დისტანციური მომხმარებლის აქტივობისგან, მიეცით ამ როლებს ცალკეული ავთენტიფიცირებული იდენტობები და დაშვებული ოპერაციები. საერთო საჯარო წყარო კვლავ შეიძლება იყოს ქსელური შეზღუდვა, მაგრამ ის არ ცვლის მომხმარებლის ან მოწყობილობის ავთენტიფიკაციას.
შეინახეთ მტკიცებულებები იარლიყიანად: დაკვირვებული წყარო, ავთენტიფიცირებული ანგარიში, დრო და განსახილველი დასკვნა. არ თარგმნოთ «აქ შიდა წყარო არ ჩანს» როგორც «არსად მიკუთვნება შეუძლებელია». იარლიყს მნიშვნელობა აქვს, როცა თვეების შემდეგ ჩანაწერს კითხულობს ადამიანი, რომელიც გამოძიების ნაწილი არ იყო.
ჩაწერეთ დაკვირვების თარიღი და სისტემა, რომელმაც ის შექმნა. მიკუთვნების გარეშე ჟურნალის ნაწყვეტის დაცვა მოგვიანებით ძნელია.