Filtro Fail2ban per OpenVPN Access Server: real_ip e jail

L'Access Server scrive un proprio formato di log, quindi i filtri standard non trovano nulla. Ancora su real_ip, separa le jail per superficie e verifica che l'indirizzo non sia un proxy.

Hai copiato una OpenVPN jail da un post della community, hai riavviato fail2ban e nessun indirizzo viene mai bannato. La causa è quasi sempre il formato del log: l'Access Server non scrive le righe di errore di autenticazione che un filtro standard si aspetta. Prima di toccare il filtro, conferma che i record esistano, perché un pattern non può corrispondere a ciò che il servizio non ha mai registrato.

Questo è il runbook che seguo su un host Access Server: confermare la forma del record, scrivere un'espressione ancorata, provarla sul log reale, poi separare le jail in base alla superficie attaccata e verificare che il ban raggiunga il firewall.

Conferma che il record di errore esista

L'Access Server scrive le proprie righe strutturate in /var/log/openvpnas.log, e l'indirizzo del client si trova in un campo real_ip tra virgolette e non all'inizio di una riga syslog. Cerca un accesso non riuscito che sai essere avvenuto prima di scrivere qualsiasi pattern:

grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20

Se non compare nulla, il livello di log è il prossimo sospetto. L'Access Server ha un interruttore di debug del database dei log in /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), e il servizio deve essere riavviato dopo averlo modificato. Tratta quell'interruttore come un'impostazione diagnostica da riabbassare una volta ottenuto il pattern, non come una configurazione permanente.

Mentre sei nel file, nota quali superfici vi scrivono. Gli errori del portale client, dell'interfaccia di amministrazione e dell'autenticazione del tunnel finiscono nello stesso file con marcatori diversi, e quel dettaglio decide più avanti la disposizione delle jail.

Ancora un filtro su real_ip

Mantieni l'espressione stretta. Un filtro che rivendica ogni riga contenente un indirizzo IP bannerà persone per normali disconnessioni, e su un server occupato l'unico sintomo è che gli utenti si lamentano di essere stati bloccati per aver chiuso un portatile. Rivendica il record di errore e cattura l'indirizzo tra virgolette:

# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =

Lo spazio iniziale non è cosmetico. L'Access Server indenta i propri record, e ancorarsi a esso impedisce al pattern di rivendicare anche righe emesse da servizi non correlati che scrivono nello stesso file. Se i tuoi record portano invece un timestamp iniziale, fai corrispondere quel prefisso, ma ancorati a qualcosa che sia davvero presente in ogni record che intendi rivendicare.

Quando ti serve precisione per superficie, restringi ulteriormente richiedendo il marcatore di superficie (WEB_CLIENT, WEB_ADMIN o VPN) sulla stessa riga. Un solo filtro con tre pattern è più facile da verificare di tre filtri che differiscono per una parola.

Prova l'espressione prima di abilitare una jail

Non abilitare mai un filtro che non hai eseguito sul log di produzione. Il test documentato passa il filtro due volte, una per caricarlo e una per applicarlo, e il report delle righe mancate è la parte che vale la pena leggere:

fail2ban-regex --print-all-missed /var/log/openvpnas.log \
  /etc/fail2ban/filter.d/openvpnaccess.local \
  /etc/fail2ban/filter.d/openvpnaccess.local > missed.txt

Confronta il numero di corrispondenze con gli errori che hai verificato al primo passo. Zero corrispondenze significa che il pattern è sbagliato; corrispondenze su righe che non sono errori di autenticazione significano che è troppo ampio. Leggi missed.txt finché non riesci a spiegare ogni riga che hai scelto di non rivendicare.

Fai questo test su una copia se il log è grande, e ripetilo dopo ogni aggiornamento dell'Access Server. Il formato del log è l'interfaccia contro cui fai corrispondere, e non è un'API stabile.

Separa le jail per superficie, non per demone

Un Access Server presenta diverse superfici di autenticazione: interfacce web client e di amministrazione sulla 943/tcp, e il tunnel sulla 1194/udp o 443/tcp nella maggior parte delle installazioni. Una sola jail che le copra tutte permette ai tentativi di indovinare sul tunnel di bannare un indirizzo che è anche il tuo percorso di amministrazione, e nasconde quale superficie sia davvero sotto attacco. Dai a ogni superficie la sua jail con la sua porta e le sue soglie:

# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled  = true
port     = 943
protocol = tcp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime  = 1h
[openvpnas-tunnel]
enabled  = true
port     = 443
protocol = udp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime  = 1h

Inizia con contatori piccoli e un ban breve, poi alzali dopo aver osservato una settimana di traffico reale. Una soglia generosa su un indirizzo di ufficio condiviso punisce ogni utente dietro un solo NAT, e un ban aggressivo sulla superficie del tunnel disconnette client legittimi le cui credenziali memorizzate sono scadute durante la notte.

Verifica il ban, il backend e i danni collaterali

Dopo un riavvio, l'output di stato è la conferma più rapida che la jail esiste e sta contando:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Poi conferma che il ban raggiunga il firewall che esegui davvero, perché una jail configurata per un backend che nessuno applica non protegge nulla. Con l'azione iptables gli indirizzi compaiono in una catena intitolata alla jail (f2b-openvpnas-tunnel); con l'azione nftables finiscono in un set nella tabella propria di fail2ban. Controlla quella che usa il tuo host invece di darlo per scontato.

Due controlli collaterali contano più del ban stesso. Primo, verifica che real_ip sia l'indirizzo del client e non un bilanciatore di carico o un proxy inverso; dietro un proxy ogni ban cade sul proxy e si porta giù l'intero servizio. Secondo, scrivi la procedura di sblocco, perché l'indirizzo che supera la soglia alle 02:00 di solito appartiene all'ingegnere di turno: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Tieni presente il limite mentre regoli. Fail2ban è un limitatore di frequenza su una superficie di autenticazione, non uno strato di controllo degli accessi. Non sostituisce MFA, restrizioni per account o il tenere l'interfaccia di amministrazione fuori da Internet, e l'Access Server ha le proprie impostazioni di autoban che vale la pena controllare prima di impilare due limitatori di frequenza sulla stessa porta.

Articoli correlati