Fail2ban su un gateway VPN: cosa risolve e cosa no

Ogni servizio esposto riceve lo stesso consiglio: mettici fail2ban. Per un gateway VPN quel consiglio non è né sbagliato né sufficiente, e trattarlo come una casella di irrobustimento è esattamente come si finisce con una prigione (jail) che non blocca nulla di utile. Fail2ban legge i record di errore verso cui lo indirizzi e chiede a un backend di applicazione di bandire le sorgenti corrispondenti. Tutto il suo valore dipende da quale superficie di autenticazione ha prodotto il record, se l'indirizzo al suo interno è il vero client e cosa succede a tutti gli altri dietro quell'indirizzo.

Cos'è fail2ban, meccanicamente

Un filtro fa corrispondere righe di un log, una prigione conta le corrispondenze per sorgente, e un'azione applica un bando tramite un backend del firewall. Tre parti mobili, e ciascuna può essere sbagliata in modo indipendente.

Nessuna delle tre tocca il percorso di autenticazione: fail2ban reagisce alle prove a posteriori e non convalida mai da solo una credenziale. Una prigione può quindi funzionare in modo pulito mentre la superficie che nomina resta esattamente esposta come prima.

L'ascoltatore del tunnel non è un modulo di accesso

Un ascoltatore OpenVPN protetto con tls-auth o tls-crypt scarta i pacchetti privi della protezione del canale di controllo prima che inizi l'elaborazione TLS ordinaria. Uno scanner che non ha mai la chiave non genera nulla che il tuo filtro possa contare. L'autenticazione con certificato aggiunge un'altra porta, perché non c'è una password da indovinare. Il progetto Fail2ban documenta un modello generale guidato dai log, e un filtro VPN generico non trasforma un pacchetto non autenticato in un evento di errore significativo.

Se il gateway accetta solo certificati, la storia di forza bruta contro cui ti difendi potrebbe non esistere affatto su quella porta.

Quindi quale superficie stai proteggendo?

Lo stesso host espone spesso tre cose diverse: l'ascoltatore del tunnel, un portale per profili client o self-service e una pagina di amministrazione. Il portale e la pagina di amministrazione hanno moduli con password e producono righe di log che un filtro può contare. Il tunnel potrebbe produrre solo errori di stretta di mano che significano qualcosa di completamente diverso. Abbina la prigione alla superficie, non al nome del prodotto.

Una prigione che sorveglia il log sbagliato è peggio di nessuna, perché crea fiducia senza copertura. Punta un filtro di accesso sugli errori di stretta di mano del tunnel e il contatore scatterà su scanner che non hanno mai avuto una chiave, mentre un attacco con password contro il portale resterà non contato. Leggi la riga di log che il filtro fa corrispondere prima di fidarti del numero della prigione.

L'attribuzione della sorgente è l'anello debole

Un bando vale quanto l'indirizzo che prende di mira. Quando il servizio sta dietro un proxy inverso locale, l'indirizzo del client nel log può essere quello del proxy, e bandirlo rimuove tutti. Fidarsi di un'intestazione inoltrata da una fonte non attendibile dà a un attaccante la capacità di bandire indirizzi arbitrari. Su UDP gli indirizzi di origine possono essere falsificati, quindi contarli merita più attenzione che contare un accesso TCP completato.

Registra il metodo di attribuzione della sorgente nel README della prigione, perché un'intestazione inoltrata da un salto non attendibile trasforma un bando in un'arma.

Il costo collaterale sono gli altri

Diversi dipendenti dietro un NAT d'ufficio condividono un indirizzo, quindi una sola password salvata e obsoleta può bloccare l'intero ufficio una volta superata la soglia. Il log mostra una sorgente e un account che hanno fallito, non un'interruzione per tutto l'ufficio.

Bandi brevi e soglie moderate riducono questo, e un percorso documentato per rimuovere il bando riduce il carico di supporto quando succede comunque. L'indirizzo è un segnale grossolano anziché un'identità, e chi apre il ticket descriverà l'interruzione, non la soglia.

Quando adottarlo, e quando correggere qualcos'altro

Adottalo quando esiste un fallimento di accesso online reale, attribuibile e ripetuto su una superficie che controlli, e quando il backend di applicazione copre davvero quella superficie. Correggi qualcos'altro quando il problema è una politica delle credenziali debole, una pagina di gestione esposta a internet o un account che accede con successo perché è stato compromesso. Un bando non può riparare nessuno di questi e non può assorbire il traffico che ha già saturato il tuo uplink. Quest'ultimo problema appartiene a monte, a qualcuno che può filtrare prima che i pacchetti ti raggiungano.

Mantieni ogni prigione legata a una superficie, rivedi i falsi positivi e misura il lavoro di autenticazione evitato invece del numero di indirizzi banditi.