Preciso de proteção DDoS em um servidor dedicado?

O que é proteção DDoS e quais ataques ela bloqueia?

Proteção DDoS é a filtragem colocada a montante do seu servidor: ela descarta o tráfego de ataque antes que ele chegue à sua porta de rede. Um ataque de negação de serviço distribuído (DDoS) envia tráfego de muitas máquinas ao mesmo tempo para esgotar um link, um firewall ou uma aplicação. Os ataques se dividem em dois grupos:

• Ataques de camada de rede (camadas 3 e 4). Enxurradas de pacotes: SYN floods, ACK floods, floods de UDP e ICMP, e ataques de reflexão como amplificação por DNS ou memcached. Floods volumétricos tentam saturar o próprio link, então só a filtragem antes do link ajuda.
• Ataques de camada de aplicação (camada 7). Enxurradas de requisições HTTP que parecem legítimas, requisições para furar o cache ou conexões lentas como Slowloris. Eles precisam de pouca largura de banda. Em vez disso, esgotam CPU, workers web ou o banco de dados.

A documentação da Cloudflare lista esses vetores em dois rulesets gerenciados: um para a camada de rede, outro para HTTP. Um servidor consegue repelir sozinho alguns floods de camada 7, mas nunca um flood maior que o seu uplink.

Qual é a diferença entre proteção sempre ativa e sob demanda?

A proteção sempre ativa inspeciona seu tráfego o tempo todo; a proteção sob demanda redireciona seu tráfego para uma rede de limpeza só quando um ataque começa. Limpar significa enviar o tráfego por uma rede de filtragem que descarta os pacotes de ataque e encaminha o restante limpo para você.

• Sempre ativa. Sem atraso de comutação, mas cada pacote passa pelo caminho do filtro. Um CDN ou proxy reverso na frente de um site funciona assim.
• Sob demanda. O tráfego flui direto para você até um ataque; então o provedor anuncia o seu prefixo de IP a partir da própria rede. O modo sob demanda do Magic Transit da Cloudflare liga esse anúncio durante um ataque e o desliga depois. Até a comutação, o ataque chega a você.

Para um único servidor alugado, a filtragem sempre ativa na frente de cada serviço público é a escolha prática.

Quem precisa de proteção DDoS em um servidor dedicado e quem não precisa?

Você precisa dela quando estranhos conhecem o endereço IP do seu servidor e têm motivo para derrubar o serviço. Normalmente dá para dispensar quando só você e pessoas de confiança se conectam à máquina.

O Ironatoll protege meu servidor dedicado contra ataques DDoS?

A Ironatoll vende bare metal, não uma rede filtrada. A regra, palavra por palavra: Contra ataques DDoS, não prometemos nada além do tratamento padrão da rede do datacenter. Não publicamos capacidade de mitigação, escopo de filtragem nem tempo de resposta, porque não prometemos nada disso.

Isso mantém os planos baratos, e faz de um serviço UDP público um projeto seu para proteger. Para tráfego de jogos filtrado, coloque um serviço de filtragem na frente do servidor. Ou escolha um provedor que venda mitigação com números por escrito. Nosso ranking de provedores de servidor dedicado offshore compara os provedores pelos mesmos critérios.

De acordo com a verificação da Ironatoll sobre a 30 October 2026, um servidor dedicado comparável ao Atoll 64 custou uma mediana de $337.49 na 14 hosts que aceitam cripto sem documento; a Ironatoll cobra $72.62. Essa diferença de 78% deixa espaço para um plano de CDN ou um proxy filtrado. Cada plano está listado em quanto custa um servidor dedicado Ironatoll.

Como protejo um site em um servidor dedicado contra DDoS?

Coloque um reverse proxy ou CDN na frente do site e depois oculte o endereço IP real do servidor. O Cloudflare é uma opção. Estes pontos vêm da documentação dele, lida em 30 de outubro de 2026:

• A proteção contra DDoS vem em todo plano do Cloudflare, inclusive no plano gratuito. O Cloudflare a lista como proteção padrão e ilimitada para as camadas 3 a 7.
• Só registros com proxy estão protegidos. O proxy funciona em registros A, AAAA e CNAME e cobre tráfego HTTP e HTTPS. Um registro somente DNS mostra o IP de origem para qualquer um que o consulte.
• O tráfego web com proxy usa portas fixas. HTTP: 80, 8080, 8880, 2052, 2082, 2086 e 2095. HTTPS: 443, 2053, 2083, 2087, 2096 e 8443.
• Aceite tráfego web somente do Cloudflare. O Cloudflare publica suas faixas em cloudflare.com/ips e recomenda bloquear todo o resto na origem. Um atacante que descobre o IP real, em registros DNS antigos ou configurações de e-mail, consegue atingir o servidor diretamente.
• Outros protocolos precisam do Spectrum. SSH, portas de jogos e outros serviços TCP ou UDP não são cobertos por um registro com proxy. O Spectrum para todas as portas TCP e UDP está apenas no plano Enterprise.

Cada servidor Ironatoll tem um endereço IPv4, então um registro somente DNS apontando para ele, como um registro de e-mail, revela a origem.

Como limito a taxa de conexões com nftables?

O nftables consegue limitar novas conexões por endereço de origem, o que atenua floods pequenos e tentativas de força bruta, mas não consegue parar um flood que enche o seu link. Quando o nftables vê um pacote, esse pacote já consumiu a sua banda.

O wiki do nftables mantém um limitador de taxa por IP de origem em um conjunto dinâmico. Cada entrada expira após 60 segundos sem tráfego. O ruleset abaixo aplica essa ideia ao SSH, aceita tráfego web e descarta o resto. Atrás do Cloudflare, aceite as portas 80 e 443 apenas de um conjunto das faixas publicadas dele. Carregue com nft -f /etc/nftables.conf, mantenha uma segunda sessão SSH aberta e então rode systemctl enable nftables. O limite de SSH cobre IPv4; adicione um conjunto ipv6_addr com ip6 saddr para IPv6.

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

table inet filter {
  set ssh_meter {
    type ipv4_addr
    timeout 60s
    flags dynamic
  }

  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    meta l4proto ipv6-icmp accept
    icmp type echo-request limit rate 10/second accept
    tcp dport 22 ct state new update @ssh_meter { ip saddr limit rate 10/minute } accept
    tcp dport { 80, 443 } accept
  }
}

# http block
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
    }
}

O que mais reduz o risco sem comprar nada?

Dê menos para os atacantes verem:

• Feche todas as portas que você não serve. Uma interface web do Proxmox, um banco de dados ou uma API de LLM ficam atrás de um túnel SSH.
• Mantenha serviços privados fora da máquina que roda os públicos. Um flood contra um servidor de jogo derruba tudo que compartilha o link dele.
• Nunca publique o IP de origem de um site com proxy, no histórico de DNS ou nos cabeçalhos de e-mail.

Nossa comparação entre servidor dedicado e VPS explica quando o bare metal vale a pena para um serviço público.