O que um WHOIS “sem nada” realmente significa

Desde 28 de janeiro de 2025, o RDAP é a fonte definitiva 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 diz que registradores podem processar informações adicionais, inclusive dados de pagamento, e devem considerar pedidos de divulgação devidamente formulados.

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.

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. 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.

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.

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.

Em registros DNS marcados como “proxied”, a Cloudflare responde com um IP anycast em vez do IP da origem. 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.

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 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

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

Checklist de lançamento

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.