Nem blokkol az VPN-eszköz állapotellenőrzés? Előbb kövesse a jelentést

Ha egy laptop, amelynek víruskereső-aláírásai hetekkel ezelőtt abbahagyták a frissítést, még mindig meg tudja nyitni a belső alkalmazását, ritkán a házirend-dokumentum az, ami rossz. Három különálló rendszernek kell egyetértenie, mielőtt a hozzáférés megtagadásra kerül: valami méri a végpontot, valami ezt a mérést engedélyez vagy elutasít ítéletté alakítja, és valami ténylegesen eldobja a forgalmat. Amikor egy nem megfelelő eszköz mégis bejut, pontosan egy láncszem hiányzik, vagy olyan bizonyítékban bízik, amelyben nem kellene. Az alábbi ellenőrzések ebben a sorrendben futnak, és mindegyiknek van egy megállási pontja.

A blokkolás az utolsó lépés, nem az első

A hitelesítés és az eszköz állapota különböző kérdésekre válaszol. A sikeres bejelentkezés azt bizonyítja, hogy bemutattak egy hitelesítő adatot; semmit nem mond a gépen futó szoftverről, amely bemutatta. Ez a rés teszi lehetővé, hogy egy másolt kliensprofil egészségesnek látszó munkamenetet vigyen át egy nem egészséges gazdagépre.

A végpont-megfelelőségi munkának már van szókincse ehhez a lánchoz. Az RFC 5209 NEA-referenciamodellje a feladatot gyűjtőre, értékelési lépésre és érvényesítési pontra osztja, és nyíltan kimondja, hogy az a kliens, amely a saját állapotáról hazudik, a modellen kívül esik. Ez a fenntartás fontosabb a diagramnál: egy megbízható platformmodul nem tesz önbejelentett mérést ténnyé.

Tartsa őszintén a gyűjtőt a hatókör tekintetében. Azokat az attribútumokat kell jelentenie, amelyeket a házirendje megnevez, a hozzáférést kérő eszközön, és kevés mást. Az a leltáragens, amely minden telepített csomagot felsorol, más eszköz, mint az állapotgyűjtő, és a különbség egyszerre megőrzési és pontossági probléma. Ha a jelentés nem köthető egyetlen eszközidentitáshoz, az értékelő találgat, melyik gépet engedte át éppen.

A piros állapotot mutató irányítópult nem ellenőrzés. Kérdezze meg, hová férhet még hozzá az elutasított felhasználó: a wikire, a fájlmegosztásra, az adatbázis portjára? A javításnak egyetlen szűk felületre van szüksége, és minden más a blokkolás mögé tartozik.

Olvassa el a jelentést, mielőtt a szabályt olvassa

A forrásnál kezdje, ne a kliens zöld pipájánál. Windowson a helyi mérés a Defendertől vagy attól a terméktől érkezik, amely regisztrálta magát a Security Centerben, és mindkettő olvasható szállítói konzol nélkül:

Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState

A második parancs egy productState nevű egész számot ad vissza. A bitjei lazán dokumentáltak, és a szállítók eltérően csomagolják az engedélyezési és naprakészségi jelzőket, ezért inkább ellenőrizze, mint elemezze. A harmadik féltől származó csomagok az eltávolítás után is meghagyják a Security Center bejegyzést, és az olyan szoftverről számol be, amely már nincs a lemezen.

A kor az a mező, amelyet az emberek kihagynak. Az aláírás időbélyege csak az értékelést végző gép órájához képest jelent valamit, ezért alakítsa intervallummá, ne szemre becsülje:

$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours

Most már egy számot kell olvasni a házirendben. Ha a szabálya 72 órát mond, ez az a szám, amelyet használ, és az egy hétig alvó laptop anélkül bukik el, hogy bárki értelmezné a címkét. Jegyezze fel a küszöböt a parancs mellé, mert a kettő elcsúszik, amikor a végponteszközt lecserélik.

Alakítson minden eszközállapotot írásos ítéletté

Az állapotról szóló viták többsége valójában az ismeretlen sorról szóló vita. Döntse el az első incidens előtt, olyan táblázatban, amely megnevezi a bizonyítékot, az ítéletet és a tulajdonost, hogy senki ne improvizáljon az átjáró konzoljánál.

Az alsó sor az, ahol a termékek különböznek. Egyes átjárók elutasítják a kapcsolatot és megmagyarázzák, miért; mások hagyják felmenni az alagutat és korlátozott házirendet alkalmaznak; kevesen visszaesnek az utolsó ismert jó jelentésre. Csak az első kettő védhető, és érdemes kipróbálni, melyiket teszi az öné.

Tartsa az identitást és az engedélyt is a saját sávjában. Az a laptop, amely minden állapottesztet átmegy, még mindig igényli a megfelelő emberi felhatalmazást az alkalmazáshoz, és az eszköztanúsítvány egy kulcs birtoklását bizonyítja, nem a fájlrendszer állapotát. A három egyetlen booleanbe sűrítése az az út, ahogyan egy ügyfélszolgálati fiók állandó hozzáférést kap a termeléshez.

Ellenőrizze az érvényesítési útvonalat kéréssel, ne irányítópulttal

Az érvényesítés a kérés tulajdonsága, ezért egyetlen kéréssel mérje. Tegyen egy nem megfelelő gépet az alagútra, és végezze el azt a hívást, amelyet egy valódi felhasználó tenne:

curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health

Ha egy blokkolandó eszköztől 200-as válasz jön, az azt jelenti, hogy a döntés soha nem érte el az adatútvonalat. Két szokásos ok: a házirend olyan csoporthoz kapcsolódik, amelyhez a tesztfiók soha nem csatlakozott, vagy az alkalmazás olyan útvonalon érhető el, amely nem a VPN tulajdona.

Először az útválasztási feltevést ellenőrizze. Ha a belső név olyan címre oldódik fel, amelyet a kliens már a helyi LAN-on keresztül elér, az alagút irreleváns, és semmilyen házirend nem érvényesül. Hasonlítsa össze ezt a címet azzal az útvonallal, amelyet az átjáró tol. OpenVPN esetén a kliensenkénti házirend a közös névvel kulcsolt fájlokban él, ezért könnyű ellenőrizni:

ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17

Az a fájl, amely disable tartalmaz, teljesen leválasztja azt a klienst, míg egy push "route ..." sor szűkíti, hová juthat el. Mindkettő érvényesítés, és mindkettő látható mindenkinek, aki a jelentést hibakeresi.

Tesztelje a négy esetet egyetlen próbafiókon

A záró ellenőrzés egy kis mátrix, nem boldog út. Vezessen át egy tesztfiókot négy állapoton: aktuális, lejárt aláírás, védelem kikapcsolva, ügynök nincs telepítve. Mindegyiknél jegyezze fel az ítéletet az értékelési naplóba, a HTTP-állapotot, amelyet az alkalmazás visszaad, és hogy betöltődött-e a javítási oldal.

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
}

Két részlet könnyen elkerüli a figyelmet. Először az ismétlés: az a jelentés, amelyet a gép egészséges állapotában rögzítettek, nem fogadható el ugyanazon eszköz későbbi munkamenetéhez, ezért keressen az aktuális kapcsolathoz kötött időbélyeget. Aztán az eltávolítás: az ügynök eltávolítása ugyanazt az elutasítást eredményezze, mint egy elavult jelentés, ne tiszta átjutást, és éppen ezt az esetet nem tesztelik leggyakrabban soha.

Amikor a mátrix megfelel a táblázatnak, adjon át három dolgot annak, aki legközelebb az átjárót viszi: a parancsokat, a küszöböt és a négy várt eredményt. Ez az átadás az igazi szállítási eredmény, mert a csak házirend-dokumentumban élő állapotterv akkor csúszik el először, amikor a végponteszköz megváltoztatja a jelentési mezőjét.