Como escolher VPS com proteção DDoS no Brasil

Resposta direta

Uma VPS com proteção DDoS no Brasil deve combinar filtragem antes da chegada do tráfego ao servidor, capacidade documentada em Gbps e Mpps, mitigação para os protocolos usados pela aplicação e procedimentos claros para ataques que ultrapassem os limites contratados. A localização brasileira ajuda na latência, mas não garante proteção. Antes de contratar, confirme se a mitigação é permanente ou sob demanda, quais portas são cobertas, quando ocorre null route, se há cobrança por tráfego limpo e como o suporte responde durante um incidente.

Para sites e APIs, a defesa costuma exigir duas camadas. A rede do provedor filtra floods de UDP, SYN e outros ataques volumétricos, enquanto um proxy reverso ou WAF trata requisições HTTP maliciosas. Em servidores de jogos, VoIP e serviços baseados em UDP, o proxy HTTP não resolve o problema sozinho. O provedor precisa reconhecer e filtrar o protocolo sem quebrar conexões legítimas.

Não escolha apenas pelo selo de proteção inclusa. Peça documentação, limites técnicos e exemplos de atuação. Uma oferta de 20 Gbps pode ser suficiente para um projeto pequeno, mas falhar diante de grande volume de pacotes por segundo. Da mesma forma, 4 vCPUs e 8 GB de RAM não compensam uma porta de rede saturada antes de o tráfego chegar ao sistema operacional.

Resumo rápido

A comparação deve começar pelo tipo de aplicação, pelos protocolos expostos e pelo impacto financeiro de alguns minutos de indisponibilidade. Estes são os pontos que mais influenciam a decisão:

• Proteção DDoS de rede normalmente cobre ataques nas camadas 3 e 4, como UDP flood, SYN flood e amplificação. Ataques HTTP complexos podem exigir CDN, proxy reverso, WAF e regras específicas.
• Capacidade em Gbps mede volume de bits, enquanto Mpps mede milhões de pacotes por segundo. Um ataque com pacotes pequenos pode esgotar equipamentos mesmo sem atingir muitos gigabits.
• Mitigação sempre ativa tende a reagir mais rápido. Soluções sob demanda dependem de detecção, anúncio de rota ou intervenção, o que pode produzir alguns minutos de instabilidade.
• Null route significa descartar todo o tráfego destinado ao IP atacado. Ele protege a rede do provedor, mas deixa a aplicação indisponível durante o bloqueio.
• Datacenter no Brasil reduz o caminho até usuários brasileiros, porém latência, capacidade externa e qualidade de peering precisam ser analisadas separadamente.
• Firewall local continua necessário. A proteção do provedor não corrige SSH exposto, senha fraca, painel desatualizado, aplicação vulnerável ou banco de dados acessível pela internet.
• Preços, localidades, limites e recursos variam com o plano. Confirme todas as condições na documentação oficial e no contrato antes da publicação ou contratação.

Uma configuração inicial equilibrada para uma API pequena pode usar 2 vCPUs, 4 GB de RAM, 60 GB de SSD ou NVMe e porta de 1 Gbps, desde que a filtragem ocorra fora da VPS. Para jogos com tráfego UDP, a capacidade de rede e a compatibilidade da mitigação com o protocolo pesam mais do que trocar SSD por NVMe.

O que a proteção DDoS de uma VPS realmente cobre

DDoS é uma categoria de ataques, não uma técnica única. Uma VPS pode receber milhões de pacotes UDP, tentativas de abrir conexões TCP, fragmentos inválidos ou requisições HTTP aparentemente legítimas. Cada cenário exige controles diferentes. Quando um provedor anuncia proteção DDoS sem explicar camadas, protocolos e limites, o cliente ainda não tem informação suficiente para avaliar o serviço.

Ataques nas camadas 3 e 4

A mitigação de rede procura remover tráfego abusivo antes que ele ocupe a porta virtual da VPS. Entre os exemplos estão UDP flood, SYN flood, ICMP flood e ataques de amplificação que exploram serviços de terceiros. O provedor pode filtrar esse tráfego no próprio datacenter ou encaminhá-lo a um centro de limpeza. Depois da análise, apenas o tráfego considerado legítimo retorna ao destino.

Considere uma VPS cuja aplicação legítima usa 80 Mbps em horário de pico. Um ataque de 5 Gbps já ultrapassa amplamente uma porta de 1 Gbps. Regras no Linux não bastam, pois o enlace fica congestionado antes de nftables ou iptables processarem os pacotes. Em outro exemplo, um ataque de 800 Mbps com pacotes muito pequenos pode gerar uma taxa elevada de pacotes por segundo e pressionar roteadores, firewalls e a pilha de rede.

Ataques de aplicação na camada 7

Na camada HTTP, o atacante pode consultar páginas pesadas, pesquisas internas, endpoints de login ou rotas que acionam banco de dados. O volume de rede parece normal, mas CPU, workers e conexões são consumidos. Um proxy reverso com cache, limitação de requisições e desafios automatizados ajuda nesse ponto.

Uma loja virtual pode filtrar floods TCP na rede e ainda cair com 2.000 requisições por segundo no endpoint de busca. Uma API pode permanecer acessível, mas acumular filas porque cada chamada executa uma consulta cara. Por isso, a estratégia deve unir mitigação de rede, observabilidade e as práticas descritas no conteúdo sobre firewall e hardening de segurança.

Como comparar capacidade de mitigação e filtragem

Números grandes chamam atenção, mas precisam de contexto. A capacidade divulgada pode representar toda a rede do provedor, um datacenter, um sistema compartilhado ou o limite aplicado a um cliente. Pergunte qual desses conceitos está sendo usado. Também confirme se o número descreve capacidade de detecção, absorção ou entrega de tráfego já filtrado.

Gbps, Mpps e conexões por segundo

Gbps indica quantos bilhões de bits são processados por segundo. Mpps indica milhões de pacotes por segundo. As duas medidas são necessárias porque os ataques variam em tamanho de pacote. Um fluxo de pacotes de 64 bytes pode gerar grande pressão de processamento sem consumir a mesma banda de um flood composto por pacotes maiores.

Conexões por segundo também importam para TCP. Um SYN flood tenta preencher tabelas de estado ou sobrecarregar componentes que acompanham sessões. Pergunte se a proteção usa SYN cookies, validação de handshake e limitação por origem. Para aplicações UDP, confirme se há perfis específicos para DNS, jogos ou VoIP. Um filtro genérico muito agressivo pode interpretar tráfego legítimo como ataque.

Mitigação permanente ou ativada sob demanda

No modelo sempre ativo, o tráfego passa continuamente pela infraestrutura de mitigação. Isso reduz o tempo de reação, mas pode adicionar caminho de rede ou exigir regras bem ajustadas para evitar falsos positivos. No modelo sob demanda, o tráfego segue diretamente para o servidor até que sensores detectem uma anomalia. A mudança de rota pode levar algum tempo e produzir perda de pacotes durante a transição.

Use perguntas mensuráveis na cotação: qual é o tempo médio de detecção, existe limite mensal de eventos, quanto tempo dura um null route e o cliente pode alterar regras? Para um fórum pequeno, alguns minutos de intervenção podem ser toleráveis. Para pagamentos, autenticação ou partidas em tempo real, a reação precisa ser mais rápida e previsível. Não aceite uma promessa de capacidade ilimitada sem condições técnicas e contratuais verificáveis.

Arquitetura de rede para manter a origem protegida

Uma boa mitigação perde eficácia quando o endereço real da VPS continua exposto. Isso acontece quando registros DNS antigos, serviços de e-mail, painéis, subdomínios ou respostas da aplicação revelam o IP de origem. O atacante ignora o proxy e envia tráfego diretamente ao servidor. A arquitetura precisa reduzir essa superfície sem bloquear a administração legítima.

Proxy reverso, DNS e ocultação do IP

Para um site, publique no DNS apenas os endereços do proxy reverso. No firewall da VPS, aceite portas 80 e 443 somente a partir das faixas oficiais desse serviço. O SSH pode ficar restrito a uma VPN administrativa ou a uma lista pequena de IPs. Se a equipe usa endereços dinâmicos, WireGuard é mais seguro e previsível do que manter a porta 22 aberta ao mundo.

Um exemplo simples separa os serviços em dois endereços. O IP público protegido recebe a aplicação, enquanto uma rede privada conecta banco de dados e monitoramento. Outro cenário usa uma VPS frontal com Nginx e duas instâncias de aplicação em rede interna. Se uma instância falhar, o balanceador remove o destino sem alterar o DNS público.

Filtros no provedor e no sistema operacional

A filtragem upstream deve ser complementada por regras locais. Uma política de entrada pode permitir apenas 80/TCP, 443/TCP e a porta da VPN, rejeitando o restante. Com nftables, revise a política usando sudo nft list ruleset. No Nginx, uma API pode aplicar limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;, seguida de limites diferentes para login, busca e endpoints públicos.

Não aplique o mesmo limite a tudo. Uma página estática aceita cache intenso, enquanto um webhook precisa receber rajadas legítimas. Em jogos, bloquear UDP indiscriminadamente derruba jogadores junto com o ataque. A escolha do datacenter também entra na arquitetura. O artigo sobre VPS de baixa latência no Brasil explica por que rota e peering podem ser tão relevantes quanto a distância geográfica.

Como dimensionar CPU, RAM, disco e conexão

Proteção DDoS não elimina a necessidade de dimensionamento. Depois que o tráfego é limpo, requisições legítimas ainda precisam ser processadas. CPU insuficiente aumenta o tempo de resposta, pouca RAM causa swap e limites baixos de conexões geram erros mesmo sem ataque. Comece pela carga normal, adicione margem e teste o comportamento sob picos controlados.

Configuração para sites e APIs

Um site institucional com cache pode começar com 2 vCPUs, 2 a 4 GB de RAM e 40 a 60 GB de SSD. Uma API com banco local, filas e Redis fica mais confortável com 4 vCPUs, 8 GB de RAM e 80 GB de armazenamento. Se o banco gera muitas gravações, NVMe pode reduzir espera de I/O, mas não aumenta a capacidade da mitigação de rede.

Imagine uma API que recebe 100 requisições por segundo normalmente e 400 durante campanhas. Teste 500 a 600 requisições por segundo em homologação para observar CPU, latência p95, conexões e erros. Se a CPU permanece abaixo de 70%, mas a latência cresce no banco, aumentar vCPUs talvez não resolva. Índices, cache e pool de conexões podem produzir resultado melhor.

Configuração para servidores de jogos

Jogos valorizam frequência de CPU, estabilidade de rota e tratamento correto de UDP. Um servidor pequeno pode usar 4 vCPUs, 8 GB de RAM e porta de 1 Gbps. Instâncias maiores, com vários mundos ou partidas simultâneas, podem exigir 8 vCPUs e 16 GB de RAM. Esses números são pontos de partida, não garantias de jogadores suportados.

A tabela resume perfis técnicos para comparação:

Perfil	Configuração inicial	Rede e mitigação	Controle adicional	Risco principal
Site com cache	2 vCPUs, 4 GB RAM, 60 GB SSD	Filtragem L3/L4 e proxy HTTP	Cache, WAF e rate limit	Exposição do IP de origem
API pública	4 vCPUs, 8 GB RAM, 80 GB SSD ou NVMe	Proteção TCP, telemetria e baixa perda	Limite por token e endpoint	Esgotamento de workers e banco
Servidor de jogo	4 a 8 vCPUs, 8 a 16 GB RAM	Filtragem UDP compatível com o jogo	Regras por porta e região	Falso positivo e variação de latência
Produção crítica	8 ou mais vCPUs, 16 GB ou mais	Mitigação permanente e redundância	Balanceamento e múltiplas origens	Dependência de um único provedor

Para jogos, use também os critérios do guia sobre VPS para hospedagem de jogos, especialmente tick rate, CPU por núcleo e estabilidade da rota.

Testes, monitoramento e resposta a incidentes

Testar proteção DDoS não significa lançar tráfego hostil contra uma rede pública. Qualquer simulação precisa de autorização escrita do provedor, escopo definido e janela de execução. Sem isso, o teste pode violar contrato, afetar terceiros ou ser interpretado como abuso. A alternativa segura é validar a aplicação com ferramentas de carga em homologação e pedir ao provedor evidências documentais da mitigação de rede.

Métricas que ajudam a identificar um ataque

Monitore banda de entrada, pacotes por segundo, novas conexões, retransmissões TCP, uso de conntrack, CPU, memória, latência p95 e taxa de erros. O comando ss -s oferece um retrato rápido das conexões. sar -n DEV 1 ajuda a observar interfaces, enquanto métricas exportadas para Prometheus permitem comparar o incidente com a linha de base.

Considere três sinais. Se a banda sobe e a VPS deixa de responder sem aumento de CPU, pode haver saturação antes do servidor. Se CPU e requisições HTTP crescem juntas, investigue camada 7. Se apenas uma rota fica lenta, procure consultas caras, autenticação abusiva ou cache ausente. Uma única métrica raramente fecha o diagnóstico.

Procedimento de resposta sem improviso

O runbook deve registrar contatos do provedor, identificadores do serviço, prefixos de rede, portas críticas e critérios de escalonamento. Durante um incidente, preserve logs e anote horários. Evite reiniciar a VPS repetidamente, pois isso apaga contexto e não corrige congestionamento upstream.

Uma sequência prática é confirmar o impacto por monitoramento externo, comparar rede e aplicação, abrir o chamado com horário e IP afetado, aplicar limites temporários e comunicar usuários. Depois, revise falsos positivos, regras acionadas e tempo de recuperação. Se o provedor aplicou null route, peça a justificativa técnica, a duração e os limites que provocaram a medida.

Limitações que precisam ser verificadas no provedor

Provedores podem oferecer mitigação de formas muito diferentes. AWS, Google Cloud, Microsoft Azure, Cloudflare e empresas de VPS usam arquiteturas, contratos e modelos de cobrança próprios. Serviços cloud nativos também separam recursos básicos de rede, produtos avançados e proteção de aplicação. Não trate nomes comerciais semelhantes como recursos equivalentes.

Null route, portas, protocolos e tráfego limpo

Confirme se a proteção atende IPv4 e IPv6, TCP e UDP, portas personalizadas e protocolos de jogos. Pergunte o que acontece quando o ataque ultrapassa a capacidade disponível. Alguns ambientes podem descartar o IP temporariamente, limitar a porta ou exigir migração para outro serviço. A duração e os critérios precisam estar no contrato ou em uma resposta formal do suporte.

O tráfego após a limpeza também pode ter limite. Uma mitigação capaz de absorver um ataque grande não significa que a VPS receberá tráfego legítimo sem restrição. Verifique a velocidade da interface, a franquia mensal, a política de excedente e a capacidade do datacenter escolhido. Localidades e recursos podem mudar por plano.

SLA, suporte e responsabilidade compartilhada

Pergunte se o suporte de segurança funciona continuamente, qual canal atende incidentes e qual é o prazo de resposta. Um SLA de disponibilidade não descreve necessariamente tempo de mitigação. Também procure exclusões, como ataques contra aplicações mal configuradas, IP revelado fora do proxy ou serviços não autorizados.

Na avaliação de Hostinger, HostGator, Locaweb, DigitalOcean, Vultr, Akamai, AWS Lightsail, Contabo, Hetzner ou LetsCloud, use a mesma lista de perguntas. Para a LetsCloud, localização, tipo de armazenamento, snapshots, backup e mitigação devem ser confirmados no plano e na localidade selecionados. Não presuma que um recurso disponível em uma região exista em todas as outras. Qualquer comparação de preço, capacidade ou SLA exige revisão humana com dados oficiais atualizados.

Recomendações por perfil

A melhor combinação depende do custo da indisponibilidade, do protocolo e da capacidade da equipe de operar o ambiente. Uma camada adicional só ajuda quando está integrada ao DNS, ao firewall, ao monitoramento e ao procedimento de incidente.

Desenvolvedor solo e projeto pequeno

Para blog, portfólio, painel interno ou API inicial, procure filtragem de camadas 3 e 4, porta de pelo menos 1 Gbps e documentação sobre null route. Uma configuração de 2 vCPUs, 4 GB de RAM e 60 GB de SSD costuma oferecer margem para sistema, proxy e aplicação leve. Coloque o site atrás de um proxy reverso, restrinja o IP de origem e mantenha snapshots ou backups fora da VPS.

O principal erro nesse perfil é pagar por uma promessa ampla e deixar SSH, painel e banco expostos. Ative autenticação por chave, VPN administrativa e alertas de indisponibilidade. Se o serviço tolera alguns minutos fora do ar, mitigação sob demanda pode ser aceitável, desde que o tempo de ativação seja conhecido.

Equipe com aplicações públicas

Uma equipe que opera SaaS, APIs ou múltiplos sites deve separar rede, aplicação e dados. Considere 4 vCPUs, 8 GB de RAM, armazenamento de 80 GB ou mais e banco isolado quando a carga justificar. Use limitação por token, rota e cliente, não apenas por endereço IP. NAT corporativo e redes móveis podem concentrar muitos usuários legítimos na mesma origem.

Exija métricas de tráfego, histórico de eventos e canal de suporte adequado ao horário de operação. Faça exercícios trimestrais de resposta com falha de origem, bloqueio de rota e aumento repentino de requisições. A equipe precisa saber quem altera DNS, quem fala com o provedor e quem comunica clientes.

Produção crítica, e-commerce e jogos

Ambientes que não podem depender de uma única VPS precisam de balanceamento, múltiplas origens e backups testados. Para aplicações web, combine mitigação de rede, proxy global, WAF e autenticação resistente a abuso. Para jogos, confirme proteção UDP, impacto de filtragem na latência e comportamento diante de pacotes fora do padrão.

Comece com 8 vCPUs, 16 GB de RAM e monitoramento detalhado quando a aplicação e os testes justificarem esse porte, mas dimensione com medições reais. Avalie redundância entre zonas ou provedores, considerando que troca de rota e sincronização de estado aumentam a complexidade. Antes da contratação, solicite limites por escrito, teste a restauração e revise os dados comerciais. A proteção mais útil é aquela cujo funcionamento, limite e procedimento de escalonamento a equipe conhece antes do primeiro ataque.