რომელ VPN პროცესს ეხება ეს დაუცველობის აღმოჩენა?

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

თანმიმდევრობა მნიშვნელოვანია: ჯერ კომპონენტი, მეორე გაფრთხილება, მესამე გამოსწორება.

ანგარიში პორტს ასახელებს, არა პროგრამას

დაიწყეთ იმ საბოლოო წერტილიდან, რომელიც რეალურად შეფასდა. HTTPS ადმინისტრირების პორტის წინააღმდეგ შემოწმებამ გაზომა ვებ სერვისი, მისი TLS სტეკი და მის წინ მდგარი ნებისმიერი პროქსი; მან ვერაფერი გაიგო სხვა პორტზე მდგარი OpenVPN ან WireGuard მსმენელის შესახებ. საპირისპირო პროქსები და მართვის აგენტები ამას აუარესებს, რადგან სერტიფიკატი და ბანერი შეიძლება წინა ნაწილს ეკუთვნოდეს, ხოლო დაუცველი ბიბლიოთეკა მის უკან, ფონურ პროცესში იყოს.

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

რა არის სინამდვილეში მოქმედი აწყობა

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

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

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

აწყობის გაფრთხილების ფარგლებთან შედარება

გაფრთხილებები აღწერენ პროდუქტებს, ვერსიებს და ზოგჯერ აუცილებელ პირობებს, და ეს სამი ველი ყოველთვის არ ემთხვევა პაკეტის ვერსიას. OpenVPN-ის 2014 წლის აპრილის Heartbleed გაფრთხილება სასარგებლო ისტორიული მაგალითია, რადგან ის გამოყოფს დაზარალებულ Access Server გამოშვებებს ვებ სერვისებისა და VPN დემონებისგან, რომლებსაც განსხვავებული ზემოქმედება ჰქონდათ. გაკვეთილი ისაა, წაიკითხოთ რომელ კომპონენტს ფარავს ტექსტი და არა შეადაროთ OpenSSL სიტყვა შაბლონით.

ეს გაფრთხილებაც მოძველებულია. მისი გასწორებული გამოშვების ნომრები ახლა ინსტალაციის რჩევა არ არის, და 2014 წელს გასწორებული ხარვეზი არაფერს ამბობს დღეს თქვენ მიერ გაშვებული ტოტის შემდგომ პრობლემებზე.

უთანხმოების გადაწყვეტა, შემდეგ ზემოქმედების დახურვა

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

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

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