auth-nocache hitelesítőadat-fájllal: segít vagy árt?

OpenVPN indításkor figyelmeztetést ír ki, amely javasolja a auth-nocache beállítást, és a csábító válasz az, hogy hozzáadjuk az opciót, és nézzük, ahogy a sor eltűnik. Ez a tanács interaktív bejelentkezést feltételez. Amint a felhasználónév és a jelszó fájlban él, az összehasonlítás megváltozik: az opció felhagy a tartós másolat védelmével, és a privilegiumokat leadó kliensen később elbonthatja az újratárgyalást. Két tárolási modellt érdemes külön tartani, mielőtt szerkesztenénk egy profilt.

Két módja a hitelesítő adatok kérésének megválaszolására

Az első modell egy ember, aki terminálba gépeli a hitelesítő adatokat, vagy egy kezelőfelület, amely a munkamenet idejére tartja őket. Az OpenVPN megtartja ezt a másolatot, hogy a következő újratárgyalást újrakérdezés nélkül megválaszolhassa, és a figyelmeztetés éppen erről szól. A lemezen semmi nem érintett, így az egyetlen védendő dolog az a folyamat, amely az értéket tartja. Zárd be a klienst, és a másolat vele együtt eltűnik.

A második modell a auth-user-pass , amely fájlra mutat, ahol a fájl a tároló, és a kliens akkor olvassa, amikor értékre van szükség. Az itt számító kitettség nem a folyamat memóriája, hanem a fájl jogosultságai és tulajdonosa. Az indítási figyelmeztetés a konfiguráció direktíváiból jön, nem abból, hogyan adod meg a jelszót, ezért mindkét modellben megjelenik, és egyikre sem mutat.

Az összehasonlítás többi része ebből a felosztásból következik: memóriakezelés az egyik modellhez, fájlkezelés és folyamatidentitás a másikhoz.

Mit dob ki valójában az auth-nocache

Interaktív bejelentkezésnél a --auth-nocache eltávolítja a tárolt másolatot a memóriából, miután használták. Az ár egy új kérés minden újratárgyalási intervallumban, mert a következő kör nem használhatja fel újra, amit kidobtak.

Fájlalapú bejelentkezésnél a kliens újra olvashatja a fájlt, így a kidobás többnyire láthatatlan. Egyetlen helyen válik láthatóvá, ahol az emberek nem számítanak rá: miután a démon leadta a privilegiumokat, ha a hitelesítőadat-fájl nem olvasható annak a fióknak, amely alatt most fut.

Az opciót azért add hozzá, mert érted ezt a cserét, nem azért, mert figyelmeztetés jelent meg. Az opció, amelyet a napló csendesítéséért adnak hozzá, olyan opció, amelynek hatását senki nem mérte.

Hol törik meg a fájlalapú útvonal

Az a kliens, amely rootként indul, hogy megnyissa az alagút-eszközt, majd átvált user és group értékre, kétszer olvassa a hitelesítőadat-fájlt: egyszer a váltás előtt, egyszer az azt követő újratárgyalásnál. Ha a fájl módja 600, és a tulajdonosa root, a második olvasás meghiúsul, és a hiba egy órával később hitelesítési hibaként jelenik meg, amely szerverproblémának látszik. Nézd meg a kliens naplóját az újratárgyalási intervallum körül, majd a fiókot és a fájlt együtt.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

Mindkét sor számít. Az első megmondja, ki olvashatja a fájlt, a második megmondja, ki a futó démon valójában, és a kettő közötti eltérés olyan hibát magyaráz, amelyet semmilyen jelszó-újragépelés nem javít meg.

A gyakorlati javítások nem csillogóak: mozgasd a fájlt olyan könyvtárba és tulajdonoshoz, amelyet a démon fiókja olvashat, vagy tartsd meg a privilegizált olvasást, és erősítsd meg, hogy a klienst csak egyszer olvas. Ne oldd meg úgy, hogy a fájlt mindenki számára olvashatóvá teszed.

Az eset, amely valóban kéri az opciót

Az egyszeri kódot hordozó bejelentkezés auth-nocache akar, más okból. Az egyszeri kódot az első hitelesítés elhasználja, így a gyorsítótárazott másolat haszontalan a következő újratárgyalásnál, és egy elavult érték akár újra is játszható.

Ez a hitelesítő adat típusáról szóló kérdés, nem arról, hol tárolják. A védett fájlban lévő statikus jelszó profilja az ellenkező: minden újratárgyalásnál olvashatónak kell lennie, és a szükséges védelem a fájlon van.

Tartsd külön ezt a két okot a profil megjegyzéseiben, különben a következő rendszergazda azt feltételezi, hogy az opció azért van ott, amiért ő választotta volna.

Az összehasonlítás egy döntésben

Válaszd az interaktív modellt, ha jelen van egy ember, és számít a frissesség, és fogadd el az ismételt kérést az áraként. Válaszd a fájlmodellt, ha a kliens felügyelet nélkül fut, és a fáradságot a tulajdonjogra, a módra és a privilegiumok leadására fordítsd.

Egyik modell sem teszi önmagában biztonságossá a tárolt jelszót, és egyik sem teszi jelentőssé az indítási figyelmeztetést.

Ha a figyelmeztetés az egyetlen ok, amiért megnyitottad a profilt, jegyezd fel a döntést egy megmagyarázatlan opció helyett: a hitelesítő adatok olyan fájlból jönnek, amelyet a démon fiókja olvashat, egy újratárgyalás sikeresnek látszott, és az OpenVPN 2.6 kézikönyv újratárgyalásról szóló része az intervallum megváltoztatása előtt elolvasásra került. Ez a feljegyzés minden egyes kapcsolónál tovább él.