Filtro Fail2ban para OpenVPN Access Server: real_ip e jails

Você copiou uma OpenVPN jail de um post da comunidade, reiniciou o fail2ban e nenhum endereço é banido. A causa é quase sempre o formato do log: o Access Server não escreve as linhas de falha de autenticação que um filtro padrão espera. Antes de mexer no filtro, confirme se os registros existem, porque um padrão não pode corresponder ao que o serviço nunca registrou.

Este é o runbook que sigo num host com Access Server: confirmar a forma do registro, escrever uma expressão ancorada, testá-la contra o log real, depois separar as jails pela superfície atacada e verificar se o ban chega ao firewall.

Confirme que o registro de falha existe

O Access Server escreve as próprias linhas estruturadas em /var/log/openvpnas.log, e o endereço do cliente fica num campo real_ip entre aspas, e não no início de uma linha de syslog. Procure um login falhado que você sabe ter acontecido antes de escrever qualquer padrão:

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

Se nada aparecer, o nível de log é o próximo suspeito. O Access Server tem um interruptor de depuração do banco de dados de logs em /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), e o serviço precisa ser reiniciado depois de alterá-lo. Trate esse interruptor como um ajuste de diagnóstico a ser baixado de novo quando tiver seu padrão, e não como uma configuração permanente.

Enquanto estiver no arquivo, note quais superfícies escrevem nele. Falhas do portal do cliente, da interface de administração e da autenticação do túnel caem no mesmo arquivo com marcadores diferentes, e esse detalhe decide mais tarde o layout das jails.

Ancore um filtro em real_ip

Mantenha a expressão estreita. Um filtro que reivindica qualquer linha com um endereço IP vai banir pessoas por desconexões comuns, e num servidor ocupado o único sintoma é usuários reclamando de terem sido bloqueados por fechar um notebook. Reivindique o registro de erro e capture o endereço entre aspas:

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

O espaço inicial não é cosmético. O Access Server recua os próprios registros, e ancorar nele impede que o padrão reivindique também linhas que serviços não relacionados escrevem no mesmo arquivo. Se os seus registros tiverem em vez disso um carimbo de tempo no início, case esse prefixo, mas ancore em algo que esteja realmente presente em cada registro que você pretende reivindicar.

Quando precisar de precisão por superfície, estreite mais exigindo o marcador de superfície (WEB_CLIENT, WEB_ADMIN ou VPN) na mesma linha. Um filtro com três padrões é mais fácil de auditar do que três filtros que diferem numa palavra.

Teste a expressão antes de habilitar uma jail

Nunca habilite um filtro que você não rodou contra o log de produção. O teste documentado passa o filtro duas vezes, uma para carregar e outra para aplicar, e o relatório de linhas perdidas é a parte que vale a pena ler:

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

Compare o número de correspondências com as falhas que você verificou no primeiro passo. Zero correspondências significa que o padrão está errado; correspondências em linhas que não são falhas de autenticação significam que ele é amplo demais. Leia missed.txt até conseguir explicar cada linha que você escolheu não reivindicar.

Faça esse teste numa cópia se o log for grande, e repita-o após qualquer atualização do Access Server. O formato do log é a interface contra a qual você corresponde, e não é uma API estável.

Separe as jails por superfície, não por daemon

Um Access Server apresenta várias superfícies de autenticação: interfaces web de cliente e de administração na 943/tcp, e o túnel na 1194/udp ou 443/tcp na maioria das implantações. Uma única jail que cubra todas permite que tentativas de adivinhação no túnel banam um endereço que também é o seu caminho de administração, e esconde qual superfície está realmente sob ataque. Dê a cada superfície a sua própria jail com a sua própria porta e limites:

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

Comece com contadores pequenos e um ban curto, e aumente-os depois de observar uma semana de tráfego real. Um limite generoso num endereço de escritório compartilhado pune todos os usuários atrás de um NAT, e um ban agressivo na superfície do túnel desconecta clientes legítimos cujas credenciais guardadas expiraram durante a noite.

Verifique o ban, o backend e os danos colaterais

Depois de um reinício, a saída de status é a confirmação mais rápida de que a jail existe e está contando:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Depois confirme que o ban chega ao firewall que você realmente executa, porque uma jail configurada para um backend que ninguém aplica não protege nada. Com a ação iptables os endereços aparecem numa cadeia com o nome da jail (f2b-openvpnas-tunnel); com a ação nftables caem num conjunto na tabela própria do fail2ban. Verifique o que o seu host usa em vez de presumir.

Duas verificações colaterais importam mais do que o próprio ban. Primeiro, verifique que real_ip é o endereço do cliente e não um balanceador de carga ou proxy reverso; atrás de um proxy cada ban cai no proxy e leva o serviço inteiro junto. Segundo, escreva o procedimento de desbloqueio, porque o endereço que cruza o limite às 02:00 normalmente pertence ao engenheiro de plantão: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Tenha o limite em mente ao ajustar. O Fail2ban é um limitador de taxa numa superfície de autenticação, não uma camada de controle de acesso. Ele não substitui MFA, restrições por conta nem manter a interface de administração fora da internet pública, e o Access Server tem as suas próprias configurações de autoban que vale a pena conferir antes de empilhar dois limitadores de taxa na mesma porta.