Como Proteger um Site com uma WAF

O que é uma WAF (Web Application Firewall)

Uma Web Application Firewall (WAF) é um sistema de segurança que filtra, monitoriza e bloqueia tráfego HTTP malicioso dirigido à sua aplicação web. Ao contrário de uma firewall de rede clássica, que opera ao nível do endereço IP e da porta, uma WAF compreende o protocolo HTTP e consegue analisar o conteúdo dos pedidos — parâmetros do URL, dados POST, cookies, cabeçalhos HTTP e o corpo do pedido. Isto permite-lhe detetar e bloquear ataques que passariam por uma firewall clássica.

Imagine uma WAF como a segurança à entrada de um restaurante que verifica cada convidado. Uma firewall clássica apenas confirma se o convidado tem convite (IP e porta corretos). A WAF verifica se o convidado traz armas, documentos falsos ou más intenções — analisa o comportamento, não apenas a identidade. Num mundo em que ocorrem cerca de 2800 ciberataques por dia, uma WAF é uma camada crítica de proteção para qualquer website.

Como funciona uma WAF

Uma WAF situa-se entre o utilizador e o servidor web e analisa cada pedido HTTP antes de este chegar à sua aplicação. As decisões são tomadas com base em regras e algoritmos predefinidos.

Modelos de deteção

Uma WAF utiliza dois modelos principais de deteção de ataques. O modelo de segurança negativa (blacklisting) bloqueia pedidos que contêm padrões maliciosos conhecidos — strings de SQL injection, payloads de XSS, sequências de path traversal, e assim por diante. Esta é a abordagem mais comum porque é mais fácil de implementar, mas não consegue detetar ataques novos e desconhecidos (zero-day). O modelo de segurança positiva (whitelisting) define o que é permitido e bloqueia todo o resto. Este modelo é mais seguro, mas exige uma configuração detalhada para cada aplicação, porque é necessário definir cada parâmetro, URL e formato de dados legítimo.

Contra o que a WAF protege

A WAF protege contra os ataques web mais comuns definidos na lista OWASP Top 10: SQL Injection (injeção de código SQL através de formulários e parâmetros de URL para aceder ou modificar a base de dados), Cross-Site Scripting — XSS (injeção de código JavaScript malicioso que é executado nos navegadores de outros utilizadores), Cross-Site Request Forgery — CSRF (forçar um utilizador autenticado a executar uma ação indesejada), Local/Remote File Inclusion (carregamento de ficheiros maliciosos através do mecanismo include do PHP), Path Traversal (acesso a ficheiros fora do diretório raiz através de sequências ../), Command Injection (execução de comandos de sistema através de uma aplicação web) e ataques de força bruta a formulários de login.

Ações que a WAF pode executar

Quando a WAF deteta um pedido suspeito, pode executar várias ações: bloquear o pedido e devolver um erro 403 Forbidden, permitir o pedido mas registá-lo para análise posterior (modo de monitorização), desencadear uma verificação CAPTCHA para determinar se o utilizador é humano ou um bot, limitar a taxa de pedidos de um determinado endereço IP, ou bloquear temporariamente um endereço IP que envia muitos pedidos maliciosos. Os sistemas WAF modernos combinam estas ações com base na gravidade da ameaça.

Tipos de WAF

As soluções WAF diferem quanto ao local onde são implementadas e quanto à arquitetura.

WAF na cloud

Uma WAF na cloud é implementada alterando os registos DNS — o tráfego é encaminhado através de um fornecedor de cloud que filtra os pedidos maliciosos antes de chegarem ao seu servidor. Exemplos: Cloudflare WAF, Sucuri, AWS WAF, Akamai. Vantagens: implementação simples (sem necessidade de alterações no servidor), escalabilidade (a infraestrutura na cloud absorve ataques DDoS), atualização automática de regras e benefícios de CDN (carregamento mais rápido do site). Desvantagens: dependência de terceiros, latência potencial (salto adicional) e custos mensais.

WAF baseada no host

Uma WAF baseada no host é instalada diretamente no servidor web como um módulo ou aplicação. O exemplo mais conhecido é o ModSecurity, que se integra com os servidores web Apache, Nginx e LiteSpeed. Vantagens: controlo total sobre a configuração, sem salto de rede adicional, acesso a registos detalhados no servidor e sem custo mensal de serviço na cloud. Desvantagens: exige conhecimento técnico para configuração e manutenção, consome recursos do servidor para análise dos pedidos e a atualização das regras é da sua responsabilidade.

Abordagem híbrida

A melhor proteção é a combinação de WAF na cloud e WAF baseada no host. Uma WAF na cloud (Cloudflare) filtra ataques volumétricos e ameaças conhecidas antes de chegarem ao servidor, enquanto uma WAF baseada no host (ModSecurity) faz uma inspeção profunda dos pedidos que passam pela camada da cloud. Esta estratégia de defesa em profundidade garante que, mesmo que uma camada deixe passar um ataque, a outra camada o apanha.

Cloudflare WAF — configuração

A Cloudflare é a WAF na cloud mais popular para sites pequenos e médios, graças ao seu plano gratuito que inclui proteção básica e a planos pagos acessíveis com funcionalidades WAF avançadas.

Configuração básica

Para utilizar a Cloudflare WAF, precisa de criar uma conta Cloudflare, adicionar o seu domínio e alterar os nameservers para os da Cloudflare. Após a propagação do DNS (normalmente 24 a 48 horas), todo o tráfego do seu site passa pela rede da Cloudflare. O plano gratuito oferece proteção DDoS, um certificado de encriptação gratuito, CDN e proteção básica contra bots. As regras WAF estão disponíveis a partir do plano Pro (20 €/mês).

Managed Rules

As Cloudflare Managed Rules são regras pré-configuradas que protegem contra vulnerabilidades conhecidas. O Cloudflare Managed Ruleset cobre os ataques do OWASP Top 10, o Cloudflare WordPress Ruleset foi concebido especificamente para vulnerabilidades do WordPress, e o Cloudflare Leaked Credentials Detection verifica se os utilizadores estão a usar palavras-passe comprometidas. Estas regras são atualizadas automaticamente quando novas ameaças são descobertas.

Custom Rules

Além das regras geridas, pode criar regras WAF personalizadas para as necessidades específicas do seu site. Por exemplo: bloquear o acesso à página wp-admin para todos exceto o seu endereço IP, restringir o acesso ao xmlrpc.php, bloquear pedidos de países específicos, exigir um CAPTCHA na página de login, ou bloquear user agents de bots e scanners conhecidos. As regras personalizadas são criadas através do painel da Cloudflare, usando um editor visual ou a sintaxe de expressões Wire Format.

Rate Limiting

O Cloudflare Rate Limiting permite limitar o número de pedidos por endereço IP num determinado período de tempo. É uma defesa eficaz contra ataques de força bruta e abuso de API. Por exemplo: limitar a página de login a 5 pedidos por minuto por endereço IP, limitar os endpoints da API a 100 pedidos por minuto. Os pedidos que excedem o limite podem ser bloqueados, desencadear um CAPTCHA ou ser redirecionados para uma página de erro.

ModSecurity — configuração

O ModSecurity é um motor WAF de código aberto que corre como módulo nos servidores Apache, Nginx e LiteSpeed. É a WAF baseada no host mais difundida no setor de alojamento.

Instalação e configuração básica

Em servidores cPanel, o ModSecurity é instalado através do WHM (Web Host Manager) com um clique. Em servidores Linux sem cPanel, é instalado a partir de pacotes (apt install libapache2-mod-security2 em Ubuntu/Debian). Após a instalação, o ModSecurity funciona em modo Detection Only — regista os pedidos suspeitos mas não os bloqueia. Isto é recomendado no início para identificar falsos positivos antes de passar para o modo enforcing.

OWASP Core Rule Set (CRS)

O ModSecurity, por si só, não contém regras — precisa de um conjunto de regras. O OWASP Core Rule Set (CRS) é o conjunto de regras mais utilizado e cobre as vulnerabilidades do OWASP Top 10. O CRS usa um sistema de pontuação de anomalias em que cada elemento suspeito do pedido acrescenta pontos, e um pedido só é bloqueado quando a pontuação total ultrapassa o limiar (5 por predefinição). Isto reduz os falsos positivos, porque um único elemento suspeito não é suficiente para bloquear — têm de existir vários indicadores de comportamento malicioso.

Afinação fina das regras

As regras do ModSecurity geram frequentemente falsos positivos — bloqueando pedidos legítimos. Os exemplos mais comuns são: o editor do WordPress a enviar código HTML/CSS (que parece XSS), plugins de firewall cujos formulários do painel de controlo contêm termos de segurança, e formulários de contacto com conteúdo específico. Para corrigir falsos positivos, pode: desativar uma regra específica para um determinado URL ou diretório, aumentar o limiar de pontuação de anomalias, ou adicionar uma regra de whitelist para pedidos seguros conhecidos. Consulte o registo de auditoria do ModSecurity para identificar que regras geram falsos positivos.

ModSecurity no LiteSpeed

O LiteSpeed Web Server tem suporte integrado para regras do ModSecurity sem necessidade de um módulo externo. O LiteSpeed processa as regras do ModSecurity mais rapidamente do que o Apache porque usa um motor otimizado, concebido para a arquitetura orientada a eventos do LiteSpeed. A configuração é idêntica à do Apache — as mesmas regras, as mesmas diretivas, mas com melhor desempenho.

WAF para WordPress — regras específicas

Os sites WordPress são o alvo mais comum de ataques e exigem regras WAF específicas, para além das genéricas.

Proteção da área de administração

Restrinja o acesso a /wp-admin/ e a /wp-login.php a endereços IP conhecidos ou exija autenticação adicional. Bloqueie o acesso a ficheiros sensíveis: wp-config.php, xmlrpc.php, wp-cron.php (permita apenas o acesso a partir do servidor). Impeça a enumeração de utilizadores bloqueando pedidos com o parâmetro ?author= que revela nomes de utilizador.

Proteção contra vulnerabilidades de plugins

Os plugins do WordPress são o vetor de ataque mais comum. As regras da WAF devem bloquear: o acesso direto a ficheiros PHP no diretório wp-content/plugins/ (exceto handlers AJAX), o upload de tipos de ficheiro maliciosos (.php, .phtml, .pht disfarçados de imagens), e a exploração de vulnerabilidades conhecidas em plugins populares (a Cloudflare e o ModSecurity CRS têm regras específicas para vulnerabilidades de plugins do WordPress).

Proteção contra bots

Uma grande percentagem do tráfego em sites WordPress provém de bots — bons (Google bot, Bing bot) e maus (scanners de vulnerabilidades, content scrapers, bots de força bruta). A WAF deve: permitir bots bons conhecidos com base no user agent e em intervalos de IP, bloquear ou limitar a taxa de bots maus conhecidos, desencadear CAPTCHA para bots suspeitos, e limitar a taxa de rastreio de todos os bots para que não sobrecarreguem o servidor.

Monitorização e manutenção da WAF

Uma WAF não é uma solução de "configurar e esquecer". Exige monitorização e afinação regulares.

Análise dos registos

Reveja regularmente os registos da WAF para identificar: falsos positivos que bloqueiam utilizadores legítimos (e ajuste as regras), padrões de ataque que possam indicar um ataque direcionado, endereços IP ou intervalos que geram muitos pedidos maliciosos, e novos tipos de ataque que possam não estar cobertos pelas regras existentes. A Cloudflare oferece um painel visual para análise, enquanto o ModSecurity usa ficheiros de registo em texto que pode analisar com ferramentas como o GoAccess ou a stack ELK.

Atualização das regras

Descobrem-se novas vulnerabilidades diariamente e as regras da WAF têm de ser atualizadas para as cobrir. As soluções WAF na cloud (Cloudflare) atualizam as regras automaticamente. No caso do ModSecurity com o OWASP CRS, atualize o conjunto de regras pelo menos uma vez por mês. Acompanhe os boletins de segurança do WordPress, dos plugins e dos temas que utiliza, e adicione regras específicas para vulnerabilidades recém-descobertas antes de um patch estar disponível (virtual patching).

Erros comuns com WAF

• Regras demasiado agressivas: Uma WAF que bloqueia utilizadores legítimos é pior do que não ter WAF nenhuma, porque afasta visitantes e clientes. Comece em modo de monitorização e aperte as regras gradualmente.
• Confiar apenas na WAF: A WAF é uma camada de proteção, não um substituto de software atualizado, palavras-passe fortes, configuração segura e cópias de segurança. Uma estratégia de defesa em profundidade é a única abordagem correta.
• Ignorar os registos: Os registos da WAF valem ouro — mostram-lhe exatamente quem está a tentar o quê no seu site. Ignorar os registos significa perder sinais importantes de ameaça.
• Regras desatualizadas: Uma WAF com regras de há um ano é como um antivírus com uma base de dados desatualizada — não reconhece as novas ameaças.
• Não testar após alterações: Cada alteração às regras da WAF deve ser testada para confirmar que não bloqueia funcionalidades legítimas do site.

Conclusão

Uma WAF é uma camada de proteção indispensável para qualquer website, sobretudo para sites WordPress, que são o alvo mais comum de ataques. A combinação de WAF na cloud (Cloudflare) para proteção volumétrica e DDoS com WAF baseada no host (ModSecurity) para inspeção profunda dos pedidos proporciona uma proteção abrangente. Comece em modo de monitorização, acompanhe os registos, afine as regras para o seu site e atualize os conjuntos de regras regularmente. Na BeoHosting, todos os planos de alojamento incluem a WAF ModSecurity pré-configurada com o OWASP Core Rule Set otimizado para WordPress, juntamente com a nossa recomendação de utilizar o plano gratuito da Cloudflare para uma camada adicional de proteção e os benefícios de CDN.