Filtre de Fail2ban per a OpenVPN Access Server: real_ip i gàbies

Heu copiat una gàbia de OpenVPN a partir d'una publicació de la comunitat, heu reiniciat fail2ban i cap adreça no es bloqueja mai. El motiu és gairebé sempre el format del registre: l'Access Server no escriu les línies de fallada d'autenticació que espera un filtre estàndard. Abans de tocar el filtre, confirmeu que els registres hi són, perquè un patró no pot coincidir amb el que el servei no ha registrat mai.

Aquest és el runbook que segueixo en un host amb Access Server: confirmar la forma del registre, escriure una expressió ancorada, provar-la contra el registre real, després separar les gàbies per la superfície atacada i verificar que el bloqueig arriba al tallafoc.

Confirmeu que el registre de fallada existeix

L'Access Server escriu les seves línies estructurades a /var/log/openvpnas.log, i l'adreça del client viu en un camp real_ip entre cometes, no a l'inici d'una línia de syslog. Cerqueu un inici de sessió fallit que sapigueu que va passar abans d'escriure cap patró:

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

Si no apareix res, el nivell de registre és el següent sospitós. L'Access Server té un commutador de depuració de la base de dades de registre a /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), i el servei s'ha de reiniciar després de canviar-lo. Tracteu aquest commutador com un paràmetre de diagnòstic que s'ha de tornar a baixar quan tingueu el patró, no com una configuració permanent.

Mentre sou al fitxer, fixeu-vos quines superfícies hi escriuen. Les fallades del portal del client, de la interfície d'administració i de l'autenticació del túnel arriben al mateix fitxer amb marcadors diferents, i aquest detall decideix més endavant el disseny de les gàbies.

Ancoreu un filtre a real_ip

Manteniu l'expressió estreta. Un filtre que reclami qualsevol línia amb una adreça IP bloquejarà gent per desconnectades normals, i en un servidor ocupat l'únic símptoma és que els usuaris es queixen que els han bloquejat per tancar un portàtil. Reclameu el registre d'error i captureu l'adreça entre cometes:

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

L'espai inicial no és estètic. L'Access Server sagna els seus registres, i ancorar-s'hi evita que el patró reclami també línies que serveis no relacionats escriuen al mateix fitxer. Si els vostres registres porten al capdavant una marca de temps, feu coincidir aquest prefix, però ancoreu-vos en alguna cosa que hi sigui realment a cada registre que vulgueu reclamar.

Quan necessiteu precisió per superfície, estretiu més exigint el marcador de superfície (WEB_CLIENT, WEB_ADMIN o VPN) a la mateixa línia. Un filtre amb tres patrons és més fàcil d'auditar que tres filtres que es diferencien en una paraula.

Proveu l'expressió abans d'activar una gàbia

No activeu mai un filtre que no hàgiu executat contra el registre de producció. La prova documentada passa el filtre dues vegades, una per carregar-lo i una per aplicar-lo, i l'informe de línies no detectades és la part que val la pena llegir:

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

Compareu el recompte de coincidències amb les fallades que heu verificat al primer pas. Zero coincidències vol dir que el patró és incorrecte; coincidències en línies que no són fallades d'autenticació vol dir que és massa ampli. Llegiu missed.txt fins que pugueu explicar cada línia que heu decidit no reclamar.

Feu aquesta prova sobre una còpia si el registre és gran, i torneu-la a fer després de qualsevol actualització de l'Access Server. El format del registre és la interfície contra la qual coincidiu, i no és una API estable.

Separeu les gàbies per superfície, no per dimoni

Un Access Server presenta diverses superfícies d'autenticació: interfícies web de client i d'administració al 943/tcp, i el túnel al 1194/udp o 443/tcp a la majoria de desplegaments. Una sola gàbia que les cobreixi totes permet que els intents d'endevinar al túnel bloquin una adreça que també és la vostra via d'administració, i amaga quina superfície està realment sota atac. Doneu a cada superfície la seva pròpia gàbia amb el seu port i llindars:

# /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

Comenceu amb comptadors petits i un bloqueig curt, i apugeu-los quan hàgiu observat una setmana de trànsit real. Un llindar generós en una adreça d'oficina compartida castiga tots els usuaris darrere d'un NAT, i un bloqueig agressiu a la superfície del túnel desconnecta clients legítims les credencials emmagatzemades dels quals han caducat durant la nit.

Verifiqueu el bloqueig, el backend i els danys col·laterals

Després d'un reinici, la sortida d'estat és la confirmació més ràpida que la gàbia existeix i que compta:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Després confirmeu que el bloqueig arriba al tallafoc que realment executeu, perquè una gàbia configurada per a un backend que ningú no aplica no protegeix res. Amb l'acció d'iptables les adreces apareixen en una cadena que porta el nom de la gàbia (f2b-openvpnas-tunnel); amb l'acció de nftables cauen en un conjunt a la taula pròpia de fail2ban. Comproveu la que fa servir el vostre host en lloc de suposar-ho.

Dues comprovacions col·laterals importen més que el bloqueig mateix. Primer, verifiqueu que real_ip és l'adreça del client i no un balancejador de càrrega o un proxy invers; darrere d'un proxy cada bloqueig cau sobre el proxy i s'emporta tot el servei. Segon, escriviu el procediment de desbloqueig, perquè l'adreça que supera el llindar a les 02:00 normalment pertany a l'enginyer de guàrdia: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Tingueu present el límit mentre ajusteu. Fail2ban és un limitador de ritme en una superfície d'autenticació, no una capa de control d'accés. No substitueix MFA, les restriccions per compte ni mantenir la interfície d'administració fora d'Internet, i l'Access Server té els seus propis paràmetres d'autoban que val la pena revisar abans d'apilar dos limitadors de ritme al mateix port.