Segurança

Fail2ban é suficiente? O que ele cobre e o que deixa de fora

O fail2ban bloqueia endereços que erram a senha várias vezes no SSH e no Nginx, o que é útil, mas insuficiente. Ele não encontra webshell, não detecta malware nem corrige falha conhecida no sistema. Servidor protegido soma essa camada com atualização, varredura de arquivos e monitoramento.

O fail2ban bloqueia IPs que erram senha no SSH e no Nginx, mas não acha webshell, malware nem falha conhecida. Veja o que ele faz, como conferir o status e o que falta.

1 de novembro de 20266 min de leituraPor Softoven

Quase todo tutorial de segurança de servidor Linux termina com "instale o fail2ban". É um bom conselho. O problema começa quando o fail2ban vira a única camada de proteção, e o dono do servidor dorme tranquilo achando que está coberto.

Este artigo explica o que o fail2ban faz de verdade, como saber se ele está funcionando, e quais ataques passam direto por ele.

O que é o fail2ban

O fail2ban é um programa de código aberto que lê arquivos de log e procura padrões de abuso, como muitas tentativas de login com senha errada vindas do mesmo IP. Quando um IP passa do limite, o fail2ban cria uma regra no firewall que bloqueia esse endereço por um tempo.

Três conceitos resumem o funcionamento:

Filtro: a expressão que reconhece uma linha de log suspeita, por exemplo "Failed password for root from 203.0.113.5".
Jail (cela): a combinação de um filtro, um arquivo de log e uma ação. Existe uma jail para SSH, outra para Nginx, outra para Postfix, e assim por diante.
Ação: o que fazer quando o limite é atingido, normalmente bloquear o IP no firewall (iptables, nftables ou ufw) e, se quiser, mandar um e-mail.

Os parâmetros mais usados são maxretry (quantas falhas antes do bloqueio), findtime (em quanto tempo essas falhas precisam acontecer) e bantime (por quanto tempo o IP fica bloqueado).

Como instalar e ligar a proteção do SSH

No Debian e no Ubuntu, a instalação é sudo apt install fail2ban. A configuração não deve ser feita no jail.conf, que é sobrescrito nas atualizações. Crie um arquivo /etc/fail2ban/jail.local com o que você quer mudar. Um exemplo mínimo para o SSH:

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

Depois, reinicie com sudo systemctl restart fail2ban.

Como ver o status do fail2ban

Dois comandos respondem quase tudo:

sudo fail2ban-client status lista as jails ativas.
sudo fail2ban-client status sshd mostra quantas falhas foram vistas, quantos IPs estão bloqueados agora e quais são.

Se a lista de jails estiver vazia, o fail2ban está rodando mas não está protegendo nada. É mais comum do que parece. Para liberar um IP bloqueado por engano (o seu, por exemplo), use sudo fail2ban-client set sshd unbanip 203.0.113.5.

Fail2ban no Nginx

O pacote traz filtros prontos para o Nginx, como nginx-http-auth (erros de senha em áreas protegidas) e nginx-botsearch (robôs procurando arquivos conhecidos). Dá para criar filtros próprios, por exemplo para bloquear quem pede wp-login.php centenas de vezes por minuto. Funciona bem para reduzir barulho e carga, desde que o filtro seja testado com fail2ban-regex antes de entrar em produção, para não bloquear visitante legítimo.

O que o fail2ban cobre bem

Força bruta no SSH, quando o login por senha ainda está ligado.
Tentativas repetidas de login em painéis, áreas com senha e serviços de e-mail.
Robôs barulhentos que fazem muitas requisições suspeitas em pouco tempo.
Redução de ruído nos logs, o que facilita ler o que importa.

O que o fail2ban deixa de fora

Aqui está o ponto central. O fail2ban só reage ao que aparece como padrão repetido no log. Tudo que não deixa esse rastro passa direto.

Ataque que acerta na primeira

Se a senha vazou em outro serviço, o invasor entra na primeira tentativa. Não há falha para contar, não há bloqueio. O mesmo vale para uma chave SSH roubada.

Falha em plugin, tema ou aplicação

A maioria das invasões em sites não passa pelo login. Elas exploram uma vulnerabilidade conhecida num plugin, numa biblioteca ou no próprio sistema. Uma única requisição bem montada basta. O fail2ban não sabe que aquela requisição é maliciosa, porque ela parece com qualquer outra.

Webshell e malware já instalados

Se um arquivo malicioso já está no servidor, o fail2ban não olha para ele. Ele não varre arquivos, não compara assinaturas e não percebe um PHP novo na pasta de uploads. Veja como procurar esse tipo de arquivo em webshell em WordPress: como achar e remover.

Ataque distribuído

Quando o ataque vem de milhares de IPs diferentes, cada um tentando poucas vezes, nenhum passa do limite. Botnets fazem exatamente isso. Abaixar demais o maxretry para compensar começa a bloquear usuários reais.

Vulnerabilidade sem correção

O fail2ban não avisa que o OpenSSL, o PHP ou o kernel estão desatualizados com falha publicada. Isso exige outro tipo de ferramenta, que compare as versões instaladas com bancos de vulnerabilidades (CVE).

Processo e conexão estranhos

Um minerador de criptomoeda rodando em /tmp, uma conexão saindo para um IP desconhecido, um usuário novo no sistema. Nada disso é linha repetida de log de autenticação, então o fail2ban não vê.

Comparando com outras camadas

Camada	O que resolve	Exemplo
Login só por chave SSH	elimina força bruta de senha no SSH	`PasswordAuthentication no`
Fail2ban	bloqueia quem insiste em errar	jail `sshd`, `nginx-http-auth`
Firewall	fecha portas que não precisam estar abertas	`ufw`, firewall do provedor
Atualização automática	corrige falha conhecida do sistema	`unattended-upgrades`
Varredura de arquivos	acha webshell e malware	assinaturas e comportamento
Monitor de vulnerabilidades	avisa sobre pacote com CVE	inventário de versões
Auditoria de postura	mostra configurações fracas	Lynis, CIS Benchmarks

Repare que o fail2ban é uma linha da tabela, não a tabela inteira. Se o login por senha já está desligado no SSH, o ganho dele no SSH fica até menor, porque a força bruta deixa de funcionar de qualquer jeito.

Erros comuns na configuração

Mesmo quem instala o fail2ban costuma cair em alguns tropeços que deixam a proteção pela metade:

Editar o jail.conf em vez do jail.local. A próxima atualização do pacote apaga as mudanças, e a proteção volta ao padrão sem ninguém perceber.
Apontar para o log errado. Em sistemas que usam o journald, o SSH pode não gravar em /var/log/auth.log. Nesse caso, a jail precisa de backend = systemd, ou ela nunca vê falha nenhuma.
Esquecer de liberar o próprio IP. A opção ignoreip evita que você bloqueie o seu escritório depois de errar a senha algumas vezes.
Bloqueio curto demais. Um bantime de poucos minutos só atrasa o robô. Para quem volta sempre, a opção bantime.increment aumenta o tempo a cada reincidência.
Nunca olhar o status. Se ninguém roda fail2ban-client status de vez em quando, não dá para saber se a proteção está ativa.

Então, fail2ban é suficiente?

Não. Ele é um bom cinto de segurança, mas não freia o carro. Mantenha o fail2ban ligado e configurado, e some a ele as outras camadas do checklist de segurança de VPS: chave SSH, firewall, atualização, backup externo e alguém olhando os sinais com frequência.

A parte de "alguém olhando" é a que mais falha em empresa pequena. O Oven Sec foi feito para isso: instalado dentro do servidor, ele cruza logs, processos, rede, arquivos e dependências a cada 12 horas, acha o que o fail2ban não vê e manda o relatório para o canal da sua equipe. Se você desconfia que o servidor já foi invadido, comece por como saber se o servidor foi invadido.

Fontes

Projeto fail2ban, repositório oficial e documentação.
OpenBSD, manual do sshd_config.
MITRE ATT&CK, Brute Force (T1110).
MITRE ATT&CK, Server Software Component: Web Shell (T1505.003).