ProtectHome kundrejt një fare TOTP: pse dështon hyrja në VPN

Autentikuesi shfaq një kod të ri gjashtëshifror, VPN e refuzon atë, dhe i njëjti kod verifikohet pa problem kur e testoni nga shell-i juaj. Ky hendek është e gjithë historia. Një modul PAM që nuk mund të hapë sekretin e regjistrimit kthen një dështim që duket identik me një kod të gabuar, dhe mjedisi i shërbimit që fsheh drejtoritë shtëpiake është një shkak i zakonshëm. Përpara se të lehtësoni çdo leje, vendosni në cilën nga tre situatat jeni.

Cili nga tre dështimet është ky?

I pari është një sekret që moduli nuk mund ta lexojë fare. I dyti është një sekret që mund ta lexojë por jo ta përditësojë. I treti është një kod që është vërtet i gabuar, zakonisht për shkak të zhvendosjes së orës ose një vlere të ripërdorur.

Ndajini duke lexuar ditarin e shërbimit dhe regjistrin e autentikimit të sistemit për një tentativë të dështuar, më pas konfirmoni cilin shërbim PAM ngarkon shtojca dhe cilën rresht moduli përdor ai shërbim. Një mesazh i përgjithshëm dështimi autentikimi nuk i dallon ata, dhe as një test manual i suksesshëm, sepse shell-i juaj nuk është mjedisi i shërbimit.

Pamja e sistemit të skedarëve të njësisë është fajtori i zakonshëm kur dështon vetëm shërbimi.

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

Opsioni A: hiqni sekretin nga shtëpia

Kur shërbimi fsheh /home dhe ju preferoni ta mbani atë mbrojtje, ruajeni sekretin diku ku ai mund ta shohë. Moduli pranon një shteg secret= dhe një llogari user= që kryen operacionet e skedarëve, gjë që lejon një depo qendrore të shërbejë shumë identitete.

Ky është opsioni i rregullt dhe ai që kërkon më shumë kujdes, sepse një depo e përbashkët e bën një drejtori të vetme kufirin e sigurisë për çdo llogari.

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

Kontrolloni tre gjëra përpara se t'i besoni: llogaria ekziston, procesi i punës i modulit mund të kalojë në të, dhe skedarët janë të tij me mënyra kufizuese. Mos përdorni ~ ose një shteg me ndryshore shtëpie së bashku me user=, dhe mos çaktivizoni kontrollet e pronësisë të modulit për të bërë një shteg të funksionojë. Mbajini të paprekura fazën e fjalëkalimit dhe pjesën tjetër të stivit.

Opsioni B: lini skedarin dhe hapni një shteg

Nëse sekreti duhet të mbetet në drejtorinë shtëpiake të përdoruesit, njësia ka nevojë për një pamje që përfshin atë drejtori të vetme pa ekspozuar çdo shtëpi në host. Një drop-in mund të shtojë një montim lidhjeje të kufizuar ngushtë nën një shtëpi të sandboxuar.

Kjo mban pronësinë për përdorues si model, me koston e një ndryshimi të njësisë që duhet rishikuar sa herë që ndryshon sandbox-i.

Dy kufij humbin lehtë. Një shteg vetëm-lexim i shtuar nën një drejtori që sandbox-i fsheh nuk e ekspozon atë, sepse prindi thjesht nuk është aty. Dhe montimi duhet të jetë i shkruajtshëm nëse moduli duhet të përditësojë gjendjen, gjë që sjell opsionin tjetër në lojë. Shkruajeni drop-in si skedar të veçantë në vend që të redaktoni njësinë e paketuar nën /usr/lib, që një përditësim pakete të mos e anulojë në heshtje.

Opsioni C: mbani sandbox-in dhe rregulloni shkrimet e gjendjes

Leximi i sekretit është vetëm gjysma e autentikimit. Moduli mund të rishkruajë informacionin e zhvendosjes së kohës, mbrojtjen nga ripërsëritja ose një numërues, dhe një skedar që kalon kontrollin e leximit mund të dështojë ende në shkrim.

Ai dështim duket si një kod i keq në tentativën tjetër dhe jo në këtë, prandaj ngatërrohet me zhvendosjen e orës.

Jepini një drejtori të vetën të shkruajtshme dhe drejtojeni shtegun e sekretit atje, në vend që të bëni të shkruajtshme të gjithë shtëpinë. Konfirmoni pronarin e drejtorisë, hapësirën e lirë të sistemit të skedarëve dhe nëse njësia kufizon shkrimet diku tjetër. Më pas provoni dy hyrje radhazi, sepse e dyta vërteton shtegun e shkrimit dhe e para vetëm leximin.

Verifikoni si shërbimi, jo si vetja

Çdo kontroll që ka rëndësi duhet të ekzekutohet brenda sandbox-it të njësisë me identitetin e njësisë.

Një komandë që ka sukses si root ju tregon se skedari ekziston dhe asgjë tjetër. Një hyrje përmes shërbimit real ju tregon nëse moduli mund të lexojë sekretin, ta përdorë dhe të shkruajë mbrapsht atë që i nevojitet.

Së fundi, mbani kërkesën të paprekur. Shtimi i një opsioni fjalëkalimi zero, pranimi i dështimeve vetëm-lexim ose heqja e sandbox-it do t'i bënin simptomat të zhdukeshin duke ndryshuar politikën. Një përdorues që detyrohet të paraqesë një kod duhet të refuzohet ende kur sekreti është i paarritshëm.