Mitigação de DDoS: De SYN Floods a Ataques Layer 7 com WAF Cloudflare

A Assimetria da Ciberguerra Moderna: Ataques Volumétricos vs Ataques de Aplicação

No mundo da segurança informática existe uma injustiça evidente: qualquer pessoa mal-intencionada pode alugar uma botnet por vinte euros e disparar centenas de gigabits de tráfego contra o teu servidor.

Para protegeres a tua infraestrutura, precisas de compreender que nem todos os ataques DDoS são iguais. Na prática, os ataques distribuídos de negação de serviço dividem-se em duas categorias muito distintas:

1. Layer 3 e 4 (Ataques de Rede e Transporte): Ataques volumétricos como UDP Reflection, ICMP Floods e TCP SYN Floods. O atacante quer simplesmente entupir o cabo de rede do teu datacenter ou esgotar a memória do kernel Linux onde ficam registadas as ligações abertas.
2. Layer 7 (Ataques à Camada de Aplicação): Ataques cirúrgicos como HTTP Floods, pedidos repetidos a motores de busca internos ou geração massiva de relatórios. O atacante completa o aperto de mão TLS normal e envia pedidos POST perfeitamente válidos desenhados para obrigar a tua base de dados a processar consultas pesadas, colapsando a máquina com apenas 30 Mbps de tráfego.

• ATAQUES VOLUMÉTRICOS (L3/4) vs ATAQUES À APLICAÇÃO (L7)
• ATAQUE LAYER 3/4 (Força Bruta Volumétrica)
• Botnet de Invasores → 300 Gbps de UDP Flood → Entope a Placa de Rede! (A placa física do servidor descarta pacotes legítimos por saturação total)
• ATAQUE LAYER 7 (Esgotamento de Recursos da Aplicação)
• Botnet de Invasores → 3.000 req/s POST /pesquisa?filtro=avancado (Usa apenas 15 Mbps de banda, mas a CPU da Base de Dados cola nos 100%!)

Para manteres os teus serviços sob as regras de fiabilidade do nosso alojamento gerido, a tua defesa precisa de dois pilares: filtragem Anycast na borda para o tráfego volumétrico e regras de WAF inteligentes para os ataques aplicacionais.

Como o BGP Anycast Pulveriza Ataques Volumétricos de Gigabits

Um servidor dedicado com uma placa de rede de 10 Gbps não consegue resistir a um ataque volumétrico de 100 Gbps. Não há configuração no Linux nem regra no iptables que te salve se a fibra ótica física do datacenter estiver completamente afogada em pacotes inúteis.

A única solução eficaz contra ataques massivos de Layer 3 e 4 é a tecnologia BGP Anycast, utilizada em grande escala pela Cloudflare.

Com o Anycast, centenas de datacenters em Lisboa, Madrid, Frankfurt, Londres e São Paulo anunciam o mesmo endereço IP público através do protocolo BGP. Quando uma botnet internacional dispara contra o teu site, o ataque é fragmentado geograficamente pelo datacenter mais próximo de cada robô.

DILUIÇÃO GEOGRÁFICA DE TRÁFEGO COM ANYCAST

• Ataque Global de 400 Gbps disparado por uma Botnet
• 40 Gbps absorvidos no Datacenter de Frankfurt → Filtrados em hardware!
• 30 Gbps absorvidos no Datacenter de Madrid → Filtrados em hardware!
• 50 Gbps absorvidos no Datacenter de Lisboa → Filtrados em hardware!
• 40 Gbps absorvidos no Datacenter de Nova Iorque → Filtrados em hardware!
• O Teu Servidor de Origem: Recebe apenas os pedidos limpos e legítimos!

Equipamentos de filtragem especializados limpam os pacotes maliciosos à velocidade da luz, entregando apenas tráfego HTTP autêntico ao teu servidor.

Ajustar o Kernel Linux: Neutralizar SYN Floods com TCP SYN Cookies

Mesmo com proteção na borda, o teu sistema operativo tem de estar blindado. Num TCP SYN Flood, o atacante envia milhares de pacotes SYN com endereços IP falsos e nunca responde ao SYN-ACK.

Por omissão, o Linux guarda cada ligação incompleta na memória RAM. Em poucos segundos, a fila de espera (tcp_max_syn_backlog) transborda e o servidor recusa novos clientes legítimos.

No teu servidor Debian, podes ativar os TCP SYN Cookies para eliminar este problema:

# /etc/sysctl.d/99-blindagem-ddos.conf

# Ativa SYN cookies: codifica o estado no número de sequência sem gastar RAM
net.ipv4.tcp_syncookies = 1

# Aumenta a fila de ligações TCP semi-abertas
net.ipv4.tcp_max_syn_backlog = 8192

# Reduz as tentativas de reenvio de SYN-ACK para descartar ligações mortas
net.ipv4.tcp_synack_retries = 2

# Recicla sockets em estado TIME_WAIT com segurança
net.ipv4.tcp_tw_reuse = 1

# Ignora mensagens de broadcast falsas
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Alarga a gama de portas locais efémeras
net.ipv4.ip_local_port_range = 1024 65535

Aplica as novas variáveis no sistema:

sudo sysctl --system

Com o parâmetro tcp_syncookies = 1, se a fila de espera encher, o kernel calcula um valor matemático e coloca-o no número de sequência do TCP sem alocar memória RAM. O sistema só consome recursos quando o cliente legítimo devolve o ACK final. Se o pedido for um pacote forjado de ataque, o impacto na memória do teu servidor é zero.

Mitigação de Layer 7: Limitação de Taxa no Nginx e Desafios de WAF

Para combateres ataques à camada de aplicação, deves colocar um proxy com Nginx à frente das tuas aplicações e aplicar regras de limitação com o algoritmo do balde furado (leaky bucket).

Vê como podes configurar limites de pedidos para proteger rotas pesadas:

# /etc/nginx/conf.d/limitacao_taxa.conf

# Zona 1: Navegação geral do site (10 pedidos por segundo por IP)
limit_req_zone $binary_remote_addr zone=zona_geral:20m rate=10r/s;

# Zona 2: Pesquisas pesadas e API (2 pedidos por segundo por IP)
limit_req_zone $binary_remote_addr zone=zona_api:10m rate=2r/s;

# Código HTTP devolvido em caso de excesso de pedidos
limit_req_status 429;

server {
    listen 443 ssl http2;
    server_name api.x078.com;

    location / {
        limit_req zone=zona_geral burst=20 nodelay;
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Protege a rota de pesquisa e geração de relatórios
    location /api/v1/pesquisa {
        limit_req zone=zona_api burst=5 nodelay;
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Se um script malicioso tentar disparar 300 pedidos por segundo para a tua rota de pesquisa, o Nginx processa os primeiros 5 e descarta os restantes 295 com HTTP 429 Too Many Requests sem acordar o teu processo Node.js ou a base de dados. Esta robustez é a base dos nossos websites de alta performance.

FILTRAGEM DE RATE LIMITING NO NGINX

• Pedidos a Entrar (300 pedidos/segundo de uma botnet)
• Filtro Nginx Leaky Bucket (rate=2r/s, burst=5)
• Os primeiros 5 pedidos: PASSAM para a aplicação
• Os restantes 295 pedidos: DESCARTADOS IMEDIATAMENTE COM HTTP 429!
• (Apenas 5 pedidos tocam no backend!)
• A Tua Base de Dados e Servidor Continuam Tranquilos!

Em conjunto com o WAF da Cloudflare, os clientes com comportamento suspeito recebem desafios silenciosos de JavaScript (Turnstile), separando pessoas reais de robôs automáticos. Encontras mais exemplos de regras no GitHub.

Boas Práticas Operacionais: Ocultar o IP de Origem e Fail2ban

De acordo com as boas práticas de infraestrutura recomendadas na WebXtek, deves seguir estas três regras vitais de segurança:

1. Esconde Completamente o IP Real do Servidor: Se um atacante descobrir o IPv4 direto da tua máquina, pode contornar a Cloudflare e atacar o teu servidor de frente. Fecha a firewall do Linux (UFW ou nftables) para que as portas 80 e 443 aceitem tráfego exclusivamente dos blocos de IP oficiais da Cloudflare.
2. Integra o Fail2ban com o Código 429: Analisa os registos de erro do Nginx e bloqueia automaticamente na firewall do Linux os endereços IP que insistam em provocar erros 429 consecutivos:

   # /etc/fail2ban/jail.d/nginx-limites.conf
   [nginx-limites]
   enabled = true
   filter = nginx-limit-req
   action = iptables-multiport[name=BloqueioDDoS, port="http,https"]
   logpath = /var/log/nginx/error.log
   maxretry = 10
   bantime = 7200

3. Controla os Prazos de Leitura: Configura tempos limite rigorosos no Nginx (client_body_timeout 5s; client_header_timeout 5s;) para neutralizares ataques lentos do tipo Slowloris, que tentam preencher a tua lista de ligações abertas enviando bytes muito devagar.

Com a combinação de Anycast BGP na borda, SYN cookies no kernel Linux e limitação de taxa no Nginx, a tua equipa garante que a tua infraestrutura se mantém inabalável mesmo perante os ataques DDoS mais agressivos da internet. Se precisas de apoio especializado para blindar os teus sistemas, a nossa equipa de consultoria técnica está pronta para ajudar.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como cibersegurança b2b e inteligência corporativa e provedores de cloud computing e iaas. Quando alinhas a tua estrutura através de alojamento gerido para websites e aplicações e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.