Como Configurar um Serviço Oculto Tor num VPS Anónimo

Manter um serviço oculto Tor a partir de uma ligação residencial funciona até ao dia em que a MEO renegoceia o contrato, o lease de IPv4 da NOS roda, ou alguém com um mandado judicial bate à porta. Toda a razão de ser de um endereço .onion é desligar o serviço da identidade no mundo físico, e esse desacoplamento desaba no instante em que o caminho de rede subjacente pode ser rastreado até um nome numa factura da EDP. É precisamente por isso que os operadores que se preocupam com durabilidade a longo prazo — nodos remotos de Monero, servidores BTCPay, pontes Matrix, espelhos de getmonero.org — alugam quase sempre um servidor privado virtual dedicado a um host que aceite pagamento sem verificação de identidade.

Este guia percorre todo o pipeline para 2026: escolher um fornecedor de VPS que aceite Monero ou dinheiro não marcado, pagar de forma anónima, endurecer uma instalação fresca de Debian 12 e levantar um serviço onion v3 que sobreviva a reinícios, actualizações de kernel e à ocasional varredura rDNS. Os exemplos assumem que se pretende expor um nodo Monero, mas a mesma receita aplica-se a qualquer serviço TCP — Lightning, SSH, IRC, ou um sítio estático que se prefira não associar ao nome legal. Quando o objectivo é alcançar um serviço como o MoneroSwapper através de um endpoint totalmente isolado, esta camada de rede é a peça que tem de estar certa antes de qualquer outra coisa importar.

Porque é que o alojamento anónimo importa para serviços ocultos

Um endereço onion Tor v3 deriva de uma chave pública ed25519. A garantia criptográfica é simples: quem alcance o .onion liga-se através de três saltos de relays Tor, e o ponto de encontro nunca aprende o IP do servidor. Até aqui, tudo sólido. O que o Tor não consegue fazer é esconder o facto de se ter pago 4,50 € por mês à Hetzner com um Visa associado ao nome do titular. No momento em que uma parte hostil correlaciona padrões de uptime ou uma fuga de configuração com o registo de facturação, toda a propriedade de anonimato do serviço evapora.

Os modelos de ameaça que justificam um VPS sem KYC são concretos e sobrepõem-se:

• Pressão por intimação judicial: Os hosts convencionais (Vultr, DigitalOcean, Hetzner, OVH) mantêm registos KYC e histórico completo de pagamentos. Perante uma intimação de grand-jury norte-americana, uma ordem de produção ao abrigo do Artigo 18 da CPCJ europeia, ou um pedido formal à CNPD ao abrigo do RGPD num quadro investigatório, esses registos são entregues com fricção mínima e sem divulgação pública.
• Discovery em litígios cíveis: Uma queixa por violação de privacidade, uma denúncia de direitos de autor ou uma disputa de marca podem obrigar um fornecedor a identificar o cliente por trás de um IP sem qualquer processo-crime envolvido. O discovery cível é mais rápido e barato que a acusação criminal.
• Fingerprinting na camada de rede: Mesmo quando um serviço oculto está bem configurado, fugas na camada aplicacional (banners de servidor, fonte NTP, versão do kernel em páginas de erro) podem correlacionar o .onion com um IP público. O pagamento anónimo garante que essa correlação não acaba a desembocar num nome.
• Resiliência operacional: Os hosts que já operam sem KYC conhecem a superfície de ameaça. Costumam aceitar receber uma denúncia de abuso sem destruir instantaneamente o VPS, porque esperam que os clientes tenham razões legítimas de privacidade em vez de tratarem cada queixa como verdade absoluta.

O ecossistema Monero é o exemplo canónico. Os nodos remotos públicos listados em monero.fail ou na lista de sementes por defeito do Cake Wallet correm rotineiramente como serviços onion v3 porque os operadores querem prestar serviço sem se tornarem alvos. A mesma lógica aplica-se a clientes de atomic swap, sidechains P2Pool e a implantações BTCPay do lado do comerciante. Depois de ter operado qualquer um destes, percebe-se rapidamente porque é que a combinação VPS-mais-onion é o padrão e não um extremo paranóico.

Escolher um fornecedor de VPS sem KYC em 2026

Depois das extensões da Regra de Viagem do GAFI em 2024 e da entrada em vigor do CARF (Crypto-Asset Reporting Framework) da UE a 1 de Janeiro de 2026, a lista de fornecedores que aceitam pagamento genuinamente anónimo encolheu mas não desapareceu. Os hosters europeus que sobreviveram são os que se posicionam explicitamente em torno da privacidade em vez de a oferecerem como pensamento secundário de marketing, e os fornecedores offshore que sobreviveram são os que têm um historial documentado de recusar fishing expeditions.

Três constantes definem um fornecedor utilizável neste mercado:

1. Aceita Monero (preferencialmente) ou Bitcoin por canais compatíveis com mistura, sem verificação de email para lá de um endereço operacional que receba uma ligação de uso único.
2. Não exige número de telefone, upload de documento de identificação, selfie, nem handshake 3-D Secure de cartão de crédito em qualquer ponto do fluxo de registo.
3. Opera a partir de uma jurisdição com postura defensável face à privacidade — Islândia, Suíça, Roménia, Bulgária, ou zonas offshore específicas — em vez de a partir de um caso-limite de Quinta Emenda nos Estados Unidos.

A tabela abaixo resume os fornecedores mais frequentemente citados por operadores Monero no final de 2025, com o preço típico do nível de entrada e os principais compromissos. Os preços flutuam com o câmbio XMR/EUR; tratem-nos como valores aproximados.

Fornecedor	Preço de entrada / mês	Vantagens	Desvantagens
Njalla (SE/NL)	~15 €	Historial forte em privacidade, aceita Monero directamente, opera ASN próprio com registo custodial de domínios.	Patamar de preço mais elevado, frota menor, lista de espera ocasional em VPS.
1984 Hosting (IS)	~10 €	Jurisdição islandesa, alimentação geotérmica, Monero aceite via gateway externo.	Oferta limitada de IPv4, apenas uma região de datacentre.
BitLaunch (multi)	~5 USD	Revende DigitalOcean, Vultr e Linode atrás de uma frente cripto, deploys muito rápidos, facturação à hora.	O fornecedor subjacente continua a ter os logs de rede; não é à prova de bala contra uma intimação a montante.
Cockbox (US)	~15 USD	Operador pró-liberdade-de-expressão, aceita Monero, política pública sem logs.	Jurisdição norte-americana, operação pequena de uma só pessoa, sem SLA.
BuyVM / Frantech (LU/CA)	~3,50 USD	Opção sustentada mais barata, aceita cripto, largura de banda generosa sem medição na maioria dos planos.	Posicionamento menos focado em privacidade; a higiene de pagamento fica do lado do cliente.
Privex (multi)	~5 €	Host amigável a Monero há vários anos, presença na Islândia e Suécia, suporta planos só com IPv6.	Stock flutuante, hardware mais antigo no nível mais barato.

Pague com Monero sempre que a opção exista. Pagamentos em Bitcoin, mesmo encaminhados via CoinJoin ou através de um swap sem KYC, deixam um grafo de UTXOs rastreável que futuras análises de cadeia podem vir a colapsar. A construção do Monero com RingCT, Bulletproofs+ e endereços stealth torna a desanonimização do lado do pagamento essencialmente impossível com as técnicas actualmente publicadas. Se um fornecedor só aceitar Bitcoin, use o MoneroSwapper ou um swap equivalente sem conta para converter XMR em BTC no último momento possível, envie directamente para o endereço de pagamento a partir de uma carteira nova, e nunca reutilize a carteira de origem para mais nada.

Higiene de email e de registo

Use um email novo por fornecedor — caixas descartáveis tipo cock.li, danwin1210.de, ou um catch-all auto-alojado num domínio separado. Nunca reutilize um nome de utilizador, uma palavra-passe nem uma impressão de chave SSH que exista em qualquer outro contexto. O IP de registo deve já estar em Tor ou numa VPN que não esteja paga com a mesma identidade que opere qualquer outra coisa. Trate cada campo do formulário como divulgação permanente: o que escrever no registo é a superfície de identificação no pior cenário para toda a vida útil do VPS — e essa vida útil pode estender-se por anos.

Passo a passo: implantar um serviço onion Tor v3

O procedimento abaixo assume um VPS Debian 12 (Bookworm) acabado de instalar, com um único IPv4 público, acesso SSH como root, e o aluguer já pago em Monero. Os passos estão escritos para se poderem copiar e colar, mas leia cada um antes de o executar — as predefinições mudam entre versões e um colar descuidado pode trancá-lo fora da máquina.

1. Endurecimento inicial. Entre por SSH como root, crie um utilizador não-root com sudo, desactive o login de root e a autenticação por palavra-passe em /etc/ssh/sshd_config, reinicie o sshd e active o ufw com política inbound de negação por defeito. Abra apenas SSH (preferencialmente num porto não-standard) até o Tor estar instalado e verificado.
2. Actualizações de sistema e pacotes-base. Corra apt update && apt full-upgrade -y, depois instale tor, nyx, ufw, fail2ban, unattended-upgrades e apt-listbugs. Active as actualizações de segurança automáticas com dpkg-reconfigure -plow unattended-upgrades e confirme com systemctl status unattended-upgrades.
3. Instale o repositório oficial do Tor. O Tor empacotado pelo Debian costuma estar várias semanas atrás. Adicione o repo do Tor Project em /etc/apt/sources.list.d/tor.list, importe a chave de assinatura, e reinstale tor e tor-geoipdb a partir de upstream. Confirme com tor --version — espere 0.4.8.x ou mais recente ao longo de 2026.
4. Configure o serviço oculto. Edite /etc/tor/torrc: acrescente HiddenServiceDir /var/lib/tor/monero-node/, depois HiddenServicePort 18089 127.0.0.1:18089 para um nodo remoto Monero público, e por fim HiddenServiceVersion 3. Para serviços não-Monero, mapeie o porto onde a aplicação escuta localmente para o porto que pretende expor na onion.
5. Inicie o Tor e leia o endereço onion. Execute systemctl restart tor@default, espere que o nyx mostre bootstrap completo a 100%, depois cat /var/lib/tor/monero-node/hostname. O endereço ed25519 de 56 caracteres terminado em .onion é a identidade do serviço. Faça backup do conteúdo do directório — em particular do hs_ed25519_secret_key — para suporte offline cifrado, porque perdê-lo significa perder o endereço para sempre.
6. Ligue a aplicação apenas a localhost. Edite a configuração do seu serviço para escutar em 127.0.0.1 em vez de 0.0.0.0. Para um daemon Monero, defina rpc-bind-ip=127.0.0.1 em monerod.conf e passe a flag --restricted-rpc para recusar operações de carteira no endpoint público. Reinicie a aplicação e confirme com ss -tlnp que nada está ligado à interface pública.
7. Verifique do exterior. A partir de uma máquina separada com Tor Browser, navegue para o endereço .onion. A aplicação deve responder exactamente como responderia em clearnet, sem fuga do IP subjacente em cabeçalhos ou páginas de erro. Use curl --socks5-hostname 127.0.0.1:9050 http://oseuservico.onion/ a partir de qualquer host com Tor para verificações automatizadas.
8. Opcional: gerar uma onion vanity. Ferramentas como mkp224o fazem força bruta a pares de chaves ed25519 para um prefixo desejado. Um prefixo de 6 caracteres demora minutos num CPU moderno; 8 caracteres demoram horas; 10 caracteres demoram dias em GPU. Evite prefixos que coincidam com o seu nome legal, alias de projecto ou qualquer outra string ligável — anula todo o propósito do exercício.

Um serviço onion é tão anónimo quanto a sua fuga mais fraca na camada aplicacional. Um nodo Monero que imprima o seu hostname em mensagens de erro, ou um servidor web que sirva um cabeçalho Server com o rDNS baseado no IP subjacente, compromete a implantação independentemente de quão cuidadosa tenha sido a configuração do Tor.

Endurecimento, monitorização e disciplina operacional

O daemon Tor é um componente. O resto do sistema tem de estar à altura do mesmo modelo de ameaça ou torna-se o elo mais fraco da corrente. Desactive a swap por completo com swapoff -a e remova a entrada de swap de /etc/fstab para que material secreto ed25519 nunca seja paginado para disco. Active kernel.kptr_restrict=2, kernel.dmesg_restrict=1 e o resto dos sysctls de endurecimento de kernel agrupados em linux-hardening ou puxados da referência sysctl do Whonix. Perfis AppArmor para o Tor e para a sua aplicação acrescentam outra camada com custo de configuração modesto.

Configure nftables ou ufw para descartar todo o tráfego inbound excepto SSH — e idealmente apenas dos seus IPs de gestão, se tiver IPs estáveis. Caso contrário, confie em autenticação por chave forte e em rate-limiting com fail2ban. No outbound, permita apenas o que o Tor precisa: TCP 443 e 9001/9030 para tráfego de relay se a máquina for também relay Tor, e force DNS através do porto SOCKS do Tor para qualquer aplicação que precise de resolução de nomes. Nunca deixe uma aplicação falar directamente com o resolver DNS clearnet do fornecedor de VPS — esse caminho fuga discretamente a existência da sua aplicação para os logs do fornecedor.

Monitorize com nyx localmente e exporte métricas Prometheus pelo próprio serviço onion se precisar de gráficos remotos. Evite empurrar logs ou métricas para qualquer SaaS de terceiros — é um vector de desanonimização de manual. A rotação de logs deve ser agressiva: logrotate diário com maxage 7, e journalctl --vacuum-time=7d num cron semanal. Quanto menos dados históricos permaneçam em disco, menos há para um actor hostil apreender e menos há para ter de explicar a posteriori.

Os backups merecem disciplina própria. O ficheiro hs_ed25519_secret_key é a única peça de estado que não consegue regenerar. Cifre-o com age ou GPG usando uma passphrase forte, armazene em pelo menos dois suportes offline (pens USB mais base64 impresso em papel num envelope selado) e mantenha uma cópia geograficamente afastada do seu local principal. Para o resto do sistema, reconstrua a partir de configuration management (Ansible, NixOS, ou scripts shell num repositório privado) em vez de fazer backup da imagem de disco inteira — o sistema deve ser efémero e apenas o segredo deve ser estável.

Perguntas frequentes

Posso correr um serviço oculto Tor em casa em vez de num VPS?

Tecnicamente sim — o Tor não se importa onde o servidor vive. Na prática, ligações residenciais introduzem risco de uptime (cortes da EDP, renegociação de contrato com a MEO ou Vodafone, rotação de IP dinâmico a quebrar guard relays de longa duração), e qualquer fuga que exponha o IP público colapsa o anonimato até à sua identidade de facturação no ISP. Um VPS sem KYC isola o serviço da sua pegada de mundo físico por um custo modesto — 5 a 15 € por mês — e a maioria dos operadores experientes considera este compromisso óbvio.

Pagar com Monero esconde-me mesmo do fornecedor de VPS?

Do lado do pagamento, sim. O RingCT do Monero, as assinaturas em anel, os endereços stealth e o relay de transacções Dandelion++ quebram a ligação entre a sua carteira e o endereço de depósito que paga. O fornecedor de VPS vê um pagamento de entrada sem remetente em texto claro. O que a higiene de pagamento não corrige é o resto do processo de registo: um email usado noutro lado, um nome de utilizador de um fórum público, ou uma impressão de chave SSH partilhada com uma conta não-anónima. Trate o anonimato como uma cadeia — o Monero é um elo, não a cadeia inteira.

Quanto tempo dura um endereço onion v3?

Indefinidamente, desde que mantenha o ficheiro hs_ed25519_secret_key em segurança. O endereço é derivado deterministicamente dessa chave. Pode copiar o directório para um novo VPS, reiniciar o Tor, e o mesmo endereço .onion passa a resolver para o novo servidor em minutos. É a base da resiliência operacional: quando um VPS se torna pouco fiável ou indisponível, migra-se a chave, não o endereço, e os clientes voltam a ligar-se sem qualquer alteração do seu lado.

Preciso de correr o meu próprio nodo Monero, ou posso usar um público por Tor?

Ambos são legítimos. Os nodos onion públicos (listados em monero.fail) são convenientes e não exigem infra-estrutura, mas vêem as suas transmissões de transacções e consultas. Correr o seu próprio nodo atrás do seu próprio serviço oculto custa cerca de 200 GB de disco mais a conta do VPS, mas remove o requisito de confiança por completo. Para fluxos de valor elevado — incluindo conversão de fundos via MoneroSwapper sem deixar metadados correlacionáveis em qualquer endpoint de terceiros — o nodo auto-alojado é a postura materialmente mais robusta.

O que acontece se a minha chave privada de serviço oculto for apreendida?

Quem detiver o ficheiro hs_ed25519_secret_key pode servir tráfego no seu endereço .onion a partir de qualquer infra-estrutura que controle, e a substituição é indistinguível para os clientes. Os backups têm portanto de estar cifrados em repouso com uma passphrase que só você conhece — cifragem completa de disco no VPS por si só não chega, porque o sistema em execução mantém a chave em memória. Se uma apreensão for iminente, faça rotação para um novo endereço onion imediatamente e anuncie a mudança através de um canal out-of-band previamente assinado em que os clientes já confiem.

Conclusão

Pôr de pé um serviço oculto Tor num VPS anónimo não é uma compra única; é uma sequência de decisões sobre jurisdição, higiene de pagamento, endurecimento de sistema e gestão de chaves. Cada passo fecha uma superfície de identificação e deixa o resto visível. A razão para fazer todos juntos é que nenhuma falha isolada — uma auditoria do fornecedor, um banner mal configurado, uma linha de log com fuga — colapsa toda a pilha. Para operadores Monero e para qualquer pessoa que precise de infra-estrutura durável e sem KYC, a receita acima é a linha de base operacional. Quando o serviço que se alcança do outro lado é algo como o endpoint onion do MoneroSwapper, os mesmos padrões aplicam-se também do lado cliente: possua o caminho de ponta a ponta, ou aceite que não tem privacidade nenhuma.