ProtectHome TOTP hazi baten aurka: zergatik huts egiten du VPN saio-hasierak

Autentifikatzaileak sei digituko kode berri bat erakusten du, VPNak ukatzen du, eta kode bera ondo egiaztatzen da zure shell propioetatik probatzen duzunean. Tarte hori da istorio osoa. Sarrera-sekretua ireki ezin duen PAM moduloak kode oker baten berdinak dirudien hutsegitea itzultzen du, eta hasierako direktorioak ezkutatzen dituen zerbitzu-ingurunea ohiko arrazoia da. Edozein baimen lasaitzen hasi aurretik, erabaki hiru egoeretatik zein zauden.

Hiru hutsegiteetatik zein da hau?

Lehenengoa moduloak batere irakurri ezin duen sekretua da. Bigarrena irakurri bai, baina eguneratu ezin duen sekretua da. Hirugarrena benetan okerra den kode bat da, normalean erlojuaren desbiderapenagatik edo berrerabilitako balio batengatik.

Bereiz itzazu saiakera huts batentzako zerbitzuaren egunkaria eta sistemaren autentifikazio-erregistroa irakurriz, eta gero egiaztatu pluginek zein PAM zerbitzu kargatzen duen eta zerbitzu horrek zein modulo-lerro erabiltzen duen. Autentifikazio-hutsegiteko mezu orokor batek ez ditu bereizten, eta eskuzko proba arrakastatsu batek ere ez, zure shell-a ez baita zerbitzuaren ingurunea.

Unitaren fitxategi-sistemaren ikuspegia da ohiko erruduna zerbitzuak bakarrik huts egiten duenean.

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 aukera: eraman sekretua etxetik kanpora

Zerbitzuak /home ezkutatzen duenean eta zu babes horri eutsi nahi badiozu, gorde sekretua ikus dezakeen leku batean. Moduloak secret= bide bat eta fitxategi-eragiketak egiten dituen user= kontu bat onartzen ditu, eta horrek biltegi zentral bati identitate asko zerbitzatzeko aukera ematen dio.

Hau aukera txukuna da, eta arreta handiena behar duena, biltegi partekatu batek direktorio bakarra egiten baitu kontu bakoitzaren segurtasun-muga.

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

Egiaztatu hiru gauza hari fidatu aurretik: kontua existitzen da, moduluaren lan-prozesua hara alda daiteke, eta fitxategiak berak ditu modu murriztaileekin. Ez erabili ~ edo etxe-aldagaiko bide bat user=-rekin batera, eta ez desgaitu moduloaren jabetza-egiaztapenak bide bat funtziona dezan. Eutsi pasahitz-faseari eta pilaren gainerakoari osorik.

B aukera: utzi fitxategia eta ireki bide bat

Sekretuak erabiltzailearen hasierako direktorioan egon behar badu, unitateak direktorio hori bakarrik barne hartzen duen ikuspegia behar du, ostalariaren etxebizitza guztiak agerian jarri gabe. Drop-in batek sandbox-tutako etxe baten azpian mendekotasun-muntaketa estu bat gehi dezake.

Horrek erabiltzaile bakoitzeko jabetza modelo gisa mantentzen du, sandboxa aldatzen den bakoitzean berrikusi beharreko unitate-aldaketaren kostuan.

Bi muga erraz pasatzen dira oharkabean. Sandboxak ezkutatzen duen direktorio baten azpian gehitutako irakurketa-soileko bide batek ez du hura agerian uzten, gurasoa ez baitago han. Eta muntaketak idazgarria izan behar du moduloak egoera eguneratu behar badu, eta horrek hurrengo aukera dakar. Idatzi drop-in fitxategi bereizi gisa /usr/lib azpiko unitate paketatua editatu beharrean, paketearen eguneraketak isilpean desegin ez dezan.

C aukera: mantendu sandboxa eta konpondu egoera-idazketak

Sekretua irakurtzea autentifikazioaren erdia baino ez da. Moduloak denbora-desbiderapenaren informazioa, errepikapenaren aurkako babesa edo kontagailu bat berridatz ditzake, eta irakurketa-egiaztapena gainditzen duen fitxategi batek idazketan huts egin dezake oraindik.

Hutsegite horrek kode txar baten itxura du hurrengo saiakeran, ez honetan, eta horregatik nahasten da erlojuaren desbiderapenarekin.

Eman iezazkiozu bere idazgarria den direktorio bat eta zuzendu sekretuaren bidea hara, etxe osoa idazgarri egin beharrean. Egiaztatu direktorioaren jabea, fitxategi-sistemako leku librea eta unitateak beste nonbait idazketak mugatzen ote dituen. Gero probatu jarraiko bi saio-hasiera, bigarrenak idazketa-bidea frogatzen baitu eta lehenak irakurketa soilik.

Egiaztatu zerbitzu gisa, ez zeure burua bezala

Garrantzitsua den egiaztapen bakoitzak unitatearen sandboxaren barruan exekutatu behar du, unitatearen identitatearekin.

Root gisa arrakasta duen komando batek fitxategia badagoela esaten dizu, eta besterik ez. Benetako zerbitzuaren bidezko saio-hasierak esaten dizu moduloak sekretua irakurri, erabili eta behar duena atzera idatz dezakeen.

Azkenik, mantendu baldintza osorik. Pasahitz nuluko aukera gehitzeak, irakurketa-soileko hutsegiteak onartzeak edo sandboxa kentzeak sintoma desagerraraziko lukete politika aldatuz. Kode bat aurkeztu behar duen erabiltzaileari uko egin behar zaio sekretua eskuraezina denean ere.