Limitare gli accessi OpenVPN a un gruppo con un criterio PAM
Un servizio PAM dedicato può ammettere solo i membri di un gruppo VPN senza toccare le regole di accesso del sistema. Puntate il plugin auth-pam su di esso e provate i risultati.
Lasciate ogni account in grado di accedere normalmente, ma consentite a un solo gruppo di usare la VPN. PAM può esprimere questa differenza senza un secondo archivio di password, e il plugin OpenVPN può essere puntato su un servizio che contiene solo i controlli che intendete. Il trucco è costruire quel servizio senza ereditare accidentalmente uno stack a livello di sistema.
Il percorso qui parte dal nome del servizio del plugin, costruisce un criterio e poi prova i tre esiti che contano: un membro, un esterno con una password valida e una credenziale errata.
Perché un servizio PAM separato
Il plugin auth-pam prende un nome di servizio come argomento. Quel nome seleziona un file sotto /etc/pam.d, e lo stack di quel file è ciò che viene eseguito durante un accesso VPN. Se passate lo stesso nome usato da un accesso a livello di sistema, ereditate ogni decisione di quello stack, comprese quelle aggiunte in seguito per motivi non correlati.
Create invece un servizio dedicato. Partite da uno stack funzionante che autentica già verso il backend previsto, come un file di password locale, SSSD o un servizio di directory, poi aggiungete la regola di idoneità. Copiare due righe in un file vuoto è l’errore comune: scadenza della password, blocco dell’account e altri controlli possono vivere nello stack che non avete copiato.
Separare il servizio limita anche il raggio del danno. Una regola solo VPN in uno stack condiviso può negare l’accesso SSH o console a tutti, il che trasforma un cambio di accesso in un’interruzione.
Scrivere la regola del gruppo
Il controllo di idoneità appartiene alla fase account, dopo che la credenziale è stata verificata. Una regola come account required pam_succeed_if.so user ingroup vpnusers consente l’elaborazione solo quando l’utente autenticato è membro di quel gruppo.
Quella riga è un frammento, non un servizio completo. Integratela dove ogni percorso accettato la raggiunge e controllate i flag di controllo intorno ad essa. Un controllo sufficient o un salto più in alto nello stack può terminare l’elaborazione prima che la vostra regola venga eseguita, il che trasforma la restrizione in un suggerimento.
Non aggiungete use_uid per abitudine. Senza, il modulo valuta l’utente in fase di autenticazione; con, il modulo valuta l’account sotto cui gira il processo OpenVPN, che di solito è root o un account di servizio e quindi non la persona che accede.
L’appartenenza al gruppo deriva dalla risoluzione delle identità del sistema, non da un nome che riconoscete. Per gli utenti di directory, confermate che lo stesso backend risponda alle query di gruppo per quell’utente, perché un gruppo locale con un nome familiare è un oggetto diverso dal gruppo di directory con lo stesso nome.
Trappole di ordine e identità
Mettete la regola del gruppo dopo lo stack di autenticazione e dopo ogni controllo che deve ancora valere, ma prima o accanto ai controlli account che mantenete. PAM valuta i moduli nell’ordine del file, e il valore di controllo su ogni riga decide se un errore è definitivo.
Attenzione agli stack duplicati. Uno schema comune è un include che contiene già una regola account, seguito dalla vostra regola di gruppo, che produce due decisioni dove ne aspettavate una. Leggete il file incluso, non solo quello che avete modificato. Un modo rapido per vedere l’ordine effettivo è leggere il file dall’alto in basso e annotare ogni valore di controllo.
Mantenete intatti gli altri requisiti di ammissione. Una password corretta non sostituisce i controlli del certificato, un secondo fattore o l’autorizzazione dopo la connessione, e questo criterio non sostituisce nessuno di essi. Decide solo se l’account è idoneo a essere considerato per l’accesso VPN.
Provare membri, esterni e password errate
Provate tre casi prima di considerare il criterio concluso. Un membro si connette correttamente. Un account valido fuori dal gruppo autentica la sua password ma gli viene negato l’accesso VPN. Una password errata per uno dei due account viene rifiutata nella fase di autenticazione, non dalla regola del gruppo.
Guardate insieme l’errore visibile al client e il registro del server, perché entrambi i fallimenti possono sembrare simili alla persona che si connette. La distinzione conta per il supporto: un esterno con la password corretta ha bisogno di un cambio di gruppo, mentre una password errata richiede un ripristino della credenziale.
Tenete aperta una seconda sessione mentre modificate PAM, e verificate anche l’accesso SSH ordinario dopo la modifica. Il punto del servizio dedicato è che l’accesso al sistema dovrebbe restare intatto, e l’unico modo per saperlo è provarlo.
Se qualcosa si rompe, ripristinate il file di servizio precedente da una copia. La regola che volete è semplice da enunciare: l’appartenenza rende un account idoneo all’accesso VPN, e ogni altro controllo richiesto vale ancora.