Pemalam masih disyorkan dalam urutan yang lebih lama daripada binaan semasa, dan ia gagal semasa dimuatkan pada pelayan yang dikompil semalam. Ini bukan kesilapan konfigurasi yang boleh dibaiki dengan laluan. Pemalam dan cangkuk skrip menyelesaikan masalah yang sama pada lapisan berbeza, dan peralihan daripada satu ke yang lain mengubah apa yang perlu dipasang, apa yang berjalan dengan keistimewaan pelayan, dan apa yang sebenarnya diberitahu oleh log masuk yang gagal.

Mitos: pemalam ialah laluan yang disokong

Pemalam ialah objek kongsi yang dimuatkan ke dalam proses OpenVPN, jadi ia mesti sepadan dengan antara muka yang didedahkan oleh proses itu. Binaan berubah, pembungkusan berubah, dan pustaka yang dikompil untuk antara muka lama hanya menolak untuk dimuatkan. Tiada apa dalam konfigurasi pelayan boleh merapatkan jurang itu, sebab itu nasihat "hanya pasang radiusplugin" berakhir dengan pelayan yang tidak bermula.

Cangkuk skrip sebaliknya berdiri di luar proses. OpenVPN menjalankan program, menyerahkan kelayakan kepadanya dan membaca keputusan. Pemisahan itulah yang membolehkannya bertahan melalui peningkatan, dan ia juga yang menjadikannya tanggungjawab anda dengan cara pemalam tidak pernah menjadi.

Tiada pendekatan yang lebih selamat dari segi binaan. Satu menjalankan kod asing di dalam daemon; yang lain menjalankan kod anda di sebelahnya dengan kelayakan di tangan. Soalan yang betul ialah risiko mana antara dua ini yang benar-benar boleh anda kendalikan.

Apa yang diikat oleh pemalam

Pemalam membawa fail konfigurasinya sendiri dengan hos RADIUS, rahsia kongsi, bilangan percubaan semula dan had masa, dan konfigurasi pelayan merujuknya dengan satu baris. Pengendalian kelayakan kekal di dalam proses pelayan, bermakna kata laluan tidak pernah melintasi sempadan proses yang perlu dilindungi oleh pentadbir.

Kosnya ialah gandingan. Setiap peningkatan OpenVPN berisiko antara muka tidak serasi, dan setiap distribusi yang membina semula pakej berisiko menghasilkan pustaka yang tidak lagi sepadan. Apabila itu berlaku, kegagalan itu kuat dan serta-merta, dan itulah satu-satunya belas kasihan reka bentuk ini.

Jika pemalam sebegitu masih dimuatkan pada binaan anda, ia mungkin permukaan operasi yang lebih kecil. Sahkan antara muka yang digunakan untuk membinanya, kekalkan ia dipinkan pada binaan yang anda uji, dan anggap setiap peningkatan sebagai perubahan yang memerlukan ujian log masuk penuh, bukan kemas kini pakej rutin.

Apa yang sebenarnya dipercayai oleh cangkuk skrip

Cangkuk dikonfigurasikan dengan auth-user-pass-verify dan mekanisme penghantaran: pemboleh ubah persekitaran atau fail sementara. Dalam bentuk persekitaran, OpenVPN memerlukan script-security 3, tahap berdokumen yang membenarkan pendedahan kata laluan kepada skrip. Tahap itu ialah kelemahan lalai yang disengajakan, dan ia harus dianggap sebagai kebenaran dengan justifikasi dilampirkan.

Segala yang disentuh skrip mewarisi kepercayaan itu. Ia mesti dimiliki root, tidak boleh ditulis oleh kumpulan atau orang lain, dirujuk dengan laluan mutlak, dan bebas daripada mana-mana tempat nilai tidak dipercayai sampai ke shell. Letakkan setiap pemboleh ubah dalam petikan, tolak aksara tidak dijangka, dan jangan sekali-kali membina arahan daripada nama pengguna yang diberikan. Skrip yang berjalan sebagai root pada setiap percubaan log masuk wajar disemak sekali kerana tepat empat sifat itu.

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

Bentuk penghantaran fail mengelakkan masalah warisan persekitaran dan menyerahkan kelayakan kepada skrip melalui fail sementara dengan kebenaran terhad. Jika klien anda menyokongnya, ia biasanya lalai yang lebih baik, walaupun menambah satu lagi objek untuk dibersihkan apabila gagal.

Kod keluar menentukan sama ada anda gagal terbuka

Status keluar skrip ialah keputusan: sifar menerima, bukan sifar menolak. Corak yang menimbulkan masalah ialah skrip shell yang hanya menerima apabila balasan RADIUS mengandungi token penerimaan tertentu dan mengembalikan kegagalan untuk semua yang lain, kerana itu melakurkan tiga peristiwa berbeza menjadi satu jawapan. Kata laluan salah, pelayan tidak dapat dicapai dan balasan cacat semuanya menjadi penolakan yang sama.

Asingkan kes itu dalam skrip walaupun cangkuk hanya boleh mengembalikan terima atau tolak. Log hasil backend secara berasingan, beri amaran tentang tamat masa dan ralat pengangkutan, dan jadikan jelas dalam pemantauan apabila pengesahan gagal kerana perkhidmatan tidak berjalan dan bukan kerana pengguna tersalah menaip.

Dua tabiat memastikan selebihnya waras. Jika RADIUS ialah pihak berkuasa, ia sepatutnya menjadi satu-satunya tempat kata laluan diperiksa, kerana jadual bayangan mencipta dua jawapan kepada soalan yang sama dan yang kedua ialah permukaan serangan yang tiada siapa memantau. Dan ingat cangkuk dipanggil semula pada setiap percubaan, jadi skrip perlahan dengan klien tidak sabar menjadi penguat untuk meneka kata laluan melainkan anda menambah kelewatan atau dasar di pihak RADIUS.

Apa yang anda lepaskan apabila sijil hilang

Banyak penggunaan bentuk ini mematikan pemeriksaan sijil klien sepenuhnya, meninggalkan nama pengguna dan kata laluan sebagai keseluruhan tuntutan klien. Apa yang hilang dengan tetapan itu ialah identiti berasaskan sijil. Saluran kekal disulitkan, tetapi satu-satunya yang menamakan klien ialah keputusan RADIUS. Apa-apa di hiliran yang dahulunya bergantung pada subjek sijil kini mesti bergantung pada nama pengguna.

Kekalkan perlindungan saluran kawalan supaya rakan yang tidak disahkan tidak boleh menyiasat atau membanjiri jabat tangan, dan gunakan username-as-common-name apabila konfigurasi setiap pengguna bergantung pada nama umum. Get laluan terurus sering menyelesaikannya secara berbeza, menamatkan pengesahan sijil di get laluan yang bercakap EAP-TLS dengan RADIUS, dan dalam kes itu tiada satu pun arahan pelayan ini terpakai. Salin model yang didokumenkan oleh platform anda sendiri, bukan model produk jiran. Arahan penting cukup berbeza sehingga mencampurkannya menghasilkan konfigurasi yang dihuraikan dan kemudian tidak mengesahkan sesiapa.

Artikel berkaitan