Zapojení RADIUS do OpenVPN: plugin, nebo skriptový hák?

Plugin se stále doporučuje ve vláknech starších než současné buildy a na serveru zkompilovaném včera selže při načtení. To není chyba konfigurace, kterou byste opravili cestou. Plugin a skriptový hák řeší stejný problém na různých vrstvách a přechod z jednoho na druhý mění, co je třeba nainstalovat, co běží se serverovými oprávněními a co vám neúspěšné přihlášení vlastně říká.

Mýtus: plugin je podporovaná cesta

Plugin je sdílený objekt načtený do procesu OpenVPN, takže musí odpovídat rozhraní, které tento proces vystavuje. Buildy se mění, balení se mění a knihovna zkompilovaná pro starší rozhraní prostě odmítne se načíst. Nic v konfiguraci serveru tuto mezeru nepřemostí, a proto rada "prostě nainstalujte radiusplugin" končí serverem, který nenaběhne.

Skriptový hák stojí mimo proces. OpenVPN spustí program, předá mu přihlašovací údaje a přečte verdikt. Právě toto oddělení mu umožňuje přežít upgrady, a zároveň z něj dělá vaši odpovědnost způsobem, jakým plugin nikdy nebyl.

Ani jeden přístup není bezpečnější ze své podstaty. Jeden spouští cizí kód uvnitř démona; druhý spouští váš kód vedle něj s přihlašovacími údaji v ruce. Správná otázka je, které z těch dvou rizik dokážete skutečně provozovat.

Co plugin svazoval

Plugin nesl vlastní konfigurační soubor s hostitelem RADIUS, sdíleným tajemstvím, počtem opakování a časovým limitem a konfigurace serveru na něj odkazovala jediným řádkem. Zpracování přihlašovacích údajů zůstávalo uvnitř procesu serveru, což znamenalo, že heslo nikdy nepřekročilo hranici procesu, kterou musel administrátor zabezpečit.

Cenou bylo svázání. Každý upgrade OpenVPN riskoval nekompatibilní rozhraní a každá distribuce, která balíček znovu sestavovala, riskovala knihovnu, která už neodpovídá. Když k tomu dojde, selhání je hlasité a okamžité, a to je jediné milosrdenství tohoto návrhu.

Pokud se takový plugin na vašem buildu ještě načítá, může být menší provozní plochou. Ověřte rozhraní, pro které byl sestaven, držte ho připnutý k buildu, který jste otestovali, a každý upgrade berte jako změnu vyžadující plný test přihlášení, ne rutinní aktualizaci balíčku.

Čemu skriptový hák skutečně důvěřuje

Hák se konfiguruje pomocí auth-user-pass-verify a mechanismu doručení: proměnných prostředí nebo dočasného souboru. U formy s prostředím OpenVPN vyžaduje script-security 3, dokumentovanou úroveň, která umožňuje vystavení hesla skriptům. Tato úroveň je záměrným oslabením výchozího nastavení a mělo by se s ní zacházet jako s oprávněním s přiloženým odůvodněním.

Vše, čeho se skript dotkne, tuto důvěru dědí. Musí být vlastněn rootem, nesmí být zapisovatelný pro skupinu ani ostatní, musí být odkazován absolutní cestou a nesmí mít místo, kde se nedůvěryhodná hodnota dostane do shellu. Každou proměnnou dejte do uvozovek, odmítněte neočekávané znaky a nikdy nestavte příkaz z dodaného uživatelského jména. Skript, který běží jako root při každém pokusu o přihlášení, stojí za jedno přezkoumání právě kvůli těmto čtyřem vlastnostem.

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

Forma doručení souborem se vyhýbá problému dědění prostředí a předává přihlašovací údaje skriptu přes dočasný soubor s omezenými právy. Pokud to váš klient podporuje, je to obvykle lepší výchozí volba, i když přidává další objekt k úklidu při selhání.

Návratové kódy rozhodují, zda selžete otevřeně

Návratový stav skriptu je verdikt: nula přijímá, nenulová odmítá. Vzorem, který působí potíže, je shellový skript, který přijme jen tehdy, když odpověď RADIUS obsahuje určitý token přijetí, a pro vše ostatní vrací selhání, protože tím slévá tři různé události do jedné odpovědi. Špatné heslo, nedostupný server a zdeformovaná odpověď se stanou stejným odmítnutím.

Rozdělte ty případy ve skriptu, i když hák umí vrátit jen přijmi nebo odmítni. Výsledek backendu logujte zvlášť, upozorňujte na časové limity a transportní chyby a v monitoringu udělejte zřejmým, když autentizace selhává proto, že služba je mimo provoz, a ne proto, že uživatelé chybují při psaní.

Dva návyky drží zbytek při zdravém rozumu. Pokud je RADIUS autoritou, měl by být jediným místem, kde se heslo kontroluje, protože stínová tabulka vytváří dvě odpovědi na stejnou otázku a ta druhá je útočná plocha, kterou nikdo nesleduje. A pamatujte, že hák se volá znovu při každém opakování, takže pomalý skript s netrpělivým klientem se stane zesilovačem hádání hesel, pokud nepřidáte zpoždění nebo politiku na straně RADIUS.

O co přicházíte, když certifikát zmizí

Mnoho nasazení tohoto tvaru úplně vypíná kontrolu klientského certifikátu a nechává uživatelské jméno a heslo jako celý nárok klienta. S tímto nastavením mizí identita založená na certifikátu. Kanál zůstává šifrovaný, ale jediné, co klienta pojmenovává, je verdikt RADIUS. Cokoli níže, co se dříve opíralo o subjekt certifikátu, se nyní musí opírat o uživatelské jméno.

Zachovejte ochranu řídicího kanálu, aby neautentizovaný protějšek nemohl sondu nebo zahltit handshake, a používejte username-as-common-name, když konfigurace pro jednotlivé uživatele závisí na společném jménu. Spravované brány to často řeší jinak, ukončují autentizaci certifikátem na bráně, která mluví EAP-TLS s RADIUS, a v tom případě žádná z těchto serverových direktiv neplatí. Kopírujte model, který dokumentuje vaše vlastní platforma, ne ten od sousedního produktu. Direktivy, na kterých záleží, se liší natolik, že jejich míchání dá konfiguraci, která se parsuje a pak neautentizuje nikoho.