Bumagsak ang serbisyo ng MFA: magpasya sa VPN access bago pa ito mabigo

Humihinto ang VPN access, at sinasabi ng alerto na hindi maabot ang serbisyo ng ikalawang salik. Kung may makakakonekta pa ay tanong sa patakaran na dapat sinagot bago ang pagkaantala, hindi habang nangyayari ito. Ang hindi available na verifier ay hindi ebidensya na nakapasa ang isang salik, at ang tinanggihang hamon ay hindi parehong pangyayari sa hindi maabot. Ginagawa ng gabay sa ibaba ang pagkakaibang iyon na nakasulat na tuntunin na masusubok mo.

Hakbang 1: pangalanan ang tatlong resulta nang hiwalay

Isulat ang tatlong kalagayan at tanggihang pagsamahin ang mga ito: nabigo ang pangunahing pagpapatunay, tinanggihan o nag-expire ang hamon ng ikalawang salik, at hindi kailanman sumagot ang serbisyo ng MFA. Bawat isa ay may ibang may-ari, ibang linya sa log at ibang tamang tugon. Ang isang pangkalahatang mensahe ng timeout ay nagtatago kung alin ang kinalalagyan mo, at ang kalabuang iyon ang gumagawa ng pagkaantala tungong pagtatalo. Pangalanan ang mga kalagayan sa gabay bago mo kailanganin.

Ang pagtanggi ay nangangahulugang sumagot ang verifier at nagsabing hindi, na resulta ng patakaran at hindi problema sa pagkakaroon. Ang nag-expire na pagtatangka ay nangangahulugang umiral ang hamon at walang nakatapos nito sa oras. Ang hindi maabot na serbisyo ay nangangahulugang hindi kailanman sinagot ang tanong. Ang ikatlo lamang ang pagkaantala.

Hakbang 2: basahin ang failure mode na aktwal na ginagamit ng proxy

Hanapin ang setting na namamahala sa ugali kapag hindi makontak ang serbisyo, at basahin ito mula sa tumatakbong configuration at hindi mula sa template. Sa RADIUS proxy ng Duo, ang nakadokumentong halaga ng failmode ay safe at secure, kung saan pinapayagan ng safe ang pagtatangka lamang kapag nagtagumpay ang pangunahing pagpapatunay, at tinatanggihan ng secure ang pagtatangka sa kondisyong iyon.

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

Inilalarawan ng pangalang safe ang isang pagpili sa pagkakaroon, hindi garantiya na ang bawat tinanggap na sesyon ay may sariwang ikalawang salik. Ang pangungusap na iyon ay nabibilang sa talaan ng panganib, dahil iyon mismo ang palitan na ginagawa ng setting. Huwag gawing pangkalahatan ang halaga sa ibang tagapagbigay, ibang integrasyon o ibang mode ng proxy; basahin ang dokumentasyon ng produktong iyon para sa sarili nitong katumbas. Ang configuration na kinopya mula sa halimbawa ng vendor na walang pag-unawang ito ay sorpresang naghihintay sa susunod na pagkaantala.

Huminto kung walang makapagsabi kung aling mode ang aktibo. Nakasalalay sa sagot na iyon ang natitirang bahagi ng gabay.

Hakbang 3: itugma ang mga muling pagsubok sa daloy

Itugma ang timeout at ugali ng muling pagsubok ng gateway sa daloy ng pagpapatunay na pinapatakbo nito. Ang hindi pagkakasundo na mga muling pagsubok ay gumagawa ng maraming kahilingan, ginugulo ang pagtutugma ng pagtatangka at iniiwan ang log na hindi masabi kung aling resulta ang para sa aling pag-login. Ang napakahabang timeout ay hindi disenyo ng pagkakaroon; ito ay mas mahabang paghihintay para sa parehong sagot.

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

Ang sariling timeout ng kahilingan sa proxy ay hiwalay na hangganan: ang kahilingan sa pagpapatunay na inilabas at hindi kailanman natapos ay tinatanggihan, at ang pagtanggi na iyon ay hindi pagkaantalang maaaring urungan. Ituring ang pagtanggi, hindi natapos na hamon at hindi maabot na serbisyo bilang tatlong magkaibang input sa iyong talahanayan ng desisyon. Pagkatapos ay gawing tahasan ang talahanayan: aling kalagayan ang tumatanggap, aling kalagayan ang humahawak at aling kalagayan ang iniaakyat sa isang tao.

Kung ang dalawang bahagi ay parehong nagsubok muli, ayusin muna ang pagmamay-ari ng mga muling pagsubok. Ang doble na kahilingan ay sintomas ng dalawang may-ari, hindi ng mabagal na serbisyo.

Hakbang 4: pamahalaan ang emergency access nang hiwalay

Kung kailangan ang emergency access, bigyan ito ng sariling saklaw, pagkakakilanlan, pahintulot at bakas ng audit. Ang tahimik na pagpatay sa MFA para sa lahat ng gumagamit ay hindi emergency procedure; ito ay permanenteng pagpapahina na may nakakabit na insidente. Inaprubahan ng may-ari ng seguridad nang maaga ang tuntunin ng pagtanggap, ang pagiging nakikita at ang landas ng escalation.

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

Subukan ang buong matrix sa isang kapaligirang hindi produksyon: pangunahing pagkabigo, sinadyang pagtanggi, pag-expire ng hamon at kawalan ng serbisyo. Para sa bawat isa, itala ang resulta ng pagtanggap at ang dahilang naitala. Huwag lumikha ng pagkaantala sa produksyon para matuklasan ang naka-configure na ugali, at huwag subukan ang emergency path sa unang pagkakataon sa panahon ng insidenteng isinulat ito. Ang pamamaraang recovery na hindi kailanman pinatakbo ay dokumento, hindi kontrol.

Nagtatapos ang gabay kapag pinangalanan ang tatlong kalagayan, nabasa ang failure mode mula sa tumatakbong sistema, may isang may-ari ang mga muling pagsubok, at may sariling pag-apruba at pagsusuri ang emergency access. Ang mahuhulaang pagpapatupad kasama ang kilalang landas ng recovery ang resultang sulit idokumento.