ProtectHome versus benih TOTP: mengapa login VPN gagal

Aplikasi autentikator menampilkan kode enam digit yang baru, VPN menolaknya, dan kode yang sama terverifikasi dengan baik saat Anda mengujinya dari shell Anda sendiri. Kesenjangan itulah seluruh ceritanya. Modul PAM yang tidak dapat membuka rahasia pendaftaran mengembalikan kegagalan yang tampak identik dengan kode salah, dan lingkungan layanan yang menyembunyikan direktori home adalah penyebab umum. Sebelum melonggarkan izin apa pun, tentukan di mana dari tiga situasi Anda berada.

Kegagalan mana dari tiga ini?

Yang pertama adalah rahasia yang tidak dapat dibaca modul sama sekali. Yang kedua adalah rahasia yang dapat dibacanya tetapi tidak dapat diperbarui. Yang ketiga adalah kode yang benar-benar salah, biasanya karena pergeseran jam atau nilai yang diputar ulang.

Pisahkan keduanya dengan membaca jurnal layanan dan log autentikasi sistem untuk satu percobaan yang gagal, lalu pastikan layanan PAM mana yang dimuat plugin dan baris modul mana yang digunakan layanan itu. Pesan kegagalan autentikasi umum tidak membedakannya, dan uji manual yang berhasil juga tidak, karena shell Anda bukan lingkungan layanan.

Tampilan sistem berkas unit adalah tersangka biasa ketika hanya layanan yang gagal.

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

Opsi A: pindahkan rahasia keluar dari home

Ketika layanan menyembunyikan /home dan Anda lebih suka mempertahankan perlindungan itu, simpan rahasia di tempat yang dapat dilihatnya. Modul menerima jalur secret= dan akun user= yang melakukan operasi berkas, yang memungkinkan penyimpanan pusat melayani banyak identitas.

Ini opsi yang rapi, dan inilah yang paling membutuhkan kehati-hatian, karena penyimpanan bersama menjadikan satu direktori sebagai batas keamanan setiap akun.

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

Periksa tiga hal sebelum mempercayainya: akun itu ada, proses kerja modul dapat beralih ke sana, dan berkas dimiliki olehnya dengan mode ketat. Jangan gunakan ~ atau jalur variabel home bersama user=, dan jangan nonaktifkan pemeriksaan kepemilikan modul agar suatu jalur berfungsi. Pertahankan tahap kata sandi dan sisa tumpukan tetap utuh.

Opsi B: biarkan berkas dan buka jalur

Jika rahasia harus tetap di direktori home pengguna, unit memerlukan tampilan yang menyertakan satu direktori itu tanpa mengekspos setiap home di host. Drop-in dapat menambahkan mount ikat yang sempit di bawah home yang disandbox.

Ini mempertahankan kepemilikan per pengguna sebagai model, dengan biaya perubahan unit yang harus ditinjau setiap kali sandbox berubah.

Dua batas mudah terlewat. Jalur hanya-baca yang ditambahkan di bawah direktori yang disembunyikan sandbox tidak mengeksposnya, karena induknya memang tidak ada. Dan mount harus dapat ditulis jika modul harus memperbarui status, yang memunculkan opsi berikutnya. Tulis drop-in sebagai berkas terpisah alih-alih mengedit unit terpaket di bawah /usr/lib, agar peningkatan paket tidak membatalkannya secara diam-diam.

Opsi C: pertahankan sandbox dan perbaiki penulisan status

Membaca rahasia hanyalah separuh autentikasi. Modul dapat menulis ulang informasi pergeseran waktu, perlindungan pemutaran ulang, atau penghitung, dan berkas yang lolos pemeriksaan baca masih dapat gagal saat menulis.

Kegagalan itu tampak seperti kode buruk pada percobaan berikutnya, bukan pada percobaan ini, sehingga disalahartikan sebagai pergeseran jam.

Beri ia direktori sendiri yang dapat ditulis dan arahkan jalur rahasia ke sana, alih-alih membuat seluruh home dapat ditulis. Pastikan pemilik direktori, ruang kosong sistem berkas, dan apakah unit membatasi penulisan di tempat lain. Lalu uji dua login berturut-turut, karena yang kedua membuktikan jalur tulis dan yang pertama hanya membuktikan baca.

Verifikasi sebagai layanan, bukan sebagai diri sendiri

Setiap pemeriksaan yang penting harus berjalan di dalam sandbox unit dengan identitas unit.

Perintah yang berhasil sebagai root memberi tahu bahwa berkas itu ada dan tidak lebih. Login melalui layanan sebenarnya memberi tahu apakah modul dapat membaca rahasia, menggunakannya, dan menuliskan kembali yang dibutuhkannya.

Terakhir, pertahankan persyaratannya. Menambahkan opsi kata sandi nol, menerima kegagalan hanya-baca, atau menghapus sandbox semuanya akan menghilangkan gejala dengan mengubah kebijakan. Pengguna yang diwajibkan menunjukkan kode tetap harus ditolak ketika rahasia tidak terjangkau.