VPN ierīces stāvokļa pārbaude nebloķē? Vispirms izsekojiet atskaiti
Jūsu galapunkta aģents ziņo par veselīgu stāvokli, taču iekšējā lietotne joprojām atveras. Izejiet kolektoru, spriedumu un bloķēšanu, pēc tam pierādiet atteikumu ar vienu pieprasījumu.
Ja klēpjdators, kura antivīrusa paraksti pārstāja atjaunoties pirms nedēļām, joprojām var atvērt jūsu iekšējo lietotni, tad politikas dokuments reti ir tas, kas ir nepareizi. Trim atsevišķām sistēmām jāvienojas, pirms piekļuve tiek liegta: kaut kas mēra galapunktu, kaut kas pārvērš šo mērījumu lēmumā atļaut vai liegt, un kaut kas tiešām nomet datu plūsmu. Kad neatbilstoša ierīce tomēr tiek iekšā, tieši viens no šiem posmiem trūkst vai uzticas pierādījumiem, kuriem nevajadzētu. Tālāk minētās pārbaudes notiek šajā secībā, un katrai ir apstāšanās punkts.
Bloķēšana ir pēdējais solis, nevis pirmais
Autentifikācija un ierīces stāvoklis atbild uz dažādiem jautājumiem. Veiksmīga pieteikšanās pierāda, ka tika uzrādīti akreditācijas dati; tā neko nepasaka par programmatūru, kas darbojas mašīnā, kura tos uzrādīja. Tieši šī plaisa ļauj nokopētam klienta profilam pārnest veselu izskata sesiju uz neveselu resursdatoru.
Galapunktu atbilstības darbam jau ir šīs ķēdes vārdnīca. RFC 5209 informatīvais NEA atsauces modelis sadala uzdevumu kolektorā, novērtēšanas solī un izpildes punktā un skaidri saka, ka klients, kas melo par savu stāvokli, atrodas ārpus modeļa. Šis precizējums ir svarīgāks par diagrammu: uzticams platformas modulis pašziņotu mērījumu nepārvērš faktā.
Turiet kolektoru godīgu attiecībā uz tvērumu. Tam jāziņo par atribūtiem, kurus nosauc jūsu politika, ierīcē, kas pieprasa piekļuvi, un maz par ko citu. Inventāra aģents, kas uzskaita katru instalēto pakotni, ir cits instruments nekā stāvokļa kolektors, un atšķirība vienlaikus ir glabāšanas un precizitātes problēma. Ja atskaiti nevar piesaistīt vienai ierīces identitātei, vērtētājs min, kuru mašīnu viņš tikko pielaida.
Informācijas panelis ar sarkanu statusu nav kontrole. Pajautājiet, ko liegtais lietotājs vēl var sasniegt: wiki, failu koplietojumu, datubāzes portu? Labošanai vajadzīga viena šaura virsma, un viss pārējais pieder aiz bloķēšanas.
Lasiet atskaiti pirms noteikuma lasīšanas
Sāciet no avota, nevis no klienta zaļās atzīmes. Operētājsistēmā Windows vietējais mērījums nāk no Defender vai no produkta, kas reģistrējies Security Center, un abus var nolasīt bez piegādātāja konsoles:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateOtrā komanda atgriež veselu skaitli ar nosaukumu productState. Tā biti ir brīvi dokumentēti, un piegādātāji iespējošanas un aktualitātes karodziņus iepako atšķirīgi, tāpēc apstipriniet to, nevis analizējiet. Trešo pušu komplekti pēc atinstalēšanas arī atstāj Security Center ierakstu, un tas ziņo par programmatūru, kas vairs nav diskā.
Vecums ir lauks, kuru cilvēki izlaiž. Paraksta laika zīmogs kaut ko nozīmē tikai attiecībā pret mašīnas, kas veic novērtējumu, pulksteni, tāpēc pārvērtiet to intervālā, nevis novērtējiet ar aci:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursTagad politikai ir viens skaitlis, ko lasīt. Ja jūsu noteikums saka 72 stundas, tas ir skaitlis, ko tā izmanto, un klēpjdators, kas gulējis nedēļu, neiztur bez tā, ka kāds interpretētu etiķeti. Pierakstiet slieksni blakus komandai, jo abi izšķiras, kad galapunkta instruments tiek nomainīts.
Pārvērtiet katru ierīces stāvokli rakstiskā spriedumā
Lielākā daļa strīdu par stāvokli patiesībā ir strīdi par nezināmo rindu. Izlemiet to pirms pirmā incidenta tabulā, kas nosauc pierādījumu, spriedumu un īpašnieku, lai neviens neimprovizētu pie vārtejas konsoles.
| 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 |
Produkti atšķiras tieši apakšējā rindā. Dažas vārtejas atsaka savienojumu un paskaidro kāpēc; citas ļauj tunelim pacelties un piemēro ierobežotu politiku; nedaudzas atgriežas pie pēdējās zināmās labās atskaites. Tikai pirmās divas ir aizstāvamas, un ir vērts pārbaudīt, kuru dara jūsējā.
Turiet identitāti un atļauju arī savās joslās. Klēpjdators, kas iztur katru stāvokļa testu, joprojām prasa pareizu cilvēka autorizāciju lietotnei, un ierīces sertifikāts pierāda atslēgas piederību, nevis failu sistēmas stāvokli. Trīs sablīvēšana vienā Būla vērtībā ir ceļš, kā palīdzības dienesta konts iegūst pastāvīgu piekļuvi produkcijai.
Pārbaudiet izpildes ceļu ar pieprasījumu, nevis paneli
Izpilde ir pieprasījuma īpašība, tāpēc izmēriet to ar vienu pieprasījumu. Ielieciet neatbilstošu mašīnu tunelī un veiciet izsaukumu, kādu veiktu īsts lietotājs:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthAtbilde 200 no ierīces, kurai vajadzētu būt bloķētai, nozīmē, ka lēmums nekad nav sasniedzis datu ceļu. Divi ierasti iemesli: politika ir piesaistīta grupai, kurai testa konts nekad nav pievienojies, vai lietotne ir sasniedzama pa maršrutu, kas VPN nepieder.
Vispirms pārbaudiet maršrutēšanas pieņēmumu. Ja iekšējais nosaukums atrisinās uz adresi, kuru klients jau sasniedz vietējā LAN, tunelis ir nebūtisks un nekāda politika netiks piemērota. Salīdziniet šo adresi ar maršrutu, ko vārteja bīda. Uz OpenVPN katra klienta politika dzīvo failos, kas aizslēgti ar kopējo nosaukumu, tāpēc to ir viegli pārbaudīt:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17Fails, kas satur disable, pilnībā atvieno šo klientu, bet rinda push "route ..." sašaurina, kur tas var nokļūt. Abi ir izpilde, un abi ir redzami ikvienam, kas atkļūdo atskaiti.
Testējiet četrus gadījumus vienā testa kontā
Pēdējā pārbaude ir neliela matrica, nevis laimīgs ceļš. Izvediet vienu testa kontu cauri četriem stāvokļiem: aktuāls, beidzies paraksts, aizsardzība izslēgta, aģents nav instalēts. Katram ierakstiet spriedumu novērtēšanas žurnālā, HTTP statusu, ko atgriež lietotne, un vai ielādējās labošanas lapa.
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
}Divi sīkumi ir viegli palaist garām. Pirmkārt, atkārtošana: atskaiti, kas uzņemta, kamēr mašīna bija vesela, nedrīkst pieņemt vēlākai sesijai tajā pašā ierīcē, tāpēc meklējiet laika zīmogu, kas saistīts ar pašreizējo savienojumu. Pēc tam noņemšana: aģenta atinstalēšanai jārada tāds pats atteikums kā novecojušai atskaitei, nevis tīra iziešana, un tieši šis gadījums visbiežāk netiek nekad pārbaudīts.
Kad matrica sakrīt ar tabulu, nododiet trīs lietas tam, kas turpmāk pārvaldīs vārteju: komandas, slieksni un četrus gaidāmos rezultātus. Tieši šī nodošana ir īstais rezultāts, jo stāvokļa dizains, kas dzīvo tikai politikas dokumentā, noslīd pirmajā reizē, kad galapunkta instruments maina savu atskaites lauku.