Proteção contra DDoS no servidor dedicado: o que a rede filtra e o que você deve configurar

Proteção contra DDoS: entenda o que o AntiDDoS da rede filtra e configure firewall, fail2ban e limite de requisições para ataques de camada 7.

Para que serve

Os servidores dedicados contam com proteção contra DDoS (AntiDDoS) na rede. Ela existe para segurar ataques que tentam lotar o link com volume de tráfego. Mas nenhuma proteção de rede consegue diferenciar sozinha um acesso legítimo de um abuso que parece legítimo, como milhares de requisições HTTP válidas ou tentativas de senha no SSH e no RDP. Este artigo explica essa divisão de responsabilidades e mostra o que configurar no servidor.

O que a proteção contra DDoS da rede cobre e o que fica com você

Nos servidores da E-Consulters, a proteção AntiDDoS da rede é feita em parceria com a UPX e a Rocket, opera em modo always-on (o tráfego passa pela filtragem o tempo todo, sem esperar a detecção de um ataque para ativar) e não tem limite de mitigação. Ela atua só na camada de rede (camadas 3 e 4): não bloqueia portas nem filtra o conteúdo do tráfego, então HTTP/HTTPS (80/443) e as demais portas chegam normalmente ao servidor, e o firewall é responsabilidade sua. Ainda assim, ataques de aplicação (camada 7) e tentativas de senha precisam ser tratados no próprio servidor, como mostram os passos abaixo. Para os conceitos e os tipos de ataque, veja também o artigo «O que é ataque DDoS, quais os tipos e como funciona a proteção AntiDDoS».

Pré-requisitos

• Acesso root/administrador e o console IPMI/iLO funcionando.
• Lista dos serviços que realmente precisam estar acessíveis pela internet.

Passo a passo

1. Descubra o que está exposto

ss -tulpn

Tudo o que aparece escutando em 0.0.0.0, [::] ou * está aberto para a internet, a menos que um firewall bloqueie. No Windows, use Get-NetTCPConnection -State Listen e Get-NetUDPEndpoint.

Feche ou restrinja, nesta ordem de prioridade:

• Serviços usados em amplificação: DNS recursivo aberto (porta 53 respondendo a qualquer um), NTP (123/UDP), SNMP (161/UDP), memcached (11211), SSDP. Se não precisa, desinstale; se precisa, limite a IPs autorizados.
• Bancos de dados e caches: MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), MongoDB (27017). Faça escutar só em 127.0.0.1 ou em rede privada.
• Acesso administrativo: RDP (3389), painel do Proxmox (8006), SSH (22). O ideal é acessar por VPN (WireGuard, por exemplo) ou liberar só para os IPs fixos da sua empresa.

2. Endureça o acesso remoto

• SSH: use chaves e desative senha. Em /etc/ssh/sshd_config: PasswordAuthentication no e PermitRootLogin prohibit-password. Teste o login por chave em outra janela antes de fechar a sessão atual, e depois rode systemctl reload ssh. Veja também o artigo «Como proteger o SSH: chaves ed25519, sem senha, sem root e com fail2ban ou CrowdSec».
• RDP: não deixe a porta 3389 aberta para a internet. Use VPN ou restrinja por IP no Firewall do Windows; mudar a porta não resolve. Mantenha a autenticação no nível da rede (NLA) ativa.
• Bloqueio automático com fail2ban (Debian 12/13, Ubuntu 24.04):

  apt install fail2ban
  cat > /etc/fail2ban/jail.d/sshd.local <<'EOF'
  [sshd]
  enabled  = true
  backend  = systemd
  maxretry = 5
  findtime = 10m
  bantime  = 1h
  EOF
  systemctl restart fail2ban
  fail2ban-client status sshd

  O backend = systemd é necessário nas versões atuais, que registram o log do SSH no journal e não em /var/log/auth.log.

3. Firewall com limite de taxa (nftables)

Em servidores Debian/Ubuntu sem Proxmox, um ruleset básico com política de bloqueio e limite de novas conexões por IP. Salve em /etc/nftables.conf e ajuste as portas:

#!/usr/sbin/nft -f
flush ruleset

table inet filtro {
    set ssh_v4 { type ipv4_addr; flags dynamic; timeout 1m; }
    set ssh_v6 { type ipv6_addr; flags dynamic; timeout 1m; }

    chain input {
        type filter hook input priority 0; policy drop;

        ct state established,related accept
        ct state invalid drop
        iif lo accept

        # ICMPv6 é obrigatório para o IPv6 funcionar
        meta l4proto ipv6-icmp accept
        icmp type echo-request limit rate 10/second accept
        icmp type echo-request drop
        ip protocol icmp accept

        # SSH: no máximo 10 novas conexões por minuto por IP
        tcp dport 22 ct state new update @ssh_v4 { ip saddr limit rate 10/minute } accept
        tcp dport 22 ct state new update @ssh_v6 { ip6 saddr limit rate 10/minute } accept

        # serviços públicos
        tcp dport { 80, 443 } accept
    }
}

Aplique com uma rede de segurança: agende a remoção das regras em 5 minutos, aplique e, se tudo estiver funcionando, cancele o agendamento.

nft -c -f /etc/nftables.conf                          # só valida a sintaxe
systemd-run --on-active=5min /usr/sbin/nft flush ruleset  # anote o nome da unidade exibida
nft -f /etc/nftables.conf
# testou SSH e site em outra janela e está tudo certo?
systemctl stop run-XXXX.timer                         # use o nome exibido acima
systemctl enable nftables

No Proxmox VE, não misture regras nft manuais com o firewall do Proxmox. Use Datacenter > Firewall e Node > Firewall na interface web, e libere a porta 8006 e o SSH apenas para seus IPs antes de ativar o firewall. Cada VM pode ter seu próprio firewall na aba Firewall da VM.

4. Limite de requisições no servidor web (camada 7)

No nginx, limite requisições por IP. No bloco http:

limit_req_zone $binary_remote_addr zone=porip:10m rate=10r/s;

E no server ou location que quer proteger (login, busca, API):

limit_req zone=porip burst=20 nodelay;
limit_req_status 429;

Valide e recarregue: nginx -t && systemctl reload nginx. Ajuste rate e burst ao seu tráfego real: valores baixos demais bloqueiam usuários legítimos, principalmente atrás de NAT corporativo. Para sites muito expostos, um CDN/WAF na frente do servidor absorve boa parte dos ataques de camada 7: veja também o artigo «Como instalar um WAF no servidor: ModSecurity com OWASP CRS e Cloudflare».

5. Ajustes de kernel

Confirme que os SYN cookies estão ativos (padrão nas distribuições atuais):

sysctl net.ipv4.tcp_syncookies    # deve retornar 1

Como saber se funcionou

• ss -tulpn mostra apenas os serviços que você decidiu expor; os demais escutam em 127.0.0.1.
• De uma máquina externa, nmap -Pn IP_DO_SERVIDOR mostra somente as portas liberadas.
• nft list ruleset mostra as regras carregadas; fail2ban-client status sshd lista IPs banidos.
• Requisições acima do limite no nginx recebem HTTP 429 e aparecem no error.log.

Durante um ataque: o que coletar

nload eno1                                  # volume de tráfego em tempo real
ss -s                                       # resumo de conexões
ss -ant state syn-recv | wc -l              # conexões semiabertas (SYN flood)
tcpdump -nni eno1 -c 2000 -w /root/ataque.pcap   # amostra do tráfego

Para ataques HTTP, veja quais IPs mais acessam: awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20.

Problemas comuns

• Trancado para fora após o firewall: entre pelo console IPMI/iLO e rode nft flush ruleset ou pve-firewall stop.
• IPv6 parou de funcionar após o firewall: faltou liberar ICMPv6.
• Usuários legítimos recebendo 429: aumente burst ou rate, ou aplique o limite só nas rotas sensíveis.
• Servidor lento sem tráfego alto: o problema pode ser camada 7 ou a própria aplicação. Veja o artigo sobre diagnóstico de lentidão.

Perguntas frequentes

A proteção AntiDDoS precisa ser ativada quando começa um ataque?

Não. Na E-Consulters ela funciona em modo always-on: o tráfego é filtrado o tempo todo, sem tempo de ativação, e sem limite de mitigação.

A proteção contra DDoS da rede bloqueia ataques HTTP (camada 7)?

Não totalmente. Requisições HTTP válidas em excesso parecem tráfego legítimo, então precisam ser tratadas no servidor web, na aplicação ou em um WAF/CDN, com limite de requisições.

O AntiDDoS protege contra força bruta no SSH e no RDP?

Não. Tentativas de senha são tratadas no servidor: acesso por VPN ou restrito por IP, login por chave e bloqueio automático com fail2ban.

Como saber se meu servidor está sofrendo um ataque DDoS?

Veja o tráfego com nload, o número de conexões com ss -s e as conexões semiabertas com ss -ant state syn-recv. Em ataques HTTP, conte os IPs que mais aparecem no log de acesso.

Que portas devo fechar para reduzir o risco?

Feche DNS recursivo, NTP, SNMP e memcached abertos, bancos de dados e acessos administrativos. Veja também o artigo «Portas abertas no servidor: quais nunca devem ficar expostas na internet (e como liberar só para o seu IP)».

Precisa de ajuda?

Se suspeitar de um ataque, abra um ticket informando o IP afetado, o horário de início, o tipo de tráfego observado e anexando as saídas acima (ou o arquivo .pcap). Isso ajuda o suporte a verificar o que chegou à rede e o que foi filtrado.