RADIUS prijungimas prie OpenVPN: papildinys ar scenarijaus kabliukas?

Papildinys vis dar rekomenduojamas temose, senesnėse už dabartinius rinkinius, o vakar sukompiliuotame serveryje jis nepavyksta įkeliant. Tai ne konfigūracijos klaida, kurią galima ištaisyti keliu. Papildinys ir scenarijaus kabliukas sprendžia tą pačią problemą skirtinguose sluoksniuose, o perėjimas nuo vieno prie kito keičia, ką reikia įdiegti, kas veikia su serverio teisėmis ir ką iš tikrųjų pasako nesėkmingas prisijungimas.

Mitas: papildinys yra palaikomas kelias

Papildinys yra bendras objektas, įkeliamas į OpenVPN procesą, todėl jis turi atitikti sąsają, kurią tas procesas teikia. Rinkiniai keičiasi, pakavimas keičiasi, o biblioteka, sukompiliuota senesnei sąsajai, tiesiog atsisako įsikelti. Niekas serverio konfigūracijoje negali užpildyti šios spragos, todėl patarimas „tiesiog įdiekite radiusplugin“ baigiasi serveriu, kuris nepaleidžiamas.

Scenarijaus kabliukas vietoj to stovi už proceso. OpenVPN paleidžia programą, perduoda jai prisijungimo duomenis ir perskaito nuosprendį. Būtent šis atskyrimas leidžia jam išgyventi atnaujinimus, ir jis taip pat daro jį jūsų atsakomybe taip, kaip papildinys niekada nebuvo.

Nė vienas metodas nėra saugesnis savo konstrukcija. Vienas vykdo svetimą kodą demono viduje; kitas vykdo jūsų kodą šalia jo, laikydamas prisijungimo duomenis rankoje. Teisingas klausimas yra, kurią iš šių dviejų rizikų jūs iš tikrųjų galite valdyti.

Ką papildinys surišo

Papildinys turėjo savo konfigūracijos failą su RADIUS hostu, bendru slaptažodžiu, bandymų skaičiumi ir laiko limitu, o serverio konfigūracija jį nurodė viena eilute. Prisijungimo duomenų apdorojimas liko serverio proceso viduje, o tai reiškė, kad slaptažodis niekada nekirto proceso ribos, kurią administratorius turėjo apsaugoti.

Kaina buvo susiejimas. Kiekvienas OpenVPN atnaujinimas rizikavo nesuderinama sąsaja, o kiekviena distribucija, perdariusi paketą, rizikavo sukurti biblioteką, kuri nebeatitinka. Kai taip nutinka, gedimas yra garsus ir momentinis, ir tai vienintelis dizaino gailestingumas.

Jei toks papildinys dar įsikelia jūsų rinkinyje, jis gali būti mažesnis operacinis paviršius. Patvirtinkite sąsają, kuriai jis buvo sukurtas, laikykite jį prisegtą prie jūsų išbandyto rinkinio ir kiekvieną atnaujinimą traktuokite kaip pakeitimą, reikalaujantį viso prisijungimo testo, o ne kaip įprastą paketo atnaujinimą.

Kuo scenarijaus kabliukas iš tikrųjų pasikliauja

Kabliukas konfigūruojamas su auth-user-pass-verify ir pristatymo mechanizmu: aplinkos kintamaisiais arba laikinu failu. Aplinkos formoje OpenVPN reikalauja script-security 3, dokumentuoto lygio, kuris leidžia atskleisti slaptažodį scenarijams. Tas lygis yra sąmoningas numatytosios reikšmės susilpninimas, ir į jį reikia žiūrėti kaip į leidimą su pridėtu pagrindimu.

Viskas, ką scenarijus paliečia, paveldi tą pasitikėjimą. Jis turi priklausyti root, būti neįrašomas grupei ar kitiems, nurodytas absoliučiu keliu ir neturėti vietos, kur nepatikima reikšmė pasiekia apvalkalą. Kiekvieną kintamąjį dėkite į kabutes, atmeskite netikėtus simbolius ir niekada nekurkite komandos iš pateikto vartotojo vardo. Scenarijus, veikiantis kaip root kiekvieno prisijungimo bandymo metu, vertas vienos peržiūros būtent dėl tų keturių savybių.

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

Failų pristatymo forma išvengia aplinkos paveldėjimo problemos ir perduoda prisijungimo duomenis scenarijui per laikiną failą su ribotomis teisėmis. Jei jūsų klientas tai palaiko, paprastai tai geresnė numatytoji reikšmė, nors prideda dar vieną objektą, kurį reikia sutvarkyti gedimo atveju.

Išėjimo kodai nusprendžia, ar žlugsite atvirai

Scenarijaus išėjimo būsena yra nuosprendis: nulis priima, ne nulis atmeta. Bėdų keliantis modelis yra apvalkalo scenarijus, kuris priima tik tada, kai RADIUS atsakyme yra tam tikras priėmimo žymuo, o visais kitais atvejais grąžina gedimą, nes taip sujungiami trys skirtingi įvykiai į vieną atsakymą. Neteisingas slaptažodis, nepasiekiamas serveris ir sugadintas atsakymas visi tampa tuo pačiu atmetimu.

Atskirkite šiuos atvejus scenarijuje, net jei kabliukas gali grąžinti tik priėmimą arba atmetimą. Registruokite backend rezultatą atskirai, įspėkite apie laiko limitus ir transporto klaidas, ir stebėjime padarykite aišku, kada autentifikacija nepavyksta dėl to, kad paslauga neveikia, o ne dėl to, kad vartotojai klysta rinkdami.

Du įpročiai išlaiko likusį sveiką. Jei RADIUS yra autoritetas, jis turėtų būti vienintelė vieta, kur tikrinamas slaptažodis, nes šešėlinė lentelė sukuria du atsakymus į tą patį klausimą, o antrasis yra atakos paviršius, kurio niekas nestebi. Ir atminkite, kad kabliukas vėl iškviečiamas kiekvieno pakartotinio bandymo metu, todėl lėtas scenarijus su nekantriu klientu tampa slaptažodžių spėjimo stiprintuvu, jei nepridėsite delsimo ar politikos RADIUS pusėje.

Ko atsisakote, kai sertifikatas dingsta

Daugelis tokios formos diegimų visiškai išjungia kliento sertifikato patikrą, palikdami vartotojo vardą ir slaptažodį kaip visą kliento pretenziją. Su tuo nustatymu dingsta sertifikatu pagrįsta tapatybė. Kanalas lieka šifruotas, bet vienintelis dalykas, kuris įvardija klientą, yra RADIUS nuosprendis. Viskas toliau, kas anksčiau rėmėsi sertifikato subjektu, dabar turi remtis vartotojo vardu.

Išlaikykite valdymo kanalo apsaugą, kad neautentifikuotas partneris negalėtų tyrinėti ar užtvindyti rankos paspaudimo, ir naudokite username-as-common-name, kai kiekvieno vartotojo konfigūracija priklauso nuo bendro vardo. Valdomi tinklai tai dažnai sprendžia kitaip, užbaigdami sertifikato autentifikaciją prie tinklo, kuris kalba EAP-TLS su RADIUS, ir tokiu atveju nė viena iš šių serverio direktyvų netaikoma. Kopijuokite modelį, kurį dokumentuoja jūsų platforma, o ne kaimyninio produkto. Svarbios direktyvos pakankamai skiriasi, kad jų sumaišymas duoda konfigūraciją, kuri išanalizuojama ir tada nieko neautentifikuoja.