Perkhidmatan MFA mati: putuskan akses VPN sebelum gagal

Akses VPN berhenti, dan amaran menyatakan perkhidmatan faktor kedua tidak dapat dicapai. Sama ada seseorang masih boleh menyambung ialah soalan dasar yang sepatutnya dijawab sebelum gangguan, bukan semasanya. Pengesah yang tidak tersedia bukan bukti bahawa faktor telah lulus, dan cabaran yang ditolak bukan peristiwa yang sama dengan yang tidak dapat dicapai. Runbook di bawah menukar perbezaan itu menjadi peraturan bertulis yang boleh anda uji.

Langkah 1: namakan tiga hasil secara berasingan

Tulis tiga keadaan dan enggan menggabungkannya: pengesahan utama gagal, cabaran faktor kedua ditolak atau tamat tempoh, dan perkhidmatan MFA tidak pernah menjawab. Setiap satu mempunyai pemilik berbeza, baris log berbeza dan respons betul yang berbeza. Satu mesej tamat masa generik menyembunyikan yang mana anda berada, dan kekaburan itulah yang menukar gangguan menjadi perdebatan. Namakan keadaan itu dalam runbook sebelum anda memerlukannya.

Penolakan bermakna pengesah menjawab dan berkata tidak, yang merupakan hasil dasar dan bukan masalah ketersediaan. Cubaan tamat tempoh bermakna cabaran wujud dan tiada siapa menyelesaikannya tepat pada masanya. Perkhidmatan tidak dapat dicapai bermakna soalan itu tidak dijawab sama sekali. Hanya yang ketiga ialah gangguan.

Langkah 2: baca mod kegagalan yang benar-benar digunakan oleh proksi

Cari tetapan yang mengawal tingkah laku apabila perkhidmatan tidak dapat dihubungi, dan bacanya daripada konfigurasi yang berjalan, bukan daripada templat. Dalam proksi RADIUS Duo, nilai failmode yang didokumenkan ialah safe dan secure, dengan safe hanya membenarkan cubaan apabila pengesahan utama berjaya, dan secure menolak cubaan dalam keadaan itu.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

Nama safe menerangkan pilihan ketersediaan, bukan jaminan bahawa setiap sesi yang diterima mempunyai faktor kedua yang baharu. Ayat itu tergolong dalam daftar risiko, kerana itulah tepatnya pertukaran yang dibuat oleh tetapan ini. Jangan umumkan nilai itu kepada pembekal lain, integrasi lain atau mod proksi yang berbeza; baca dokumentasi produk itu untuk persamaannya sendiri. Konfigurasi yang disalin daripada contoh vendor tanpa pemahaman ini ialah kejutan yang menunggu gangguan seterusnya.

Berhenti jika tiada siapa dapat menyatakan mod mana yang aktif. Baki runbook bergantung pada jawapan itu.

Langkah 3: selaraskan cubaan semula dengan aliran

Selaraskan tamat masa dan tingkah laku cubaan semula gateway dengan aliran pengesahan yang dipandunya. Cubaan semula yang tidak diselaraskan mencipta berbilang gesaan, mengelirukan padanan cubaan dan membiarkan log tidak dapat menyatakan hasil mana milik log masuk mana. Tamat masa yang sangat panjang bukan reka bentuk ketersediaan; ia penantian lebih lama untuk jawapan yang sama.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

Tamat masa permintaan proksi itu sendiri ialah had berasingan: permintaan pengesahan yang dikeluarkan dan tidak pernah diselesaikan akan ditolak, dan penolakan itu bukan gangguan untuk berundur daripadanya. Anggap penolakan, cabaran yang belum selesai dan perkhidmatan yang tidak dapat dicapai sebagai tiga input berbeza dalam jadual keputusan anda. Kemudian jadikan jadual itu eksplisit: keadaan mana yang menerima, keadaan mana yang menahan dan keadaan mana yang dieskalasi kepada manusia.

Jika dua komponen kedua-duanya mencuba semula, betulkan dahulu pemilikan cubaan semula. Gesaan berganda ialah gejala dua pemilik, bukan perkhidmatan yang perlahan.

Langkah 4: tadbir akses kecemasan secara berasingan

Jika akses kecemasan diperlukan, berikannya skop, identiti, kebenaran dan jejak audit tersendiri. Melumpuhkan MFA secara senyap untuk semua pengguna bukan prosedur kecemasan; ia pelemahan kekal dengan insiden terlekat padanya. Pemilik keselamatan meluluskan peraturan kemasukan, keterlihatan dan laluan eskalasi lebih awal.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Uji seluruh matriks dalam persekitaran bukan pengeluaran: kegagalan utama, penolakan sengaja, tamat tempoh cabaran dan ketidaktersediaan perkhidmatan. Bagi setiap satu, catat hasil kemasukan dan sebab yang direkodkan. Jangan cipta gangguan pengeluaran untuk menemui tingkah laku yang dikonfigurasikan, dan jangan uji laluan kecemasan buat kali pertama semasa insiden yang ia ditulis untuknya. Prosedur pemulihan yang tidak pernah dijalankan ialah dokumen, bukan kawalan.

Runbook berakhir apabila tiga keadaan dinamakan, mod kegagalan dibaca daripada sistem yang berjalan, cubaan semula mempunyai satu pemilik, dan akses kecemasan mempunyai kelulusan serta semakannya sendiri. Penguatkuasaan yang boleh diramal serta laluan pemulihan yang diketahui ialah hasil yang wajar didokumenkan.