ProtectHome laban sa isang binhi ng TOTP: bakit nabibigo ang pag-login sa VPN

Nagpapakita ang authenticator ng bagong anim na digit na code, tinatanggihan ito ng VPN, at ang parehong code ay nagbe-verify nang maayos kapag sinusubukan mo mula sa sarili mong shell. Ang agwat na iyon ang buong kuwento. Ang PAM module na hindi mabuksan ang lihim ng enrollment ay nagbabalik ng pagkabigo na mukhang kapareho ng maling code, at ang kapaligiran ng serbisyo na nagtatago ng mga home directory ay karaniwang dahilan. Bago magluwag ng anumang pahintulot, magpasya kung alin sa tatlong sitwasyon ka naroroon.

Aling sa tatlong pagkabigo ito?

Ang una ay isang lihim na hindi mabasa ng module. Ang pangalawa ay isang lihim na nababasa nito ngunit hindi ma-update. Ang pangatlo ay isang code na talagang mali, kadalasan dahil sa pag-anod ng orasan o isang value na muling ginamit.

Paghiwalayin ang mga ito sa pamamagitan ng pagbasa ng journal ng serbisyo at log ng authentication ng system para sa isang nabigong pagtatangka, pagkatapos ay kumpirmahin kung aling PAM service ang nilo-load ng plugin at kung aling module line ang ginagamit ng serbisyong iyon. Ang pangkalahatang mensahe ng pagkabigo sa authentication ay hindi nagtatangi sa kanila, at gayundin ang matagumpay na manu-manong pagsubok, dahil ang shell mo ay hindi ang kapaligiran ng serbisyo.

Ang view ng filesystem ng unit ang karaniwang salarin kapag ang serbisyo lang ang nabibigo.

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

Opsyon A: ilabas ang lihim mula sa home

Kapag itinago ng serbisyo ang /home at mas gusto mong panatilihin ang proteksyong iyon, itago ang lihim sa lugar na nakikita nito. Tumatanggap ang module ng path na secret= at account na user= na gumagawa ng mga operasyon sa file, na nagpapahintulot sa sentral na imbakan na maglingkod sa maraming pagkakakilanlan.

Ito ang maayos na opsyon, at ito ang nangangailangan ng pinakamaraming pag-iingat, dahil ginagawang isang direktoryo ng nakabahaging imbakan ang hangganan ng seguridad ng bawat account.

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

Suriin ang tatlong bagay bago mo ito pagkatiwalaan: umiiral ang account, makakalipat ang proseso ng trabaho ng module dito, at pag-aari nito ang mga file na may mahigpit na mode. Huwag gumamit ng ~ o path na may home variable kasama ng user=, at huwag patayin ang mga pagsusuri ng pagmamay-ari ng module para gumana ang isang path. Panatilihing buo ang yugto ng password at ang natitirang stack.

Opsyon B: iwanan ang file at magbukas ng path

Kung kailangang manatili ang lihim sa home ng user, kailangan ng unit ng view na kasama ang nag-iisang direktoryong iyon nang hindi inilalantad ang bawat home sa host. Ang drop-in ay makakapagdagdag ng makitid na bind mount sa ilalim ng naka-sandbox na home.

Pinapanatili nito ang pagmamay-ari kada user bilang modelo, kapalit ng pagbabago sa unit na dapat suriin sa tuwing magbabago ang sandbox.

Dalawang limitasyon ang madaling makaligtaan. Ang read-only na path na idinagdag sa ilalim ng direktoryo na itinatago ng sandbox ay hindi ito inilalantad, dahil wala talaga ang magulang. At dapat na maisusulat ang mount kung kailangang i-update ng module ang estado, na nagdadala ng susunod na opsyon. Isulat ang drop-in bilang hiwalay na file sa halip na i-edit ang naka-package na unit sa ilalim ng /usr/lib, upang hindi ito tahimik na bawiin ng pag-upgrade ng package.

Opsyon C: panatilihin ang sandbox at ayusin ang pagsusulat ng estado

Ang pagbasa ng lihim ay kalahati lang ng authentication. Maaaring muling isulat ng module ang impormasyon ng time skew, proteksyon sa replay o counter, at ang file na pumasa sa check ng pagbasa ay maaari pa ring mabigo sa pagsusulat.

Ang pagkabigong iyon ay mukhang masamang code sa susunod na pagtatangka at hindi sa isang ito, kaya napagkakamalang pag-anod ng orasan.

Bigyan ito ng sariling maisusulat na direktoryo at ituro doon ang path ng lihim, sa halip na gawing maisusulat ang buong home. Kumpirmahin ang may-ari ng direktoryo, ang libreng espasyo ng filesystem at kung nililimitahan ng unit ang mga pagsusulat sa ibang lugar. Pagkatapos ay subukan ang dalawang sunod-sunod na login, dahil ang pangalawa ay nagpapatunay ng path ng pagsusulat at ang una ay pagbasa lamang.

I-verify bilang serbisyo, hindi bilang sarili mo

Bawat mahalagang pagsusuri ay dapat tumakbo sa loob ng sandbox ng unit gamit ang pagkakakilanlan ng unit.

Ang command na nagtagumpay bilang root ay nagsasabi lamang na umiiral ang file at wala nang iba. Ang login sa pamamagitan ng aktwal na serbisyo ay nagsasabi kung mababasa ng module ang lihim, magagamit ito at maisusulat pabalik ang kailangan nito.

Sa huli, panatilihing buo ang kinakailangan. Ang pagdaragdag ng null-password na opsyon, pagtanggap ng read-only na pagkabigo o pagtanggal ng sandbox ay pawang magpapawala ng sintomas sa pamamagitan ng pagbabago ng patakaran. Ang user na kinakailangang magpakita ng code ay dapat pa ring tanggihan kapag hindi maabot ang lihim.