შემავალი გაფრთხილება VPN სერვერზე: წაიკითხეთ დაკვირვების წერტილი

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

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

პირველი ეტაპი: რა დაინახა ჩაჭერამ სინამდვილეში

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

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

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

მეორე ეტაპი: რა ადგენს უარყოფის ჩანაწერს

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

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

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

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

მესამე ეტაპი: რას ამტკიცებს ავთენტიფიკაციის მოვლენა

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

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

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

ერთი დაკავშირებული ნიმუში აჯობებს დაფას

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

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

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