VPN მოწყობილობის მდგომარეობის შემოწმება არ ბლოკავს? ჯერ ანგარიშს გაჰყევით
თქვენი საბოლოო წერტილის აგენტი იუწყება ჯანსაღ მდგომარეობას, მაგრამ შიდა აპლიკაცია მაინც იხსნება. გაიარეთ შემგროვებელი, გადაწყვეტილება და ბლოკირება, შემდეგ კი დაამტკიცეთ უარი ერთი მოთხოვნით.
თუ ლეპტოპი, რომლის ანტივირუსული ხელმოწერები კვირების წინ შეწყვიტა განახლება, მაინც ახერხებს თქვენი შიდა აპლიკაციის გახსნას, მაშინ პოლიტიკის დოკუმენტი იშვიათად არის ის, რაც არასწორია. წვდომის უარყოფამდე სამი ცალკე სისტემა უნდა შეთანხმდეს: რაღაც ზომავს საბოლოო წერტილს, რაღაც აქცევს ამ გაზომვას დაშვების ან უარის გადაწყვეტილებად, და რაღაც რეალურად ყრის ტრაფიკს. როცა შეუსაბამო მოწყობილობა მაინც შემოდის, ზუსტად ერთი ასეთი რგოლი აკლია ან ენდობა მტკიცებულებებს, რომლებსაც არ უნდა ენდობოდეს. ქვემოთ მოცემული შემოწმებები ამ რიგით მიდის და თითოეულს აქვს გაჩერების წერტილი.
ბლოკირება ბოლო ნაბიჯია, არა პირველი
ავთენტიფიკაცია და მოწყობილობის მდგომარეობა სხვადასხვა კითხვას პასუხობს. წარმატებული შესვლა ამტკიცებს, რომ სერტიფიკატი იქნა წარდგენილი; ის არაფერს ამბობს იმ მანქანაზე გაშვებულ პროგრამულ უზრუნველყოფაზე, რომელმაც ის წარადგინა. სწორედ ეს ნაპრალი იძლევა საშუალებას, რომ კოპირებულმა კლიენტის პროფილმა ჯანსაღად მოჩვენებული სესია არაჯანსაღ ჰოსტზე გადაიტანოს.
საბოლოო წერტილების შესაბამისობის სამუშაოს უკვე აქვს ლექსიკა ამ ჯაჭვისთვის. RFC 5209-ის NEA საცნობარო მოდელი დავალებას ყოფს შემგროვებლად, შეფასების საფეხურად და აღსრულების წერტილად და პირდაპირ ამბობს, რომ კლიენტი, რომელიც საკუთარ მდგომარეობაზე იტყუება, მოდელის გარეთაა. ეს დათქმა დიაგრამაზე მნიშვნელოვანია: სანდო პლატფორმის მოდული თვითგამოცხადებულ გაზომვას ფაქტად არ აქცევს.
შემგროვებელი მოცულობის მიმართ გულახდილი შეინახეთ. მან უნდა შეატყობინოს ის ატრიბუტები, რომლებსაც თქვენი პოლიტიკა ასახელებს, წვდომის მთხოვნელ მოწყობილობაზე, და ცოტა სხვა. აგენტი, რომელიც ყველა დაყენებულ პაკეტს ჩამოთვლის, სხვა ინსტრუმენტია, ვიდრე მდგომარეობის შემგროვებელი, და განსხვავება ერთდროულად შენახვისა და სიზუსტის პრობლემაა. თუ ანგარიში ერთ მოწყობილობის იდენტობას ვერ მიუერთდება, შემფასებელი ხვდება, რომელ მანქანას გაუშვა ახლახან.
წითელი მდგომარეობის მქონე დაფა კონტროლი არ არის. ჰკითხეთ, სადამდე აღწევს უარყოფილი მომხმარებელი ჯერ კიდევ: ვიკიმდე, ფაილების გაზიარებამდე, მონაცემთა ბაზის პორტამდე? გასწორებას ერთი ვიწრო ზედაპირი სჭირდება, და ყველა დანარჩენი ბლოკირების მიღმაა.
წაიკითხეთ ანგარიში, სანამ წესს წაიკითხავთ
დაიწყეთ წყაროდან და არა კლიენტის მწვანე ნიშნიდან. Windows-ში ლოკალური გაზომვა Defender-იდან ან იმ პროდუქტიდან მოდის, რომელმაც თავი Security Center-ში დაარეგისტრირა, და ორივე მიმწოდებლის კონსოლის გარეშე იკითხება:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateმეორე ბრძანება აბრუნებს მთელ რიცხვს სახელად productState. მისი ბიტები ფხვიერადაა დოკუმენტირებული და მიმწოდებლები ჩართვისა და აქტუალობის დროშებს სხვადასხვანაირად აფუთავენ, ამიტომ დაადასტურეთ და ნუ გააანალიზებთ. მესამე მხარის პაკეტები განუდგენის შემდეგაც ტოვებენ Security Center-ის ჩანაწერს, და ის იუწყება იმ პროგრამულ უზრუნველყოფაზე, რომელიც დისკზე აღარ არის.
ასაკი ის ველია, რომელსაც ხალხი გამოტოვებს. ხელმოწერის დროის ნიშანი მნიშვნელობას მხოლოდ შეფასების შემსრულებელი მანქანის საათთან ფარდობით იძენს, ამიტომ გადააკეთეთ ინტერვალად და ნუ შეაფასებთ თვალით:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursახლა პოლიტიკას ერთი რიცხვი აქვს წასაკითხად. თუ თქვენი წესი ამბობს 72 საათს, ეს არის ის რიცხვი, რომელსაც ის იყენებს, და კვირა მძინარე ლეპტოპი ვარდება ისე, რომ არავინ განმარტავს იარლიყს. ჩაწერეთ ზღვარი ბრძანების გვერდით, რადგან ორივე ერთმანეთს შორდება, როცა საბოლოო წერტილის ინსტრუმენტი იცვლება.
ყოველი მოწყობილობის მდგომარეობა წერილობით გადაწყვეტილებად აქციეთ
მდგომარეობის შესახებ კამათის უმეტესობა სინამდვილეში უცნობი სტრიქონის კამათია. გადაწყვიტეთ ის პირველ ინციდენტამდე, ცხრილში, რომელიც ასახელებს მტკიცებულებას, გადაწყვეტილებას და მფლობელს, რათა არავინ იმპროვიზაცია მოახდინოს კარიბჭის კონსოლზე.
| Evidence the assessor has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents that fail open under load |
პროდუქტები სწორედ ქვედა სტრიქონში განსხვავდებიან. ზოგი კარიბჭე კავშირს უარყოფს და ხსნის რატომ; სხვები ტუნელს ასვლის საშუალებას აძლევენ და შეზღუდულ პოლიტიკას იყენებენ; რამდენიმე უკანასკნელ ცნობილ კარგ ანგარიშს უბრუნდება. მხოლოდ პირველი ორია დასაცავი და ღირს შემოწმება, თქვენი რომელია.
იდენტობა და ნებართვა თავის ზოლებში შეინახეთ. ლეპტოპი, რომელიც ყველა მდგომარეობის ტესტს გადის, მაინც საჭიროებს აპლიკაციისთვის სწორ ადამიანურ ავტორიზაციას, და მოწყობილობის სერტიფიკატი ამტკიცებს გასაღების ფლობას და არა ფაილური სისტემის მდგომარეობას. სამივეს ერთ ბულეში ჩაწურვა ის გზაა, რომლითაც დახმარების სამსახურის ანგარიში წარმოებაზე მუდმივ წვდომას იღებს.
აღსრულების გზა მოთხოვნით შეამოწმეთ და არა დაფით
აღსრულება მოთხოვნის თვისებაა, ამიტომ ერთი მოთხოვნით გაზომეთ. შეუსაბამო მანქანა ტუნელზე დასვით და გააკეთეთ ის გამოძახილი, რასაც ნამდვილი მომხმარებელი გააკეთებდა:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthთუ იმ მოწყობილობიდან მოდის 200, რომელიც უნდა დაიბლოკოს, ეს ნიშნავს, რომ გადაწყვეტილება მონაცემთა გზამდე არასდროს მისულა. ორი ჩვეული მიზეზი: პოლიტიკა მიბმულია ჯგუფზე, რომელშიც სატესტო ანგარიში არასდროს შესულა, ან აპლიკაცია მისაწვდომია მარშრუტით, რომელიც VPN-ს არ ეკუთვნის.
ჯერ მარშრუტიზაციის დაშვება შეამოწმეთ. თუ შიდა სახელი იხსნება ისეთ მისამართამდე, რომელსაც კლიენტი უკვე აღწევს ლოკალური LAN-ით, ტუნელი უმნიშვნელოა და არც ერთი პოლიტიკა არ გავრცელდება. შეადარეთ ეს მისამართი იმ მარშრუტს, რომელსაც კარიბჭე უბიძგებს. OpenVPN-ში თითოეული კლიენტის პოლიტიკა საერთო სახელით გასაღებულ ფაილებში ცხოვრობს, ამიტომ მისი შემოწმება მარტივია:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17ფაილი, რომელიც შეიცავს disable-ს, მთლიანად წყვეტს იმ კლიენტს, ხოლო push "route ..." სტრიქონი ავიწროებს, სადამდე შეიძლება მისვლა. ორივე აღსრულებაა და ორივე ჩანს ყველასთვის, ვინც ანგარიშს ამუშავებს.
ოთხი შემთხვევა ერთ სატესტო ანგარიშზე შეამოწმეთ
საბოლოო შემოწმება პატარა მატრიცაა და არა ბედნიერი გზა. გაატარეთ ერთი სატესტო ანგარიში ოთხ მდგომარეობაში: მიმდინარე, ვადაგასული ხელმოწერა, დაცვა გამორთული, აგენტი არ არის დაყენებული. თითოეულისთვის ჩაწერეთ გადაწყვეტილება შეფასების ჟურნალში, HTTP სტატუსი, რომელსაც აპლიკაცია აბრუნებს, და დატვირთულია თუ არა გასწორების გვერდი.
foreach ($case in 'current', 'stale', 'disabled', 'absent') {
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}ორი დეტალი ადვილად ჩაგვივარდება. ჯერ გამეორება: ანგარიში, რომელიც მაშინ ჩაიწერა, როცა მანქანა ჯანსაღი იყო, არ უნდა იქნას მიღებული იმავე მოწყობილობის შემდგომი სესიისთვის, ამიტომ მოძებნეთ მიმდინარე კავშირზე მიბმული დროის ნიშანი. შემდეგ მოცილება: აგენტის განუდგენას იგივე უარი უნდა გამოიწვიოს, რაც მოძველებულმა ანგარიშმა, და არა სუფთა გავლამ, და სწორედ ეს შემთხვევა არასდროს არ მოწმდება ხოლმე.
როცა მატრიცა ცხრილს დაემთხვევა, კარიბჭეს შემდეგი მძღოლისთვის გადაეცით სამი რამ: ბრძანებები, ზღვარი და ოთხი მოსალოდნელი შედეგი. სწორედ ეს გადაცემაა ნამდვილი შედეგი, რადგან მხოლოდ პოლიტიკის დოკუმენტში მცხოვრები მდგომარეობის დიზაინი პირველად მაშინ სრიალდება, როცა საბოლოო წერტილის ინსტრუმენტი თავის საანგარიშო ველს იცვლის.