Tilslutning af RADIUS til OpenVPN: plugin eller scriptkrog?

Pluginnet anbefales stadig i tråde, der er ældre end de aktuelle builds, og det fejler ved indlæsning på en server, der blev kompileret i går. Det er ikke en konfigurationsfejl, du kan rette med en sti. Pluginnet og scriptkrogen løser samme problem på forskellige lag, og flytningen fra det ene til det andet ændrer, hvad der skal installeres, hvad der kører med serverrettigheder, og hvad en mislykket login faktisk fortæller dig.

Myten: pluginnet er den understøttede vej

Et plugin er et delt objekt, der indlæses i OpenVPN-processen, så det skal matche den grænseflade, processen udstiller. Builds ændres, pakning ændres, og et bibliotek kompileret til en ældre grænseflade nægter simpelthen at indlæse. Intet i serverkonfigurationen kan bygge bro over det hul, og derfor ender rådet "installer bare radiusplugin" med en server, der ikke starter.

Scriptkrogen ligger uden for processen i stedet. OpenVPN kører et program, giver det legitimationsoplysningerne og læser en dom tilbage. Den afkobling er det, der får den til at overleve opgraderinger, og det er også det, der gør den til dit ansvar på en måde, pluginnet aldrig var.

Ingen af tilgangene er mere sikre af bygning. Den ene kører fremmed kode inde i daemonen; den anden kører din kode ved siden af med legitimationsoplysningerne i hånden. Det rigtige spørgsmål er, hvilken af de to risici du faktisk kan drive.

Hvad pluginnet bandt sammen

Pluginnet havde sin egen konfigurationsfil med RADIUS-værten, den delte hemmelighed, antal forsøg og timeout, og serverkonfigurationen refererede til den med én linje. Håndtering af legitimationsoplysninger blev inde i serverprocessen, hvilket betød, at adgangskoden aldrig krydsede en procesgrænse, som administratoren skulle sikre.

Prisen var kobling. Hver OpenVPN-opgradering risikerede en inkompatibel grænseflade, og hver distribution, der genopbyggede pakken, risikerede at producere et bibliotek, der ikke længere passede. Når det sker, er fejlen høj og øjeblikkelig, og det er designets eneste nåde.

Hvis et sådant plugin stadig indlæses på dit build, kan det være den mindre driftsflade. Bekræft den grænseflade, det blev bygget til, hold det fastgjort til det build, du testede, og behandl enhver opgradering som en ændring, der kræver en fuld login-test frem for en rutinemæssig pakkeopdatering.

Hvad scriptkrogen faktisk stoler på

Krogen konfigureres med auth-user-pass-verify og en leveringsmekanisme: miljøvariabler eller en midlertidig fil. Med miljøformen kræver OpenVPN script-security 3, det dokumenterede niveau, der tillader adgangskodeeksponering til scripts. Det niveau er en bevidst svækkelse af standarden, og det bør behandles som en tilladelse med en begrundelse vedhæftet.

Alt, hvad scriptet rører, arver den tillid. Det skal være ejet af root, ikke skrivbart for gruppe eller andre, refereret med en absolut sti og fri for ethvert sted, hvor en ubetroet værdi når en shell. Sæt hver variabel i anførselstegn, afvis uventede tegn, og byg aldrig en kommando fra det angivne brugernavn. Et script, der kører som root ved hvert login-forsøg, er værd at gennemgå én gang netop for de fire egenskaber.

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

Fil-leveringsformen undgår miljøarvsproblemet og giver legitimationsoplysningerne til scriptet gennem en midlertidig fil med begrænsede rettigheder. Hvis din klient understøtter det, er det normalt den bedre standard, selvom det tilføjer endnu et objekt at rydde op på ved fejl.

Exitkoder afgør, om du fejler åbent

Scriptets exitstatus er dommen: nul accepterer, ikke-nul afviser. Det mønster, der skaber problemer, er et shell-script, der kun accepterer, når RADIUS-svaret indeholder et bestemt accept-token, og returnerer fejl for alt andet, fordi det slår tre forskellige hændelser sammen i ét svar. En forkert adgangskode, en utilgængelig server og et misdannet svar bliver alle den samme afvisning.

Opdel de tilfælde i scriptet, selv om krogen kun kan returnere accept eller afvis. Log backend-resultatet separat, alarmér om timeouts og transportfejl, og gør det tydeligt i overvågningen, når godkendelse fejler, fordi tjenesten er nede, og ikke fordi brugerne skriver forkert.

To vaner holder resten fornuftig. Hvis RADIUS er autoriteten, bør den være det eneste sted, en adgangskode kontrolleres, fordi en skyggetabel skaber to svar på samme spørgsmål, og det andet er en angrebsflade, ingen overvåger. Og husk, at krogen kaldes igen ved hvert nyt forsøg, så et langsomt script kombineret med en utålmodig klient bliver en forstærker for gæt på adgangskoder, medmindre du tilføjer forsinkelse eller en politik på RADIUS-siden.

Hvad du giver afkald på, når certifikatet forsvinder

Mange implementeringer af denne form slår klientcertifikatkontrol helt fra og lader et brugernavn og en adgangskode være hele klientens krav. Det, der forsvinder med den indstilling, er certifikatbaseret identitet. Kanalen forbliver krypteret, men det eneste, der navngiver klienten, er RADIUS-dommen. Alt nedstrøms, der før byggede på et certifikat-subjekt, skal nu bygge på brugernavnet i stedet.

Hold kontrolkanalbeskyttelse på plads, så en uautentificeret peer ikke kan probe eller oversvømme håndtrykket, og brug username-as-common-name, når konfiguration per bruger afhænger af common name. Administrerede gateways løser det ofte anderledes og afslutter certifikatgodkendelsen ved en gateway, der taler EAP-TLS med RADIUS, og i så fald gælder ingen af disse serverdirektiver. Kopiér den model, din egen platform dokumenterer, ikke den fra et naboprodukt. De direktiver, der betyder noget, er forskellige nok til, at blanding af dem giver en konfiguration, der parses og derefter ikke godkender nogen.