Integrar RADIUS a OpenVPN: connector o ganxo d’script?
El vell connector RADIUS està lligat a la compilació del servidor per a la qual es va compilar. El ganxo auth-user-pass-verify el substitueix, però trasllada la confiança al vostre script.
El connector encara es recomana en fils anteriors a les compilacions actuals, i falla en carregar-se en un servidor compilat ahir. No és un error de configuració que pugueu arreglar amb una ruta. El connector i el ganxo d’script resolen el mateix problema en capes diferents, i passar d’un a l’altre canvia què cal instal·lar, què s’executa amb privilegis de servidor i què us diu realment un inici de sessió fallit.
El mite: el connector és la via suportada
Un connector és un objecte compartit carregat dins del procés d’OpenVPN, així que ha de coincidir amb la interfície que aquest procés exposa. Les compilacions canvien, l’empaquetament canvia, i una biblioteca compilada per a una interfície antiga simplement es nega a carregar-se. Res de la configuració del servidor no pot salvar aquesta bretxa, i per això el consell de "només instal·leu radiusplugin" acaba amb un servidor que no arrenca.
El ganxo d’script queda fora del procés. OpenVPN executa un programa, li passa les credencials i llegeix un veredicte. Aquest desacoblament és el que li permet sobreviure a les actualitzacions, i també el que el converteix en responsabilitat vostra d’una manera que el connector mai no ho va ser.
Cap dels dos enfocaments no és més segur per construcció. Un executa codi aliè dins del dimoni; l’altre executa el vostre codi al costat amb les credencials a la mà. La pregunta correcta és quin d’aquests dos riscos podeu operar de debò.
Què lligava el connector
El connector portava el seu propi fitxer de configuració amb l’amfitrió RADIUS, el secret compartit, el nombre de reintents i el temps d’espera, i la configuració del servidor hi feia referència amb una sola línia. El tractament de les credencials es quedava dins del procés del servidor, cosa que volia dir que la contrasenya no creuava mai una frontera de procés que l’administrador hagués de protegir.
El cost era l’acoblament. Cada actualització d’OpenVPN arriscava una interfície incompatible, i cada distribució que reconstruïa el paquet arriscava produir una biblioteca que ja no coincidia. Quan això passa, la fallada és sorollosa i immediata, i aquesta és l’única misericòrdia del disseny.
Si un connector d’aquest tipus encara es carrega a la vostra compilació, pot ser la superfície operativa més petita. Confirmeu la interfície per a la qual es va compilar, manteniu-lo fixat a la compilació que heu provat i tracteu qualsevol actualització com un canvi que exigeix una prova completa d’inici de sessió, no una actualització rutinària del paquet.
En què confia realment el ganxo d’script
El ganxo es configura amb auth-user-pass-verify i un mecanisme de lliurament: variables d’entorn o un fitxer temporal. Amb la forma d’entorn, OpenVPN exigeix script-security 3, el nivell documentat que permet exposar la contrasenya als scripts. Aquest nivell és un afebliment deliberat del valor per defecte, i s’ha de tractar com un permís amb una justificació adjunta.
Tot el que el script toca hereta aquesta confiança. Ha de ser propietat de root, no escrivible pel grup ni per altres, referenciat amb un camí absolut i lliure de qualsevol lloc on un valor no fiable arribi a un shell. Poseu cada variable entre cometes, rebutgeu caràcters inesperats i no construïu mai una ordre a partir del nom d’usuari proporcionat. Un script que s’executa com a root a cada intent d’inici de sessió mereix una revisió justament per aquestes quatre propietats.
ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh
La forma de lliurament per fitxer evita el problema de l’herència d’entorn i lliura les credencials al script mitjançant un fitxer temporal amb permisos restringits. Si el vostre client ho admet, normalment és el millor valor per defecte, tot i que afegeix un objecte més a netejar en cas de fallada.
Els codis de sortida decideixen si feu fallada oberta
L’estat de sortida del script és el veredicte: zero accepta, no-zero rebutja. El patró que causa problemes és un script de shell que només accepta quan la resposta RADIUS conté un testimoni d’acceptació concret i retorna fallada per a tot la resta, perquè això ajunta tres esdeveniments diferents en una sola resposta. Una contrasenya incorrecta, un servidor inabastable i una resposta malformada esdevenen tots el mateix rebuig.
Separeu aquests casos al script encara que el ganxo només pugui retornar accepta o rebutja. Registreu el resultat del backend per separat, alerteu sobre temps d’espera i errors de transport, i feu evident en el monitoratge quan l’autenticació falla perquè el servei està caigut i no perquè els usuaris s’equivoquen en escriure.
Dos hàbits mantenen la resta assenyada. Si RADIUS és l’autoritat, hauria de ser l’únic lloc on es comprova una contrasenya, perquè una taula d’ombra crea dues respostes a la mateixa pregunta i la segona és una superfície d’atac que ningú no mira. I recordeu que el ganxo es crida de nou a cada reintent, així que un script lent amb un client impacient es converteix en un amplificador per endevinar contrasenyes tret que afegiu retard o una política al costat de RADIUS.
Què perdeu quan el certificat desapareix
Moltes implantacions d’aquesta forma desactiven del tot la comprovació del certificat de client, deixant un nom d’usuari i una contrasenya com a tota l’afirmació del client. El que desapareix amb aquest paràmetre és la identitat basada en certificat. El canal continua xifrat, però l’única cosa que anomena el client és el veredicte de RADIUS. Qualsevol element posterior que abans es basava en el subjecte del certificat ara ha de basar-se en el nom d’usuari.
Manteniu la protecció del canal de control perquè un parell no autenticat no pugui sondar ni inundar l’encaixada de mans, i feu servir username-as-common-name quan la configuració per usuari depèn del nom comú. Les passarel·les gestionades sovint ho resolen d’una altra manera, acabant l’autenticació de certificat en una passarel·la que parla EAP-TLS amb RADIUS, i en aquest cas cap d’aquestes directives de servidor no s’aplica. Copieu el model que documenta la vostra pròpia plataforma, no el d’un producte veí. Les directives que importen difereixen prou que barrejar-les produeix una configuració que s’analitza i després no autentica ningú.