Kunigi RADIUS en OpenVPN: aldonaĵo aŭ skripta hoko?

La aldonaĵo ankoraŭ estas rekomendata en fadenoj pli malnovaj ol la nunaj versioj, kaj ĝi malsukcesas ĉe ŝarĝo sur servilo kompilita hieraŭ. Tio ne estas agorda eraro, kiun vi povas ripari per vojo. La aldonaĵo kaj la skripta hoko solvas la saman problemon ĉe malsamaj tavoloj, kaj transiri de unu al la alia ŝanĝas kion oni devas instali, kio ruliĝas kun servilaj privilegioj, kaj kion malsukcesa ensaluto vere diras al vi.

La mito: la aldonaĵo estas la subtenata vojo

Aldonaĵo estas komuna objekto ŝargita en la procesos de OpenVPN, do ĝi devas kongrui kun la interfaco, kiun tiu proceso montras. Versioj ŝanĝiĝas, pakaĵado ŝanĝiĝas, kaj biblioteko kompilita por pli malnova interfaco simple rifuzas ŝarĝiĝi. Nenio en la servila agordo povas ponti tiun breĉon, tial la konsilo "simple instalu radiusplugin" finiĝas per servilo, kiu ne ekfunkcias.

La skripta hoko staras ekster la proceso. OpenVPN ruligas programon, donas al ĝi la akreditaĵojn kaj legas verdikton. Tiu malkuplado estas tio, kio igas ĝin postvivi ĝisdatigojn, kaj ĝi ankaŭ igas ĝin via respondeco tiel, kiel la aldonaĵo neniam estis.

Neniu el la du aliroj estas pli sekura pro sia konstruo. Unu ruligas fremdan kodon ene de la demono; la alia ruligas vian kodon apud ĝi kun la akreditaĵoj en la mano. La ĝusta demando estas, kiun el tiuj du riskoj vi vere povas funkciigi.

Kion la aldonaĵo kunligis

La aldonaĵo havis sian propran agordan dosieron kun la RADIUS-gastiganto, la komuna sekreto, la ripetnombro kaj la tempolimo, kaj la servila agordo referencis ĝin per unu linio. La traktado de akreditaĵoj restis ene de la servila proceso, kio signifis, ke la pasvorto neniam transiris proceslimon, kiun la administranto devis sekurigi.

La kosto estis kunligo. Ĉiu ĝisdatigo de OpenVPN riskis neakordigeblan interfacon, kaj ĉiu distribuo, kiu rekonstruis la pakaĵon, riskis produkti bibliotekon, kiu jam ne kongruas. Kiam tio okazas, la malsukceso estas laŭta kaj tuja, kaj tio estas la sola kompato de la dezajno.

Se tia aldonaĵo ankoraŭ ŝarĝiĝas en via versio, ĝi povas esti la pli malgranda operacia surfaco. Konfirmu la interfacon, por kiu ĝi estis konstruita, tenu ĝin fiksita al la versio, kiun vi testis, kaj traktu ĉiun ĝisdatigon kiel ŝanĝon, kiu postulas plenan ensalutan teston, ne rutinan pakaĵan ĝisdatigon.

Kion la skripta hoko efektive fidas

La hoko agordiĝas per auth-user-pass-verify kaj livera mekanismo: mediaj variabloj aŭ provizora dosiero. En la media formo OpenVPN postulas script-security 3, la dokumentitan nivelon, kiu permesas malkaŝi pasvorton al skriptoj. Tiu nivelo estas intenca malfortigo de la defaŭlto, kaj ĝi traktu kiel permeson kun alkroĉita pravigado.

Ĉio, kion la skripto tuŝas, heredas tiun fidon. Ĝi devas esti posedata de root, ne skribebla de grupo aŭ aliaj, referencita per absoluta vojo, kaj libera de iu loko, kie nefidinda valoro atingas ŝelon. Metu ĉiun variablon en citilojn, malakceptu neatenditajn signojn, kaj neniam konstruu komandon el la provizita uzantnomo. Skripto, kiu ruliĝas kiel root ĉe ĉiu ensaluta provo, indas unufojan revizion ĝuste pro tiuj kvar ecoj.

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

La dosiera liverformo evitas la problemon de media heredo kaj donas la akreditaĵojn al la skripto per provizora dosiero kun limigitaj permesoj. Se via kliento subtenas ĝin, ĝi kutime estas la pli bona defaŭlto, kvankam ĝi aldonas ankoraŭ unu objekton por purigi ĉe malsukceso.

Elirkodoj decidas, ĉu vi malsukcesos malferme

La elirstatuso de la skripto estas la verdikto: nulo akceptas, ne-nulo malakceptas. La ŝablono, kiu kaŭzas problemojn, estas ŝela skripto, kiu akceptas nur kiam la RADIUS-respondo enhavas specifan akceptan ĵetonon kaj redonas malsukceson por ĉio alia, ĉar tio kunfalda tri malsamajn eventojn en unu respondon. Malĝusta pasvorto, neatingebla servilo kaj malformita respondo ĉiuj fariĝas la sama malakcepto.

Apartigu tiujn kazojn en la skripto eĉ se la hoko povas redoni nur akcepton aŭ malakcepton. Registru la backend-rezulton aparte, alarmu pri tempolimoj kaj transportaj eraroj, kaj evidentigu en monitorado, kiam aŭtentigo malsukcesas ĉar la servo estas malaktiva, ne ĉar uzantoj mistajpas.

Du kutimoj tenas la reston sana. Se RADIUS estas la aŭtoritato, ĝi devus esti la sola loko, kie pasvorto estas kontrolata, ĉar ombra tabelo kreas du respondojn al la sama demando kaj la dua estas ataka surfaco, kiun neniu observas. Kaj memoru, ke la hoko estas vokata denove ĉe ĉiu ripeto, do malrapida skripto kun senpacienca kliento fariĝas amplifilo por diveni pasvortojn, krom se vi aldonas prokraston aŭ politikon ĉe la RADIUS-flanko.

Kion vi perdas, kiam la atestilo foriras

Multaj deplojoj de tiu ĉi formo tute malŝaltas kontroladon de klienta atestilo, lasante uzantnomon kaj pasvorton kiel la tutan postulon de la kliento. Tio, kio malaperas kun tiu agordo, estas atestilbazita identeco. La kanalo restas ĉifrita, sed la sola afero nomanta la klienton estas la RADIUS-verdikto. Ĉio malsupre, kio antaŭe baziĝis sur atestila subjekto, nun devas baziĝi sur la uzantnomo.

Tenu kontrolkanalan protekton, por ke neaŭtentigita peer ne povu sondi aŭ superŝuti la manpremon, kaj uzu username-as-common-name kiam la agordo por uzanto dependas de la komuna nomo. Administritaj enirejoj ofte solvas tion alie, finante atestilan aŭtentigon ĉe enirejo, kiu parolas EAP-TLS kun RADIUS, kaj en tiu kazo neniu el tiuj servilaj direktivoj validas. Kopiu la modelon, kiun via propra platformo dokumentas, ne tiun de najbara produkto. La direktivoj, kiuj gravas, sufiĉe malsamas, ke ilia miksado produktas agordon, kiu analiziĝas kaj poste aŭtentigas neniun.