Em 2026, apenas alterar a porta SSH já não é suficiente para bloquear os scripts de varredura automatizados que inundam a internet. Este guia prático mostra como implementar o Fail2Ban, um sistema de prevenção de intrusões baseado em logs. Desde a lógica de funcionamento e os parâmetros essenciais de defesa, até o bloqueio preciso de ataques de força bruta no SSH, ataques CC no Nginx e varreduras maliciosas no WordPress. Vamos blindar seu servidor de ponta a ponta.
Sinceramente, no momento em que você instala o sistema e aponta o domínio para o IP público, seu servidor já está na mira de milhares de scripts automatizados ao redor do mundo.
Se você verificar o arquivo /var/log/auth.log, verá uma enxurrada de tentativas de login de força bruta vindas de todos os cantos do planeta. Mesmo com o login por senha desativado, essas requisições maliciosas e concorrentes continuam consumindo CPU e conexões de rede do seu servidor.
Para evitar que seu plano legado fique indisponível por causa de scanners ou seja transformado em um nó de botnet, vamos direto ao ponto com uma solução robusta: Guia completo de instalação e configuração do Fail2Ban.
Essa configuração não só bloqueia ataques de força bruta no SSH com precisão, como também se integra ao Nginx para mitigar ataques CC e proteger o WordPress contra invasões. Você terá conclusões diretas, dados técnicos e arquivos de configuração prontos para uso, resolvendo de vez o problema das varreduras maliciosas.
Entenda a lógica por trás do Fail2Ban
Em ambientes públicos, as varreduras maliciosas geralmente se dividem em duas categorias:
- Varredura de portas e força bruta no SSH: Robôs testam portas como a 22 24 horas por dia, usando dicionários de senhas fracas para tentar invadir.
- Varredura de vulnerabilidades Web e ataques CC: Focados em plataformas como o WordPress, esses bots varrem incessantemente o
wp-login.php, diretórios de plugins sensíveis ou disparam requisições CC em alta frequência para esgotar os recursos do banco de dados.
A lógica do Fail2Ban é elegante e direta: ele funciona como um sistema de prevenção de intrusões (IPS) baseado em logs. Ele monitora continuamente os arquivos de registro do sistema (SSH, Nginx, logs do sistema). Assim que um IP excede um número definido de tentativas maliciosas (maxretry) dentro de um período específico (findtime), o Fail2Ban aciona o firewall do sistema (iptables, ufw ou firewalld) para descartar o tráfego desse IP na camada de rede, mantendo-o bloqueado por um tempo determinado (bantime).
Instalação rápida e a lógica correta de configuração
Seja no Debian ou Ubuntu, o processo de instalação é extremamente simples.
1. Instalação com um comando
sudo apt update
sudo apt install fail2ban -y
2. A “regra de ouro” dos arquivos de configuração (evite erros comuns)
Após a instalação, os arquivos ficam em /etc/fail2ban/. Aqui vai um erro clássico de iniciante: nunca edite diretamente o arquivo jail.conf.
A lógica correta de leitura é: o sistema carrega primeiro as configurações padrão do jail.conf e, em seguida, aplica o jail.local, substituindo os parâmetros correspondentes. Durante atualizações futuras, o jail.conf será sobrescrito, mas suas personalizações no jail.local permanecerão intactas.
Portanto, o primeiro passo é sempre criar uma cópia local:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
3. Configurando a política global
Abra o arquivo /etc/fail2ban/jail.local com seu editor de texto preferido, localize a seção [DEFAULT] e defina sua linha de base de segurança:
ignoreip = 127.0.0.1/8 ::1 seu_ip_publico(Lista de permissão para evitar bloqueios acidentais, essencial).bantime = 24h(Duração do bloqueio).findtime = 10m(Janela de monitoramento).maxretry = 3(Limite de tolerância).
Prática avançada 1: Estratégia definitiva para proteger o SSH
Muitos acreditam que “se desativar o login por senha e usar apenas chaves (Key), o Fail2Ban é desnecessário”. Essa lógica é perigosa. Mesmo com autenticação por chave, scripts maliciosos continuam abrindo conexões TCP, gerando logs inúteis no auth.log e forçando o serviço SSH a gastar recursos processando handshakes.
A proteção real combina: alterar a porta padrão do SSH + desativar login por senha do Root + permitir apenas chaves + Fail2Ban como defesa de última linha. As três primeiras medidas eliminam 99% das tentativas na origem, enquanto o Fail2Ban descarta o tráfego restante na camada de rede, minimizando o consumo de recursos.
No jail.local, localize o módulo [sshd] e ative-o:
[sshd]
enabled = true
port = 2222 # Se você alterou a porta SSH, ajuste aqui
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
Prática avançada 2: Proteção para WordPress e regras nativas
Para ataques de força bruta no wp-login.php e explorações via XML-RPC, as versões recentes do Fail2Ban já incluem filtros predefinidos. Não é mais necessário escrever expressões regulares do zero como nos tutoriais antigos.
Basta adicionar a seguinte configuração ao final do jail.local para ativá-la:
[wordpress]
enabled = true
port = http,https
filter = wordpress # Usa a regra nativa
logpath = /var/log/nginx/access.log # Verifique se o caminho corresponde ao seu servidor web
maxretry = 5
findtime = 10m
bantime = 24h
(Dica técnica: se você usa um painel de hospedagem muito específico e as regras nativas não funcionarem, edite manualmente o arquivo /etc/fail2ban/filter.d/wordpress.conf para ajustar as expressões regulares.)
Prática avançada 3: Defesa contra ataques CC no Nginx e bots maliciosos
Este é um ponto crucial que muitos tutoriais ignoram. Ataques CC (Challenge Collapsar) simulam tráfego real de usuários para sobrecarregar processos PHP e bancos de dados. Integrado ao módulo limit_req do Nginx, o Fail2Ban neutraliza essa ameaça com eficiência.
1. Bloqueando requisições CC em alta frequência
Quando o limit_req do Nginx é acionado, ele gera entradas no error.log. Ative a seguinte regra para bloquear esses IPs automaticamente:
[nginx-limit-req]
enabled = true
port = http,https
filter = nginx-limit-req
logpath = /var/log/nginx/error.log
findtime = 1m
maxretry = 10 # 10 acionamentos de limite em 1 minuto resultam em bloqueio
bantime = 24h
2. Bloqueando scanners de vulnerabilidades (erros 404)
Hackers frequentemente usam ferramentas para varrer diretórios sensíveis (como .env ou backup.zip), gerando uma enxurrada de erros 404. Ative a defesa contra bots maliciosos:
[nginx-botsearch]
enabled = true
port = http,https
filter = nginx-botsearch
logpath = /var/log/nginx/access.log
maxretry = 3
Após configurar, reinicie o serviço com sudo systemctl restart fail2ban. Use sudo fail2ban-client status nginx-limit-req para monitorar quantos IPs foram bloqueados.
Guia vps1111 de prevenção de erros e estratégia de defesa em camadas
Configurar segurança exige equilíbrio. Como especialista em administração de sistemas, deixo duas regras de ouro para evitar problemas:
💡 Dicas essenciais para evitar erros:
- Evite bloqueios permanentes (bantime = -1): Muitos iniciantes preferem definir um bloqueio vitalício. Na prática, o Fail2Ban moderno lida bem com milhares de regras no iptables sem impacto perceptível na CPU. O verdadeiro problema do bloqueio permanente é: inchar a tabela de regras do firewall, dificultando drasticamente a solução de problemas em caso de bloqueio acidental e impedindo a liberação automática. Para a maioria dos casos, um bloqueio de 24 a 48 horas já é suficiente para fazer scripts automatizados desistirem do seu IP por inviabilidade econômica.
- Entenda a “defesa em camadas”: O Fail2Ban é um software de camada de aplicação. Se você sofrer um ataque DDoS massivo (centenas de Gbps), o Fail2Ban sozinho não resolverá (a interface de rede saturará primeiro). A arquitetura correta é: escolher um servidor com roteamento de backbone global (como AS1299, AS174 ou AS2914) e proteção DDoS nativa no data center. Deixe a infraestrutura de rede filtrar o tráfego volumétrico pesado e use o Fail2Ban internamente para bloquear ameaças específicas na camada de aplicação (como CC ou força bruta no SSH), criando um sistema de defesa completo e eficiente.
Com essa configuração ativa, a segurança do seu servidor já estará à frente de 90% dos projetos que operam sem proteção adequada.
❓ Perguntas frequentes (FAQ)
O Fail2Ban consome muita CPU e memória do servidor?
Não. O Fail2Ban é um script Python leve, acionado por eventos. Em servidores modernos, o monitoramento de logs SSH e Web tem impacto quase zero. Apenas em ataques CC extremamente massivos, a leitura frequente de logs gigantes ou a execução constante do iptables pode gerar um leve consumo. Para sites comuns, a instalação é totalmente segura e recomendada.
O Fail2Ban pode ser usado junto com UFW ou Firewalld?
Sim, e eles funcionam perfeitamente juntos. O Fail2Ban não é um firewall por si só; ele atua como um “gerenciador”. Ao detectar uma ameaça, ele envia comandos diretamente para o iptables, UFW ou Firewalld do sistema para bloquear o IP. É uma relação de integração perfeita entre camadas.