Conectarea RADIUS la OpenVPN: plugin sau cârlig de script?

Pluginul este încă recomandat în fire mai vechi decât versiunile actuale, iar pe un server compilat ieri eșuează la încărcare. Nu este o eroare de configurare pe care o repari cu o cale. Pluginul și cârligul de script rezolvă aceeași problemă la niveluri diferite, iar trecerea de la unul la altul schimbă ce trebuie instalat, ce rulează cu privilegii de server și ce îți spune de fapt o autentificare eșuată.

Mitul: pluginul este calea susținută

Un plugin este un obiect partajat încărcat în procesul OpenVPN, deci trebuie să corespundă interfeței pe care acel proces o expune. Versiunile se schimbă, ambalarea se schimbă, iar o bibliotecă compilată pentru o interfață mai veche pur și simplu refuză să se încarce. Nimic din configurația serverului nu poate acoperi acel gol, de aceea sfatul „doar instalează radiusplugin” se termină cu un server care nu pornește.

Cârligul de script stă în schimb în afara procesului. OpenVPN rulează un program, îi dă acreditările și citește înapoi un verdict. Această decuplare îl face să supraviețuiască actualizărilor și tot ea îl face responsabilitatea ta într-un mod în care pluginul nu a fost niciodată.

Niciuna dintre abordări nu este mai sigură prin construcție. Una rulează cod străin în interiorul daemonului; cealaltă rulează codul tău alături, cu acreditările în mână. Întrebarea corectă este care dintre aceste două riscuri poți opera cu adevărat.

Ce lega pluginul

Pluginul avea propriul fișier de configurare cu gazda RADIUS, secretul partajat, numărul de reîncercări și limita de timp, iar configurația serverului îl referenția printr-o singură linie. Gestionarea acreditărilor rămânea în procesul serverului, ceea ce însemna că parola nu traversa niciodată o graniță de proces pe care administratorul trebuia să o securizeze.

Costul era cuplarea. Fiecare actualizare OpenVPN risca o interfață incompatibilă, iar fiecare distribuție care reconstruia pachetul risca să producă o bibliotecă ce nu mai corespunde. Când se întâmplă asta, eșecul este zgomotos și imediat, și aceasta este singura milă a designului.

Dacă un astfel de plugin se mai încarcă pe versiunea ta, poate fi suprafața operațională mai mică. Confirmă interfața pentru care a fost construit, ține-l fixat pe versiunea pe care ai testat-o și tratează orice actualizare ca o schimbare care cere un test complet de autentificare, nu ca o actualizare de rutină a pachetului.

Pe ce se bazează de fapt cârligul de script

Cârligul se configurează cu auth-user-pass-verify și un mecanism de livrare: variabile de mediu sau un fișier temporar. În forma de mediu, OpenVPN cere script-security 3, nivelul documentat care permite expunerea parolei către scripturi. Acel nivel este o slăbire deliberată a valorii implicite și trebuie tratat ca o permisiune cu o justificare atașată.

Tot ce atinge scriptul moștenește acea încredere. Trebuie să aparțină lui root, să nu fie scriibil de grup sau de alții, să fie referit printr-o cale absolută și să fie lipsit de orice loc în care o valoare neîncrezută ajunge într-un shell. Pune fiecare variabilă între ghilimele, respinge caracterele neașteptate și nu construi niciodată o comandă din numele de utilizator furnizat. Un script care rulează ca root la fiecare încercare de autentificare merită o revizuire exact pentru cele patru proprietăți.

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

Forma de livrare prin fișier evită problema moștenirii mediului și predă acreditările scriptului printr-un fișier temporar cu permisiuni restricționate. Dacă clientul tău o susține, este de obicei valoarea implicită mai bună, deși adaugă încă un obiect de curățat la eșec.

Codurile de ieșire decid dacă eșuezi deschis

Starea de ieșire a scriptului este verdictul: zero acceptă, diferit de zero respinge. Modelul care creează probleme este un script shell care acceptă doar când răspunsul RADIUS conține un anumit token de acceptare și returnează eșec pentru tot restul, pentru că asta topește trei evenimente diferite într-un singur răspuns. O parolă greșită, un server inaccesibil și un răspuns malformat devin toate aceeași respingere.

Separă acele cazuri în script chiar dacă cârligul poate returna doar acceptă sau respinge. Înregistrează rezultatul backendului separat, alertează la expirări și erori de transport și fă evident în monitorizare când autentificarea eșuează pentru că serviciul e căzut, nu pentru că utilizatorii tastează greșit.

Două obiceiuri țin restul sănătos. Dacă RADIUS este autoritatea, ar trebui să fie singurul loc unde se verifică o parolă, pentru că un tabel umbră creează două răspunsuri la aceeași întrebare, iar al doilea este o suprafață de atac pe care nimeni nu o supraveghează. Și ține minte că cârligul este apelat din nou la fiecare reîncercare, așa că un script lent cu un client nerăbdător devine un amplificator pentru ghicirea parolelor, dacă nu adaugi întârziere sau o politică pe partea RADIUS.

Ce pierzi când certificatul dispare

Multe implementări de această formă dezactivează complet verificarea certificatului de client, lăsând un nume de utilizator și o parolă ca întreaga pretenție a clientului. Ce dispare cu această setare este identitatea bazată pe certificat. Canalul rămâne criptat, dar singurul lucru care numește clientul este verdictul RADIUS. Orice element din aval care se baza pe subiectul certificatului trebuie acum să se bazeze pe numele de utilizator.

Păstrează protecția canalului de control pentru ca un partener neautentificat să nu poată sonda sau inunda strângerea de mână, și folosește username-as-common-name când configurația pe utilizator depinde de numele comun. Gateway-urile gestionate rezolvă adesea asta altfel, încheind autentificarea pe certificat la un gateway care vorbește EAP-TLS cu RADIUS, iar în acest caz niciuna dintre aceste directive de server nu se aplică. Copiază modelul documentat de propria platformă, nu pe cel al unui produs vecin. Directivele care contează diferă suficient încât amestecarea lor produce o configurație care se parsează și apoi nu autentifică pe nimeni.