Proteger Servidor Web Contra Ataques: WAF, fail2ban e Rate Limit

Proteger servidor web contra ataques não é mais tarefa de empresa grande: em 2026, quem tem um site, uma loja ou um sistema rodando em VPS própria é alvo todos os dias, de forma automática. Neste guia eu mostro as três camadas que usamos na Agathas Web — WAF, fail2ban e rate limit —, o que cada uma barra, quanto custa, e quando ela atrapalha mais do que ajuda.

TL;DR

• 94% das tentativas de login que passam pela rede da Cloudflare vêm de bots, segundo o relatório de ameaças 2026 da empresa. Seu formulário de login está sendo testado agora.
• WAF barra requisição maliciosa antes de chegar ao servidor; rate limit limita volume por IP ou rota; fail2ban lê logs e bane quem insiste. Uma camada não substitui a outra.
• O plano Free da Cloudflare já dá WAF gerenciado básico, 5 regras customizadas e 1 regra de rate limit — suficiente para começar, insuficiente para um sistema crítico.
• A armadilha nº 1: fail2ban atrás de proxy/CDN sem configurar o IP real bane a própria Cloudflare e derruba o site.
• Sem alguém lendo os logs e ajustando regras, toda proteção envelhece. É aí que entra a hospedagem gerenciada.

Por que proteger servidor web contra ataques virou rotina, não exceção

Até alguns anos atrás, a conversa sobre ataque era "e se um hacker escolher a minha empresa?". Hoje ninguém escolhe ninguém. Robôs varrem faixas inteiras de IP, testam senhas vazadas em qualquer tela de login que encontram e disparam enxurradas de requisições contra quem responde.

Os números recentes deixam isso claro:

• O relatório DDoS do 1º semestre de 2026 da Cloudflare contabilizou 29,64 trilhões de requisições HTTP de DDoS mitigadas no semestre e 23,2 milhões de ataques de camada de rede — cerca de 5.343 por hora.
• No mesmo relatório, o Brasil passou os Estados Unidos como principal país de origem de DDoS no semestre (14,9% contra 13,4%). Boa parte desse tráfego sai de máquinas infectadas aqui dentro.
• 90,6% dos ataques duram menos de 10 minutos. Quando alguém percebe e abre chamado, o estrago já foi feito.
• O Verizon DBIR 2025 mostra que 88% das invasões por ataque básico a aplicação web envolveram credenciais roubadas, e que a força bruta nessa categoria saltou de cerca de 20% para 60% dos incidentes.
• O Imperva Bad Bot Report 2025 estima que bots maliciosos já são 37% de todo o tráfego da internet, e o tráfego automatizado total passou do humano (51%).

Na prática, proteger servidor web contra ataques automatizados deixou de ser opcional: a sua VPS de entrada recebe o mesmo tipo de pancada que um portal grande — só que sem ninguém olhando. Nos servidores que eu administro, o log de acesso de um WordPress recém-publicado mostra tentativas em /wp-login.php e /xmlrpc.php em questão de horas, antes de o site aparecer no Google.

Os três tipos de ataque que derrubam servidor de empresa pequena

Antes de escolher ferramenta para proteger servidor web contra ataques desse tipo, vale separar o problema. Na nossa experiência com sites, sistemas e ambientes Moodle, quase todo incidente de indisponibilidade se encaixa em um destes três grupos.

Força bruta e credential stuffing

Força bruta é tentar senha atrás de senha até acertar. Credential stuffing é a versão refinada: o robô usa pares de e-mail e senha vazados de outros serviços, apostando que o usuário repetiu a senha. O mesmo relatório de ameaças 2026 da Cloudflare aponta que 46% dos logins humanos usam credenciais que já apareceram em vazamentos.

O risco não é só a invasão. Cada tentativa de login custa CPU: o PHP sobe, consulta o banco, calcula hash de senha. Mil tentativas por minuto em um wp-login.php bastam para deixar uma VPS pequena lenta para os clientes reais.

Bots de raspagem e varredura

São os robôs que não querem sua senha, e sim seu conteúdo, seus preços ou uma falha conhecida. Eles percorrem URLs como /.env, /phpmyadmin, /wp-content/plugins/<plugin-vulnerável>/ e qualquer caminho que já tenha tido CVE publicado. Desde 2025 somam-se a eles os crawlers de IA, que podem baixar milhares de páginas em sequência.

DDoS de aplicação (camada 7)

Diferente do DDoS volumétrico, que tenta entupir o link, o DDoS de aplicação manda requisições HTTP que parecem legítimas — busca interna, página de relatório, carrinho — escolhidas justamente porque são caras para o servidor. Poucas centenas de requisições por segundo na rota certa derrubam um sistema que aguentaria dezenas de milhares de acessos a uma página em cache.

As três camadas para proteger servidor web contra ataques

Quem tenta proteger servidor web contra ataques costuma instalar uma ferramenta e parar. A forma mais útil de entender WAF, rate limit e fail2ban é pela posição de cada um no caminho da requisição:

Camada	Onde roda	O que barra melhor	Ponto fraco
WAF (Web Application Firewall)	Na borda (Cloudflare) ou no servidor (ModSecurity + OWASP CRS)	SQL injection, XSS, exploração de CVE conhecida, bots ruins identificados	Falso positivo em formulário legítimo; não entende a lógica do seu negócio
Rate limit	Na borda e/ou no Nginx/Apache e na própria aplicação	Força bruta, flood de rota cara, raspagem agressiva	Limite mal calibrado bloqueia usuário real (NAT de empresa, escola, 4G)
fail2ban	No servidor, lendo logs	Quem insiste: SSH, login, varredura repetida	Reativo — age depois do log; inútil se o IP registrado for o do proxy

O ponto central: para proteger servidor web contra ataques de verdade, você precisa das três, porque cada uma cobre o buraco da outra. O WAF não sabe que o IP X errou a senha 40 vezes; o fail2ban sabe. O fail2ban não vê o tráfego que a borda já descartou; e o rate limit não reconhece uma assinatura de SQL injection.

WAF: o filtro na porta de entrada

WAF é um firewall que entende HTTP. Em vez de olhar só porta e IP, ele inspeciona URL, cabeçalhos e corpo da requisição e compara com regras de ataque conhecidas.

WAF na borda: Cloudflare

É o caminho que usamos por padrão para proteger servidor web contra ataques de aplicação. A requisição passa pela Cloudflare antes de chegar ao seu servidor, e o que é bloqueado lá não consome nem um ciclo de CPU seu. Pela documentação oficial do WAF, o plano Free inclui o Free Managed Ruleset (regras para vulnerabilidades de alto impacto, como Log4Shell e Shellshock) e 5 regras customizadas. O plano Pro custa US$ 20/mês no pagamento anual (US$ 25 no mensal) e libera o conjunto gerenciado completo.

As regras customizadas que mais rendem, na nossa experiência:

1. Desafio (managed challenge) em rotas administrativas — /wp-admin, /wp-login.php, /admin — para quem não vem do Brasil, quando o público é só nacional.
2. Bloqueio total de /xmlrpc.php em WordPress que não usa app mobile nem Jetpack.
3. Bloqueio de caminhos que não existem no seu sistema e só aparecem em varredura: /.env, /.git/, /phpmyadmin.

WAF no servidor: ModSecurity e OWASP CRS

Quando o tráfego não passa por CDN, ou o cliente precisa de regras dentro do próprio servidor, a alternativa open source é o ModSecurity com o OWASP Core Rule Set (CRS). Dois fatos que mudaram o cenário e que muito tutorial antigo ignora:

• A Trustwave encerrou o suporte ao ModSecurity em 1º de julho de 2024 e passou a custódia do projeto para a OWASP.
• A F5 descontinuou o NGINX ModSecurity WAF comercial em 31 de março de 2024.

O CRS segue ativo: a linha 4.25.x é LTS, com correções de segurança previstas até o 3º trimestre de 2027, segundo o projeto OWASP CRS. Funciona, mas exige ajuste fino — um CRS em nível de paranoia alto, instalado sem período de observação, bloqueia formulário de contato, editor de post e upload de arquivo no primeiro dia.

Quando NÃO usar WAF em modo bloqueio

Não ligue o bloqueio direto em sistema com muita entrada de texto livre (ERP, Moodle com fórum e questionário, editores ricos) sem antes rodar alguns dias em modo log only. No Moodle, por exemplo, questões com trechos de código ou SQL em aula de programação disparam regras de injeção com facilidade.

Rate limit: quanto é demais?

Rate limit é a peça que mais ajuda a proteger servidor web contra ataques de volume. É contar requisições por cliente num intervalo e cortar quem passa do teto. Parece simples; o difícil é escolher o número.

Na borda

Desde 2022, a Cloudflare oferece rate limiting em todos os planos, mas com limites bem diferentes. Segundo a documentação de rate limiting rules:

• Free: 1 regra, janela de contagem de até 10 segundos, bloqueio de até 10 segundos, contagem só por IP e filtro só por caminho.
• Pro: 2 regras, janela de até 1 minuto, bloqueio de até 1 hora.
• Business: 5 regras, janela de até 10 minutos, bloqueio de até 1 dia, e contagem por IP com suporte a NAT.

Com uma única regra no Free, use-a na rota de login. É onde o ganho é maior.

No servidor web

No Nginx, o módulo limit_req faz o trabalho com o algoritmo de balde furado (leaky bucket): você define a taxa (por exemplo, 5r/m para /wp-login.php) e uma rajada tolerada com burst. No Apache, o equivalente costuma ser o mod_evasive ou regras do próprio ModSecurity. O importante é limitar rota por rota: login e busca com teto baixo; arquivos estáticos, nenhum.

Na aplicação

A camada mais precisa é a própria aplicação, porque ela sabe quem é o usuário. No painel administrativo deste site, implementamos um registro de tentativas de login em banco que bloqueia por conta e por IP depois de uma sequência de erros. O Moodle tem isso nativo: em Administração do site › Segurança › Políticas do site, os parâmetros de bloqueio de conta (limite de tentativas, janela e duração) vêm desligados por padrão — e quase ninguém liga.

Armadilha: o NAT da escola e da empresa

Uma escola inteira, um call center ou uma operadora 4G podem sair para a internet pelo mesmo IP. Já vimos plataforma EAD travar a prova de uma turma inteira porque um rate limit de 60 requisições por minuto por IP contava 40 alunos como "um cliente". Calibre com base no log real de pico, não em número de tutorial.

fail2ban: quem insiste, sai

O fail2ban lê arquivos de log, procura padrões de falha (senha errada no SSH, 401 no login, 404 em série) e, ao passar do limite, cria uma regra de firewall banindo o IP por um tempo.

Os valores padrão (e por que mudar)

O fail2ban é a camada mais antiga para proteger servidor web contra ataques persistentes, mas vem com valores tímidos. No jail.conf oficial, o padrão é bantime = 10m, findtime = 10m e maxretry = 5: cinco falhas em dez minutos rendem dez minutos de banimento. Para robô, dez minutos é pausa para o café. O que aplicamos:

• bantime.increment = true — vem comentado por padrão; ativado, cada reincidência dobra o tempo de banimento.
• Jail recidive — já vem no pacote e bane por 1 semana quem foi banido várias vezes em 1 dia.
• Jails específicas para a aplicação: nginx-limit-req (quem estoura o rate limit do Nginx), filtros para login do WordPress e do painel do sistema.
• SSH sem senha, só com chave — aí o fail2ban no SSH vira segunda linha, não primeira.

A armadilha que derruba o site: fail2ban atrás da Cloudflare

Tentar proteger servidor web contra ataques com fail2ban atrás de CDN sem ajuste é o erro que mais encontramos em servidores que recebemos para sustentar. Com Cloudflare na frente, o IP que chega ao Nginx é o da Cloudflare, não o do visitante. O fail2ban lê o log, vê "o mesmo IP" errando senha e bane… a Cloudflare. Resultado: o site sai do ar para uma fatia dos visitantes, sem erro aparente.

Para evitar:

1. Configure o módulo real_ip do Nginx (ou mod_remoteip no Apache) para confiar só nas faixas de IP publicadas pela Cloudflare e ler o cabeçalho CF-Connecting-IP. Não use X-Forwarded-For cru — ele pode ser forjado.
2. Mesmo com o IP real no log, banir via iptables no servidor não bloqueia nada: a conexão continua vindo da Cloudflare. Use a action de Cloudflare do fail2ban (que cria a regra via API na borda) ou feche a origem para aceitar apenas a Cloudflare.

O que não resolve (e custa caro)

Algumas medidas para proteger servidor web contra ataques aparecem em todo checklist e entregam pouco:

• Plugin de segurança como única camada. Em WordPress, o plugin roda dentro do PHP: quando ele bloqueia, o servidor já gastou o processamento. Ajuda, mas não segura um flood.
• Trocar a porta do SSH e parar por aí. Reduz ruído no log, não protege nada contra quem faz varredura completa.
• Bloquear países inteiros no firewall do servidor. Listas de IP por país mudam; mal mantidas, bloqueiam clientes reais e não barram botnet brasileira — que, como vimos, lidera o ranking.
• Comprar servidor maior para aguentar o ataque. Escalar verticalmente para absorver bot é pagar para ser atacado. Filtrar na borda é mais barato.
• Configurar e esquecer. Regra de WAF sem revisão gera falso positivo silencioso; fail2ban sem monitoramento para de funcionar quando o formato do log muda numa atualização e ninguém percebe.

Se o seu servidor está em cloud pública, o custo de ignorar isso também aparece na fatura: tráfego de saída e CPU extra de bot são cobrados como se fossem de cliente. Detalhei essa conta em Moodle na AWS vs hospedagem gerenciada.

Checklist prático para proteger servidor web contra ataques em 30 dias

Para quem quer proteger servidor web contra ataques por conta própria, esta é a ordem que recomendamos — da maior redução de risco por hora investida para a menor:

Semana 1 — borda

• Coloque o domínio atrás da Cloudflare (proxy ativo, laranja).
• Feche a origem: firewall aceitando HTTP/HTTPS só das faixas da Cloudflare.
• Ative o Free Managed Ruleset e crie as regras de desafio para rotas administrativas.

Semana 2 — acesso

• SSH só com chave, login de root desativado.
• MFA em painel de hospedagem, registrador de domínio e contas administrativas do sistema.
• Bloqueio de conta por tentativas na aplicação (Moodle, WordPress, painel próprio).

Semana 3 — servidor

• real_ip configurado e testado (o IP do visitante aparece no log?).
• fail2ban com bantime.increment, recidive e jails da aplicação.
• limit_req nas rotas de login e busca.

Semana 4 — observação

• Revise os bloqueios: quem foi barrado era mesmo robô?
• Teste a restauração do backup. Proteção falha; backup é o plano B. Para Moodle, o passo a passo está em backup do Moodle: a rotina que salva a instituição.
• Defina quem recebe o alerta quando algo sair do normal — e em quanto tempo responde.

Se você chegou até aqui pensando "não tenho quem faça isso", essa é a resposta honesta: sem alguém dono do assunto, o checklist vira arquivo esquecido.

Como a Agathas Web resolve isso

Na hospedagem gerenciada da Agathas Web, o trabalho de proteger servidor web contra ataques descrito neste post não é um opcional: vem configurada por padrão e é mantida por quem opera o servidor. Concretamente, o que está incluso:

• WAF Cloudflare com regras customizadas para a sua stack (WordPress, Laravel, Next.js, Moodle, ERP), mitigação automática de DDoS e bloqueio de bots maliciosos.
• fail2ban, rate limit e hardening do sistema operacional, com o IP real configurado corretamente atrás do proxy — a armadilha da seção anterior não acontece.
• SSL Let's Encrypt automático, MFA obrigatório e auditoria de logs.
• Monitoramento 24/7 com Grafana, Prometheus, Sentry e UptimeRobot, e alertas no WhatsApp da equipe técnica.
• Backup diário + incremental, criptografado (AES-256) e fora do servidor, com restauração testada mensalmente.
• Patch crítico aplicado em até 72 horas após CVE público, passando por staging.
• SLA contratual: 99,9% de uptime, resposta em até 15 minutos e resolução em até 2 horas para incidente crítico — com multa se não cumprirmos.
• Relatório mensal com uptime, eventos, backups testados e ameaças mitigadas pelo WAF.

Como funciona: começa por um diagnóstico gratuito da infraestrutura atual, entregue em até 3 dias úteis, com riscos apontados. Se fizer sentido seguir, migramos site, banco, e-mails e DNS em até 7 dias úteis, com staging para validação e plano de rollback (o ambiente antigo fica intacto por 30 dias). Contrato mensal, sem fidelidade, 30 dias de aviso para cancelar.

Quanto custa: sites institucionais e blogs ficam, em média, entre R$ 250 e R$ 500 por mês; e-commerce e SaaS, entre R$ 600 e R$ 2.500 por mês; setup de R$ 800 a R$ 3.500 conforme a complexidade. Ambientes Moodle têm oferta própria — os requisitos estão em requisitos de servidor para Moodle 5.x.

Você fala direto com quem opera o seu ambiente, pelo WhatsApp, sem central de atendimento.

Conclusão: proteção é processo, não produto

WAF, rate limit e fail2ban são peças baratas — boa parte é gratuita. O que custa é a operação: calibrar limites com base no tráfego real, perceber quando uma regra começou a barrar cliente, reagir em minutos quando 90% dos ataques duram menos de dez. Para proteger servidor web contra ataques de forma sustentável, alguém precisa ser responsável por isso toda semana.

Se esse alguém ainda não existe na sua empresa, peça o diagnóstico gratuito da hospedagem gerenciada: em até 3 dias úteis você sabe onde o seu servidor está exposto — e decide o que fazer com isso.