რატომ იცვლება პორტების სკანირების შედეგები VPN-გასასვლელის მიღმა?
შეცვალეთ გასასვლელი და პორტმა შეიძლება სხვაგვარად უპასუხოს სერვისის გადაადგილების გარეშე. გამოყავით ბილიკის დაკვირვება იმ ინვენტარისგან, რომელიც ნამდვილად გჭირდებათ.
გაუშვით იგივე პორტის შემოწმება საოფისე ხაზიდან და VPN-გასასვლელიდან, და ორი პასუხი შეიძლება არ დაეთანხმოს მისამართს, რომელიც არავის შეუცვლია. ეს სხვაობა მოდის მარშრუტიდან და იმიდან, თუ რომელმა ჰოსტმა უპასუხა, და არა იმიდან, მუშაობს თუ არა სერვისი. სამი კითხვა ჰყოფს ამ ახსნებს: რა იკითხა რეალურად ზონდმა, რომელმა ჰოსტმა უპასუხა მას, და რა ჩაწერა თქვენმა სერვერმა. გაიარეთ ისინი ამ თანმიმდევრობით და ჩაწერეთ ყოველი პასუხი, სანამ შემდეგზე გადახვალთ.
გაასწორეთ ზონდი, სანამ ორ გაშვებას შეადარებთ
მდგომარეობის სიტყვა შედარებადია სხვა მდგომარეობის სიტყვასთან მხოლოდ მაშინ, როცა ორივე ერთი და იმავე ექსპერიმენტიდან მოდის. ხუთი ველი ამას აფიქსირებს: წყაროს მისამართი, რომელიც შორეულმა მხარემ დაინახა, ამოხსნილი დანიშნულება, პორტი, სკანირების ტიპი და დრო. შეცვალეთ რომელიმე მათგანი და თქვენ ჩაატარეთ მეორე ექსპერიმენტი, ნაცვლად იმისა, რომ პირველი ორჯერ გაზომოთ.
შეამოწმეთ წყარო ყველაფრამდე, რადგან VPN-კლიენტი შეიძლება ჩართული იყოს, სანამ ტრაფიკი კვლავ ფიზიკური ინტერფეისიდან გადის. ჰკითხეთ შორეულ მხარეს, რას ხედავს, შემდეგ ჰკითხეთ ბირთვს, რომელი ინტერფეისი აირჩია:
curl -s https://ifconfig.me
ip route get 203.0.113.20ორი მისამართი სხვადასხვა ქსელში ნიშნავს, რომ ახსნა უკვე ხელშია, და დანარჩენი შემოწმებები მხოლოდ დაადასტურებს მას. როცა ისინი ემთხვევა, ჩაწერეთ ზონდი მიზეზის დროშით ჩართული, რათა მდგომარეობა დაბრუნდეს ახსნასთან დაკავშირებული და არ დადგეს მარტო შიშველ სიტყვად. სკანირების ტიპიც ეკუთვნის ამ ჩანაწერს, რადგან ის აღწერს, რა იკითხა და არა რა დაბრუნდა. მდგომარეობა წყაროს, მეთოდისა და დროის ნიშნულის გარეშე ვერ შეედრება არაფერს:
nmap -sT -p 443,8443 --reason 203.0.113.20შეინახეთ ეს გამომავალი ჩანაწერის გვერდით და არა სქროლის ბუფერში, რომელსაც შემდეგი ადამიანი ვერ ნახავს. ორი პატიოსანი სკანირება, რომლებიც არ ეთანხმებიან, კამათია მხოლოდ მაშინ, როცა არავინ ჩაწერა პირობები. პირობების დაფიქსირებისას ან შედეგები ემთხვევა და კითხვა იხურება, ან ისინი განსხვავდებიან და სხვაობა ფაქტია ბილიკის შესახებ.
გაარკვიეთ, რომელმა ჰოსტმა დაასრულა ხელის ჩამორთმევა
დასრულებული ხელის ჩამორთმევა ამტკიცებს, რომ რომელიღაც ჰოსტმა დაასრულა ის, და ეს ჰოსტი სულაც არ არის აუცილებელი იყოს ის პროცესი, რომელიც თქვენ გახსოვთ. დატვირთვის გამანაწილებელი, უკუ პროქსი ან SYN პროქსი შეიძლება უპასუხონ მანამ, სანამ რეალური სერვერი მიიღებს მონაწილეობას, რაც ჩვეულებრივი დიზაინია და არა სიმპტომი. მოსალოდნელი სახელისთვის ვალიდური სერტიფიკატიც არ ავიწროებს ამას, რადგან სერტიფიკატი აღწერს სერვისულ ურთიერთობას და არაფერს ამბობს იმაზე, რომელმა მანქანამ დაასრულა კავშირი.
Nmap-ის პორტის მდგომარეობების ცნობარი ამას საბაზისოდ მიიჩნევს: მდგომარეობა აღრიცხავს, რისი დაკვირვებაც ზონდმა შეძლო გაგზავნის ადგილიდან, და არა პორტის თვისებას. წაიკითხეთ მდგომარეობის სიტყვა ასე და ორი გაშვება, რომლებიც არ ეთანხმებოდნენ, დაიწყებენ თანმიმდევრულად გამოჩენას და არა წინააღმდეგობრივად, სანამ კითხვა გადადის იმაზე, ღიაა თუ არა პორტი, იმაზე, თუ ვინ იდგა მის წინ.
უპასუხეთ მეორე კითხვას backend-ში და არა გარედან. frontend, რომელიც იღებს კავშირებს და შემდეგ ვერ აღწევს თავის upstream-ს, ქმნის ზუსტად ჯანსაღი სერვისის გარეგნულ სურათს ნელი აპლიკაციით. მხოლოდ upstream-ის საკუთარი ჩანაწერი ჰყოფს ორ შემთხვევას:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'ლოგის სტრიქონი გვიჩვენებს კლიენტის მისამართს, რომელიც აპლიკაციამ ნამდვილად დაინახა, და მეორე ბრძანება გვიჩვენებს, 443 პორტის მფლობელი პროცესი თქვენი აპლიკაციაა თუ რაღაც მის წინ. თუ ეს ორი არ ეთანხმება იმას, რომელი მისამართი დაუკავშირდა, თქვენ უყურებთ ერთი მოთხოვნის ორ ფეხს და ბილეთმა ეს უნდა თქვას.
შეამოწმეთ საკუთარი წესები, სანამ გვირაბს დაადანაშაულებთ
განზრახ პოლიტიკა ყველაზე გავრცელებული მიზეზია იმისა, რომ პორტი ერთ ქსელში პასუხობს და მეორეში არა, და ეს არის ყველაზე ნაკლებად საინტერესო ხელმისაწვდომი ახსნა. წვდომის წესები არსებობს იმისთვის, რომ ერთი წყარო დაუშვან და დანარჩენი გადააგდონ, ამიტომ გასასვლელის შეცვლა ზუსტად ის მოვლენაა, რომლისთვისაც დაიწერა ისინი. ამიტომ VPN-ის გავლით განსხვავებული მდგომარეობა არ აჩვენებს, რომ პროვაიდერი ამოწმებს ტრაფიკს. ის აჩვენებს, რომ თქვენი წყაროს მისამართი ახლა განსხვავებულია, რაც ბევრად უფრო მცირე მტკიცებაა.
ეს წესები სერვერზე იკითხება, ამიტომ წაიკითხეთ ისინი და ნუ ივარაუდებთ ქსელის შუაზე. ჩამოთვალეთ ის ფილტრის წესები, რომლებიც ახსენებენ ორიდან რომელიმე მისამართების დიაპაზონს, შემდეგ შეამოწმეთ, საერთოდ მიაღწია თუ არა კავშირმა დემონამდე:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113ცარიელი მეორე შედეგი ინფორმაციულია, რადგან დემონამდე არაფერი მიუღწევია და კითხვა ეკუთვნის ფილტრს, უსაფრთხოების ჯგუფს ან თავად ბილიკს. დაბრუნება ნიშნავს, რომ სერვისმა დაინახა თქვენი წყარო და აირჩია თავისი პასუხი, და ეს გადაწყვეტილება ჩვეულებრივ ჩაწერილია წესში, რომლის წაკითხვაც შეგიძლიათ. არც ერთი შედეგი არ უჭერს მხარს ამბავს პროვაიდერზე, და ორივე უფრო იაფად მოწმდება, ვიდრე პაკეტების დაჭერა.
წაიკითხეთ ტრანსპორტი, სერტიფიკატი და პასუხი ცალ-ცალკე
სამი შრე ქმნის სამ დაკვირვებას, და ზონდი, რომელიც ერთ მათგანს ამოწმებს, ვერ მოგვიყვება დანარჩენ ორზე. შეინახეთ ისინი ცალკე სტრიქონებად ჩანაწერში და ნუ ჩაკეცავთ ერთ განაჩენად, რადგან ყოველი სტრიქონი საკუთარი წესით ფუჭდება და მარცხის რეჟიმი გეუბნებათ, სად უნდა შეხედოთ შემდეგ.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
ერთი ბრძანება ქმნის პირველ სამ სტრიქონს სერვისის მიმართ, რომელსაც თქვენ აკონტროლებთ. მოათავსეთ მისი გამომავალი ჩანაწერში სკანირების გვერდით და არა ჩატის შეტყობინებაში:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/წაიკითხეთ გამომავალი რიგითობით: ხელის ჩამორთმევა პასუხობს ტრანსპორტის კითხვას, სერტიფიკატის სუბიექტი — სახელის კითხვას, ხოლო პასუხის სხეული — აპლიკაციის კითხვას. როცა ხელის ჩამორთმევის სტრიქონი წარმატდება და პასუხის სტრიქონი არა, თქვენ გაქვთ frontend გატეხილი upstream-ით და არა დაბლოკილი პორტი. ეს სხვა ბილეთია, ვიდრე თქვენ გახსენით, და ღირს ამის პირდაპირ თქმა.
დაასრულეთ ბილეთში ოთხი ფაქტის ჩაწერით: წყაროს მისამართი, სკანირების ტიპი, ჰოსტი, რომელმაც უპასუხა, და დრო. ყველაფერი, რაც მოგვიანებით შედარებას სჭირდება, ამ ოთხში ცხოვრობს, და ვინც საქმეს შემდეგ აიღებს, თქვენი ტერმინალის ისტორია არ ექნება. თუ ოთხივეს ვერ შეავსებთ, გაშვება არ დასრულებულა.