Ocultando o IP do Servidor de Origem

"Devo colocar um CDN na frente do servidor?" é a primeira pergunta que a maioria das pessoas faz depois de comprar um servidor offshore, e ela não tem uma resposta única, porque na prática são duas perguntas vestindo a mesma roupa. Absorver um ataque e permanecer inencontrável são problemas diferentes, com soluções diferentes, e o arranjo que resolve um pode desfazer o outro silenciosamente.

A confusão sai cara nos dois sentidos. Há quem coloque um grande CDN americano na frente de um conteúdo escolhido justamente pela hospedagem com DMCA ignorado, devolvendo a um intermediário exatamente o tipo de central de reclamações que tentava evitar. Outros ignoram tudo isso, são atingidos por uma inundação na camada de aplicação que a filtragem de rede nunca foi projetada para enxergar, e concluem que a proteção contra DDoS era mentira. Este guia separa os dois problemas, explica o que cada camada realmente faz, e dedica a maior parte do texto à parte que decide o resultado de qualquer forma: as seis maneiras pelas quais um endereço de origem vaza mesmo quando tudo o mais está configurado corretamente.

Dois problemas que parecem um só

Tudo o que você coloca na frente de um servidor está fazendo um de dois trabalhos: manter um ataque afastado dele, ou manter o endereço dele desconhecido. Eles se sobrepõem o suficiente para serem confundidos e diferem o suficiente para que resolver o errado seja desperdício de dinheiro.

Leia a última linha duas vezes, porque é ela que pega as pessoas de surpresa. Tudo o mais nesta página é engenharia. Aquela linha não é.

O que seu host já faz, e onde isso para

A filtragem de camada 3 e camada 4 vem incluída em todos os planos que vendemos, sem custo extra, e roda na borda da rede em vez de no seu servidor — o único lugar onde ela pode funcionar, já que um link saturado não é corrigido por nada rodando atrás dele. A largura de banda não é medida, então um ataque não vira uma fatura. Para a grande maioria do que as pessoas chamam de "um DDoS", essa é toda a história.

O que ela não enxerga é o outro tipo. Quinhentas requisições por segundo a um endpoint de busca vindas de quarenta mil endereços residenciais não é tráfego malformado; é tráfego. Conexões Slowloris que gotejam um cabeçalho a cada poucos segundos são, individualmente, educadas. Um formulário de login martelado com corpos POST reais é indistinguível, no nível do pacote, de uma segunda-feira movimentada. Nenhum filtro de pacotes ajuda, porque não há nada de errado com os pacotes.

Há uma direção de tráfego sobre a qual agimos, e vale dizer isso com clareza: ataques e spam em massa originados da nossa rede podem ser null-routed para manter o resto da infraestrutura saudável. Isso é uma medida operacional, não uma medida sobre conteúdo — a distinção que nosso guia de hospedagem com DMCA ignorado detalha melhor.

O que um CDN esconde, e a central de reclamações que você herda

O mecanismo é simples e genuinamente eficaz. Seu domínio resolve para os endereços do provedor, os clientes se conectam ali, e o provedor busca o conteúdo na sua origem. O endereço real nunca aparece na conexão do cliente, então ninguém que conheça apenas o domínio consegue atacá-lo. É o mesmo truque que faz o CDN fronting funcionar para proxies resistentes à censura: um censor vê tráfego indo para um endereço que ele não pode se dar ao luxo de bloquear.

Três coisas chegam junto, e nenhuma delas está escondida nas letras miúdas:

• A borda termina seu TLS. O tráfego é texto puro dentro da rede do provedor por design — é assim que o cache e a filtragem funcionam. O que quer que seus usuários digitem chega a um terceiro antes de chegar até você.
• Um canal de abuso que não existia antes. Reclamações podem ser registradas diretamente contra o CDN, e um CDN responde a elas: encaminhando para você, identificando seu provedor de hospedagem, ou encerrando sua conta. Se o motivo de você estar offshore é que reclamações não vão a lugar nenhum, colocar um intermediário americano na frente reconecta a corrente que você pagou para romper.
• Uma conta. Endereço de e-mail, forma de pagamento, muitas vezes um número de telefone, vinculados ao seu domínio e mantidos indefinidamente. Mais sobre isso adiante, porque geralmente é o elo mais fraco de todo o arranjo.

Nada disso torna um CDN errado. Torna a decisão algo com dois lados: excelente para uma loja ou uma aplicação com usuários reais e pressão real de camada 7, ativamente contraproducente para publicações que atraem notificações de remoção. Nossa própria resposta à pergunta na página de hospedagem com DMCA ignorado sempre foi a versão curta disto: para resistir a remoções, use a filtragem de rede que você já tem e dispense o CDN.

As seis maneiras pelas quais um endereço de origem vaza de qualquer jeito

Esta é a seção que importa, porque ocultação não é um produto que se compra — é uma propriedade que você mantém ou perde, geralmente em poucos dias, para uma de seis coisas. Origens são encontradas todos os dias atrás de configurações de CDN perfeitamente corretas.

• Logs de Certificate Transparency. Todo certificado publicamente confiável emitido para o seu domínio é publicado em logs públicos, permanentes e pesquisáveis em poucos minutos. Eles não publicam seu endereço; publicam seus nomes de host — staging, mail, vpn, aquele subdomínio que você configurou uma vez em 2024. Cada um é um candidato a ser resolvido, e um único registro que não aponte para a frente encerra o exercício.
• Histórico de DNS. Serviços de DNS passivo arquivam todo endereço para o qual seu domínio já resolveu. Migrar para trás de um CDN depois não despublica o que já foi registrado — a ocultação precisa começar antes de o domínio resolver pela primeira vez, ou você precisa de um endereço novo, não de uma frente nova.
• Registros que não podem ser proxeados, e os que você esqueceu. Os servidores de e-mail (MX) precisam apontar para algo alcançável. O mesmo vale para um registro AAAA esquecido quando você só proxeou o IPv4, um antigo hostname de FTP ou painel, um curinga, ou aquele host de desenvolvimento "temporário" que já tem três anos.
• Qualquer coisa que o servidor envie. O e-mail vindo da origem carrega o endereço dela nos cabeçalhos Received — uma mensagem de redefinição de senha é uma autodenúncia. Webhooks, buscas de imagens de saída, prévias de links, pingbacks, verificações de atualização e relatores de falhas, todos partem do endereço real, e qualquer um que consiga fazer sua aplicação falar com um host que controla descobre esse endereço.
• Varredura de toda a internet. Todo endereço IPv4 é escaneado e indexado continuamente por serviços públicos, e os resultados são consultáveis em segundos. Se sua origem responde na porta 443 com seu certificado, ou serve sua homepage para qualquer cabeçalho Host, encontrá-la é uma única consulta contra um hash do corpo da página, uma impressão digital de certificado ou um hash de favicon. É assim que a maioria das origens é encontrada, e não custa nada a quem procura.
• A aplicação falando sobre si mesma. URLs absolutas e redirecionamentos contendo o endereço bruto, endpoints de status ou métricas deixados abertos, stack traces verbosos citando hosts internos, cabeçalhos que revelam o backend, e o virtual host padrão que alegremente serve seu site para quem quer que pergunte pelo endereço.

Travando a origem para que só a frente consiga alcançá-la

Ocultação que depende de ninguém adivinhar o endereço não é ocultação. O arranjo só se sustenta quando a origem se recusa a falar com qualquer um além da frente, de modo que um endereço vazado seja um incômodo, não um evento.

• Negar por padrão, depois liberar a frente. Aceite as portas 80 e 443 apenas das faixas de endereço publicadas pelo provedor, e atualize essa lista automaticamente — as faixas mudam, e uma lista desatualizada falha aberta ou falha fechada no pior momento possível. Tudo o mais, incluindo o SSH, pertence a um túnel ou a um endereço de gestão, como no nosso checklist de hardening da primeira hora.
• Autentique a frente. Certificados de cliente entre o CDN e sua origem — geralmente chamados de authenticated origin pulls — fazem com que até um endereço correto somado a um cabeçalho Host correto não consiga nada sem o certificado.
• Melhor ainda: nenhuma porta de entrada. Um túnel apenas de saída da origem até a borda, seja o conector do próprio CDN ou WireGuard até um nó que você administra, faz com que a origem nunca escute em uma interface pública. Varreduras não encontram o que não responde, e esta é a versão mais forte do arranjo, de longe.
• Um único virtual host, um único cabeçalho Host. O servidor padrão não deve devolver nada útil. Se o seu site carrega quando acessado pelo endereço, um scanner vai encontrá-lo em uma semana.
• Tire o e-mail da origem web. O e-mail precisa ser alcançável e precisa se identificar; mantenha-o em uma máquina própria, como pressupõe o guia de servidor de e-mail.
• Verifique de fora. Toda verificação desta lista não significa nada quando rodada a partir do próprio servidor. Teste a partir de uma rede que não seja sua.

Seu próprio nó frontal em vez de um CDN

A terceira opção fica de lado porque não tem orçamento de marketing: um VPS pequeno como face pública, um túnel criptografado de volta até a máquina que guarda os dados, e nginx ou HAProxy repassando o tráfego entre eles. De fora, parece qualquer servidor web. O de verdade está em outro lugar, sem nenhuma porta de entrada.

O que você ganha é ocultação sem mais ninguém no arranjo — nenhuma conta de terceiros, nenhuma central de reclamações externa, nenhum estranho terminando seu TLS. Você também ganha uma separação de jurisdições difícil de comprar de outra forma: a frente onde os usuários estão, os dados onde a lei lhe convém, escolhidos entre nossas sete localizações. E como nenhuma identidade foi vinculada no cadastro, a frente é descartável — um endereço queimado é substituído em minutos, não negociado.

O que você não ganha é capacidade anycast. Um nó tem a capacidade de um nó, e embora nossa filtragem de rede o proteja exatamente como protege qualquer outro servidor, um ataque volumétrico genuinamente grande é uma disputa de largura de banda que uma rede global vence. O posicionamento honesto: um nó frontal é a resposta certa para esconder um backend pesado ou caro — um array de armazenamento, uma máquina com GPU, um servidor de e-mail, um banco de dados — e para separar jurisdições. Não é substituto para um CDN sob pressão sustentada de camada 7.

Escolhendo, em uma tabela

A conta costuma ser o elo mais fraco

Considere o que acontece quando a infraestrutura é perfeita e a papelada não é. O servidor foi pago em Monero, sem documentos de identidade e sem endereço de e-mail — o arranjo descrito nas nossas páginas de hospedagem sem KYC. Depois, uma conta de CDN é aberta com um cartão, um endereço pessoal e um número de telefone, listando o domínio que ela protege. Essa conta é um registro de identidade mais forte e mais durável do que qualquer coisa no servidor, mantido por uma empresa que responde a intimações, e ela desfaz por completo a privacidade do pagamento.

A correção não é complicada, só fácil de esquecer: se o objetivo é o anonimato, ou a frente pertence a você, ou a conta na frente dela é tão descartável e tão inatribuível quanto o servidor atrás dela. O OpSec para Servidores trata dessa disciplina com propriedade, e nossa resposta honesta sobre anonimato offshore é direta sobre quais elos da corrente costumam quebrar primeiro. Quase nunca são os técnicos.

Auditando sua própria exposição em dez minutos

Cada item abaixo é algo que uma parte interessada verificaria nos primeiros minutos. Rode-os você mesmo, a partir de uma máquina que não seja o servidor, antes de precisar das respostas.

• Liste todo hostname que você já certificou. Busque seu domínio raiz em um mecanismo de busca de Certificate Transparency e resolva cada resultado. Qualquer coisa que não aponte para a frente é um vazamento, incluindo hosts que você não usa mais.
• Leia seu próprio histórico de DNS. Uma consulta de DNS passivo mostra os endereços para os quais seu domínio resolveu antes do CDN. Se a origem de ontem ainda é a origem de hoje, a ocultação nunca foi real.
• Pergunte diretamente à origem. curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — se o site responder, seu firewall não está restringindo a frente, e qualquer um com um endereço candidato pode confirmar isso em uma única requisição.
• Pergunte a ela sem educação. curl -skI https://198.51.100.10/ não deveria devolver nada reconhecível. Um virtual host padrão servindo sua homepage é o erro isolado mais comum desta página.
• Verifique cada tipo de registro, não só o A. dig +short AAAA example.com, dig +short MX example.com, e o mesmo para cada subdomínio que os logs de transparência revelaram. IPv6 deixado sem proxy é um clássico.
• Mande um e-mail para si mesmo pela aplicação. Dispare uma redefinição de senha e leia a cadeia completa de Received. Se o endereço da origem estiver ali, também está em toda mensagem que você já enviou.
• Confirme que as portas estão fechadas. A partir de uma rede não relacionada, nmap -Pn -p80,443 198.51.100.10 deveria mostrar "filtered" (filtrada), não "open" (aberta).
• Pesquise nos scanners. Procure a impressão digital do seu certificado e o hash do favicon da sua homepage em um índice público de varredura da internet. Se sua origem está indexada, é assim que ela será encontrada.

Quando o endereço já está queimado

Assuma que ele continua queimado. Um endereço que já apareceu em DNS passivo e em índices de varredura está em registro público permanente, e nenhuma mudança de configuração o retira de lá. A resposta é mecânica, não engenhosa.

• Corrija o vazamento primeiro. Trocar para um endereço novo sem fechar o buraco reproduz a situação em poucos dias, e você terá gasto uma migração para não aprender nada.
• Depois, faça a rotação. Implante um substituto — em uma jurisdição diferente, se o motivo foi legal e não técnico — restaure, e faça a virada. Como nenhuma identidade foi vinculada ao primeiro servidor, isso é um recomeço, não uma negociação, o que é o retorno prático e nada glamouroso de comprar servidores sem histórico de conta.
• Prepare a virada antes da emergência. Um TTL de DNS curto, uma configuração que você consiga reimplantar a partir de um repositório e uma restauração testada transformam uma tarde ruim em vinte minutos. Ninguém organiza isso durante um ataque.
• Aposente o endereço antigo direito. Não deixe o servidor antigo estacionado no endereço antigo servindo o mesmo conteúdo; isso é uma confirmação ao vivo para quem estiver observando, e mantém o registro atualizado.

A versão curta

A filtragem em nível de rede cuida de ataques volumétricos, vem com o servidor e não custa nada a mais. Um CDN cuida da camada de aplicação e esconde a origem, ao preço de um intermediário que termina seu TLS, responde a reclamações e sabe quem você é. Seu próprio nó frontal compra ocultação sem o intermediário, mas não capacidade global. A jurisdição decide a questão legal, e nenhum dos três resolve isso. E todos eles são desfeitos por um único registro sem proxy, um único e-mail vindo da origem, ou um único virtual host padrão.

Decida pelo objetivo, não pelo hábito, e depois gaste os dez minutos na auditoria — ela encontra mais exposição real do que qualquer upgrade. Se você quer a arquitetura sem o terceiro, um VPS pequeno como frente e o trabalho de verdade em hardware dedicado atrás dele é o arranjo que mais vemos entre quem já foi encontrado uma vez.