Pag-uugnay ng RADIUS sa OpenVPN: plugin o script hook?
Ang lumang plugin ng RADIUS ay nakatali sa build ng server kung saan ito kinompile. Pinapalitan ito ng hook na auth-user-pass-verify, ngunit inililipat ang tiwala sa iyong script.
Inirerekomenda pa rin ang plugin sa mga thread na mas matanda kaysa sa kasalukuyang mga build, at nabibigo ito kapag naglo-load sa isang server na kinompile kahapon. Hindi ito error sa configuration na maaayos sa pamamagitan ng path. Ang plugin at ang script hook ay nilulutas ang parehong problema sa magkaibang layer, at ang paglipat mula sa isa patungo sa isa ay nagbabago kung ano ang dapat i-install, ano ang tumatakbo nang may pribilehiyo ng server, at ano ang talagang sinasabi ng nabigong login.
Ang mito: ang plugin ang sinusuportahang landas
Ang plugin ay isang shared object na nilo-load sa proseso ng OpenVPN, kaya dapat itong tumugma sa interface na inilalantad ng prosesong iyon. Nagbabago ang mga build, nagbabago ang packaging, at ang library na kinompile para sa lumang interface ay tumatanggi na mag-load. Wala sa configuration ng server ang makakapuno sa puwang na iyon, kaya ang payong "i-install lang ang radiusplugin" ay nagtatapos sa server na hindi nagsisimula.
Ang script hook ay nasa labas ng proseso. OpenVPN ay nagpapatakbo ng programa, ibinibigay ang mga kredensyal at binabasa ang hatol. Ang paghihiwalay na iyon ang nagpapabuhay nito sa mga upgrade, at ito rin ang gumagawa nitong responsibilidad mo sa paraang hindi kailanman naging ang plugin.
Walang paraan ang mas secure sa pamamagitan ng konstruksyon. Ang isa ay nagpapatakbo ng banyagang code sa loob ng daemon; ang isa ay nagpapatakbo ng code mo sa tabi nito na may kredensyal sa kamay. Ang tamang tanong ay alin sa dalawang panganib na ito ang talagang kayang pangasiwaan mo.
Ano ang pinagbuklod ng plugin
Ang plugin ay may sariling configuration file na may RADIUS host, shared secret, bilang ng pagsubok at time limit, at tinutukoy ito ng configuration ng server sa isang linya. Nanatili ang paghawak ng kredensyal sa loob ng proseso ng server, na nangangahulugang hindi kailanman tumawid ang password sa hangganan ng proseso na kailangang i-secure ng administrator.
Ang halaga ay ang pagkakaugnay. Bawat upgrade ng OpenVPN ay nanganganib sa hindi tugmang interface, at bawat distribusyon na muling bumubuo ng pakete ay nanganganib na makagawa ng library na hindi na tugma. Kapag nangyari iyon, ang pagkabigo ay malakas at agaran, at iyon ang tanging awa ng disenyo.
Kung ang ganitong plugin ay naglo-load pa rin sa build mo, maaaring ito ang mas maliit na operating surface. Kumpirmahin ang interface kung saan ito itinayo, panatilihin itong naka-pin sa build na sinubukan mo, at ituring ang anumang upgrade bilang pagbabagong nangangailangan ng buong pagsubok ng login, hindi rutinang pag-update ng pakete.
Ano ang talagang pinagkakatiwalaan ng script hook
Ang hook ay naka-configure sa auth-user-pass-verify at isang mekanismo ng paghahatid: environment variables o pansamantalang file. Sa anyo ng environment, kailangan ng OpenVPN ang script-security 3, ang dokumentadong antas na nagpapahintulot sa paglantad ng password sa mga script. Ang antas na iyon ay sadyang pagpapahina ng default, at dapat ituring na pahintulot na may kalakip na katwiran.
Lahat ng hinahawakan ng script ay nagmamana ng pagtitiwalang iyon. Dapat itong pag-aari ng root, hindi maisusulat ng grupo o iba, tinutukoy ng absolute path, at walang lugar kung saan umaabot ang hindi pinagkakatiwalaang halaga sa shell. Ilagay ang bawat variable sa quotes, tanggihan ang hindi inaasahang karakter, at huwag kailanman bumuo ng command mula sa ibinigay na username. Ang script na tumatakbo bilang root sa bawat pagtatangkang mag-login ay karapat-dapat sa isang pagsusuri dahil sa apat na katangiang iyon.
ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh
Iniiwasan ng anyo ng paghahatid ng file ang problema ng mana ng environment at ibinibigay ang mga kredensyal sa script sa pamamagitan ng pansamantalang file na may limitadong pahintulot. Kung sinusuportahan ito ng iyong client, karaniwang ito ang mas mabuting default, kahit nagdadagdag ito ng isang bagay na lilinisin kapag nabigo.
Ang mga exit code ang nagpapasya kung mabibigo ka nang bukas
Ang exit status ng script ang hatol: zero tumatanggap, hindi zero tumatanggi. Ang pattern na nagdudulot ng gulo ay isang shell script na tumatanggap lamang kapag ang tugon ng RADIUS ay naglalaman ng partikular na acceptance token at nagbabalik ng pagkabigo sa lahat ng iba pa, dahil pinagsasama nito ang tatlong magkaibang pangyayari sa isang sagot. Ang maling password, server na hindi maabot at malformed na tugon ay nagiging parehong pagtanggi.
Paghiwalayin ang mga kasong iyon sa script kahit ang hook ay makakabalik lamang ng tanggap o tanggi. I-log nang hiwalay ang resulta ng backend, mag-alarma sa mga timeout at error sa transport, at gawing malinaw sa monitoring kung kailan nabibigo ang authentication dahil down ang serbisyo at hindi dahil nagkamali ang mga user sa pag-type.
Dalawang ugali ang nagpapanatiling matino sa iba. Kung ang RADIUS ang awtoridad, dapat itong maging tanging lugar kung saan sinusuri ang password, dahil ang shadow table ay lumilikha ng dalawang sagot sa parehong tanong at ang pangalawa ay attack surface na walang nagmamasid. At tandaan na ang hook ay tinatawag muli sa bawat pagsubok, kaya ang mabagal na script kasama ang impatient na client ay nagiging amplifier para sa paghula ng password maliban kung magdagdag ka ng delay o patakaran sa panig ng RADIUS.
Ano ang isinusuko mo kapag nawala ang certificate
Maraming deployment ng ganitong anyo ang ganap na nagpapatay sa pagsusuri ng client certificate, na iniiwan ang username at password bilang buong pag-aangkin ng client. Ang nawawala sa setting na iyon ay pagkakakilanlang batay sa certificate. Nananatiling naka-encrypt ang channel, ngunit ang tanging bagay na nagpapangalan sa client ay ang hatol ng RADIUS. Anumang nasa downstream na dating umaasa sa certificate subject ay dapat na ngayong umasa sa username.
Panatilihin ang proteksyon ng control channel upang ang hindi awtentikadong peer ay hindi makapagsiyasat o makapagbaha ng handshake, at gamitin ang username-as-common-name kapag ang configuration bawat user ay nakadepende sa common name. Ang mga managed gateway ay madalas na nilulutas ito nang iba, tinatapos ang certificate authentication sa isang gateway na nagsasalita ng EAP-TLS sa RADIUS, at sa kasong iyon wala sa mga server directive na ito ang nalalapat. Kopyahin ang modelong dokumentado ng sarili mong platform, hindi ang sa kalapit na produkto. Ang mahahalagang directive ay sapat na magkaiba kaya ang paghahalo sa kanila ay gumagawa ng configuration na nagpa-parse at pagkatapos ay walang awtentikasyon.