Hogyan alakítja az OpenConnect a bejelentkezési sütit alagúttá?
Az OpenConnect webes bejelentkezési sütit cserél VPN-alagútra. A süti a munkamenet hordozója, ezért védje az átadást, ne csak a bejelentkező oldalt.
Az OpenConnect két külön cserét köt össze egyetlen rövid életű értékkel: a webes bejelentkezést és a VPN-alagutat. Az első csere közönséges HTTPS: a hitelesítő adatok, egy SAML-oda-vissza vagy egy token az átjáróhoz mennek, és a válasz egy hitelesítési sütit hoz. A második csere ezt a sütit mutatja be ugyanannak az átjárónak annak bizonyítékaként, hogy a webes szakasz már megtörtént, és csak ezután jön fel az alagút.
A bejelentkezés alatt semmit nem tárgyalnak az alagútról. Ezt érdemes megérteni, mert a legtöbb szkripthiba azt feltételezi, hogy a süti egy tárolandó jelszó, vagy egy kulcs, amely a forgalmat védi, holott valójában egy adott átjárómunkamenet hordozójegye.
Mit cserél az ügyfél és az átjáró, sorrendben
A hitelesítési szakasz úgy néz ki, mint egy közönséges védett webhely. Az OpenConnect elküldi a felhasználó hitelesítő adatait, vagy követi az átjáró átirányítását egy identitásszolgáltatóhoz, és az átjáró olyan dokumentummal válaszol, amely beágyazza a hitelesítési sütit. Az AnyConnect protokollban ez az érték egy süti fejlécben utazik a következő kérésekben, általában webvpn jellegű néven, és a kézikönyv a munkamenetet továbbvivő hitelesítő adatként kezeli.
A második szakasz egy CONNECT kérés az átjáró VPN-végpontjára, azzal a sütivel csatolva. Az átjáró ellenőrzi, címet oszt ki, és az ügyfél CSTP-t indít TLS fölött, a DTLS pedig opcionális gyorsabb adatút, ha a munkamenet már létezik. Csak ezen a ponton állnak fel az alagút paraméterei, az útvonalak, a DNS-beállítások és a munkamenet forgalmi kulcsai. A süti beengedte az ügyfelet az ajtón; semmit nem titkosított.
Ez a sorrend magyarázza, miért létezik az openconnect --authenticate. Futtassa, és végrehajtja a webes szakaszt, kiír egy kis blokkot shell-változókból, például COOKIE, HOST, CONNECT_URL és FINGERPRINT, majd kilép, mielőtt bármilyen alagút felépülne. Egy burkolószkript ezután ezekkel az értékekkel indíthatja a valódi kapcsolatot, és pontosan erre a felosztásra van szüksége egy fej nélküli vagy kétkonténeres telepítésnek.
A süti munkamenet-hordozó, nem kulcs
Úgy kezelje az értéket, ahogy egy webalkalmazásban a munkamenet-azonosítót kezelné. Aki az élettartama alatt birtokolja, kérheti az átjárótól azt az alagutat, amelyre ez a munkamenet jogosult, ezért a titkossága számít. A másolás azonban nem tár fel forgalmat, mert az alagút bizalmassága a TLS-kézfogásból és a származtatott kulcsokból jön, nem a süti karakterláncából.
Ez sem állandó engedély. Az átjáró és az identitásszolgáltató dönti el, meddig él a munkamenet, és egy még bejelentkezett oldalt mutató böngésző semmit nem mond arról, hogy az alagút munkamenete még érvényes-e. A lejárat utáni újracsatlakozás a webes szakasz megismétlését és friss süti előállítását jelenti, és éppen ez az újrahitelesítés értelme, nem pedig egy mérnöki munkával megkerülendő bosszúság.
Ne tekintse a sütit más hitelesítő adatok egyetemes helyettesítőjének. Egy SAML-állítás, egy böngészőjelszó és egy másik szolgáltatás által kiállított süti különböző objektumok különböző közönséggel, és az egyiket a másik mezőjébe illeszteni általában az átjárónál bukik meg, vagy ami rosszabb, a rossz bizalmi határral szemben sikerül.
A süti továbbadása másolatok hátrahagyása nélkül
A legbiztonságosabb mechanikus átadás Linuxon a szabványos bemenet. A --cookie-on-stdin a stdinről olvassa az értéket, így a süti soha nem jelenik meg a folyamat argumentumlistájában, ahol bármely helyi felhasználó elolvashatja a ps paranccsal. Az a csővezeték, amely az egyik folyamatban hitelesít, és a másikban táplálja az alagutat, az értéket csőben tartja, nem fájlban vagy környezeti változóban.
Az argumentumok és a környezeti változók különböző okokból gyengébbek. Az argumentum látható a folyamattáblában az ügyfél teljes élettartama alatt, és gyakran a shell-előzményekbe kerül. A környezeti változót a gyermekfolyamatok öröklik, és az a systemd-egység, amely az egységfájlban beállítja, olvasható konfigurációban tárolja a titkot. Ha mindenképp fájl kell, korlátozza a szolgáltatásfiókra, és a munkamenet végén törölje.
Tartsa szándékosnak a jogosultsági határt is. A folyamatnak, amely az identitásszolgáltatóval beszél, és esetleg böngészőt nyit, azon felhasználóként kell futnia, akié ez a bejelentkezés. A folyamatnak, amely útvonalakat, DNS-t és az alagúteszközt konfigurálja, több jogosultságra lehet szüksége. Az egész böngészőt rootként futtatni, hogy a sütije elérhető legyen egy root-tulajdonú alagút számára, rossz csere, és a modern OpenConnect-telepítések kifejezetten át tudják adni az értéket ezen a határon.
A naplózás ugyanazt a gyanút érdemli. A részletes ügyfélkimenet, a segédszkriptek és az átjáró diagnosztikája mind megismételhetik a kérés anyagát, és nem minden naplózási szint takarja el a sütit. Rögzítse a legkisebb szükséges hibarekordot, tartsa távol a megosztott csatornáktól, és a jegyhez csatolás előtt ellenőrizzen egy kitakart mintát.
Ellenőrzés és lejárat a második szakaszban
A második szakasznak még mindig ellenőriznie kell a szervert. Az a FINGERPRINT, amelyet az --authenticate kiír, tanúsítvány-tűzés pin-sha256: formában, és ha a --servercert kapcsolóval átadja az alagúthívásnak, az ellenőrzés ahhoz az átjáróhoz horgonyozva marad, amely felé hitelesített. A tanúsítványellenőrzés kikapcsolása egy szkript egyszerűsítéséért eltávolítja az egyetlen bizonyítékot arra, hogy a süti a szándékolt hoszthoz kerül.
Amikor az átjáró elutasítja a sütit, a megoldás egy új hitelesítési kör, nem egy hosszabb gyorsítótár. Csak a kapcsolat élettartamára tárolja a sütit, kilépéskor törölje az ideiglenes fájlokat, és ha egy munkamenet kiszivárog vagy egy eszköz elveszik, használja az identitásszolgáltató vagy az átjáró munkamenet-eltávolítási folyamatát. A gyorsítótárazott süti nem mentesítés az MFA alól.
Mielőtt automatizálja ezt, ellenőrizzen négy dolgot: az alagút a megfelelő fiókkal fut, a süti stdinen érkezik, a tanúsítvány ujjlenyomata rögzítve van, és a munkamenetet eldobják, amikor az alagút bezárul. Ha bármelyik hiányzik, az automatizálás kibővítette a sütibe vetett bizalmat ahelyett, hogy reprodukálta volna a kézi folyamatot.