< the skull HOSPEDAGEM PRIVADA NA WEB ABERTA ================================ 2026-09-13 Figura 1 — A identidade pública é apenas a camada central; intermediários e infraestrutura ainda observam partes diferentes da operação. O que um WHOIS “sem nada” realmente significa ============================================= Desde 28 de janeiro de 2025, o RDAP é a fonte definitiva [1] para dados de registro de domínios genéricos, substituindo o WHOIS. Um resultado público com campos “REDACTED” ou quase vazios normalmente significa que a publicação foi limitada; não significa que os dados deixaram de existir. A política da ICANN em vigor desde 21 de agosto de 2025 permite ou exige redação de dados pessoais em certas situações, mas também prevê processos de solicitação de divulgação e retenção. A própria política [2] diz que registradores podem processar informações adicionais, inclusive dados de pagamento, e devem considerar pedidos de divulgação devidamente formulados. REGRA DE OURO Privacidade pública responde “o que um curioso encontra?”. Anonimato contra provedores responde “quem pode ligar a conta a mim?”. São problemas diferentes. Este guia otimiza o primeiro e reduz — sem eliminar — o segundo. Modelo de ameaça ---------------- Antes de comprar qualquer serviço, defina contra quem você está se protegendo. A EFF recomenda começar por ativos, adversários, impacto, probabilidade, custo aceitável e aliados. A pergunta “quero que ninguém saiba” precisa virar uma lista verificável. Adversário O que ele usa Meta realista Proteção esperada Visitante curioso RDAP, DNS, cabeçalhos e conteúdo Ocultar nome, endereço e origem Alta Pesquisador OSINT / doxxer Histórico DNS, commits, metadados, nomes de usuário Evitar correlações acidentais Média a alta, se houver disciplina Registrador, host, CDN e pagamento Cadastro, acesso, faturamento e logs Minimizar dados e pontos de confiança Baixa a média Autoridade com processo legal Pedidos de divulgação, apreensão e cooperação Nenhuma promessa de invisibilidade Fora do objetivo deste guia Passo 1 — Crie uma identidade operacional separada ================================================== O maior vazamento raramente é criptográfico. É a reutilização: o mesmo nome de usuário, avatar, e-mail de recuperação, chave SSH, conta de Git, estilo de biografia ou horário de publicação que você já usa com seu nome real. · Escolha um pseudônimo e nomes de usuário que nunca tenham aparecido nas suas contas pessoais. · Crie um e-mail inicial independente do domínio; assim, a recuperação não depende de um domínio que pode expirar ou ser suspenso. · Use uma senha única e longa, guardada em um gerenciador, e ative TOTP ou chave física. Evite SMS quando houver alternativa. · Mantenha um perfil de navegador ou sistema separado. Para painéis web, use Tor Browser quando o serviço permitir; nunca entre em contas pessoais na mesma sessão. · Não invente dados onde o contrato exigir dados corretos. Prefira um serviço legítimo de privacidade/proxy ou um modelo fiduciário que publique os dados dele por contrato. · Documente a separação: e-mail, contas, chaves, método de recuperação, data de renovação e quais empresas conhecem cada dado. O Tor Browser reduz a exposição do IP, mas não garante anonimato perfeito [3]. Ele protege apenas aplicativos corretamente configurados para usar Tor; preencher um formulário com nome, telefone ou e-mail pessoal entrega a identidade ao serviço de qualquer maneira. Passo 2 — Escolha a estratégia de domínio ========================================= Há três modelos comuns. A diferença decisiva não é estética: é quem aparece como titular e quem conserva poder jurídico e operacional sobre o domínio. Modelo O que aparece no RDAP Quem controla o domínio Trade-off Registrador com redação Campos pessoais redigidos; alguns dados técnicos permanecem Você é o titular Bom equilíbrio; registrador ainda conhece seus dados Serviço privacy/proxy Dados do serviço ou contato intermediado Você mantém direitos conforme contrato Leia regras de revelação, transferência e abuso Modelo fiduciário / trustee O intermediário figura como titular O intermediário é o registrante formal Escudo público mais forte; maior risco de dependência e disputa Checklist antes de registrar ---------------------------- · A extensão escolhida permite privacidade? Políticas variam por TLD e podem mudar. · A privacidade está incluída ou é opcional? O país/estado continua público? · Existe um canal de e-mail intermediado sem revelar seu endereço real? · Quem é o registrante formal? Como funciona transferência, desbloqueio e código de autorização? · Em que casos o serviço pede identificação, suspende o domínio ou divulga dados? · Como você recupera a conta sem telefone pessoal? O contrato exige informações corretas? Leitura crítica de serviços de privacidade ------------------------------------------ Os exemplos abaixo não são endossos. Eles mostram por que a página de vendas deve ser lida ao lado dos Termos e da Política de Privacidade. Serviço O que oferece publicamente O que o contrato/política revela Njalla Domínio, VPS, DNS e uma camada de privacidade. O serviço figura como registrante formal por padrão; exige e-mail ou XMPP atualizado. Isso reduz exposição pública, mas transfere dependência jurídica ao intermediário. 1984 Hosting VPS na Islândia, privacidade de domínio quando o TLD permite e pagamentos em Bitcoin/Monero. A política informa coleta de IP, nome, faturamento e contato; logs de acesso podem ser retidos e dados podem ser divulgados quando houver obrigação legal. OrangeWebsite Hospedagem na Islândia e discurso de minimização de dados. A política diz coletar o mínimo, mas lista nome, endereço, telefone, e-mail, histórico e forma de pagamento entre os dados possíveis. Cloudflare Reverse proxy e Tunnel capazes de ocultar o IP da origem do público. É um intermediário de infraestrutura, não um serviço de anonimato. A conta e o tráfego passam a depender de mais um ponto de confiança. SINAL DE ALERTA Se a página inicial promete “no logs”, mas a política permite registrar IP, faturamento, suporte ou acesso à rede, trate a política como a descrição mais importante. “Privacidade” quase sempre significa minimização e limites de divulgação — não ausência total de registros. Passo 3 — Trate o pagamento como um identificador ================================================= Cartão, PayPal, transferência e lojas de aplicativos criam registros no processador de pagamento, mesmo quando o host não guarda o número do cartão. Criptomoeda também não é sinônimo de anonimato. O próprio Bitcoin.org lembra que transações são públicas, rastreáveis e permanentes, e que endereços podem ser ligados a identidades quando usados para comprar serviços. · Use apenas meios de pagamento legais e compatíveis com os termos do fornecedor. · Decida se sua ameaça é exposição pública ou correlação pelo fornecedor. Para a primeira, um pagamento comum pode ser aceitável; para a segunda, ele é um elo forte. · Não reutilize endereços de recebimento publicados no site para pagar infraestrutura. · Guarde comprovantes e datas de renovação de forma criptografada: perder o domínio por falta de pagamento é mais provável do que uma quebra criptográfica. Passo 4 — Prefira um site estático e uma origem silenciosa ========================================================== Quanto menos componentes públicos, menor a superfície de ataque e menor a quantidade de dados operacionais. Para um blog, uma pilha enxuta atende a quase tudo sem banco de dados, painel administrativo aberto ou plugins de terceiros. PILHA DE REFERÊNCIA Pelican (Python) para gerar HTML estático • Nginx ligado apenas a 127.0.0.1 • VPS de um fornecedor cuja política você leu • Cloudflare Tunnel ou reverse proxy equivalente • DNS separado • backup local criptografado. O visitante recebe um site normal da surface web; a origem não precisa aceitar conexões web da internet. Título: Diagrama mostra visitante conectado ao proxy ou túnel, que encaminha para um ser - Descrição: Diagrama mostra visitante conectado ao proxy ou túnel, que encaminha para um servidor Nginx estático; registrador, operador e administração ficam em um caminho separado. Figura 2 — Arquitetura sugerida: publicação pública por proxy/túnel e administração por um canal separado. Em registros DNS marcados como “proxied”, a Cloudflare responde com um IP anycast em vez do IP da origem [4]. Com Tunnel, o agente no servidor cria conexões somente de saída; a origem pode bloquear tráfego de entrada. Isso esconde o endereço da origem do público, mas a Cloudflare continua sabendo qual conta e qual origem estão conectadas. Passo 5 — Configure o servidor em uma ordem segura ================================================== Use Debian estável ou outra distribuição com atualizações previsíveis. A sequência importa: primeiro garanta acesso de recuperação pelo console do fornecedor; depois crie e teste uma conta sem privilégios permanentes; só então feche portas. 1\. Atualize e crie um usuário administrativo --------------------------------------------- sudo apt update sudo apt full-upgrade sudo apt install nginx unattended-upgrades ufw sudo adduser publisher sudo usermod -aG sudo publisher Copie uma chave SSH nova — não reutilizada em projetos pessoais — para o usuário publisher. Abra uma segunda sessão e confirme que a chave funciona antes de tocar na configuração do SSH. 2\. Desative login direto de root e senhas ------------------------------------------ Crie /etc/ssh/sshd\_config.d/99-site.conf com o conteúdo abaixo. Substitua publisher se usar outro nome. PermitRootLogin no PasswordAuthentication no KbdInteractiveAuthentication no AllowUsers publisher Valide a sintaxe antes de recarregar: sudo sshd -t && sudo systemctl reload ssh 3\. Sirva o site apenas em localhost ------------------------------------ Gere o site localmente e envie apenas a pasta de saída. Um bloco mínimo do Nginx pode ouvir em 127.0.0.1:8080: > server { > listen 127.0.0.1:8080; > server\_name \_; > root /srv/private-site/output; > index index.html; > location / { try\_files $uri $uri/ =404; } > add\_header X-Content-Type-Options nosniff always; > add\_header Referrer-Policy no-referrer always; > add\_header Permissions-Policy "camera=(), microphone=(), geolocation=()" > always; > add\_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; > style-src 'self' 'unsafe-inline'" always; > } 4\. Conecte o túnel e feche a entrada ------------------------------------- Instale o agente do túnel pelo repositório e pela documentação atual do fornecedor; publique o hostname para http://127.0.0.1:8080. Teste o domínio por uma rede externa. Depois, com o console de emergência confirmado, aplique política de firewall que negue entrada e permita saída. Se também transportar SSH pelo túnel, proteja-o com autenticação forte e uma política separada. EVITE SE TRANCAR PARA FORA Não ative “deny incoming” até confirmar: console web do provedor, login por chave em uma segunda sessão, túnel operacional e um caminho de recuperação. Fechar a porta 22 sem alternativa testada transforma uma melhoria de privacidade em indisponibilidade. Passo 6 — Não revele a origem antes do proxy ============================================ · Configure o proxy/túnel antes de criar qualquer A ou AAAA público apontando para o VPS. Bancos de DNS histórico podem preservar erros por anos. · Não crie subdomínios óbvios como origin., direct., cpanel. ou server. apontando diretamente para a máquina. · Não rode e-mail no mesmo IP. MX, SPF, DKIM e mensagens enviadas podem criar uma trilha independente até a infraestrutura. · Não use o IP da origem em monitores, status pages, repositórios, capturas de tela ou relatórios públicos. · Mantenha o serviço web ligado a localhost quando usar túnel. Se usar apenas reverse proxy, limite a origem aos endereços do proxy e autentique a conexão. · Não use o mesmo VPS, conta de nuvem, chave SSH ou snapshot de um projeto ligado ao seu nome real. Passo 7 — Limpe código, imagens e hábitos ========================================= Uma foto sem nome no arquivo ainda pode conter GPS, modelo da câmera, software, horário e miniaturas. Um repositório pode publicar o e-mail real em cada commit. Um identificador de analytics reutilizado pode ligar dois sites que nunca se mencionam. Git --- Ative “Keep my email addresses private” no GitHub e copie o endereço noreply fornecido pela plataforma. Configure-o apenas no repositório pseudônimo e audite todo o histórico antes do primeiro push público: git config user.name "Seu pseudônimo" git config user.email "ENDERECO\_NOREPLY\_FORNECIDO\_PELO\_GITHUB" git log --all --format='%an <%ae>' | sort -u A documentação do GitHub alerta que mudar a configuração afeta commits futuros; commits antigos continuam com o e-mail anterior. Se houver histórico comprometido, recrie o repositório antes de publicá-lo em vez de confiar apenas na nova configuração. Imagens e documentos -------------------- Inspecione antes, remova metadados para uma cópia nova e inspecione novamente. O ExifTool avisa que remover “tudo” não é garantia absoluta para todo formato; reexportar ou reencodar pode ser necessário. exiftool -a -G1 -s imagem-original.jpg exiftool -all= -o imagem-publica.jpg imagem-original.jpg exiftool -a -G1 -s imagem-publica.jpg Conteúdo e front-end -------------------- · Hospede fontes, CSS, JavaScript e imagens no próprio domínio. Recursos externos expõem seus leitores e criam dependências. · Evite comentários de terceiros, pixels de marketing e IDs de analytics que você já usa em sites pessoais. · Remova source maps, arquivos .env, backups, diretórios de build, nomes de usuário locais e caminhos absolutos. · Não publique fotos inéditas do seu ambiente, recibos, telas com fuso horário, notificações ou detalhes de rotina. · Assuma que vocabulário, horários e temas podem permitir análise estilométrica. Não existe ferramenta simples que torne um autor irreconhecível. Passo 8 — Lembre que HTTPS também deixa registros públicos ========================================================== HTTPS é obrigatório para proteger leitores, mas certificados públicos entram em logs de Certificate Transparency [5] consultáveis por qualquer pessoa. Isso pode revelar domínios e subdomínios presentes no certificado, mesmo quando o servidor de origem permanece oculto. · Use nomes de subdomínio neutros; não coloque nomes pessoais, ambientes internos ou fornecedores no hostname. · Considere um certificado wildcard obtido por DNS-01 quando muitos subdomínios internos não devem aparecer individualmente. O domínio-base continuará público. · Ative DNSSEC quando o registrador e o DNS autoritativo oferecerem suporte e você souber como recuperar uma troca de chaves malfeita. · Reveja MX e TXT: registros de verificação, SPF e ferramentas SaaS podem revelar serviços e contas relacionados. Passo 9 — Faça uma auditoria como um estranho ============================================= Título: Cinco cartões numerados mostram as verificações de RDAP, DNS, TLS, arquivos e có - Descrição: Cinco cartões numerados mostram as verificações de RDAP, DNS, TLS, arquivos e código antes da publicação. Figura 3 — Auditoria mínima antes de publicar: registro, DNS, certificados, arquivos e código. Consultas locais ---------------- dig +short A exemplo.net dig +short AAAA exemplo.net dig +short MX exemplo.net dig +short TXT exemplo.net dig +short NS exemplo.net curl -sSIk https://exemplo.net Verificações externas --------------------- · Abra o ICANN Lookup/RDAP e confirme exatamente quais campos estão públicos. · Pesquise o domínio e cada subdomínio em logs de certificados e em serviços de histórico DNS. · Pesquise o pseudônimo, e-mail, frases exatas do texto, favicon e nomes de arquivo em mecanismos de busca. · Abra o site em um navegador limpo e em outra rede; examine requisições externas no painel Network das ferramentas do desenvolvedor. · Baixe cada imagem e documento do site e execute uma inspeção de metadados na cópia publicada, não apenas no arquivo-fonte. · Peça a uma pessoa de confiança para repetir a investigação sem saber sua arquitetura. O que você conhece sobre si mesmo distorce a auditoria. Passo 10 — Mantenha a separação depois do lançamento ==================================================== Pseudonimato é uma rotina, não uma compra. Um único login em conta pessoal, commit antigo, renovação por um método identificável ou resposta de suporte assinada com seu nome pode ligar anos de trabalho. · Ative atualizações de segurança e verifique mensalmente o sistema, Nginx, gerador estático e agente do túnel. · Mantenha dois backups criptografados em locais diferentes e teste a restauração pelo menos a cada trimestre. · Registre renovações de domínio e VPS com antecedência; use lembretes fora do e-mail do próprio domínio. · Revise sessões ativas, tokens de API, chaves SSH e métodos de recuperação. Revogue o que não é usado. · Audite RDAP, DNS, Certificate Transparency e o histórico Git a cada mudança de fornecedor ou arquitetura. · Tenha um plano de incidente: tirar o site do ar, revogar tokens, trocar chaves, preservar evidências e comunicar leitores sem improviso. O que não fazer =============== Atalho tentador Por que falha Cadastrar dados falsos Pode violar contrato, impedir recuperação e causar suspensão. Use mecanismos legítimos de redação/proxy. Confiar apenas no WHOIS/RDAP DNS, certificados, pagamentos, Git, imagens e suporte criam trilhas independentes. Apontar o domínio à origem “só por alguns minutos” Coletores de DNS histórico podem guardar esse endereço. Comprar “bulletproof hosting” sem ler políticas Marketing não substitui contrato, jurisdição, histórico operacional e controle da conta. Desativar todos os logs Você perde capacidade de detectar invasão e depurar falhas. Minimize e retenha pelo tempo necessário; não apague para obstruir investigações. Misturar persona e vida real Correlação por usuário, e-mail, chave, navegador, linguagem ou horário costuma ser mais fácil que um ataque técnico. Checklist de lançamento ======================= ☐ Modelo de ameaça escrito e limites aceitos ☐ Pseudônimo, e-mail, senhas, MFA e recuperação separados ☐ TLD e contrato do registrador revisados ☐ RDAP testado após o registro ☐ Pagamento tratado como potencial identificador ☐ VPS/host nunca usado em projeto pessoal ☐ Chave SSH exclusiva e login por senha desativado ☐ Site estático sem painel público ☐ Origem em localhost ou restrita ao proxy ☐ Nenhum A/AAAA público aponta para a origem ☐ Sem e-mail no mesmo IP ☐ Git e histórico sem nome/e-mail pessoal ☐ Imagens e documentos auditados após publicação ☐ Sem analytics ou IDs reutilizados ☐ Certificados e subdomínios verificados em CT ☐ Backup criptografado e restauração testada ☐ Renovações e plano de incidente documentados Um site da surface web pode parecer e ser, para o público, completamente pseudônimo. O desenho mais sólido combina identidade operacional separada, registro com redação legítima, origem sem porta pública, conteúdo estático e auditorias recorrentes. Ainda assim, cada intermediário conserva uma parte do quebra-cabeça. A medida de sucesso não é “ninguém jamais saberá”. É: um visitante ou pesquisador não encontra seu nome, endereço, contas pessoais ou IP de origem; uma falha em uma camada não revela automaticamente todas as outras; e você sabe exatamente quais empresas continuam capazes de correlacionar a operação. Links: [1] https://www.icann.org/en/announcements/details/icann-update-launching-rdap-sunsetting-whois-27-01-2025-en [2] https://www.icann.org/en/contracted-parties/consensus-policies/registration-data-policy [3] https://support.torproject.org/tor-browser/security/using-tb-safely/ [4] https://developers.cloudflare.com/fundamentals/concepts/how-cloudflare-works/ [5] https://certificate.transparency.dev/howctworks/ < the skull