Dua pemeriksaan log masuk bukan dua faktor: VPN dan RADIUS

Menambah backend pengesahan kedua pada gateway VPN terasa seperti menambah faktor kedua. Biasanya ia menambah pemeriksaan kedua, iaitu objek berbeza dengan mod kegagalan berbeza. Sama ada kedua-duanya mesti berjaya, apa yang dibuktikan setiap satu dan apa yang berlaku apabila satu tidak tersedia ialah tiga keputusan berasingan. Salah tentukan dan gateway menjadi lebih ketat dalam demonstrasi dan lebih lemah semasa gangguan.

Apa yang sebenarnya dibuktikan backend kedua

Carian akaun tempatan membuktikan bahawa sesuatu nama wujud dalam pangkalan data dan bahawa kata laluan sepadan dengannya. Pertukaran RADIUS membuktikan bahawa pelayan RADIUS memulangkan Access-Accept untuk atribut yang diterimanya. Tiada satu pun pernyataan menyebut jenis faktor, kerana kedua-duanya mengesahkan pengetahuan. Dan panduan identiti digital NIST mengira jenis faktor yang berbeza dan pengesahnya, bukan pelayan atau gesaan.

Ada reka bentuk sah yang melibatkan kedua-dua sistem. Perkhidmatan pusat boleh mengesahkan orang itu manakala gateway menyemak secara bebas sama ada akaun itu berhak ke terowong ini. Itu kebenaran di sisi pengesahan, dan memanggilnya dua faktor mengelirukan semakan dasar dengan bukti pemilikan.

RADIUS boleh membawa faktor kedua sebenar apabila ia berada di hadapan sesuatu yang mengesahkan satu, seperti kelulusan push atau token perkakasan. Sampul itu tidak memberitahu pengesah mana yang ditunjukkan pengguna, jadi bacalah dasar backend, bukan label gateway.

AND, OR dan sandaran ialah produk berbeza

Sebelum membandingkan pelaksanaan, tentukan apa maksud kedua-duanya dalam keperluan anda. Dasar AND memerlukan setiap pemeriksaan yang dinamakan lulus, dasar OR menerima mana-mana yang berjaya, dan sandaran mencuba yang kedua hanya dalam syarat kegagalan yang dinyatakan. Ketiga-tiganya bertindak bertentangan semasa gangguan, dan biasanya hanya satu daripadanya ialah apa yang dimaksudkan oleh semakan.

Menambah dua entri backend pada skrin konfigurasi tidak mendedahkan dasar mana yang dilaksanakan produk. Sesetengah gateway merangkai pemalam mengikut urutan dan berhenti pada penolakan pertama, yang merupakan AND hanya apabila setiap pemalam wajib. Yang lain menganggap akaun tempatan sebagai pengganti, yang menjadikan gangguan pusat sebagai pintasan. Jawapan yang boleh dipercayai ialah ujian negatif terdokumen untuk setiap laluan, dijalankan terhadap binaan yang anda gunakan.

Sandaran paling patut disyaki, kerana ia wujud untuk terus berfungsi apabila sesuatu rosak. Sandaran yang menerima kata laluan tempatan setiap kali RADIUS tidak dapat dicapai telah menjadikan dasar pusat sebagai pintu kedua yang lebih lemah.

Pemeriksaan berganda OpenVPN ialah kes konkrit

OpenVPN komuniti 2.6 memerlukan sijil klien dan skrip auth-user-pass-verify yang dikonfigurasikan apabila kedua-duanya diaktifkan. Itu AND terdokumen antara pengesahan sijil dan skrip kelayakan, dan ia benar-benar dua pemeriksaan. Ia masih bukan secara automatik dua jenis faktor, kerana skrip mungkin hanya mengesahkan kata laluan.

Gabungan itu juga membiarkan persoalan perkaitan terbuka. Sijil biasanya mengenal pasti peranti manakala kelayakan mengenal pasti orang, dan tiada apa dalam aliran lalai yang memerlukan kedua-duanya merujuk kepada prinsipal yang sama. Tentukan pasangan mana yang dibenarkan, kemudian kuatkuasakan peta itu di dalam skrip pengesahan atau pada langkah kebenaran kemudian.

Mod sijil sahaja ialah satu pemeriksaan, disokong oleh kunci yang mungkin atau mungkin tidak dilindungi oleh PIN. PIN menukar kelayakan yang sama kepada pengetahuan serta pemilikan hanya jika kunci tidak boleh digunakan tanpanya. Membiarkan kunci itu tidak disulitkan pada cakera mengurangkan bahagian kedua kepada kebenaran fail.

Vendor perkakas membina saluran paip mereka sendiri, selalunya modul PAM atau pemalam RADIUS di belakang konsol web. Tingkah laku komuniti ialah rujukan tentang rupa pemeriksaan berganda, bukan penerangan bagaimana perkakas menggabungkannya.

Semak gabungan itu pada gateway anda

Baca konfigurasi sebelum mempercayai ringkasan konsol. Baris yang menentukan dasar ialah mod sijil, skrip kelayakan dan urutan pemalam.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep menunjukkan sama ada sijil diperlukan dan skrip mana yang berjalan selepasnya, dan urutan lebih penting daripada yang disiratkan oleh nama. Dump sijil memberikan identiti yang akan dilihat gateway, termasuk CN dan nombor siri yang diperlukan untuk peta perkaitan. Ujian RADIUS ialah kes negatif: kata laluan salah mesti menghasilkan Access-Reject, dan yang betul Access-Accept. Jika kelayakan yang ditolak masih menghasilkan sesi, skrip itu langsung tidak berada pada laluan pengesahan.

Kemudian jalankan kes gangguan pada instans makmal: hentikan backend wajib dan sambung dengan kelayakan yang sah. Hasil yang dijangka ialah penolakan, dan apa-apa selain itu ialah dasar sandaran yang tiada siapa mendokumenkan.

Tulis keperluan sebagai kes negatif

Keperluan yang boleh digunakan menamakan bukti, akaun yang dibenarkan mengemukakannya dan hasil apabila pengesah tiada. Ia juga menyatakan pasangan yang dibenarkan antara identiti peranti dan identiti orang. Itu lebih tepat daripada nama produk pada pesanan belian, dan ia boleh diuji.

Penerimaan harus merangkumi empat penolakan: akaun tempatan yang tidak layak, bukti wajib yang hilang, faktor kedua tidak sah dan backend wajib yang tidak dapat dicapai. Setiap penolakan memerlukan baris log yang membezakannya daripada yang lain, jika tidak insiden seterusnya bermula dengan tekaan. Catat komponen mana yang membuat setiap keputusan, kerana gateway, pelayan RADIUS dan direktori akan saling menyalahkan.

Jalankan semula empat penolakan selepas sebarang perubahan pemalam atau firmware. Ia murah, dan dasar yang dilindunginya ialah bahagian yang diperiksa penyerang terlebih dahulu.