Duas palavras, dois comportamentos opostos
Há duas coisas que uma hospedagem pode fazer quando chega uma inundação, e o setor vende as duas como "proteção contra DDoS". A primeira é a absorção: o tráfego é levado para uma camada de scrubbing a montante do seu servidor, os pacotes de ataque são descartados ali, os pacotes legítimos seguem em frente, e o seu serviço permanece acessível o tempo todo. A segunda é o blackholing — também chamado de null-routing, ou RTBH, conforme a RFC 5635 — em que o seu endereço IP é retirado da tabela de roteamento para que nada mais chegue até ele. A inundação para de atingir o datacenter. O mesmo acontece com os seus usuários, o seu monitoramento e a sua sessão SSH. O atacante obtém exatamente o resultado pelo qual pagou.
Ambas são engenharia real, e nenhuma delas é desonesta em seus próprios termos. O blackholing existe porque absorver uma inundação grande custa dinheiro de verdade — o trânsito é medido, a capacidade de scrubbing é comprada e provisionada — e uma hospedagem econômica que aplica null-route em um cliente para manter outros quatrocentos online está tomando uma decisão defensável. O truque está no pronome. "Proteção contra DDoS" é verdadeiro nos dois casos; o que muda é de quem é o serviço sendo protegido. Leia todo cartão de plano com essa pergunta em mente.
| Resposta | Tráfego de ataque | Seu serviço | Geralmente descrito como |
|---|---|---|---|
| Scrubbing / absorção | Filtrado a montante, descartado na borda | Permanece no ar, geralmente sem mudança visível | "Mitigação sempre ativa", "scrubbing anycast" |
| Blackhole / null-route | Descartado junto com o seu tráfego legítimo | Offline durante o período — normalmente 1–24 h | "Proteção até X Gbps", "suspensão temporária de IP" |
| Apenas rate-limit na borda | Parcialmente descartado, em parte de forma aleatória | Degradado — usuários reais percebem perda de pacotes | "Proteção básica incluída" |
| Nada (a operadora decide) | Chega ao rack até que um upstream aplique blackhole ao prefixo | Offline, assim como os seus vizinhos de rack | "Proteção contra DDoS disponível" |
Lendo a letra miúda antes de pagar
O vocabulário entrega o jogo. "Proteção até 10 Gbps" é um teto, e a frase logo depois dele — a que fala sobre tráfego que excede o limite — é a cláusula de null-route. "IP protegido disponível como add-on" significa que o endereço que você recebe por padrão não é protegido. "Por incidente" significa que a fatura chega depois do ataque. "Uso justo" associado à mitigação significa uma cota de ataques por mês, depois da qual você está por conta própria. Nenhuma dessas frases é mentira; elas são simplesmente escritas para serem lidas por cima.
Um exemplo nomeado e publicado, porque é política documentada, não boato: a BuyVM vende endereços filtrados contra DDoS como um add-on separado de $3/mês por IP, e endereços não filtrados recebem null-route enquanto um ataque está em andamento. Nós descrevemos isso sem muito comentário na nossa página de comparação com a BuyVM, porque um IP não filtrado e barato é um produto perfeitamente razoável quando você sabe que foi isso que comprou. O modo de falha é descobrir isso às 03h com um booter em ação.
Quatro perguntas que valem a pena enviar para o pré-venda antes da primeira fatura. Qual é a capacidade de mitigação, e esse número é o agregado ou o valor disponível em um único ponto de presença? Uma "rede de 2 Tbps" que termina em um único centro de scrubbing tem apenas um cano para encher. A mitigação está incluída neste plano ou é um add-on? Existe cobrança por incidente ou uma cota mensal de eventos mitigados? A partir de que limiar vocês aplicam null-route, e por quanto tempo? Uma hospedagem que responde à última pergunta com um número vale mais do que uma que responde com adjetivos.
As três camadas, e por que a camada decide quem pode corrigir o problema
Volumétrico de Layer 3/4. SYN floods, UDP floods, e reflexão ou amplificação através de serviços NTP, DNS, memcached, CLDAP e SSDP abertos. O atacante gasta um pouco de largura de banda a montante e recebe de volta um múltiplo dela direcionado a você. Isso é um problema de largura de banda e pacotes por segundo, e é categoricamente impossível de resolver no seu servidor: no momento em que o seu kernel poderia descartar o pacote, o cano que o transporta já está cheio. Nada em nftables ajuda aqui. Só a capacidade acima de você resolve.
Esgotamento de estado de Layer 4. Floods de SYN, ACK e de conexões dimensionados não para encher o cano, mas para encher uma tabela — o backlog de SYN do kernel, a tabela conntrack, a fila de aceitação da sua aplicação. A largura de banda pode ser trivial: algumas centenas de Mbps derrubam uma máquina sem ajustes, enquanto o gráfico do lado da hospedagem parece uma tarde tranquila. Essa camada é genuinamente metade sua: é sobrevivível com tcp_syncookies, um nf_conntrack_max dimensionado corretamente, e limites por origem — e não é sobrevivível sem eles.
Aplicação de Layer 7. Floods HTTP compostos por requisições individualmente válidas — handshakes TLS reais, strings de User-Agent críveis, às vezes navegadores reais — direcionados a qualquer coisa cara no seu site: busca, login, carrinho, uma página de listagem baseada em banco de dados. A classe HTTP/2 Rapid Reset mostrou como bastam poucos megabits quando cada requisição custa mais ao servidor do que ao cliente. Um appliance de scrubbing não consegue ver dentro de uma sessão TLS que não termina, então essa camada é tratada por regras na borda ou pelo seu próprio reverse proxy — nunca por capacidade volumétrica bruta.
| Camada | Ataque típico | Tamanho típico | Onde deve ser parado | Corrigível na sua máquina? |
|---|---|---|---|---|
| Volumétrico L3/L4 | UDP flood, amplificação DNS/NTP/memcached | 5 Gbps – 1+ Tbps | A montante, na borda | Não — o cano enche primeiro |
| Esgotamento de estado L4 | SYN / ACK flood, esgotamento de conntrack | 0.1 – 10 Gbps | Borda, mais ajuste de kernel | Parcialmente — syncookies, dimensionamento de conntrack |
| Aplicação L7 | Flood de requisições HTTP(S), slow POST, Rapid Reset | Geralmente abaixo de 1 Gbps | Regras na borda ou seu reverse proxy | Sim — rate-limit, desafio, cache |
Qual é o tamanho real de um ataque, honestamente?
Aproximadamente nove em cada dez ataques que atingem um pequeno servidor offshore vêm de um booter ou stresser — um serviço por assinatura que custa de $10 a $30 por mês e revende capacidade de amplificação por minuto. Eles entregam algo entre 5 e 50 Gbps em rajadas de alguns minutos, e é exatamente isso que um servidor Minecraft, uma rede IRC, um relay Tor, um fórum com um ex-moderador irritado ou um lobby de jogo competitivo realmente enfrentam. Essa faixa é totalmente sobrevivível, e também é totalmente suficiente para derrubar um VPS de $5 desprotegido.
A próxima faixa acima — 100 a 400 Gbps vindos de uma botnet alugada — é o que chega quando alguém tem uma implicância específica e orçamento para isso. É raro contra alvos pequenos e rotineiro contra propriedades de apostas, streaming e conteúdo adulto. Acima disso ficam os eventos de recorde relatados pelos grandes fornecedores de mitigação, hoje medidos em múltiplos terabits por segundo e centenas de milhões de requisições por segundo; os números trimestrais do Cloudflare Radar são a referência pública usual. Você quase certamente não é o alvo pretendido de um desses.
Ainda assim você pode ser vítima colateral de um deles, e essa é a parte que ninguém coloca no cartão do plano: o dano colateral viaja por prefixo. Se uma hospedagem aplica blackhole com granularidade /24 — muitas fazem isso, porque é o menor prefixo que a maioria das operadoras aceita para RTBH — então um ataque direcionado a um endereço da sua sub-rede derruba todos os endereços dela. O seu uptime depende dos inimigos de um estranho. A margem de capacidade é o que evita que essa decisão precise ser tomada.
Os nossos próprios números, para calibração e não como alarde: 1 Tbps de scrubbing anycast L3/L4 dividido entre quatro pontos de presença, cada um capaz de absorver cerca de 300 Gbps sozinho, com detecção automática em até dois segundos. O maior evento que já absorvemos para um cliente foi acima de 600 Gbps contra um servidor de jogo, e as conexões dos jogadores não caíram. A arquitetura está documentada em mais detalhes na página de rede.
Incluído, por incidente ou por cota — o formato comercial importa
Existem três formas de vender mitigação, e elas geram faturas muito diferentes. Incluído: o custo já está embutido no plano, e um ataque não muda nada no que você paga. Por incidente: você é cobrado por cada evento mitigado, às vezes por hora de mitigação. Cota: um número de eventos por mês, ou uma cláusula de "uso justo" que deixa a hospedagem decidir quando você já teve o suficiente.
O modelo por incidente não é um golpe. O tráfego filtrado ainda atravessa o trânsito da hospedagem antes de ser descartado, e o trânsito é cobrado pelo percentil 95 ou contra uma taxa comprometida — uma campanha sustentada contra um cliente é um item de custo real na fatura de alguém. O problema não é justiça, é previsibilidade: sob uma campanha de duas semanas, uma hospedagem que cobra por incidente transforma um ataque contra você em uma fatura para você, o que é um segundo ataque com passos extras. Pergunte qual modelo se aplica antes de precisar saber.
A nossa posição, dita com clareza para que possa ser verificada: o escudo vem ativado por padrão em todo plano, do Starter de $8.50 ao Citadel de $299.50, sem opt-in, sem cobrança por incidente, sem cota mensal e sem cláusula de "uso justo" associada à mitigação. É a mesma malha no VPS mais barato e na maior máquina dedicada — veja os planos VPS e os níveis dedicados. O que muda de acordo com o nível é o uplink e o conjunto opcional de regras de Layer 7, não se você está defendido ou não.
Difusão anycast, e por que o tempo de detecção supera a capacidade de manchete
Um único centro de scrubbing tem um teto rígido: o trânsito que entra naquele único prédio. Ele também tem um custo de latência, porque durante a mitigação o tráfego de todo mundo é levado primeiro até aquele prédio — a razão pela qual algumas hospedagens ficam visivelmente mais lentas para usuários europeus no momento em que um ataque começa, e continuam assim até ele parar.
O anycast muda a aritmética antes mesmo de qualquer hardware entrar em ação. O mesmo prefixo é anunciado a partir de todos os pontos de presença, então uma botnet distribuída globalmente é dividida entre esses pontos apenas pela topologia da internet: um ataque de 600 Gbps originado de todo lugar chega como aproximadamente 150 Gbps em quatro lugares, em vez de 600 Gbps em um só. A difusão faz a maior parte do trabalho; o equipamento de scrubbing só precisa lidar com o que sobra depois que a geografia já dividiu o ataque.
O tempo de detecção é o número subestimado. Uma mitigação que entra em ação em dois segundos é invisível para uma sessão TCP; uma mitigação que entra em ação em sessenta segundos chega depois que os seus usuários já recarregaram a página duas vezes e foram embora, e depois que um lobby de jogo já esvaziou. Quando uma hospedagem informa a capacidade mas não a latência de detecção, peça o segundo número — é ele que decide se os seus usuários chegaram a perceber alguma coisa.
Se você traz o seu próprio prefixo, o blackholing se torna um bisturi que você segura, em vez de algo que é feito com você. Nossas comunidades BGP cobrem de-preferência por operadora (cs:100:carrier), prepend regional (cs:200:region) e blackhole seletivo (cs:666:prefix), então você pode aplicar null-route a um endereço sob ataque enquanto o resto da sua alocação continua servindo. Isso é blackholing usado corretamente: cirúrgico, breve, e uma decisão sua.
A complicação offshore: um proxy dos EUA na frente anula o propósito
O conselho padrão em todo fórum é "simplesmente coloque atrás da Cloudflare, o plano grátis já resolve". Para um site comum, é um bom conselho. Se você escolheu uma hospedagem offshore por razões jurisdicionais, esse conselho reimporta silenciosamente tudo o que você deixou para trás: uma empresa constituída nos EUA passa a terminar o seu TLS e ver o seu tráfego em texto claro, recebe reclamações de abuso e de direitos autorais e age sobre elas segundo a sua própria política, mantém uma conta vinculada a um endereço de e-mail e geralmente a um método de pagamento, e pode ser intimada por um processo legal dos EUA. A sua hospedagem ignorar um aviso de DMCA vale muito pouco quando o seu CDN o cumpre — os mecanismos estão em o explicador sobre ignorar o DMCA e a exposição jurisdicional em o guia 14-Eyes.
Um proxy também não esconde a sua origem, a menos que você configure o firewall da origem para aceitar apenas os prefixos do proxy e mantenha isso assim. Mesmo nesse caso, o endereço vaza pelo histórico de DNS passivo, pelos logs de transparência de certificados se a origem já respondeu TLS no seu próprio nome, por e-mails enviados diretamente da máquina, por um registro A antigo que nunca foi removido, e por qualquer página de erro que ecoe o hostname do próprio servidor. Acessos diretos à origem são como sites "protegidos" acabam sendo derrubados de qualquer forma. O manual de hospedagem anônima percorre toda a superfície de vazamento.
Se você quer uma camada de proxy sem o custo jurisdicional, rode-a você mesmo: uma segunda instância pequena na mesma jurisdição ou em uma compatível, terminando o TLS sob a sua própria chave, com o firewall da origem aceitando apenas aquele endereço. Você mantém o cache e a filtragem de requisições, e nenhum terceiro entra na cadeia de confiança. As duas máquinas ficam atrás da mesma malha de scrubbing, então o proxy não é um novo alvo fácil.
O que ainda é responsabilidade sua, na máquina
O scrubbing a montante protege o cano. Ele não ajusta o seu kernel, e a faixa de esgotamento de estado é onde um servidor sem ajustes morre para um ataque que a rede mal registrou. A lista curta, na ordem em que compensa: ative net.ipv4.tcp_syncookies e aumente net.ipv4.tcp_max_syn_backlog (os parâmetros estão documentados na referência ip-sysctl do kernel); dimensione nf_conntrack_max para a quantidade de conexões que você realmente espera, ou use notrack para tráfego de jogo UDP de alta taxa, para que a tabela nunca seja consultada; adicione limites de taxa por origem em nftables em vez de contar com a borda para ser cirúrgica.
No lado da aplicação, limit_req e limit_conn no nginx não custam nada e param a maioria dos floods de L7 que não são deliberadamente moldados para parecer humanos. Faça cache de tudo que pode ser cacheado, porque o melhor alvo de um atacante é sempre aquela página que você gera a partir do banco de dados a cada requisição. Mantenha o SSH e qualquer painel de controle fora do endereço que serve a carga pública, ou atrás de uma allowlist.
Uma direção que as pessoas esquecem: não se torne um refletor. Um resolvedor DNS aberto, um daemon NTP mal configurado ou um memcached exposto na sua máquina fazem de você parte do ataque de amplificação de outra pessoa, e abuso de saída é tratado de forma muito mais severa do que o de entrada — o tempo de resposta publicado na nossa AUP é null-route e suspensão em até duas horas. Floods de entrada são algo que acontece com você; floods de saída são algo pelo qual você é responsável.
A checklist que vale a pena rodar antes de comprar
Nove perguntas, na ordem que separa as hospedagens mais rápido. Qual é a capacidade de mitigação, e ela é por ponto de presença ou agregada? Está incluída no preço do plano ou é vendida por IP? Existe cobrança por incidente, ou uma cota de eventos mitigados por mês? Qual é a latência de detecção? A filtragem de Layer 7 está disponível, e em quais níveis? A partir de que limiar e por quanto tempo vocês aplicam null-route, e vocês avisam quando isso acontece? A mitigação muda o meu roteamento ou a minha latência enquanto está ativa? A proteção está no endereço que recebo por padrão? E — a que quase ninguém pergunta — o que é retido sobre o meu tráfego enquanto a mitigação está em execução?
Essa última pergunta importa mais nesse mercado do que em qualquer outro. Scrubbing significa que algo a montante está olhando para os seus pacotes. Pergunte o que sobrevive ao evento. A nossa resposta, e ela não muda durante um ataque: a detecção roda sobre contadores agregados na borda — pacotes e bits por segundo, por prefixo — não sobre registros retidos por fluxo, e a posição permanente de nenhum netflow, nenhum PCAP e nenhum espelhamento de NIC, publicada na política de privacidade, se aplica durante a mitigação exatamente como no resto do tempo. Uma hospedagem que não consegue responder a isso está te dizendo alguma coisa.
Se as respostas vierem rasas, a alternativa é barata: compre um mês do menor plano, aponte uma sonda de monitoramento para ele e pergunte diretamente ao suporte o que acontece quando a máquina é atingida. Aqui não há contrato nem taxa de configuração, então uma hospedagem que foge da pergunta por escrito custa apenas $8.50 para você descobrir isso. Implante um Starter, ou leia VPS versus dedicado se a carga de trabalho for grande o suficiente para que a resposta mude o nível.
