Collegare RADIUS a OpenVPN: plugin o hook di script?

Il plugin viene ancora consigliato in discussioni più vecchie delle build attuali, e fallisce al caricamento su un server compilato ieri. Non è un errore di configurazione che si possa correggere con un percorso. Il plugin e l'hook di script risolvono lo stesso problema a livelli diversi, e passare dall'uno all'altro cambia cosa va installato, cosa gira con i privilegi del server e cosa un login fallito vi dice realmente.

Il mito: il plugin è la via supportata

Un plugin è un oggetto condiviso caricato nel processo OpenVPN, quindi deve corrispondere all'interfaccia che quel processo espone. Le build cambiano, il packaging cambia, e una libreria compilata per un'interfaccia più vecchia semplicemente rifiuta di caricarsi. Nulla nella configurazione del server può colmare quel divario, per questo il consiglio "installa solo radiusplugin" finisce con un server che non si avvia.

L'hook di script sta invece fuori dal processo. OpenVPN esegue un programma, gli consegna le credenziali e ne legge un verdetto. È questo disaccoppiamento a fargli sopravvivere agli aggiornamenti, ed è anche ciò che lo rende una vostra responsabilità in un modo in cui il plugin non lo è mai stato.

Nessuno dei due approcci è più sicuro per costruzione. Uno esegue codice estraneo dentro il demone; l'altro esegue il vostro codice accanto, con le credenziali in mano. La domanda giusta è quale di questi due rischi potete davvero gestire.

Cosa teneva insieme il plugin

Il plugin portava con sé un proprio file di configurazione con host RADIUS, segreto condiviso, numero di tentativi e timeout, e la configurazione del server lo referenziava con una sola riga. La gestione delle credenziali restava dentro il processo del server, il che significava che la password non attraversava mai un confine di processo che l'amministratore dovesse proteggere.

Il costo era l'accoppiamento. Ogni aggiornamento di OpenVPN rischiava un'interfaccia incompatibile, e ogni distribuzione che ricostruiva il pacchetto rischiava di produrre una libreria che non corrispondeva più. Quando accade, il guasto è rumoroso e immediato, ed è l'unica misericordia del progetto.

Se un plugin di quel tipo si carica ancora sulla vostra build, può essere la superficie operativa più piccola. Verificate l'interfaccia per cui è stato costruito, tenetelo ancorato alla build che avete testato, e trattate ogni aggiornamento come un cambiamento che richiede un test di login completo, non come un aggiornamento di pacchetto di routine.

Di cosa si fida davvero l'hook di script

L'hook si configura con auth-user-pass-verify e un meccanismo di consegna: variabili d'ambiente o un file temporaneo. Nella forma con ambiente, OpenVPN richiede script-security 3, il livello documentato che consente di esporre la password agli script. Quel livello è un indebolimento deliberato del valore predefinito, e va trattato come un permesso con una giustificazione allegata.

Tutto ciò che lo script tocca eredita quella fiducia. Deve essere di proprietà di root, non scrivibile da gruppo o altri, referenziato con un percorso assoluto e privo di qualsiasi punto in cui un valore non fidato raggiunga una shell. Mettete ogni variabile tra virgolette, rifiutate caratteri inattesi e non costruite mai un comando dal nome utente fornito. Uno script che gira come root a ogni tentativo di login merita una revisione proprio per quelle quattro proprietà.

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

La forma di consegna tramite file evita il problema dell'ereditarietà dell'ambiente e consegna le credenziali allo script attraverso un file temporaneo con permessi ristretti. Se il vostro client lo supporta, di solito è il valore predefinito migliore, anche se aggiunge un altro oggetto da ripulire in caso di guasto.

I codici di uscita decidono se fallite aperti

Lo stato di uscita dello script è il verdetto: zero accetta, diverso da zero rifiuta. Il modello che crea problemi è uno script shell che accetta solo quando la risposta RADIUS contiene uno specifico token di accettazione e restituisce un errore per tutto il resto, perché così fonde tre eventi diversi in una sola risposta. Una password sbagliata, un server irraggiungibile e una risposta malformata diventano tutti lo stesso rifiuto.

Separate quei casi nello script anche se l'hook può restituire solo accetta o rifiuta. Registrate l'esito del backend a parte, allertate su timeout ed errori di trasporto, e rendete evidente nel monitoraggio quando l'autenticazione fallisce perché il servizio è giù e non perché gli utenti sbagliano a digitare.

Due abitudini tengono sana il resto. Se RADIUS è l'autorità, dovrebbe essere l'unico posto in cui si controlla una password, perché una tabella ombra crea due risposte alla stessa domanda e la seconda è una superficie d'attacco che nessuno sorveglia. E ricordate che l'hook viene richiamato a ogni nuovo tentativo, quindi uno script lento con un client impaziente diventa un amplificatore per indovinare le password, a meno che non aggiungiate un ritardo o una policy sul lato RADIUS.

Cosa perdete quando il certificato sparisce

Molti deployment di questa forma disattivano del tutto la verifica del certificato client, lasciando un nome utente e una password come tutta la pretesa del client. Ciò che scompare con quell'impostazione è l'identità basata sul certificato. Il canale resta cifrato, ma l'unica cosa che nomina il client è il verdetto RADIUS. Qualunque elemento a valle che prima si basava sul soggetto del certificato ora deve basarsi sul nome utente.

Mantenete la protezione del canale di controllo perché un pari non autenticato non possa sondare o inondare l'handshake, e usate username-as-common-name quando la configurazione per utente dipende dal nome comune. I gateway gestiti spesso risolvono diversamente, terminando l'autenticazione del certificato su un gateway che parla EAP-TLS con RADIUS, e in quel caso nessuna di queste direttive del server si applica. Copiate il modello che documenta la vostra piattaforma, non quello di un prodotto vicino. Le direttive che contano differiscono abbastanza che mescolarle produce una configurazione che viene analizzata e poi non autentica nessuno.