Koble RADIUS til OpenVPN: plugin eller skriptkrok?

Pluginen blir fortsatt anbefalt i tråder som er eldre enn dagens bygginger, og på en server som ble kompilert i går feiler den ved lasting. Dette er ikke en konfigurasjonsfeil du kan rette med en sti. Pluginen og skriptkroken løser det samme problemet på ulike lag, og flyttingen fra den ene til den andre endrer hva som må installeres, hva som kjører med serverrettigheter, og hva en mislykket innlogging faktisk forteller deg.

Myten: pluginen er den støttede veien

En plugin er et delt objekt som lastes inn i OpenVPN-prosessen, så den må passe til grensesnittet den prosessen eksponerer. Bygginger endres, pakking endres, og et bibliotek kompilert for et eldre grensesnitt nekter rett og slett å laste. Ingenting i serverkonfigurasjonen kan bygge bro over det gapet, derfor ender rådet «bare installer radiusplugin» med en server som ikke starter.

Skriptkroken står i stedet utenfor prosessen. OpenVPN kjører et program, gir det legitimasjonen og leser en dom tilbake. Den frakoblingen er det som gjør at den overlever oppgraderinger, og det er også det som gjør den til ditt ansvar på en måte pluginen aldri var.

Ingen av tilnærmingene er sikrere av byggemåte. Den ene kjører fremmed kode inne i daemonen; den andre kjører din kode ved siden av med legitimasjonen i hånden. Det riktige spørsmålet er hvilken av disse to risikoene du faktisk kan drifte.

Hva pluginen bandt sammen

Pluginen hadde sin egen konfigurasjonsfil med RADIUS-vert, delt hemmelighet, antall forsøk og tidsavbrudd, og serverkonfigurasjonen refererte til den med én linje. Håndteringen av legitimasjon ble værende i serverprosessen, noe som betydde at passordet aldri krysset en prosessgrense administratoren måtte sikre.

Kostnaden var kobling. Hver OpenVPN-oppgradering risikerte et inkompatibelt grensesnitt, og hver distribusjon som bygde pakken på nytt risikerte å produsere et bibliotek som ikke lenger passer. Når det skjer, er feilen høy og umiddelbar, og det er designets eneste nåde.

Hvis en slik plugin fortsatt lastes på byggingen din, kan den være den mindre driftsflaten. Bekreft grensesnittet den ble bygget for, hold den festet til byggingen du testet, og behandle enhver oppgradering som en endring som krever en full innloggingstest, ikke en rutinemessig pakkeoppdatering.

Hva skriptkroken faktisk stoler på

Kroken konfigureres med auth-user-pass-verify og en leveringsmekanisme: miljøvariabler eller en midlertidig fil. I miljøformen krever OpenVPN script-security 3, det dokumenterte nivået som tillater passordreveksponering til skript. Det nivået er en bevisst svekkelse av standarden, og det bør behandles som en tillatelse med en begrunnelse vedlagt.

Alt skriptet berører arver den tilliten. Det må eies av root, ikke være skrivbart for gruppe eller andre, refereres med en absolutt sti, og være fritt for ethvert sted der en ikke-klarert verdi når et skall. Sett hver variabel i anførselstegn, avvis uventede tegn, og bygg aldri en kommando fra brukernavnet som er oppgitt. Et skript som kjører som root ved hvert innloggingsforsøk er verdt én gjennomgang nettopp for de fire egenskapene.

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

Fil-leveringsformen unngår problemet med miljøarv og gir legitimasjonen til skriptet gjennom en midlertidig fil med begrensede rettigheter. Hvis klienten din støtter det, er det vanligvis det bedre standardvalget, selv om det legger til ett objekt til som må ryddes ved feil.

Utgangskoder avgjør om du feiler åpent

Skriptets utgangsstatus er dommen: null godtar, ikke-null avviser. Mønsteret som skaper trøbbel er et skallskript som bare godtar når RADIUS-svaret inneholder et bestemt aksepttoken og returnerer feil for alt annet, fordi det smelter tre forskjellige hendelser sammen til ett svar. Feil passord, en utilgjengelig server og et misdannet svar blir alle den samme avvisningen.

Skill de tilfellene i skriptet selv om kroken bare kan returnere godta eller avvis. Logg backend-resultatet separat, varsle om tidsavbrudd og transportfeil, og gjør det tydelig i overvåkingen når autentiseringen feiler fordi tjenesten er nede og ikke fordi brukerne skriver feil.

To vaner holder resten fornuftig. Hvis RADIUS er autoriteten, bør den være det eneste stedet et passord kontrolleres, fordi en skyggetabell skaper to svar på samme spørsmål, og det andre er en angrepsflate ingen overvåker. Og husk at kroken kalles på nytt ved hvert nytt forsøk, så et tregt skript med en utålmodig klient blir en forsterker for passordgjetting med mindre du legger til forsinkelse eller en policy på RADIUS-siden.

Hva du gir opp når sertifikatet forsvinner

Mange utplasseringer av denne formen slår helt av klient-sertifikatkontrollen, og lar et brukernavn og et passord være hele klientens krav. Det som forsvinner med den innstillingen, er sertifikatbasert identitet. Kanalen forblir kryptert, men det eneste som navngir klienten, er RADIUS-dommen. Alt nedstrøms som før bygget på et sertifikatsubjekt, må nå bygge på brukernavnet.

Hold kontrollkanalbeskyttelsen på plass slik at en uautentisert peer ikke kan sondere eller overflomme håndtrykket, og bruk username-as-common-name når konfigurasjonen per bruker avhenger av fellesnavnet. Administrerte gatewayer løser dette ofte annerledes, ved å avslutte sertifikatautentiseringen på en gateway som snakker EAP-TLS med RADIUS, og i så fall gjelder ingen av disse serverdirektivene. Kopier modellen din egen plattform dokumenterer, ikke den fra et naboprodukt. Direktivene som betyr noe er forskjellige nok til at blanding av dem gir en konfigurasjon som parses og deretter ikke autentiserer noen.