Aloja un sitio .onion en un VPS sin delatar el servidor

Empecemos por lo que realmente es distinto, porque es más que un nombre de host de aspecto extraño. Un sitio normal depende de una cadena de terceros externos, y un servicio onion sencillamente no tiene esa cadena.

• Sin registrador y sin registro. Una dirección onion v3 es la codificación base32 de una clave pública ed25519, más una suma de comprobación y un byte de versión — cincuenta y seis caracteres, generados en tu propia máquina en una fracción de segundo. Nadie te la vendió, así que nadie puede quitártela, y no hay fecha de renovación. Eso es exactamente lo contrario del modelo de riesgo de nuestra guía para registrar un dominio en privado.
• Sin DNS. Nada resuelve un nombre .onion. El cliente le pide a la red Tor un descriptor firmado publicado bajo esa clave, así que no hay resolutor que envenenar, ni zona que filtrar, ni servidor de nombres que tumbar.
• Sin autoridad de certificación. La dirección es la clave pública, así que el cliente verifica el servicio contra el nombre que escribió. Esto es lo que significa “autoautenticado”: no hay un tercero que responda por la identidad, porque identidad y dirección son el mismo objeto.
• Sin puerto entrante. El servicio abre circuitos salientes hacia un puñado de puntos de introducción y espera ahí. Tu firewall puede descartar todos los paquetes entrantes y el sitio sigue funcionando. Nada está escuchando en una dirección pública, así que no hay nada que escanear, nada que identificar y nada que inundar directamente.

Una nota histórica que todavía causa confusión: las antiguas direcciones de dieciséis caracteres ya no existen. El soporte para los servicios onion de versión 2 se eliminó de Tor en octubre de 2021, esas direcciones ya no funcionan en ningún sitio, y cualquier cosa que encuentres describiéndolas está desactualizada. Todo lo que sigue es v3, que es el único tipo que existe.

Y que quede claro lo que nada de esto elimina. Sigue habiendo una máquina física en un centro de datos, un proveedor que sabe que existe, una factura que alguien pagó, y una aplicación en la que se puede entrar. Los servicios onion sacan de alcance la capa de la dirección. No mueven el servidor.

La gente llega a Tor queriendo hacer una de cuatro cosas bastante distintas, y los perfiles de riesgo no son ni remotamente comparables. Merece la pena saber a cuál de ellas te estás apuntando.

• Un relay intermedio pasa tráfico cifrado entre otros relays. Transporta datos de otras personas, pero nunca toca el internet abierto en su nombre, así que no atrae denuncias.
• Un bridge es un punto de entrada no listado para personas cuyo acceso a Tor está bloqueado. El mismo perfil de tráfico que un relay intermedio, con la dirección mantenida fuera del directorio público.
• Un relay de salida (exit) es por donde el tráfico de otras personas sale de Tor y llega al internet ordinario, bajo tu dirección IP. Este es el que genera correo de abuso y correspondencia legal, y necesita un manejo deliberado — nuestra guía de relay de Tor lo cubre como corresponde.
• Un servicio onion publica. No transporta más tráfico que el suyo propio, nunca contacta con la clearweb en nombre de nadie, y por lo tanto no produce ningún informe de abuso contra tu IP. No hay salida, así que no hay nada que salga.

Ese último punto merece la pena asimilarlo, porque se malinterpreta habitualmente. Ejecutar un servicio onion es, operativamente, lo más silencioso que puedes hacer en la red Tor. Tu servidor hace conexiones salientes que parecen tráfico de cliente Tor corriente; nunca aparece como el origen de una conexión hacia el servidor de otra persona; y lo que a la mayoría le preocupa — que el comportamiento de otro aterrice en tu IP — es estructuralmente imposible.

Tampoco necesitas ejecutar un relay para ejecutar un servicio onion, y es mejor mantener las dos cosas separadas. Un relay quiere ancho de banda, un ORPort público y un ContactInfo publicado. Un servicio no quiere nada de eso. Si quieres hacer las dos cosas, hazlas en dos servidores.

Aquí está la parte de la que la documentación oficial habla poco, y la parte que en realidad determina si el ejercicio mereció la pena. Es extremadamente improbable que Tor, configurado como se indica más abajo, sea lo que delate tu servidor. El software que hay detrás sí lo es, porque ese software se escribió asumiendo que un servidor web quiere que lo encuentren.

Estos son los canales, aproximadamente en el orden en que suelen atrapar a la gente:

• El mismo contenido en la IP pública. Si tu servidor web también escucha en 0.0.0.0, cualquiera que escanee internet ve la página idéntica tanto en una dirección IP como en una dirección onion. Los escáneres de internet entero indexan continuamente cada puerto abierto y sus resultados se pueden buscar por hash del cuerpo y por hash del favicon. Una sola consulta enlaza las dos. Esta es, con diferencia, la forma más habitual en que se desenmascara un servicio onion, y es un error de configuración de una sola línea.
• Banners de servidor y páginas por defecto. Una instalación de fábrica de nginx o apache2 responde a nombres de host desconocidos con una página por defecto, imprime su versión en la cabecera Server, y a menudo revela el nombre de host real de la máquina en la salida de error. Cada una de esas cosas es un asidero de correlación.
• URL absolutas. Las redirecciones, las etiquetas canónicas, los sitemaps, los feeds RSS, las etiquetas Open Graph y los correos de restablecimiento de contraseña adoran emitir una URL de clearweb totalmente cualificada. Basta con que haya una dentro de la versión onion de una página.
• Solicitudes salientes que hace la aplicación. Analítica, tipografías web, recursos de CDN, servicios de avatar, teselas de mapas, webhooks y comprobaciones de actualizaciones se originan todos desde la IP real del servidor, y varios de ellos le dicen a un tercero qué página se estaba renderizando en ese momento. Un sitio autoalojado con una tipografía cargada desde el dominio de otro tiene un rastro de auditoría que no pretendía tener.
• Correo. Cualquier cosa que envíe la máquina estampa su IP real en las cabeceras Received. Si el servicio necesita enviar correo, eso es un problema de diseño que hay que resolver deliberadamente — empieza por nuestra guía de servidor de correo, y da por hecho, por defecto, que no debería enviar nada en absoluto.
• Claves y huellas reutilizadas. La misma clave de host SSH respondiendo tanto en la IP pública como en una dirección onion las enlaza de forma permanente. Lo mismo ocurre con el mismo certificado TLS, el mismo favicon, el mismo identificador de analítica, o la misma página de error característica en dos proyectos.
• Certificate Transparency. Si esa misma máquina llega a servir alguna vez un dominio de clearweb por HTTPS, el certificado de ese dominio queda escrito para siempre en registros públicos de solo apéndice. Eso nombra a la máquina, no al onion, pero nombra a la máquina.

La forma común de todo esto es siempre la misma: Tor ocultó la dirección, y otra cosa en el servidor la publicó. El paso ocho, más abajo, es una lista de comprobación para encontrarlas antes de que lo haga otra persona.

Antes de instalar nada, responde a una pregunta, porque todo lo que viene después depende de ella: ¿es la ubicación física de este servidor un secreto que estás intentando guardar?

Hay tres respuestas honestas y llevan a configuraciones genuinamente distintas.

• Sí, la ubicación es el objetivo. Entonces esta máquina hace exactamente un trabajo. Ningún sitio en la clearweb, ningún registro DNS público que apunte a su IP, nada de correo, ningún otro servicio escuchando en ningún sitio. Págalo de una forma que no ate tu nombre — nuestro tutorial de Monero cubre la mecánica, y las cuentas no-KYC significan que no hay nada que entregar más allá de una dirección de envío. Mantén la configuración completa de tres saltos. Cualquier atajo de los que siguen que cambie anonimato por velocidad queda cerrado para ti, y está bien, porque no estás optimizando para la velocidad.
• No, el servidor ya es público. Ejecutas un sitio normal y también quieres una dirección onion — para lectores tras la censura, para gente que preferiría no resolver tu dominio, o porque te gustaría ofrecerla. Nadie está ocultando nada, así que puedes usar un servicio onion de salto único, recortar el circuito de seis saltos a tres, y anunciar la dirección desde el sitio en la clearweb con una cabecera Onion-Location. Esto es una función de alcanzabilidad, y es una razón completamente legítima para estar aquí.
• En algún punto intermedio. Aquí es donde está de verdad la mayoría de la gente, y es la opción peligrosa, porque “algo oculto” no es una propiedad que un servidor pueda tener. Elige un bando. Si la ubicación importa de verdad, constrúyelo como si importara. Si no importa, deja de pagar el coste de latencia por una propiedad de anonimato que no estás manteniendo.

Anota la respuesta antes de continuar. Casi todos los errores en la materia de esta guía vienen de construir para el primer caso y operar como si fuera el segundo.

Si la ubicación del servidor no es un secreto, ejecutar las dos cosas es sencillo y genuinamente útil — es como grandes organizaciones de noticias, Debian y varios motores de búsqueda ofrecen sus sitios. Hay dos mecanismos y una concesión que entender.

Anúnciala con Onion-Location. Una sola cabecera en el sitio de la clearweb hace que Tor Browser muestre un botón de “.onion disponible” en la barra de direcciones, y que ofrezca cambiar. La cabecera solo se respeta en páginas servidas por HTTPS, y el valor tiene que ser una URL onion válida:

add_header Onion-Location "http://<your-address>.onion$request_uri" always;

Hay un equivalente en HTML para hosts donde no puedes fijar cabeceras, que tiene el mismo requisito de HTTPS:

<meta http-equiv="onion-location" content="http://<your-address>.onion">

Pon también la dirección en algún sitio donde una persona pueda leerla, en el pie de página o en una página de about. La cabecera solo llega a quien ya usa Tor Browser; el pie de página llega a todos los demás.

Plantéate un servicio onion de salto único. Una conexión onion normal tiene seis saltos — tres del cliente, tres del servicio — y los tres del servicio existen únicamente para ocultar dónde está. Si eso no es un secreto, puedes eliminarlos. La mejora de latencia es grande e inmediatamente perceptible. La configuración es contundente a propósito:

# /etc/tor/torrc — these are INSTANCE-WIDE, not per service
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
SOCKSPort 0

Las dos opciones son necesarias juntas, el puerto SOCKS debe estar desactivado, y se aplican a todos los servicios onion de esa instancia de Tor — no hay forma de excluir a uno solo. Tor se negará a arrancar si fijas una sin las otras, que es el software haciéndote un favor. Si una sola instancia aloja un servicio cuya ubicación es pública y otro cuya ubicación no lo es, ejecuta dos instancias, o mejor, dos servidores.

Y acepta la concesión. Publicar las dos direcciones declara que el mismo operador ejecuta ambas, y servir contenido idéntico desde las dos las hace trivialmente enlazables de todos modos. Ese es el trato, y para un sitio público no cuesta nada. Mantén de todas formas la higiene: ninguna URL absoluta de la clearweb dentro de la versión onion, cookies delimitadas por host para que una sesión no viaje entre ellas, y una política de seguridad de contenido que no traiga recursos de fuera.

Por defecto, cualquiera que conozca tu dirección puede alcanzar el servicio. La autorización de cliente cambia eso en la capa de red en lugar de en la capa de aplicación, y la diferencia importa más de lo que parece.

Con la autorización activada, el descriptor que publica tu servicio está cifrado para un conjunto de claves de cliente. Un visitante sin una de esas claves no puede descifrarlo, no puede conocer los puntos de introducción, y por lo tanto no puede conectar en absoluto — no llega a una página de inicio de sesión, no recibe un rechazo, no recibe nada. El servicio no está simplemente no listado; es invisible.

Genera un par de claves x25519 por cliente. Todas las herramientas ya están en una máquina Debian:

openssl genpkey -algorithm x25519 -out alice.prv.pem

# private key — goes to the client, never to the server
grep -v 'PRIVATE KEY' alice.prv.pem | base64 -d | tail -c 32 | base32 | tr -d '='

# public key — goes on the server
openssl pkey -in alice.prv.pem -pubout | grep -v 'PUBLIC KEY' \
  | base64 -d | tail -c 32 | base32 | tr -d '='

En el servidor, coloca la clave pública dentro de un directorio authorized_clients dentro del directorio del servicio. El nombre de archivo es arbitrario mientras acabe en .auth, lo que convierte la revocación en cuestión de borrar un archivo:

mkdir -p /var/lib/tor/onion-site/authorized_clients
echo "descriptor:x25519:<ALICE-PUBLIC-KEY>" \
  > /var/lib/tor/onion-site/authorized_clients/alice.auth
chown -R debian-tor:debian-tor /var/lib/tor/onion-site
systemctl reload tor@default

En el cliente, la clave privada va en el directorio indicado por ClientOnionAuthDir, en un archivo que termina en .auth_private, con la dirección repetida dentro. Tor Browser tiene su propio directorio para esto bajo su carpeta de datos, y pedirá una clave si se encuentra con un servicio que necesita una:

# /var/lib/tor/onion-auth/mysite.auth_private
<address-without-the-.onion>:descriptor:x25519:<ALICE-PRIVATE-KEY>

Esta es la herramienta adecuada para un sitio de staging, un panel de administración, un depósito de archivos privado, o un Nextcloud autoalojado que solo uses tú — cualquier cosa donde la respuesta honesta a “¿quién debería poder ver que esto existe?” sea “nadie más que nosotros”. El coste es real y es administrativo: tienes que hacer llegar las claves a la gente por un canal en el que confíes, y tienes que acordarte de retirarlas después.

Los servicios onion fallan de formas particulares propias, y ninguna de ellas se parece a una caída normal. Hay cuatro cosas que merece la pena configurar antes de necesitarlas.

La denegación de servicio es el verdadero problema operativo. Como no hay una dirección IP que filtrar, las defensas habituales no se aplican, y una inundación decidida de solicitudes de introducción es barata de enviar. Tor tiene dos respuestas, ambas configuradas por servicio en torrc: HiddenServiceEnableIntroDoSDefense 1 limita la tasa de solicitudes en los puntos de introducción, y HiddenServicePoWDefensesEnabled 1 hace que los clientes resuelvan un pequeño rompecabezas de prueba de trabajo que se vuelve más difícil bajo carga, de modo que los visitantes legítimos esperan un momento mientras una inundación se vuelve cara. Activa las dos desde el principio; el coste cuando nada te está atacando es insignificante.

Mantén el reloj en hora. Los descriptores se publican y se consultan contra periodos de tiempo derivados de un valor compartido de la red. Un servidor cuyo reloj se ha desviado considerablemente publica en el sitio equivocado y se vuelve inalcanzable mientras parece perfectamente sano en sus propios registros. Asegúrate de que hay un cliente NTP en marcha, mantén la máquina en UTC, y compruébalo cuando un servicio deja de resolver misteriosamente.

La monitorización tiene que pasar por Tor. Ningún servicio comercial de monitorización de disponibilidad puede sondear una dirección .onion, lo que significa que la respuesta habitual no está disponible para ti. Ejecuta tú mismo la comprobación desde una segunda máquina que no sea la que aloja el servicio — una tarea de cron que haga torsocks curl -s --max-time 60 contra una URL conocida, comparando la salida con una cadena conocida, basta y no cuesta nada.

Planea más de una instancia si la disponibilidad importa. OnionBalance permite que varios servidores de backend compartan una única dirección onion: una instancia de front-end guarda la clave que posee la dirección y publica un descriptor que apunta a los puntos de introducción de los backends, así que obtienes distribución de carga y conmutación por error sin que la dirección cambie nunca. Son más piezas móviles de las que necesita la mayoría de los sitios, pero es la respuesta soportada oficialmente, y merece la pena saber que existe antes de que te hayas quedado encerrado en una sola máquina.

Un último hábito operativo: reiniciar Tor deja el servicio fuera de línea unos segundos mientras vuelve a publicar, y una reinstalación que borre /var/lib/tor lo deja fuera de línea para siempre. Trata ese directorio como tratarías una clave privada, porque lo es.

Una dirección onion elimina el registrador, el resolutor, la autoridad de certificación y el puerto abierto. No elimina nada más, y ser preciso sobre lo que queda es lo que separa una herramienta útil de una falsa sensación de seguridad.

No arregla la aplicación. Una aplicación web vulnerable detrás de un servicio onion es una aplicación web vulnerable; lo primero que hacen muchos atacantes después de conseguir ejecución de código es hacer una solicitud saliente que revela la dirección real del servidor. Dale a la máquina el repaso de diez minutos de nuestra guía de endurecimiento de Debian, mantenla parcheada, y trátala como expuesta aunque no haya nada escuchando.

No oculta el servidor de quienes lo operan. Nosotros sabemos que un servidor existe, cuándo se desplegó, y cuál es su dirección IP, porque somos quienes la asignamos. Eso es cierto en todos los hosts, en todas partes, y cualquiera que te diga lo contrario te está vendiendo algo. Lo que sí podemos decir con precisión es qué hacemos con ello, que está expuesto en nuestro relato honesto de lo que oculta un VPS pagado en cripto.

No derrota por sí sola a un adversario paciente y con buenos recursos. El volumen y el momento del tráfico son visibles en los bordes de la red, y un servicio que se queda callado siempre que una persona concreta está dormida te está diciendo algo. Tampoco ayuda si es el contenido el que te identifica: el mismo estilo de escritura, la misma clave PGP, el mismo avatar o el mismo alias de foro que una identidad pública cierra el círculo por muy bueno que sea el transporte.

Por nuestra parte, para que puedas calibrar: los servicios onion son bienvenidos en todos los niveles y no necesitan nada especial de nosotros, porque no abren puertos ni generan tráfico de abuso. Operamos cuentas no-KYC que solo necesitan una dirección a la que entregar las credenciales. Tratamos la correspondencia rutinaria de derechos de autor como un asunto operativo y no como una retirada automática, actuamos ante órdenes judiciales válidas en la jurisdicción en la que está el servidor, y el suelo firme es absoluto y se aplica aquí exactamente igual que en cualquier otro sitio: nada de CSAM, nada de contenido terrorista, sin excepciones. Lee la política de uso aceptable y cómo gestionamos los informes de abuso antes de construir algo que lamentarías tener que mudar. Nuestra página de VPS compatible con Tor tiene la orientación de niveles.