Koppla RADIUS till OpenVPN: plugin eller skriptkrok?

Insticksprogrammet rekommenderas fortfarande i trådar som är äldre än de nuvarande byggena, och på en server som kompilerades i går misslyckas det vid laddning. Det är inte ett konfigurationsfel som du rättar med en sökväg. Insticksprogrammet och skriptkroken löser samma problem på olika lager, och flytten från det ena till det andra ändrar vad som måste installeras, vad som körs med serverbehörigheter och vad ett misslyckat login faktiskt säger dig.

Myten: insticksprogrammet är den stödda vägen

Ett insticksprogram är ett delat objekt som laddas in i OpenVPN-processen, så det måste matcha det gränssnitt som processen exponerar. Byggena ändras, paketeringen ändras, och ett bibliotek kompilerat för ett äldre gränssnitt vägrar helt enkelt att laddas. Inget i serverkonfigurationen kan överbrygga den klyftan, därför slutar rådet "installera bara radiusplugin" med en server som inte startar.

Skriptkroken står i stället utanför processen. OpenVPN kör ett program, ger det uppgifterna och läser en dom tillbaka. Den frikopplingen gör att den överlever uppgraderingar, och den gör den också till ditt ansvar på ett sätt som insticksprogrammet aldrig var.

Ingen av metoderna är säkrare av sin konstruktion. Den ena kör främmande kod inne i daemonen; den andra kör din kod bredvid med uppgifterna i handen. Rätt fråga är vilken av dessa två risker du faktiskt kan driva.

Vad insticksprogrammet band samman

Insticksprogrammet hade sin egen konfigurationsfil med RADIUS-värden, den delade hemligheten, antalet försök och tidsgränsen, och serverkonfigurationen refererade till den med en enda rad. Hanteringen av uppgifterna stannade i serverprocessen, vilket innebar att lösenordet aldrig korsade en processgräns som administratören måste skydda.

Kostnaden var kopplingen. Varje OpenVPN-uppgradering riskerade ett inkompatibelt gränssnitt, och varje distribution som byggde om paketet riskerade att producera ett bibliotek som inte längre passar. När det händer är felet högt och omedelbart, och det är designens enda nåd.

Om ett sådant insticksprogram fortfarande laddas på ditt bygge kan det vara den mindre driftsytan. Bekräfta gränssnittet det byggdes för, håll det fäst vid bygget du testade, och behandla varje uppgradering som en ändring som kräver ett fullt inloggningstest, inte en rutinmässig paketuppdatering.

Vad skriptkroken faktiskt litar på

Kroken konfigureras med auth-user-pass-verify och en leveransmekanism: miljövariabler eller en tillfällig fil. I miljöformen kräver OpenVPN script-security 3, den dokumenterade nivån som tillåter att lösenordet exponeras för skript. Den nivån är en avsiktlig försvagning av standardvärdet, och den bör behandlas som ett tillstånd med en bifogad motivering.

Allt skriptet rör vid ärver det förtroendet. Det måste ägas av root, inte vara skrivbart för grupp eller andra, refereras med en absolut sökväg och vara fritt från varje plats där ett icke betrott värde når ett skal. Sätt varje variabel inom citattecken, avvisa oväntade tecken och bygg aldrig ett kommando från användarnamnet som anges. Ett skript som körs som root vid varje inloggningsförsök förtjänar en granskning just för de fyra egenskaperna.

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

Filformens leverans undviker problemet med miljöarv och ger skriptet uppgifterna via en tillfällig fil med begränsade rättigheter. Om din klient stöder det är det oftast det bättre standardvalet, även om det lägger till ett objekt till att städa vid fel.

Utgångskoderna avgör om du misslyckas öppet

Skriptets utgångsstatus är domen: noll accepterar, icke-noll avvisar. Mönstret som skapar problem är ett skalskript som bara accepterar när RADIUS-svaret innehåller en viss accepttoken och annars returnerar fel, eftersom det smälter tre olika händelser till ett svar. Fel lösenord, en oåtkomlig server och ett felformat svar blir alla samma avvisning.

Separera de fallen i skriptet även om kroken bara kan returnera acceptera eller avvisa. Logga backend-resultatet separat, larma vid tidsgränser och transportfel, och gör det tydligt i övervakningen när autentiseringen misslyckas för att tjänsten ligger nere och inte för att användarna skriver fel.

Två vanor håller resten förnuftig. Om RADIUS är auktoriteten bör den vara den enda platsen där ett lösenord kontrolleras, eftersom en skuggatabell skapar två svar på samma fråga och det andra är en attackyta som ingen bevakar. Och kom ihåg att kroken anropas igen vid varje nytt försök, så ett långsamt skript med en otålig klient blir en förstärkare för lösenordsgissning om du inte lägger till fördröjning eller en policy på RADIUS-sidan.

Vad du ger upp när certifikatet försvinner

Många distributioner av den här formen stänger av klientcertifikatkontrollen helt och låter ett användarnamn och ett lösenord vara hela klientens anspråk. Det som försvinner med den inställningen är certifikatbaserad identitet. Kanalen förblir krypterad, men det enda som namnger klienten är RADIUS-domen. Allt nedströms som förut byggde på ett certifikatsubjekt måste nu bygga på användarnamnet.

Behåll skyddet av kontrollkanalen så att en oautentiserad part inte kan sondera eller överflöda handskakningen, och använd username-as-common-name när konfigurationen per användare beror av det gemensamma namnet. Hanterade gateways löser ofta detta annorlunda, genom att avsluta certifikatautentiseringen vid en gateway som talar EAP-TLS med RADIUS, och i så fall gäller ingen av dessa serverdirektiv. Kopiera modellen som din egen plattform dokumenterar, inte den från en närliggande produkt. De direktiv som spelar roll skiljer sig tillräckligt för att blandning av dem ger en konfiguration som parsas och sedan inte autentiserar någon.