Mengapa menyunting fail .ovpn tidak boleh menghidupkan MFA di pelayan

Anda menambah auth-user-pass pada profil, menyambung semula, dan klien meminta nama pengguna dan kata laluan. Nampak seperti MFA dihidupkan. Kemudian anda menaip kod daripada akaun yang salah, atau kod yang tamat tempoh sepuluh minit lalu, dan terowong tetap naik. Itulah gejalanya: klien berubah, pelayan tidak. Kata laluan sekali guna hanyalah faktor apabila pengesah di pelayan memutuskan sama ada ia sah untuk identiti yang menuntutnya.

Permintaan itu hanya membuktikan bahawa klien bertanya, tidak lebih

Fail .ovpn ialah dokumen di sebelah klien. Ia boleh memberitahu klien supaya meminta kelayakan, menyimpannya dalam cache atau berhenti berbuat demikian. Ia tidak boleh mendaftarkan pengguna, memasang modul PAM, atau memaksa pelayan memerlukan faktor kedua yang tidak diperiksanya sekarang.

Memasang aplikasi pengesahan pada telefon juga tidak mencipta hubungan itu. Projek Google Authenticator PAM ialah komponen pengesahan OTP yang boleh berdiri di belakang OpenVPN; ia bukan cara untuk menampal log masuk akaun Google pada profil yang diimport.

Pendaftaran ialah bahagian yang profil tidak boleh lakukan

TOTP memerlukan bahan pendaftaran yang dikongsi antara aplikasi pengesahan dan pengesahnya. Enam digit pada telefon ialah output; benih di belakangnya ialah rahsia, dan ia milik satu identiti.

Jadi pengendali memerlukan proses pendaftaran yang mengikat benih yang betul pada identiti VPN yang betul, serta laluan penggantian yang disahkan untuk telefon yang hilang. Membenarkan pengguna memuat naik fail yang dinamakan sempena nama mereka menjadikan pendaftaran sebagai peluang pengambilalihan akaun, dan menyulitkan muat naik tidak mengubahnya.

Reka bentuk berasaskan PAM tidak perlu mencipta akaun Unix berasingan bagi setiap pengguna VPN. Dokumentasi modul menyokong laluan rahsia alternatif dan akaun khusus untuk akses fail, iaitu identiti sistem fail, bukan identiti log masuk yang disahkan.

Kesilapan biasa ialah laluan rahsia tetap yang berakhir dengan satu nama pengguna, disalin daripada contoh satu pengguna. Itu demonstrasi satu identiti, bukan carian setiap pengguna, dan menggunakannya untuk setiap permintaan tidak memberikan sesiapa aplikasi pengesahan yang didaftarkan secara bebas. Tuliskan pemetaan identiti, lindungi fail benih, dan kekalkan pemeriksaan kata laluan, sijil dan akaun dalam tindanan pengesahan yang sama.

Baca tindanan PAM untuk melihat apa yang sebenarnya diperlukan

Baris seperti account required pam_permit.so tidak melaksanakan kelayakan akaun dan tidak menambah faktor. Ia membenarkan peringkat pengurusan akaun PAM itu, yang merupakan kenyataan tentang peringkat dan bukan tentang pengguna anda.

Perkara yang sama berlaku untuk pilihan pendaftaran yang longgar. Menerima pengguna tanpa rahsia berdaftar mungkin pilihan pelancaran yang disengajakan, tetapi ia bukan bukti bahawa MFA wajib, dan ia harus dicatat sebagai pengecualian sementara dengan tarikh tamat.

Selaraskan interaksi klien dengan reka bentuk pelayan

auth-user-pass

Arahan itu meminta input nama pengguna dan kata laluan. Ia tidak mengkonfigurasi PAM, tidak mencipta rekod pendaftaran, dan tidak memberitahu pelayan bahawa medan kata laluan mengandungi nilai TOTP. Integrasi pelayan dan klien mesti bersetuju tentang interaksi yang benar-benar disokong oleh penggunaan: cabaran, format kelayakan gabungan yang didokumenkan, atau aliran khusus produk.

Jangan tambah kod pada kata laluan hanya kerana klien menunjukkan satu medan. Itu hanya berfungsi di tempat pemalam pelayan menjangkakan format itu tepat, dan ia gagal secara mengelirukan di tempat lain.

Jauhkan benih dan bahan QR daripada profil dikongsi dan log diagnostik rutin. Kod yang dihantar melalui saluran log masuk yang disahkan bukan objek yang sama dengan benih yang dikeluarkan semasa pendaftaran terkawal, dan mencampurkannya dalam tiket sokongan ialah cara rahsia terlepas.

Sambungan semula, token dan ujian yang menyelesaikannya

Rancang apa yang berlaku selepas log masuk pertama yang berjaya. Kod yang diterima sebelum ini mungkin telah tamat tempoh atau ditolak sebagai main semula pada pengesahan seterusnya. auth-nocache mengawal penyimpanan kelayakan dan tidak memasang MFA, dan reneg-sec 0 bukan definisi sokongan TOTP, sesering mana pun ia muncul dalam utas forum.

Sesetengah penggunaan mengeluarkan token pengesahan selepas pemeriksaan awal supaya sambungan semula tidak bertanya lagi. Itu keputusan reka bentuk dengan tetingkap kesahihannya dan kisah pembatalannya sendiri, bukan lalai yang anda warisi.

Kemudian uji dasar kemasukan dengan klien yang benar-benar digunakan orang. Pengguna berdaftar dengan kata laluan, sijil dan kod semasa yang betul sepatutnya dapat menyambung. Kod yang salah, pengguna tanpa pendaftaran dan akaun yang dilarang masing-masing harus gagal, dan sebabnya harus kelihatan dalam log pelayan. Sehingga anda melihat penolakan itu, anda mempunyai permintaan, bukan dasar.