Como proteger o servidor contra ataques DDoS com proxy: configuração em 15 minutos

Ataques DDoS podem paralisar o funcionamento de qualquer serviço web em questão de minutos. Os criminosos enviam milhares de solicitações de diferentes endereços IP, sobrecarregando o servidor e tornando-o inacessível para usuários reais. Servidores proxy são uma das ferramentas eficazes de proteção, permitindo filtrar tráfego malicioso, distribuir carga e ocultar o endereço IP real do seu servidor.

Neste guia, vamos explorar como configurar proxies para proteção contra DDoS, quais tipos de proxies usar e como construir um sistema de segurança em múltiplas camadas. O material é voltado para administradores de sistemas, proprietários de serviços web e especialistas em DevOps.

Como funcionam os ataques DDoS e por que os proxies ajudam

DDoS (Distributed Denial of Service) é um ataque distribuído de negação de serviço. O criminoso utiliza um botnet composto por milhares de dispositivos infectados que enviam solicitações simultaneamente para o seu servidor. O objetivo é esgotar os recursos do servidor (processador, memória, largura de banda) e torná-lo inacessível para usuários legítimos.

Os principais tipos de ataques DDoS:

• Volumetric attacks (ataques volumétricos) — saturam a largura de banda com uma enorme quantidade de tráfego (amplificação DNS, inundação UDP)
• Protocol attacks (ataques de protocolo) — exploram vulnerabilidades em protocolos de rede (inundação SYN, Ping of Death)
• Application layer attacks (ataques na camada de aplicação) — imitam solicitações legítimas a uma aplicação web (inundação HTTP, Slowloris)

Servidores proxy ajudam a se proteger contra DDoS de várias maneiras:

• Ocultação do endereço IP real do servidor — os atacantes veem apenas o IP do proxy, e não o do seu servidor principal
• Filtragem de tráfego malicioso — o proxy analisa as solicitações e bloqueia as suspeitas
• Distribuição de carga — vários servidores proxy distribuem o tráfego entre servidores backend
• Rate limiting — limitação do número de solicitações de um único endereço IP
• Cache de conteúdo estático — reduz a carga no servidor principal

É importante entender que proxies não são uma panaceia para todos os tipos de DDoS. Ataques volumétricos poderosos podem saturar a largura de banda até o servidor proxy. Portanto, proxies são eficazes em combinação com outros métodos de proteção: CDN, serviços anti-DDoS em nuvem (Cloudflare, AWS Shield), firewalls.

Tipos de proxies para proteção contra DDoS: reversos vs diretos

Para proteção contra DDoS, são utilizados dois tipos principais de servidores proxy:

Proxies Reversos (Reverse Proxy)

O proxy reverso está posicionado à frente do seu servidor web e aceita todas as solicitações de entrada dos clientes. Os clientes interagem apenas com o proxy, sem saber o endereço IP real do seu servidor. Esta é a principal ferramenta para proteção contra DDoS.

Soluções populares para proxies reversos:

• Nginx — um servidor web rápido e leve com funções de proxy reverso
• HAProxy — um balanceador de carga especializado com poderosas capacidades de filtragem
• Apache mod_proxy — módulo para Apache, menos eficiente que o Nginx
• Varnish — acelerador HTTP com foco em caching

Proxies Diretos (Forward Proxy)

Proxies diretos são usados do lado do cliente para solicitações de saída. No contexto de proteção contra DDoS, eles são utilizados com menos frequência, mas podem ser úteis para:

• Ocultar os endereços IP dos seus servidores ao acessar APIs externas
• Distribuir o tráfego de saída através de múltiplos endereços IP
• Contornar bloqueios ao coletar informações sobre potenciais ataques

Para essas tarefas, são adequados proxies residenciais — eles possuem endereços IP reais de usuários domésticos e parecem tráfego comum, o que dificulta sua detecção e bloqueio.

Configuração de proxy reverso no Nginx para proteção do servidor

O Nginx é uma das ferramentas mais populares para criar proxies reversos. Ele processa rapidamente as solicitações de entrada, suporta rate limiting e pode filtrar tráfego suspeito.

Configuração básica do proxy reverso

Instale o Nginx em um servidor separado, que receberá todo o tráfego de entrada. O servidor web real deve estar oculto atrás do proxy e aceitar solicitações apenas dele.

# /etc/nginx/nginx.conf

http {
    # Limitação do número de conexões de um único IP
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;

    # Limitação do número de solicitações (rate limiting)
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_req zone=req_limit burst=20 nodelay;

    # Timeouts para proteção contra Slowloris
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 5s 5s;
    send_timeout 10s;

    upstream backend {
        # IP do seu servidor web real
        server 192.168.1.100:80;
        # Você pode adicionar vários servidores para balanceamento
        # server 192.168.1.101:80;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            # Encaminhamento de solicitações para o backend
            proxy_pass http://backend;
            
            # Encaminhamento do IP original do cliente
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            
            # Timeouts para o proxy
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
            proxy_read_timeout 10s;
        }
    }
}

Bloqueio de User-Agents suspeitos

Muitos ataques DDoS utilizam bots com User-Agents característicos. Adicione regras para bloqueá-los:

# Bloqueio de bots conhecidos
map $http_user_agent $bad_bot {
    default 0;
    ~*bot 1;
    ~*crawler 1;
    ~*spider 1;
    ~*scraper 1;
    "" 1; # User-Agent vazio
}

server {
    listen 80;
    server_name example.com;

    if ($bad_bot) {
        return 403;
    }

    location / {
        proxy_pass http://backend;
    }
}

Geo-bloqueio de países indesejados

Se o seu serviço opera apenas em determinados países, você pode bloquear o tráfego de outras regiões usando o módulo GeoIP:

# Instalação do módulo GeoIP
# apt-get install nginx-module-geoip

load_module modules/ngx_http_geoip_module.so;

http {
    geoip_country /usr/share/GeoIP/GeoIP.dat;

    # Permitir apenas tráfego da Rússia e Ucrânia
    map $geoip_country_code $allowed_country {
        default no;
        RU yes;
        UA yes;
    }

    server {
        listen 80;
        server_name example.com;

        if ($allowed_country = no) {
            return 403;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

HAProxy para balanceamento de carga e filtragem de tráfego

HAProxy é um poderoso balanceador de carga com recursos avançados de filtragem de tráfego. Ele suporta ACLs (Access Control Lists) complexas para bloquear ataques na camada de aplicação.

Configuração básica do HAProxy

# /etc/haproxy/haproxy.cfg

global
    maxconn 50000
    # Log
    log /dev/log local0
    log /dev/log local1 notice

defaults
    mode http
    log global
    option httplog
    option dontlognull
    
    # Timeouts
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    
    # Limitação do tamanho da solicitação (proteção contra POST flood)
    maxconn 3000

frontend http_front
    bind *:80
    
    # Rate limiting: máximo de 100 solicitações a cada 10 segundos de um único IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 100 }
    
    # Bloqueio de solicitações sem cabeçalho Host
    acl has_host hdr(host) -m found
    http-request deny if !has_host
    
    # Bloqueio de User-Agents suspeitos
    acl bad_bot hdr_sub(User-Agent) -i bot crawler spider scraper
    http-request deny if bad_bot
    
    # Encaminhamento para o backend
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    
    # Lista de servidores backend
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check
    server web3 192.168.1.102:80 check

Proteção contra HTTP Flood com ACL

HTTP Flood é um ataque em que o criminoso envia um grande número de solicitações HTTP legítimas. O HAProxy permite criar regras complexas para sua detecção:

frontend http_front
    bind *:80
    
    # Rastreamento do número de solicitações de um único IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    
    # Bloqueio ao exceder limites
    acl too_many_requests sc_http_req_rate(0) gt 50
    acl too_many_connections sc_conn_cur(0) gt 10
    
    http-request deny deny_status 429 if too_many_requests
    http-request deny deny_status 429 if too_many_connections
    
    # Bloqueio de solicitações para caminhos inexistentes (varredura)
    acl valid_path path_beg /api /static /login /
    http-request deny if !valid_path
    
    default_backend web_servers

Whitelist de endereços IP confiáveis

Crie uma whitelist para endereços IP confiáveis (por exemplo, seus endereços de escritório ou parceiros), que não serão sujeitos a rate limiting:

frontend http_front
    bind *:80
    
    # Whitelist de endereços IP confiáveis
    acl whitelist src 203.0.113.0/24 198.51.100.50
    
    # Rate limiting apenas para IPs não-whitelist
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src if !whitelist
    http-request deny if { sc_http_req_rate(0) gt 100 } !whitelist
    
    default_backend web_servers

Uso de proxies residenciais para ocultar a infraestrutura

Além de proxies reversos à frente do seu servidor, você pode usar proxies residenciais para proteção adicional da infraestrutura. Isso é especialmente relevante se você precisar:

• Ocultar os endereços IP dos seus servidores de monitoramento — se você está monitorando ataques DDoS ou coletando informações sobre ameaças, proxies residenciais ajudarão a ocultar suas ações
• Acessar APIs externas sem revelar a infraestrutura — seus servidores podem fazer solicitações através de proxies residenciais, dificultando sua detecção
• Testar a proteção contra DDoS — simular ataques de diferentes endereços IP para verificar a eficácia dos seus filtros

Proxies residenciais têm endereços IP reais de usuários domésticos, tornando-os indistinguíveis do tráfego comum. Isso dificulta seu bloqueio e permite contornar geo-restrições.

Exemplo: Monitoramento de ameaças através de proxies residenciais

Suponha que você queira monitorar a atividade de botnets que podem atacar seu serviço. Usando proxies residenciais, você pode coletar informações sem revelar os endereços IP dos seus servidores:

import requests

# Configuração do proxy residencial
proxies = {
    'http': 'http://username:password@residential-proxy.com:8080',
    'https': 'http://username:password@residential-proxy.com:8080'
}

# Coleta de informações sobre ameaças potenciais
threat_sources = [
    'http://suspicious-site1.com',
    'http://suspicious-site2.com'
]

for source in threat_sources:
    try:
        response = requests.get(source, proxies=proxies, timeout=5)
        # Análise da resposta para identificar padrões de ataque
        print(f"Status: {response.status_code}, IP: {response.headers.get('X-Your-IP')}")
    except Exception as e:
        print(f"Erro ao acessar {source}: {e}")

Regras de filtragem: como distinguir um ataque de tráfego legítimo

A principal dificuldade na proteção contra DDoS na camada de aplicação (L7) é distinguir o tráfego malicioso do tráfego legítimo. Ataques modernos imitam o comportamento de usuários reais, dificultando sua detecção.

Sinais de um ataque DDoS

• Aumento repentino no número de solicitações — de 2 a 10 vezes mais do que o normal em um curto período
• Solicitações com o mesmo User-Agent — bots frequentemente usam o mesmo User-Agent
• Ausência de Referer — solicitações diretas sem transição de outras páginas
• Solicitações homogêneas — acessos ao mesmo URL com variações mínimas
• Ausência de JavaScript — bots não executam código JS na página
• Baixo tempo na página — bots fecham a conexão imediatamente após receber a resposta
• Intervalos de IP suspeitos — solicitações em massa de uma única sub-rede

Filtragem em múltiplas camadas

A proteção eficaz utiliza vários níveis de filtragem:

Exemplo: Desafio JavaScript no Nginx

Uma maneira simples de filtrar bots é exigir a execução de JavaScript para definir cookies:

server {
    listen 80;
    server_name example.com;

    # Verificação da presença do cookie
    set $has_cookie 0;
    if ($http_cookie ~* "verified=true") {
        set $has_cookie 1;
    }

    # Se o cookie não estiver presente, mostramos o desafio JS
    location / {
        if ($has_cookie = 0) {
            return 200 '
                <html>
                <head><title>Verificação</title></head>
                <body>
                <script>
                    document.cookie = "verified=true; path=/";
                    window.location.reload();
                </script>
                <noscript>Por favor, habilite o JavaScript</noscript>
                </body>
                </html>
            ';
        }

        proxy_pass http://backend;
    }
}

Monitoramento e resposta a DDoS em tempo real

A proteção eficaz contra DDoS requer monitoramento constante do tráfego e resposta rápida a anomalias. Configure um sistema de monitoramento que rastreie métricas-chave:

• Número de solicitações por segundo — um aumento repentino pode indicar um ataque
• Número de endereços IP únicos — DDoS frequentemente vem de muitos IPs
• Taxa de erros 4xx/5xx — aumento de erros pode ser um sinal de sobrecarga
• Tempo de resposta do servidor — aumento da latência indica problemas
• Consumo de recursos — CPU, memória, tráfego de rede

Ferramentas de monitoramento

Configuração de alertas no Prometheus

Crie regras para alertas automáticos ao detectar anomalias:

# prometheus_alerts.yml

groups:
  - name: ddos_detection
    interval: 10s
    rules:
      # Alerta ao detectar aumento repentino de solicitações
      - alert: HighRequestRate
        expr: rate(nginx_http_requests_total[1m]) > 1000
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Taxa de solicitações alta detectada"
          description: "A taxa de solicitações é {{ $value }} req/s"

      # Alerta ao detectar aumento de erros 5xx
      - alert: HighErrorRate
        expr: rate(nginx_http_requests_total{status=~"5.."}[5m]) > 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Alta taxa de erro 5xx"
          description: "Erros 5xx: {{ $value }} req/s"

      # Alerta ao detectar alta utilização de CPU
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Alta utilização de CPU"
          description: "A utilização de CPU é {{ $value }}%"

Resposta automática com Fail2ban

O Fail2ban analisa logs e bloqueia automaticamente endereços IP que excedem os limites de solicitações:

# /etc/fail2ban/jail.local

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]

# /etc/fail2ban/filter.d/nginx-req-limit.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"
ignoreregex =

Proteção em múltiplas camadas: combinando proxies com outros métodos

Servidores proxy são um elemento importante na proteção contra DDoS, mas são mais eficazes em combinação com outros métodos. Vamos considerar a arquitetura de proteção em múltiplas camadas:

Nível 1: Proteção de Rede (L3/L4)

• Serviços anti-DDoS em nuvem — Cloudflare, AWS Shield, Google Cloud Armor filtram o tráfego antes que ele chegue aos seus servidores
• Firewalls de hardware — equipamentos especializados para filtragem de tráfego de rede
• BGP blackholing — redirecionamento de tráfego malicioso para um "buraco negro" no nível do provedor

Nível 2: CDN e caching

• CDN (Content Delivery Network) — distribui conteúdo estático por vários servidores, reduzindo a carga no origin
• Caching em proxies — Varnish, Nginx armazenam páginas populares em cache e as entregam sem consultar o backend
• Otimização de conteúdo — minificação de CSS/JS, compressão de imagens reduzem o volume de tráfego

Nível 3: Proxies e balanceamento (L7)

• Proxies Reversos — Nginx, HAProxy filtram solicitações na camada de aplicação
• Balanceamento de carga — distribuição de carga entre vários servidores backend
• Rate limiting — limitação do número de solicitações de um único IP
• WAF (Web Application Firewall) — ModSecurity, AWS WAF bloqueiam ataques a aplicações web

Nível 4: Otimização do backend

• Otimização de banco de dados — índices, caching de consultas, réplicas de leitura
• Processamento assíncrono — tarefas pesadas são executadas em segundo plano através de filas (RabbitMQ, Redis)
• Escalonamento horizontal — adição de novos servidores conforme a carga aumenta

Exemplo de arquitetura

Cliente
  ↓
Cloudflare (anti-DDoS L3/L4, CDN)
  ↓
Nginx proxy reverso (rate limiting, filtragem)
  ↓
HAProxy (balanceamento de carga)
  ↓
Servidores backend (aplicação web)
  ↓
Banco de dados (com replicação)

Essa arquitetura fornece proteção em todos os níveis: rede, transporte, aplicação. Mesmo que um ataque passe por um nível, o próximo o deterá.

Uso de proxies de data center para uma camada adicional

Em alguns casos, faz sentido adicionar proxies de data center como uma camada intermediária entre a CDN e seus servidores. Eles oferecem alta velocidade de processamento e podem realizar filtragem adicional de tráfego. Proxies de data center são mais baratos que residenciais e móveis, tornando-os uma solução econômica para lidar com grandes volumes de tráfego.

Conclusão

A proteção contra ataques DDoS usando servidores proxy é um método eficaz que permite filtrar tráfego malicioso, ocultar endereços IP reais dos servidores e distribuir carga. Proxies reversos baseados em Nginx ou HAProxy oferecem configuração flexível de regras de filtragem, rate limiting e bloqueio de solicitações suspeitas.

Pontos-chave que abordamos:

• Proxies reversos (Nginx, HAProxy) — a principal ferramenta de proteção na camada de aplicação (L7)
• Rate limiting e filtragem por User-Agent, reputação de IP ajudam a filtrar a maioria dos ataques
• Proxies residenciais são úteis para ocultar a infraestrutura de monitoramento e coletar informações sobre ameaças
• A proteção em múltiplas camadas (CDN + proxies + WAF + otimização do backend) garante máxima resiliência
• Monitoramento e resposta automática são críticos para rápida detecção e bloqueio de ataques

Lembre-se de que os ataques DDoS estão em constante evolução, portanto, o sistema de proteção requer atualizações e testes regulares. Realize testes de carga, analise logs, atualize regras de filtragem e fique atento a novos métodos de ataque.

Se você planeja construir um sistema de proteção em múltiplas camadas usando proxies, recomendamos considerar proxies residenciais para ocultar infraestrutura crítica e proxies de data center para processamento de grandes volumes de tráfego em alta velocidade. A combinação de diferentes tipos de proxies garante um equilíbrio ideal entre segurança, desempenho e custo.