ProtectHome kontra TOTP-mag: miért sikertelen a VPN-bejelentkezés

A hitelesítő egy friss hatjegyű kódot mutat, a VPN elutasítja, és ugyanaz a kód hibátlanul ellenőrződik, amikor a saját shelljéből teszteli. Ez a szakadék a teljes történet. Az a PAM-modul, amely nem tudja megnyitni a regisztrációs titkot, a rossz kódhoz hasonlóan kinéző hibát ad vissza, és a szolgáltatási környezet, amely elrejti a saját könyvtárakat, gyakori ok. Mielőtt bármilyen engedélyt lazítana, döntse el, melyik a három helyzet közül.

Melyik a három hiba közül?

Az első egy titok, amelyet a modul egyáltalán nem tud olvasni. A második egy titok, amelyet olvasni tud, de frissíteni nem. A harmadik egy valóban hibás kód, általában óraelcsúszás vagy újrajátszott érték miatt.

Különítse el őket a szolgáltatás naplójának és a rendszer hitelesítési naplójának egyetlen sikertelen kísérletre való átolvasásával, majd erősítse meg, melyik PAM-szolgáltatást tölti be a bővítmény, és melyik modulsort használja az a szolgáltatás. Az általános hitelesítési hibaüzenet nem különbözteti meg őket, és a sikeres kézi teszt sem, mert a shellje nem a szolgáltatás környezete.

Az egység fájlrendszer-nézete a szokásos bűnös, amikor csak a szolgáltatás hibázik.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

A lehetőség: vigye ki a titkot az otthonból

Amikor a szolgáltatás elrejti a /home könyvtárat, és inkább megtartaná ezt a védelmet, tárolja a titkot ott, ahol látja. A modul elfogad egy secret= útvonalat és egy user= fiókot, amely a fájlműveleteket végzi, így egy központi tároló sok identitást szolgálhat ki.

Ez a rendezett lehetőség, és ez igényli a legtöbb gondosságot, mert a megosztott tároló egyetlen könyvtárat tesz minden fiók biztonsági határává.

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

Ellenőrizzen három dolgot, mielőtt megbízik benne: a fiók létezik, a modul munkafolyamata át tud rá váltani, és a fájlok az övéi szigorú módokkal. Ne használjon ~ vagy otthonváltozós útvonalat a user= mellett, és ne kapcsolja ki a modul tulajdonjog-ellenőrzéseit egy útvonal működéséhez. Tartsa érintetlenül a jelszószakaszt és a verem többi részét.

B lehetőség: hagyja a fájlt, és nyisson utat

Ha a titoknak a felhasználó saját könyvtárában kell maradnia, az egységnek olyan nézetre van szüksége, amely tartalmazza ezt az egy könyvtárat anélkül, hogy a gazdagép minden otthonát felfedné. Egy drop-in szűken határolt bind mountot adhat hozzá egy sandboxolt otthon alá.

Ez megtartja a felhasználónkénti tulajdonjogot modellként, egy olyan egységmódosítás árán, amelyet a sandbox minden változásakor felül kell vizsgálni.

Két határ könnyen elkerüli a figyelmet. A sandbox által elrejtett könyvtár alá hozzáadott csak olvasható útvonal nem fedi fel azt, mert a szülő egyszerűen nincs ott. És a mountnak írhatónak kell lennie, ha a modulnak frissítenie kell az állapotot, ami a következő lehetőséget hozza játékba. A drop-int külön fájlként írja, ne a /usr/lib alatti csomagolt egységet szerkessze, hogy egy csomagfrissítés ne vonja vissza csendesen.

C lehetőség: tartsa meg a sandboxot, és javítsa az állapotírásokat

A titok olvasása csak a hitelesítés fele. A modul átírhatja az időeltolódási információkat, az újrajátszás elleni védelmet vagy egy számlálót, és egy olvasási ellenőrzést átlépő fájl még mindig elbukhat az íráson.

Ez a hiba a következő kísérletnél látszik rossz kódnak, nem ennél, ezért keverik össze óraelcsúszással.

Adjon neki saját írható könyvtárat, és irányítsa oda a titok útvonalát, ahelyett hogy az egész otthont írhatóvá tenné. Erősítse meg a könyvtár tulajdonosát, a fájlrendszer szabad helyét és azt, hogy az egység korlátoz-e írásokat máshol. Aztán teszteljen két egymást követő bejelentkezést, mert a második bizonyítja az írási utat, az első csak az olvasást.

A szolgáltatásként ellenőrizzen, ne önmagaként

Minden fontos ellenőrzésnek az egység sandboxán belül, az egység identitásával kell futnia.

Egy rootként sikeres parancs azt mondja meg, hogy a fájl létezik, és semmi mást. A tényleges szolgáltatáson keresztüli bejelentkezés megmondja, hogy a modul tudja-e olvasni, használni és visszaírni a szükségeset.

Végül tartsa érintetlenül a követelményt. Egy nulljelszavas lehetőség hozzáadása, a csak olvasható hibák elfogadása vagy a sandbox eltávolítása mind megszüntetné a tünetet a szabályzat megváltoztatásával. A kód bemutatására kötelezett felhasználót továbbra is el kell utasítani, amikor a titok elérhetetlen.