Filtro de Fail2ban para OpenVPN Access Server: real_ip e cárceres

O Access Server escribe o seu propio formato de rexistro, así que os filtros estándar non atopan nada. Ancora en real_ip, separa os cárceres por superficie e comproba que o enderezo non sexa un proxy.

Copiaches un OpenVPN cárcere dunha publicación da comunidade, reiniciaches fail2ban e ningunha dirección se bloquea nunca. A causa case sempre é o formato do rexistro: o Access Server non escribe as liñas de fallo de autenticación que espera un filtro estándar. Antes de tocar o filtro, confirma que os rexistros existen sequera, porque un patrón non pode coincidir co que o servizo nunca rexistrou.

Este é o runbook que sigo nun host con Access Server: confirmar a forma do rexistro, escribir unha expresión ancorada, probala contra o rexistro real, despois separar os cárceres pola superficie atacada e verificar que o bloqueo chega á devasa.

Confirma que o rexistro de fallo existe

O Access Server escribe as súas propias liñas estruturadas en /var/log/openvpnas.log, e o enderezo do cliente vive nun campo real_ip entre comiñas e non ao comezo dunha liña de syslog. Busca un inicio de sesión fallido que saibas que ocorreu antes de escribir calquera patrón:

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

Se non aparece nada, o nivel de rexistro é o seguinte sospeitoso. O Access Server ten un interruptor de depuración da base de datos de rexistro en /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), e o servizo ten que reiniciarse despois de cambialo. Trata ese interruptor como un axuste de diagnóstico que se volve baixar cando teñas o teu patrón, non como unha configuración permanente.

Mentres estás no ficheiro, fíxate que superficies escriben nel. Os fallos do portal do cliente, da interface de administración e da autenticación do túnel acaban no mesmo ficheiro con marcadores distintos, e ese detalle decide máis tarde o deseño dos cárceres.

Ancora un filtro en real_ip

Mantén a expresión estreita. Un filtro que reclame calquera liña cun enderezo IP bloqueará xente por desconexións normais, e nun servidor ocupado o único síntoma é que os usuarios se queixan de quedaren bloqueados por pecharen un portátil. Reclama o rexistro de erro e captura o enderezo entre comiñas:

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

O espazo inicial non é cosmético. O Access Server sangra os seus rexistros, e ancorarse nel evita que o patrón reclame tamén liñas que servizos non relacionados escriben no mesmo ficheiro. Se os teus rexistros levan en cambio unha marca de tempo ao principio, fai coincidir ese prefixo, pero ancora en algo que estea realmente presente en cada rexistro que pretendas reclamar.

Cando necesites precisión por superficie, estreita aínda máis esixindo o marcador de superficie (WEB_CLIENT, WEB_ADMIN ou VPN) na mesma liña. Un filtro con tres patróns é máis doado de auditar que tres filtros que se diferencian nunha palabra.

Proba a expresión antes de habilitar un cárcere

Nunca habilites un filtro que non executaches contra o rexistro de produción. A proba documentada pasa o filtro dúas veces, unha para cargalo e outra para aplicalo, e o informe de liñas non detectadas é a parte que merece lerse:

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

Compara o número de coincidencias cos fallos que verificaches no primeiro paso. Zero coincidencias significa que o patrón está mal; as coincidencias en liñas que non son fallos de autenticación significan que é demasiado amplo. Le missed.txt ata que poidas explicar cada liña que decidiches non reclamar.

Fai esta proba sobre unha copia se o rexistro é grande, e repítea despois de calquera actualización do Access Server. O formato do rexistro é a interface contra a que coincidiches, e non é unha API estable.

Separa os cárceres por superficie, non por demonio

Un Access Server presenta varias superficies de autenticación: interfaces web de cliente e de administración en 943/tcp, e o túnel en 1194/udp ou 443/tcp na maioría de despregamentos. Un só cárcere que as cubra todas permite que os intentos de adiviñar no túnel bloqueen un enderezo que tamén é a túa vía de administración, e oculta que superficie está realmente baixo ataque. Dálle a cada superficie o seu propio cárcere co seu porto e límites:

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

Comeza con contadores pequenos e un bloqueo curto, e cólgaos cando observes unha semana de tráfico real. Un límite xeneroso nun enderezo de oficina compartida castiga todos os usuarios detrás dun NAT, e un bloqueo agresivo na superficie do túnel desconecta clientes lexítimos cuxas credenciais gardadas caducaron durante a noite.

Verifica o bloqueo, o backend e os danos colaterais

Tras un reinicio, a saída de estado é a confirmación máis rápida de que o cárcere existe e está contando:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Logo confirma que o bloqueo chega á devasa que realmente executas, porque un cárcere configurado para un backend que ninguén aplica non protexe nada. Coa acción de iptables os enderezos aparecen nunha cadea co nome do cárcere (f2b-openvpnas-tunnel); coa acción de nftables caen nun conxunto na táboa propia de fail2ban. Comproba a que usa o teu host en lugar de supoñelo.

Dúas comprobacións colaterais importan máis que o propio bloqueo. Primeiro, verifica que real_ip é o enderezo do cliente e non un balanceador de carga ou un proxy inverso; detrás dun proxy cada bloqueo cae sobre o proxy e leva todo o servizo por diante. Segundo, escribe o procedemento de desbloqueo, porque o enderezo que cruza o límite ás 02:00 adoita pertencer ao enxeñeiro de garda: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Ten presente o límite mentres axustas. Fail2ban é un limitador de velocidade nunha superficie de autenticación, non unha capa de control de acceso. Non substitúe MFA, as restricións por conta nin manter a interface de administración fóra de internet, e o Access Server ten os seus propios axustes de autoban que paga a pena revisar antes de apilar dous limitadores de velocidade no mesmo porto.

Artigos relacionados