Cómo configurar un servicio oculto Tor en un VPS anónimo

Mantener un servicio oculto Tor desde una conexión doméstica funciona bien hasta que el operador renegocia el contrato, la IP pública se rota o alguien aparece con una orden judicial en la puerta de tu casa. El sentido de una dirección .onion es desacoplar el servicio de una identidad física, y ese desacoplamiento se desmorona en cuanto la ruta de red subyacente se puede rastrear hasta un nombre en una factura de la luz. Por eso quienes buscan durabilidad real a largo plazo —nodos remotos de Monero, servidores BTCPay, puentes de Matrix, espejos de getmonero.org— casi siempre alquilan un VPS dedicado a un proveedor que acepte pagos sin verificación de identidad.

Esta guía recorre la cadena completa para 2026: elegir un VPS que acepte Monero o efectivo sin marcar, pagar de forma anónima, endurecer una instalación limpia de Debian 12 y levantar un servicio onion v3 que sobreviva a reinicios, actualizaciones de kernel y algún que otro escaneo rDNS. Los ejemplos asumen que quieres exponer un nodo Monero, pero la receta sirve para cualquier servicio TCP —Lightning, SSH, IRC o una web estática que prefieres no asociar a tu nombre legal—. Cuando el objetivo es alcanzar un servicio como MoneroSwapper a través de un punto final completamente aislado, la capa de red es la pieza que tiene que estar bien antes de que cualquier otra cosa importe.

Por qué el hosting anónimo es crítico para los servicios ocultos

Una dirección onion v3 deriva de una clave pública ed25519. La garantía criptográfica es directa: cualquiera que llegue al .onion conecta a través de tres saltos de relés Tor, y el punto de rendezvous nunca aprende la IP del servidor. Eso es sólido. Lo que Tor no puede hacer es ocultar el hecho de que pagaste 4,50 € al mes a Hetzner con una Visa a tu nombre. En el momento en que un adversario correlaciona patrones de uptime o una filtración de configuración con el registro de facturación, toda la propiedad de anonimato del servicio se evapora.

Los modelos de amenaza que justifican un VPS sin KYC son concretos y se superponen:

• Presión vía requerimiento judicial: Los proveedores convencionales (Vultr, DigitalOcean, Hetzner, OVH) mantienen registros KYC e historial completo de pagos. Ante un requerimiento del juzgado en España, una orden de producción del artículo 18 del Reglamento e-Evidence en la UE o una notificación bajo la Investigatory Powers Act británica, esos datos se entregan con mínima fricción y sin notificación pública.
• Diligencia probatoria en pleitos civiles: Una demanda por vulneración de derechos, una reclamación de propiedad intelectual o una disputa marcaria pueden obligar al proveedor a identificar al cliente detrás de una IP sin necesidad de procedimiento penal alguno. La diligencia preliminar es más rápida y barata que una imputación.
• Fingerprinting a nivel de aplicación: Aunque el servicio oculto esté configurado correctamente, las fugas en la capa de aplicación (banners del servidor, fuente NTP, versión del kernel en páginas de error) pueden correlacionar el .onion con una IP pública. El pago anónimo garantiza que esa correlación no acabe desembocando en un nombre.
• Resiliencia operativa: Los proveedores que ya operan sin KYC entienden la superficie de amenaza. Suelen estar dispuestos a recibir un aviso de abuso sin destruir el VPS al instante, porque dan por hecho que sus clientes tienen razones legítimas de privacidad en lugar de tratar cada queja como verdad probada.

El ecosistema Monero es el ejemplo canónico. Los nodos remotos públicos listados en monero.fail o en la lista de semillas por defecto de Cake Wallet operan habitualmente como servicios onion v3 porque los operadores quieren prestar el servicio sin convertirse en blanco. La misma lógica aplica a los clientes de atomic swaps, las sidechains de P2Pool y los despliegues de BTCPay del lado comerciante. En cuanto has gestionado cualquiera de estos, entiendes rápido por qué la combinación VPS-y-onion es el estándar y no un extremo paranoico.

Cómo elegir un proveedor VPS sin KYC en 2026

Tras las ampliaciones de la Travel Rule del GAFI en 2024 y la entrada en vigor del CARF europeo (Crypto-Asset Reporting Framework) el 1 de enero de 2026, la lista de proveedores que aceptan pago genuinamente anónimo se ha reducido pero no ha desaparecido. Los hosters europeos que han sobrevivido son los que se posicionan explícitamente alrededor de la privacidad en lugar de ofrecerla como adorno de marketing, y los proveedores offshore que siguen en pie son los que tienen un historial documentado de rechazar pesquisas exploratorias.

Tres constantes definen un proveedor utilizable en este mercado:

1. Acepta Monero (preferido) o Bitcoin por canales compatibles con mezcla, sin más verificación de email que una dirección funcional capaz de recibir un enlace único.
2. No exige número de teléfono, subida de DNI, selfie con documento ni handshake de 3-D Secure de tarjeta en ningún punto del registro.
3. Opera desde una jurisdicción con postura defendible frente a la privacidad —Islandia, Suiza, Rumanía, Bulgaria o determinadas zonas offshore— y no desde el limbo legal estadounidense.

La tabla resume los proveedores citados con más frecuencia por operadores Monero a finales de 2025, con precio de entrada típico y compromisos clave. Los precios fluctúan con el tipo XMR/EUR; tómalos como cifras orientativas.

Proveedor	Precio entrada / mes	Pros	Contras
Njalla (SE/NL)	~15 €	Trayectoria sólida en privacidad, acepta Monero directamente, opera su propio ASN con registro de dominios en custodia.	Precio más alto, flota pequeña, lista de espera ocasional.
1984 Hosting (IS)	~10 €	Jurisdicción islandesa, energía geotérmica, Monero aceptado vía pasarela.	IPv4 limitadas, una sola región de datacentre.
BitLaunch (multi)	~5 $	Revende DigitalOcean, Vultr y Linode tras una pasarela cripto, despliegues rápidos, facturación por horas.	El proveedor de fondo conserva los logs de red; no es a prueba de requerimientos aguas arriba.
Cockbox (US)	~15 $	Operador pro libertad de expresión, Monero aceptado, política pública de no-logs.	Jurisdicción EE. UU., operación unipersonal, sin SLA.
BuyVM / Frantech (LU/CA)	~3,50 $	La opción sostenida más barata, acepta cripto, ancho de banda no medido generoso en la mayoría de planes.	Menos enfocada en privacidad como marca; la higiene del pago corre por tu cuenta.
Privex (multi)	~5 €	Host pro-Monero de largo recorrido, presencia en Islandia y Suecia, soporta planes solo IPv6.	Stock fluctuante, hardware antiguo en el plan más barato.

Paga con Monero siempre que sea posible. Los pagos en Bitcoin, incluso enrutados por CoinJoin o por un swap sin cuenta, dejan un grafo de UTXO rastreable que el análisis de cadena futuro puede colapsar. RingCT, Bulletproofs+ y la construcción de direcciones stealth de Monero hacen prácticamente imposible la desanonimización por el lado del pago con las técnicas publicadas a día de hoy. Si el proveedor solo acepta Bitcoin, usa MoneroSwapper o un swap sin cuenta equivalente para convertir XMR a BTC en el último momento posible, envíalo directamente a la dirección de pago desde una cartera nueva y no reutilices nunca esa cartera origen para nada más.

Higiene de email y registro

Usa un email distinto por proveedor —buzones desechables como cock.li, danwin1210.de o un catch-all autoalojado en un dominio aparte—. No reutilices nombres de usuario, contraseñas ni huellas de clave SSH que existan en cualquier otro contexto. La IP de registro debería ya ir por Tor o por una VPN que no esté pagada con la misma identidad que nada más que operes. Trata cada campo del formulario como una revelación permanente: cualquier cosa que tecleas en el alta es la peor superficie de identificación posible durante toda la vida útil del VPS, y esa vida útil puede prolongarse durante años.

Paso a paso: desplegar un servicio onion Tor v3

El procedimiento siguiente parte de un VPS recién instalado con Debian 12 (Bookworm), una sola IPv4 pública, acceso SSH como root y el alquiler ya pagado en Monero. Los pasos se han redactado para copiar y pegar, pero lee cada uno antes de ejecutarlo —los valores por defecto cambian entre versiones y un pegado descuidado puede dejarte fuera de la máquina—.

1. Endurecimiento inicial. Entra por SSH como root, crea un usuario sin privilegios con sudo, desactiva el login de root y la autenticación por contraseña en /etc/ssh/sshd_config, reinicia sshd y activa ufw con denegación por defecto en entrada. Abre únicamente SSH (a ser posible en un puerto no estándar) hasta que Tor esté instalado y verificado.
2. Actualizaciones y paquetería base. Ejecuta apt update && apt full-upgrade -y y después instala tor, nyx, ufw, fail2ban, unattended-upgrades y apt-listbugs. Activa actualizaciones de seguridad automáticas con dpkg-reconfigure -plow unattended-upgrades y confirma con systemctl status unattended-upgrades.
3. Instala el repositorio oficial de Tor. El Tor que envía Debian suele ir semanas por detrás. Añade el repo del Tor Project a /etc/apt/sources.list.d/tor.list, importa la clave de firma y reinstala tor y tor-geoipdb desde upstream. Confirma con tor --version —espera 0.4.8.x o superior durante todo 2026—.
4. Configura el servicio oculto. Edita /etc/tor/torrc: añade HiddenServiceDir /var/lib/tor/monero-node/, después HiddenServicePort 18089 127.0.0.1:18089 para un nodo remoto Monero público y, por último, HiddenServiceVersion 3. Para servicios distintos a Monero, mapea el puerto en el que escucha tu aplicación localmente al puerto que quieras exponer en la onion.
5. Arranca Tor y lee la dirección onion. Lanza systemctl restart tor@default, espera a que nyx muestre un bootstrap exitoso al 100 % y después cat /var/lib/tor/monero-node/hostname. La dirección de 56 caracteres ed25519 terminada en .onion es la identidad del servicio. Respalda el contenido del directorio —especialmente hs_ed25519_secret_key— en un medio cifrado fuera de línea, porque perderla significa perder la dirección para siempre.
6. Vincula la aplicación solo a localhost. Modifica la configuración de tu servicio para que escuche en 127.0.0.1 en vez de 0.0.0.0. Para un demonio Monero, fija rpc-bind-ip=127.0.0.1 en monerod.conf y pasa el flag --restricted-rpc para rechazar operaciones de wallet en el endpoint público. Reinicia la aplicación y verifica con ss -tlnp que nada está enlazado a la interfaz pública.
7. Verifica desde fuera. Desde otra máquina ejecutando Tor Browser, navega a la dirección .onion. La aplicación debería responder exactamente como lo haría sobre clearnet, sin filtración de la IP subyacente en cabeceras ni páginas de error. Usa curl --socks5-hostname 127.0.0.1:9050 http://tuservicio.onion/ desde cualquier host con Tor para chequeos automatizados.
8. Opcional: genera una onion vanity. Herramientas como mkp224o hacen fuerza bruta sobre pares ed25519 buscando un prefijo determinado. Un prefijo de 6 caracteres lleva minutos en una CPU moderna; 8 caracteres, horas; 10 caracteres, días en GPU. Evita prefijos que coincidan con tu nombre legal, tu alias en el proyecto o cualquier otra cadena enlazable —arruina el sentido del ejercicio—.

Un servicio oculto solo es tan anónimo como su fuga más débil a nivel de aplicación. Un nodo Monero que imprime su hostname en mensajes de error, o un servidor web que envía una cabecera Server con el rDNS basado en la IP subyacente, compromete el despliegue por mucho cuidado que se haya puesto en la configuración de Tor.

Endurecimiento, monitorización y disciplina operativa

El demonio Tor es un único componente. El resto del sistema tiene que estar a la altura de su modelo de amenazas o se convertirá en el eslabón débil de la cadena. Desactiva la swap por completo con swapoff -a y elimina la entrada correspondiente de /etc/fstab para que el material secreto ed25519 nunca acabe paginado en disco. Habilita kernel.kptr_restrict=2, kernel.dmesg_restrict=1 y el resto de sysctls de endurecimiento de kernel empaquetados en linux-hardening o tomados de la referencia sysctl de Whonix. Los perfiles AppArmor para Tor y tu aplicación añaden otra capa con un coste de configuración modesto.

Configura nftables o ufw para descartar todo tráfico entrante salvo SSH —y, a ser posible, solo desde tus IPs de gestión, si tienes IPs estables—. En caso contrario, apóyate en autenticación robusta por clave y limitación de tasa con fail2ban. En salida, permite únicamente lo que Tor necesita: TCP 443 y 9001/9030 para tráfico de relé si el equipo es también un repetidor Tor, y fuerza el DNS a través del puerto SOCKS de Tor para cualquier aplicación que necesite resolución de nombres. Nunca permitas que una aplicación hable directamente con el resolver DNS del proveedor de VPS —esa ruta filtra discretamente la existencia de tu aplicación a los logs del proveedor—.

Monitoriza localmente con nyx y envía métricas Prometheus a través del propio servicio onion si necesitas graficar en remoto. Evita empujar logs o métricas a cualquier SaaS de terceros —es un vector clásico de desanonimización—. La rotación de logs debe ser agresiva: logrotate diario con maxage 7 y journalctl --vacuum-time=7d en una tarea cron semanal. Cuantos menos datos históricos se acumulen en disco, menos hay para que se incaute un actor hostil y menos hay que explicar después.

Las copias de seguridad merecen su propia disciplina. El archivo hs_ed25519_secret_key es la única pieza de estado que no puedes regenerar. Cífralo con age o GPG usando una passphrase fuerte, guárdalo en al menos dos medios fuera de línea (memorias USB más una impresión en papel del base64 en sobre lacrado) y mantén una copia geográficamente separada de tu ubicación principal. Para el resto del sistema, reconstruye desde gestión de configuración (Ansible, NixOS o scripts de shell en un repo privado) en lugar de respaldar la imagen entera del disco —el sistema debería ser efímero y solo el secreto debería ser estable—.

Preguntas frecuentes

¿Puedo correr un servicio oculto Tor desde casa en lugar de un VPS?

Técnicamente sí —a Tor le da igual dónde viva el servidor—. En la práctica, las conexiones residenciales introducen riesgo de uptime (cortes de luz, renegociación del operador, rotación de IP dinámica que rompe los relés guard de larga vida) y cualquier fuga que exponga la IP pública colapsa el anonimato hasta tu identidad de facturación con el ISP. Un VPS sin KYC aísla el servicio de tu huella física a un coste modesto —entre 5 € y 15 € al mes— y la mayoría de operadores experimentados consideran obvio ese intercambio.

¿Pagar con Monero realmente me oculta del proveedor de VPS?

Por el lado del pago, sí. RingCT, las firmas de anillo, las direcciones stealth y la propagación Dandelion++ de Monero rompen el enlace entre tu cartera y la dirección de depósito que pagas. El proveedor de VPS ve un ingreso entrante sin remitente en claro. Lo que la higiene del pago no puede arreglar es el resto del registro: un email reutilizado, un nombre de usuario sacado de un foro público o una huella de clave SSH compartida con una cuenta no anónima. Trata el anonimato como una cadena —Monero es un eslabón, no toda la cadena—.

¿Cuánto dura una dirección onion v3?

Indefinidamente, mientras mantengas a salvo el archivo hs_ed25519_secret_key. La dirección se deriva de forma determinista de esa clave. Puedes copiar el directorio a un VPS nuevo, reiniciar Tor y la misma dirección .onion resolverá al nuevo servidor en cuestión de minutos. Esto es la base de la resiliencia operativa: cuando un VPS deja de ser fiable o deja de estar disponible, migras la clave, no la dirección, y los clientes reconectan sin cambiar nada de su lado.

¿Necesito correr mi propio nodo Monero o puedo usar uno público sobre Tor?

Ambas opciones son legítimas. Los nodos onion públicos (listados en monero.fail) son cómodos y no requieren infraestructura, pero ven tus broadcasts de transacción y tus consultas. Correr tu propio nodo detrás de tu propio servicio oculto cuesta del orden de 200 GB de disco más el coste del VPS, pero elimina el requisito de confianza por completo. Para flujos sensibles —incluido convertir fondos vía MoneroSwapper sin dejar metadatos correlacionables en ningún endpoint de terceros— el nodo autoalojado es la postura materialmente más fuerte.

¿Qué pasa si me incautan la clave privada del servicio oculto?

Quien tenga el archivo hs_ed25519_secret_key puede servir tráfico en tu dirección .onion desde cualquier infraestructura que controle, y la sustitución es indistinguible para los clientes. Los backups deben por tanto estar cifrados en reposo con una passphrase que solo tú conozcas —el cifrado de disco completo en el VPS por sí solo no basta, porque el sistema en ejecución tiene la clave en memoria—. Si la incautación es inminente, rota a una nueva dirección onion de inmediato y anuncia el cambio por un canal previamente firmado fuera de banda en el que tus clientes ya confíen.

Conclusión

Montar un servicio oculto Tor en un VPS anónimo no es la compra de un único producto; es una secuencia de decisiones sobre jurisdicción, higiene de pago, endurecimiento del sistema y gestión de claves. Cada paso cierra una superficie de identificación y deja el resto a la vista. La razón para hacerlos todos juntos es que ningún fallo aislado —una auditoría del proveedor, un banner mal configurado, una línea de log filtrada— derriba la pila completa. Para operadores Monero y para cualquiera que necesite infraestructura sin KYC duradera, la receta de arriba es la línea base operativa. Cuando el servicio que alcanzas al otro lado es algo como el endpoint onion de MoneroSwapper, los mismos estándares se aplican también en el lado cliente: o controlas la ruta de extremo a extremo, o asumes que en realidad no tienes privacidad.