Fail2ban num gateway VPN: o que corrige e o que não corrige

Todo o serviço exposto recebe o mesmo conselho: coloque fail2ban nele. Para um gateway VPN esse conselho não é errado nem suficiente, e tratá-lo como uma caixa de endurecimento é exactamente como as pessoas acabam com uma prisão (jail) que não bloqueia nada de útil. O Fail2ban lê os registos de falha para os quais o aponta e pede a um backend de aplicação que bana as fontes correspondentes. Todo o seu valor depende de qual superfície de autenticação produziu o registo, se o endereço nele é o cliente real e do que acontece a todos os outros atrás desse endereço.

O que é o fail2ban, mecanicamente

Um filtro faz corresponder linhas de um log, uma prisão conta correspondências por fonte e uma ação aplica um banimento através de um backend de firewall. Três peças móveis, e cada uma pode estar errada de forma independente.

Nenhuma das três toca no caminho de autenticação: o fail2ban reage a evidências depois do facto e nunca valida por si uma credencial. Uma prisão pode, por isso, funcionar impecavelmente enquanto a superfície que nomeia continua exactamente tão exposta como antes.

O ouvinte do túnel não é um formulário de login

Um ouvinte OpenVPN protegido com tls-auth ou tls-crypt descarta os pacotes sem a protecção do canal de controlo antes de começar o processamento TLS normal. Um scanner que nunca tem a chave não gera nada que o seu filtro possa contar. A autenticação por certificado acrescenta outra porta, porque não há palavra-passe para adivinhar. O projeto Fail2ban documenta um modelo geral baseado em logs, e um filtro VPN genérico não transforma um pacote não autenticado num evento de falha significativo.

Se o gateway só aceita certificados, a história de força bruta contra a qual se defende pode não existir de todo nessa porta.

Então que superfície está a proteger?

O mesmo host expõe frequentemente três coisas diferentes: o ouvinte do túnel, um portal de perfis de cliente ou de self-service e uma página de administração. O portal e a página de administração têm formulários de palavra-passe e produzem linhas de log que um filtro pode contar. O túnel pode produzir apenas erros de aperto de mão que significam algo completamente diferente. Faça corresponder a prisão à superfície, não ao nome do produto.

Uma prisão que vigia o log errado é pior do que nenhuma, porque cria confiança sem cobertura. Aponte um filtro de login aos erros de aperto de mão do túnel e o contador dispara em scanners que nunca tiveram uma chave, enquanto um ataque de palavra-passe contra o portal fica por contar. Leia a linha de log que o filtro faz corresponder antes de confiar no número da prisão.

A atribuição da fonte é o elo fraco

Um banimento vale o que vale o endereço que visa. Quando o serviço está atrás de um proxy inverso local, o endereço do cliente no log pode ser o do proxy, e bani-lo remove todos. Confiar num cabeçalho reencaminhado de uma fonte não fidedigna dá a um atacante a capacidade de banir endereços arbitrários. No UDP os endereços de origem podem ser falsificados, pelo que contá-los merece mais cuidado do que contar um login TCP concluído.

Registe o método de atribuição da fonte no README da prisão, porque um cabeçalho reencaminhado de um salto não fidedigno transforma um banimento numa arma.

O custo colateral são as outras pessoas

Vários empregados atrás de um NAT de escritório partilham um endereço, pelo que uma única palavra-passe guardada e desactualizada pode bloquear todo o escritório assim que o limiar é ultrapassado. O log mostra uma fonte e uma conta que falharam, não uma falha de todo o escritório.

Banimentos curtos e limiares moderados reduzem isso, e um caminho documentado para levantar o banimento reduz a carga de suporte quando acontece mesmo assim. O endereço é um sinal grosseiro em vez de uma identidade, e quem abre o ticket descreverá a falha, não o limiar.

Quando adoptá-lo, e quando corrigir outra coisa

Adopte-o quando existe uma falha de login online real, atribuível e repetida numa superfície que controla, e quando o backend de aplicação cobre realmente essa superfície. Corrija outra coisa quando o problema é uma política de credenciais fraca, uma página de gestão exposta à internet ou uma conta que inicia sessão com sucesso porque foi comprometida. Um banimento não pode reparar nada disso e não pode absorver tráfego que já saturou o seu uplink. Esse último problema pertence a montante, a alguém que possa filtrar antes de os pacotes chegarem até si.

Mantenha cada prisão ligada a uma superfície, reveja os falsos positivos e meça o trabalho de autenticação evitado em vez do número de endereços banidos.