Ang pagdaragdag ng pangalawang backend ng pagpapatotoo sa isang VPN gateway ay parang pagdaragdag ng pangalawang salik. Karaniwan itong nagdaragdag ng pangalawang pagsusuri, na isang ibang bagay na may iba't ibang paraan ng pagpalya. Kung kailangang magtagumpay ang dalawa, ano ang pinatutunayan ng bawat isa at ano ang nangyayari kapag wala ang isa ay tatlong magkahiwalay na desisyon. Kapag nagkamali, ang gateway ay mas mahigpit sa demonstrasyon at mas mahina sa panahon ng pagkagambala.

Ano ang talagang pinatutunayan ng pangalawang backend

Ang paghahanap sa lokal na account ay nagpapatunay na may pangalan sa database at may password na tumugma dito. Ang palitan ng RADIUS ay nagpapatunay na ang isang RADIUS server ay nagbalik ng Access-Accept para sa mga natanggap na katangian. Wala sa mga pahayag ang nagbabanggit ng uri ng salik, dahil parehong nagpapatunay ng kaalaman. At ang gabay ng NIST sa digital na pagkakakilanlan ay nagbibilang ng magkaibang uri ng salik at ng kanilang mga authenticator, hindi mga server o prompt.

May lehitimong disenyo kung saan lumalahok ang dalawang sistema. Maaaring patotohanan ng sentral na serbisyo ang tao habang independiyenteng sinusuri ng gateway kung may karapatan ang account na iyon sa tunnel na ito. Iyon ay awtorisasyon sa tabi ng pagpapatotoo, at ang tawagin itong dalawang salik ay pinaghahalo ang pagsusuri ng patakaran sa patunay ng pagmamay-ari.

Maaaring magdala ang RADIUS ng tunay na pangalawang salik kapag nakatayo ito sa harap ng isang bagay na nagpapatunay ng isa, tulad ng push approval o hardware token. Hindi sinasabi ng sobre kung aling mga authenticator ang ipinakita ng gumagamit, kaya basahin ang patakaran ng backend, hindi ang label ng gateway.

AND, OR at fallback ay magkaibang produkto

Bago ihambing ang mga implementasyon, magpasya kung ano ang ibig sabihin ng dalawa sa inyong kinakailangan. Ang patakarang AND ay nangangailangan na makapasa ang bawat pinangalanang pagsusuri, tinatanggap ng patakarang OR ang magtagumpay, at sinusubukan ng fallback ang pangalawa lamang sa mga nakasaad na kondisyon ng pagpalya. Ang tatlong ito ay kumikilos nang kabaligtaran sa panahon ng pagkagambala, at kadalasan isa lamang sa kanila ang nais ng pagsusuri.

Ang pagdaragdag ng dalawang entry ng backend sa isang screen ng configuration ay hindi nagbubunyag kung aling patakaran ang ipinapatupad ng produkto. Ang ilang gateway ay nagkakabit ng mga plugin ayon sa pagkakasunod-sunod at humihinto sa unang pagtanggi, na AND lamang kapag kailangan ang bawat plugin. Ang iba ay itinuturing ang lokal na account bilang override, na ginagawang bypass ang sentral na pagkagambala. Ang mapagkakatiwalaang sagot ay isang dokumentadong negatibong pagsubok para sa bawat landas, na pinapatakbo laban sa build na ilalagay ninyo.

Ang fallback ay pinakapinagdududahan, dahil umiiral ito upang magpatuloy sa paggana kapag may nasira. Ang fallback na tumatanggap ng lokal na password tuwing hindi maabot ang RADIUS ay ginawang pangalawang, mas mahinang pinto ang sentral na patakaran.

Ang dobleng pagsusuri ng OpenVPN ay isang konkretong kaso

Ang OpenVPN ng komunidad 2.6 ay nangangailangan ng sertipiko ng kliyente at ng naka-configure na auth-user-pass-verify script kapag pareho itong naka-enable. Iyon ay dokumentadong AND sa pagitan ng pagpapatunay ng sertipiko at script ng kredensyal, at tunay na dalawang pagsusuri. Hindi pa rin ito awtomatikong dalawang uri ng salik, dahil maaaring password lamang ang pinapatunayan ng script.

Ang kombinasyon ay nag-iiwan din ng bukas na tanong sa pagkakaugnay. Karaniwang tinutukoy ng sertipiko ang isang aparato habang tinutukoy ng kredensyal ang isang tao, at wala sa default na daloy ang nangangailangan na pareho silang tumukoy sa isang principal. Magpasya kung aling mga pares ang pinapayagan, pagkatapos ay ipatupad ang mapa sa loob ng script ng pagpapatunay o sa susunod na hakbang ng awtorisasyon.

Ang mode na sertipiko lamang ay isang pagsubok, na sinusuportahan ng susi na maaaring o hindi protektado ng PIN. Ang PIN ay ginagawang kaalaman at pagmamay-ari ang parehong kredensyal lamang kung hindi magagamit ang susi nang wala ito. Ang iwanang hindi naka-encrypt ang susi sa disk ay binabawasan ang pangalawang bahagi sa pahintulot ng file.

Ang mga tagagawa ng appliance ay nagtatayo ng sarili nilang tubo, kadalasan isang PAM module o RADIUS plugin sa likod ng web console. Ang pag-uugali ng komunidad ay isang sanggunian sa hitsura ng dobleng pagsusuri, hindi paglalarawan kung paano ito pinagsasama ng appliance.

Suriin ang kombinasyon sa inyong gateway

Basahin ang configuration bago magtiwala sa buod ng console. Ang mga linyang nagpapasya ng patakaran ay ang mode ng sertipiko, ang script ng kredensyal at ang pagkakasunod-sunod ng 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

Ipinapakita ng grep kung kailangan ang sertipiko at aling script ang tumatakbo pagkatapos, at mas mahalaga ang pagkakasunod-sunod kaysa ipinahihiwatig ng mga pangalan. Ang dump ng sertipiko ay nagbibigay ng pagkakakilanlang makikita ng gateway, kabilang ang CN at serial number na kailangan para sa mapa ng pagkakaugnay. Ang pagsubok ng RADIUS ay ang negatibong kaso: ang maling password ay dapat magbigay ng Access-Reject, at ang tama Access-Accept. Kung ang tinanggihang kredensyal ay nagbibigay pa rin ng sesyon, ang script ay wala talaga sa landas ng pagpapatotoo.

Pagkatapos ay patakbuhin ang kaso ng pagkagambala sa isang laboratory instance: itigil ang kinakailangang backend at kumonekta gamit ang valid na kredensyal. Ang inaasahang resulta ay pagtanggi, at anumang iba ay ang fallback na patakaran na walang nagdokumento.

Isulat ang kinakailangan bilang mga negatibong kaso

Ang magagamit na kinakailangan ay nagpapangalan ng mga patunay, mga account na pinapayagang magpakita ng mga ito at ang resulta kapag wala ang verifier. Isinasaad din nito ang pinapayagang pagpapares sa pagitan ng pagkakakilanlan ng aparato at ng tao. Iyon ay mas tumpak kaysa mga pangalan ng produkto sa purchase order, at nasusubukan ito.

Dapat isama ng pagtanggap ang apat na pagtanggi: hindi karapat-dapat na lokal na account, nawawalang kinakailangang patunay, di-wastong pangalawang salik at hindi maabot na kinakailangang backend. Ang bawat pagtanggi ay nangangailangan ng linya ng log na nagbubukod dito sa iba, kung hindi, ang susunod na insidente ay magsisimula sa haka-haka. Itala kung aling bahagi ang gumawa ng bawat desisyon, dahil ang gateway, RADIUS server at direktoryo ay magsisihan sa isa't isa.

Patakbuhin muli ang apat na pagtanggi pagkatapos ng anumang pagbabago sa plugin o firmware. Mura sila, at ang patakarang pinoprotektahan nila ay ang bahaging unang sinusuri ng attacker.

Kaugnay na mga artikulo