Dua pemeriksaan login bukan dua faktor: VPN dan RADIUS

Menambahkan backend autentikasi kedua ke gateway VPN terasa seperti menambahkan faktor kedua. Biasanya itu menambahkan pemeriksaan kedua, yang merupakan objek berbeda dengan mode kegagalan berbeda. Apakah keduanya harus berhasil, apa yang dibuktikan masing-masing, dan apa yang terjadi saat salah satu tidak tersedia adalah tiga keputusan terpisah. Salah menentukan dan gateway menjadi lebih ketat dalam demonstrasi dan lebih lemah saat gangguan.

Apa yang sebenarnya dibuktikan backend kedua

Pencarian akun lokal membuktikan bahwa sebuah nama ada di basis data dan bahwa sebuah kata sandi cocok dengannya. Pertukaran RADIUS membuktikan bahwa server RADIUS mengembalikan Access-Accept untuk atribut yang diterimanya. Tidak satu pun pernyataan menyebut jenis faktor, karena keduanya memverifikasi pengetahuan. Dan panduan identitas digital NIST menghitung jenis faktor yang berbeda dan pengautentikasinya, bukan server atau petunjuk.

Ada rancangan sah di mana kedua sistem berperan. Layanan pusat dapat mengautentikasi orangnya sementara gateway secara independen memeriksa apakah akun itu berhak atas terowongan ini. Itu otorisasi di samping autentikasi, dan menyebutnya dua faktor mencampur pemeriksaan kebijakan dengan bukti kepemilikan.

RADIUS dapat membawa faktor kedua yang nyata ketika berada di depan sesuatu yang memverifikasi satu, seperti persetujuan push atau token perangkat keras. Amplop itu tidak memberi tahu pengautentikasi mana yang ditunjukkan pengguna, jadi bacalah kebijakan backend, bukan label gateway.

AND, OR dan cadangan adalah produk berbeda

Sebelum membandingkan implementasi, tentukan apa arti keduanya dalam kebutuhan Anda. Kebijakan AND mengharuskan setiap pemeriksaan yang disebut lolos, kebijakan OR menerima mana pun yang berhasil, dan cadangan hanya mencoba yang kedua dalam kondisi kegagalan yang dinyatakan. Ketiganya berperilaku berlawanan saat gangguan, dan biasanya hanya satu yang dimaksud tinjauan.

Menambahkan dua entri backend ke layar konfigurasi tidak mengungkap kebijakan mana yang diterapkan produk. Beberapa gateway merangkai plugin secara berurutan dan berhenti pada penolakan pertama, yang merupakan AND hanya bila setiap plugin wajib. Yang lain memperlakukan akun lokal sebagai pengganti, yang mengubah gangguan pusat menjadi jalan pintas. Jawaban yang andal adalah uji negatif terdokumentasi untuk setiap jalur, dijalankan terhadap build yang Anda terapkan.

Cadangan paling patut dicurigai, karena keberadaannya untuk tetap bekerja ketika sesuatu rusak. Cadangan yang menerima kata sandi lokal setiap kali RADIUS tidak terjangkau telah mengubah kebijakan pusat menjadi pintu kedua yang lebih lemah.

Pemeriksaan ganda OpenVPN adalah kasus konkret

OpenVPN komunitas 2.6 memerlukan sertifikat klien dan skrip auth-user-pass-verify yang dikonfigurasi bila keduanya diaktifkan. Itu AND terdokumentasi antara verifikasi sertifikat dan skrip kredensial, dan itu benar-benar dua pemeriksaan. Itu tetap bukan otomatis dua jenis faktor, karena skrip mungkin hanya memvalidasi kata sandi.

Kombinasi itu juga membiarkan pertanyaan asosiasi terbuka. Sertifikat biasanya mengidentifikasi perangkat sementara kredensial mengidentifikasi orang, dan tidak ada dalam alur bawaan yang mengharuskan keduanya merujuk ke principal yang sama. Tentukan pasangan mana yang diizinkan, lalu tegakkan peta itu di dalam skrip verifikasi atau pada langkah otorisasi berikutnya.

Mode hanya sertifikat adalah satu pemeriksaan, didukung kunci yang mungkin atau tidak dilindungi PIN. PIN mengubah kredensial yang sama menjadi pengetahuan plus kepemilikan hanya jika kunci tidak dapat digunakan tanpanya. Membiarkan kunci itu tidak terenkripsi di disk mengurangi bagian kedua menjadi izin berkas.

Vendor peralatan membangun perpipaan sendiri, sering modul PAM atau plugin RADIUS di belakang konsol web. Perilaku komunitas adalah rujukan tampilan pemeriksaan ganda, bukan deskripsi bagaimana peralatan menggabungkannya.

Periksa kombinasinya di gateway Anda

Baca konfigurasi sebelum memercayai ringkasan konsol. Baris yang menentukan kebijakan adalah mode sertifikat, skrip kredensial dan urutan plugin.

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 apakah sertifikat diperlukan dan skrip mana yang berjalan setelahnya, dan urutannya lebih penting daripada yang disiratkan namanya. Dump sertifikat memberi identitas yang akan dilihat gateway, termasuk CN dan nomor seri yang Anda butuhkan untuk peta asosiasi. Uji RADIUS adalah kasus negatif: kata sandi salah harus menghasilkan Access-Reject, dan yang benar Access-Accept. Jika kredensial yang ditolak masih menghasilkan sesi, skrip itu sama sekali tidak berada di jalur autentikasi.

Lalu jalankan kasus gangguan pada instans laboratorium: hentikan backend wajib dan sambungkan dengan kredensial valid. Hasil yang diharapkan adalah penolakan, dan apa pun selain itu adalah kebijakan cadangan yang tidak didokumentasikan siapa pun.

Tulis kebutuhan sebagai kasus negatif

Kebutuhan yang dapat dipakai menyebut bukti, akun yang diizinkan menyajikannya dan hasil saat verifikator tidak ada. Itu juga menyatakan pasangan yang diizinkan antara identitas perangkat dan identitas orang. Itu lebih tepat daripada nama produk pada pesanan pembelian, dan dapat diuji.

Penerimaan harus mencakup empat penolakan: akun lokal tidak layak, bukti wajib yang hilang, faktor kedua tidak sah dan backend wajib yang tidak terjangkau. Setiap penolakan memerlukan baris log yang membedakannya dari yang lain, atau insiden berikutnya dimulai dengan dugaan. Catat komponen mana yang mengambil setiap keputusan, karena gateway, server RADIUS dan direktori akan saling menyalahkan.

Jalankan ulang empat penolakan setelah setiap perubahan plugin atau firmware. Itu murah, dan kebijakan yang dilindunginya adalah bagian yang pertama diperiksa penyerang.