Blocco dell’account contro divieto dell’indirizzo: dove OpenVPN conta davvero

Bloccare un indirizzo e bloccare un account sono due meccanismi diversi e falliscono in direzioni opposte. Un divieto d’indirizzo ferma una sola origine e lascia l’account bersaglio raggiungibile altrove; il blocco dell’account ferma quell’identità ovunque, anche sul portatile dell’utente stesso.

Per una VPN che delega l’autenticazione a PAM, il contatore è ciò che raggiunge lo stack PAM, non ciò che ha registrato l’ascoltatore.

Due contatori, due vittime diverse

Il limitatore di velocità guarda un’origine e chiede quanti tentativi ne sono arrivati di recente. Il blocco guarda un’identità e chiede quanti errori ha accumulato quell’account. Il primo protegge la disponibilità, il secondo la credenziale; nessuno sostituisce l’altro.

Per questo la frase blocchiamo l’IP dopo cinque errori non è una risposta a un rapporto sul riempimento delle credenziali. L’attaccante ruota le origini, ognuna riceve pochi tentativi e l’account non viene mai contato. Al contrario, un blocco senza controllo dell’origine consente all’attaccante di tenere l’account bloccato a tempo indefinito fallendo di proposito.

I due controlli hanno anche storie di ripristino diverse. Un divieto d’indirizzo scade con un timer a cui nessuno deve pensare; un blocco può richiedere un amministratore, un periodo di attesa documentato o una reimpostazione self-service.

Trovate l’archivio che possiede già il conteggio

Prima di aggiungere qualsiasi cosa, accertatevi se esiste già un archivio degli errori. Un account Linux locale, un servizio di directory e un provider di identità esterno tengono ciascuno il proprio conteggio, e un modulo PAM davanti a loro ne crea un secondo invece di estendere il primo.

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

Leggete il file di servizio che la VPN nomina davvero e seguitene le righe di inclusione. In molte distribuzioni il servizio VPN include un file comune, il che significa che il conteggio che state regolando vale anche per SSH e per gli accessi locali.

Se la directory impone già un blocco, la domanda utile è come la conversazione PAM arriva a quella decisione e come la VPN la riporta. Un conteggio locale sovrapposto non diventa il contatore della directory, e le due politiche possono discordare su quando l’account si sblocca.

pam_faillock ha tre posizioni di chiamata, non una

Il modulo separa tre operazioni che una riga copiata di solito confonde: verificare se l’account è già bloccato, registrare un errore e cancellare la cronologia dopo un successo.

È qui che la migrazione da un vecchio modulo di conteggio sbaglia di solito. Copiare una riga da un esempio pam_tally2 funzionante in uno stack pam_faillock non è una rinomina; la configurazione documentata è diversa, e una chiamata fuori posto può registrare errori senza mai verificarli.

faillock --user alice
faillock --user alice --reset

L’utilità di ispezione è il modo più rapido per vedere se il contatore è reale: mostra gli errori registrati per un account e può cancellarli. Se un errore controllato non cambia quell’output, la posizione della chiamata è sbagliata.

Un nome di servizio dedicato non è isolamento

Dare alla VPN un proprio file di servizio PAM rende visibile la politica voluta, ma non ne limita l’effetto. Qualsiasi inclusione di un file comune porta dentro ciò che quel file fa, compresi i conteggi validi per l’intero sistema.

Decidete esplicitamente se il blocco deve coprire solo l’accesso VPN o ogni servizio che autentica lo stesso account. Entrambe le risposte sono difendibili; l’errore è credere di aver scelto l’una mentre lo stack applica l’altra.

Valutate poi il costo. Un attaccante può provocare il blocco, e l’utente che soffre è il proprietario dell’account. Soglia, periodo di attesa e percorso di ripristino amministrativo fanno parte della politica, e il ripristino non deve dipendere dalla riconfigurazione della VPN durante un incidente.

Accettate la sequenza, non un solo rifiuto

Provate con identità designate secondo un piano approvato, e provate una catena invece di un singolo evento: un account valido si autentica, una password deliberatamente errata sposta il contatore, il blocco configurato entra in vigore e il ripristino documentato restituisce l’accesso.

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

Esaminate il comportamento in caso di successo con la stessa cura di quello in caso di errore. Se un accesso riuscito non cancella la cronologia, un account si bloccherà dopo un lento accumulo di errori ordinari. Se cancella tutto da ogni servizio, il contatore è più debole di quanto la politica affermi.

Infine, fermate i client non presidiati prima di dichiarare vittoria. Una credenziale salvata che ritenta in background ricreerà gli errori pochi minuti dopo un ripristino e bloccherà di nuovo l’account. La limitazione di velocità per origine può restare come controllo aggiuntivo, ma non è la politica dell’account.