A laptopja eltűnt, a VPN pedig továbbra is kliensként listázza. A sürgős kérdés nem az, hogyan törölje a profilt egy gépen, amely már nincs meg, hanem hogy melyik identitást fogadja el még a kiszolgáló. A WireGuard egy nyilvános kulcsot ellenőriz, a PKI-alapú OpenVPN beállítás kliens-tanúsítványt ellenőriz, az SSO-t használó VPN pedig fiókot és annak munkamenet-tokenjét. Ezt a hármat különböző helyeken és különböző sebességgel vonják vissza, és az, hogy az egyiket rendbe teszi, míg a többit figyelmen kívül hagyja, az az út, amelyen egy elveszett eszköz csatlakoztatva marad.

Három identitás és hogy mit szabályoz mindegyik

Minden mechanizmus más kérdésre válaszol. A társkulcs arra válaszol, hogy ez-e az a gép, amelyet regisztrált. A tanúsítvány arra válaszol, hogy a CA-ja írta-e alá, és nem vonták-e vissza. A fiók arra válaszol, hogy ez a személy elég nemrég hitelesítette-e magát. Egy olyan telepítés, amely kettőt rétegez, például tanúsítvány plusz címtárbejelentkezés, csak akkor zárja be az ajtót, ha minden rétegnek, amely valamit adott az eszköznek, megmondták, hogy ne fogadja el tovább.

A gyakorlati csapda az, hogy a hiányzó gép tartja minden hitelesítő adat privát felét, így semmi, amit helyben tesz, nem ér el a kiszolgálóig.

WireGuard: távolítsa el a társat, mert nincs visszavonási lista

A WireGuard nem vezet tiltólistát. A felület pontosan azokat a nyilvános kulcsokat fogadja el, amelyek társakként be vannak állítva, tehát a visszavonás törlés: futtassa a wg set wg0 peer <public-key> remove parancsot, a wg(8) -ban dokumentált formát, majd törölje a megfelelő [Peer] blokkot a wg0.conf fájlból. Tegye meg mindkettőt. A csak futásidőben végzett eltávolítás a következő újraindításig vagy konfiguráció-újratöltésig marad meg, amikor a fájl visszateszi a kulcsot.

A meglévő munkameneteknek nincs szükségük időzítőre a megszűnéshez. A társ eltávolítása eldobja a kézfogást és a kulcsanyagot, így a forgalom leáll, amint ismét érvényes kulcspárra van szükség. Ellenőrizze a wg show wg0 latest-handshakes parancsot a kiszolgálón: az elveszett kulcs bejegyzésének el kell tűnnie és tűnve kell maradnia, miközben a többi társ továbbra is friss korszakokat jelent.

Egy figyelmeztetés fontosabb, mint amilyennek látszik. Ha az elveszett eszköz kulcsot osztott meg más eszközökkel, mert valaki egy konfigurációs fájlt másolt, a kulcs eltávolítása mindegyiket leválasztja; ez akkor is a helyes lépés, és utána eszközönként állítja ki a kulcsokat ahelyett, hogy a közöset állítaná vissza.

Tanúsítványok: a CRL csak akkor számít, ha a démon olvassa

A tanúsítványalapú hozzáférés egy lépést ad hozzá, amelyet az emberek kihagynak. A easyrsa revoke laptop-01 visszavontként jelöli a tanúsítványt a CA adatbázisában, de a VPN semmit nem tanul ebből az adatbázisból. Ezután futtatja a easyrsa gen-crl parancsot a crl.pem megírásához, átmásolja a kiszolgáló crl-verify beállításában megnevezett útvonalra, és megerősíti, hogy a futó démon az új fájlt használja. A CRL újragenerálása és terjesztése nélküli visszavonás hatástalan.

Az időzítés a második fél. A CRL-t akkor nézik meg, amikor egy kliens csatlakozik vagy újratárgyal, így a kiépített alagút addig továbbíthat. Ha az eszközt azonnal le kell választani, fejezze be ezt a munkamenetet kifejezetten az OpenVPN felügyeleti felületén keresztül ahelyett, hogy a következő kézfogásra várna. A szolgáltatás újratöltése vagy újraindítása, attól függően, hogyan tölti be a telepítés a CRL-t, a változás része, és nem választható kiegészítés.

Érdemes másik gépről elvégezni az ellenőrzést: mutassa be a visszavont tanúsítványt, és várjon kézfogási hibára, jellemzően VERIFY ERROR: depth=0, error=certificate revoked. Ha a kapcsolat mégis sikerül, a kliens más CRL-t olvas, mint amelyet frissített.

Fiókok és munkamenetek: a letiltás nem ugyanaz, mint a kilakoltatás

A címtár- vagy SSO-bejelentkezéseket a hitelesítés idején ellenőrzik. A fiók letiltása blokkolja a következő bejelentkezést, de a frissítési token és a kiépített alagút a lejáratukig tovább működhet. Vonja vissza a felhasználó munkameneteit és tokenjeit, vagy növelje a munkamenet verzióját, ha az identitásszolgáltató támogatja. Távolítsa el az elveszett eszközt az MFA-regisztrációból is, mivel egy regisztrált hitelesítő önmagában is hozzáférési útvonal.

A RADIUS-alapú VPN-ek leválasztási üzenetet vagy jogosultságváltozást küldhetnek egy aktív munkamenet eldobásához, de nem minden hálózati hozzáférési kiszolgáló tartja be ezt. Kétség esetén fejezze be a felhasználó munkamenetét a kiszolgáló oldaláról, és erősítse meg a naplókban, hogy a régi munkamenet lezárult.

A műveletek sorrendje a következő órára

A leltárból induljon ki, ne a kliensből: sorolja fel az eszközhöz tartozó minden identitást, legyen az társkulcs, tanúsítvány sorszám vagy fiók. Minden kiállító rendszerben abban a sorrendben vonja vissza, ahogy a kapcsolat felépül, tehát először a fiókot, aztán a tanúsítványt, aztán a társat. Ezután bizonyítsa az elutasítást egy általa irányított gépről.

Két utómunkát könnyű elfelejteni. Először forgassa le mindazt, ami még az eszközön volt, különösen az SSH-kulcsokat, a felhőkonzol hitelesítő adatait és egy megosztott, előre megosztott WireGuard-kulcsot. Másodszor ellenőrizze, hogy a konfigurációkezelés, a pillanatképek vagy az aranylemezek nem hozhatják-e vissza az eltávolított klienst a következő újraépítéskor.

A tartós megoldás az eszközönkénti egy identitás. Ha minden laptop a saját társkulcsát vagy tanúsítványát hordozza, egy elvesztés egy visszavonási parancsba és egy új kiállításba kerül a teljes flotta újraépítése helyett.

Kapcsolódó cikkek