# Publique un servicio onion sin pasar por alto la aplicación | SwissOctet Insights https://swissoctet.com/es/insights/publish-onion-service-safely/ SwissOctet / Perspectivas / Web y onion Web y onion Aplicado · 4 min de lectura Publique un servicio onion sin pasar por alto la aplicación Planifique una publicación onion legítima con exposición controlada del backend, revisión cuidadosa del contenido, recuperación de claves del servicio y un modelo explícito de acceso de la audiencia. Por SwissOctet Editorial Guardar guía Copiar enlace EN ESTA PÁGINA 01 Defina la publicación y su audiencia 02 Mantenga el listener del backend deliberado 03 Revise lo que publica la aplicación 04 Trate la identidad del servicio como material protegido 05 Elija acceso público o restringido de forma explícita 06 Pruebe a través de la conexión del lector 07 Lea las opciones de alojamiento como partes del diseño Su lista de verificación práctica Fuentes y lecturas adicionales Volver a la biblioteca LA RESPUESTA DIRECTA Asegure la aplicación y su acceso administrativo, limite el listener del backend, proteja las claves del servicio onion y pruebe la publicación a través de un cliente compatible. El enrutamiento onion es una capa del diseño. No elimina las vulnerabilidades de la aplicación, los errores en el contenido publicado ni la necesidad de definir quién debería tener acceso. 01 Defina la publicación y su audiencia Comience con un propósito de publicación lícito y una descripción de la audiencia. Una publicación de investigación pública y un portal de proyecto restringido tienen requisitos de acceso diferentes. Decida qué contenido está destinado a ser público, cuál necesita autenticación de la aplicación y cuál nunca debería llegar a la raíz web. Mantenga esas decisiones separadas del transporte utilizado para llegar al sitio. Escriba un pequeño inventario de datos antes del despliegue: páginas, cargas, contenido de la base de datos, cuentas de administrador y configuración del servicio. Asigne un responsable para las actualizaciones y la gestión de incidentes. El hecho de que un sitio use una dirección onion no resuelve la retención, los derechos de contenido ni las responsabilidades de seguridad. Esas siguen siendo decisiones prácticas de la aplicación que necesitan un plan operativo explícito. 02 Mantenga el listener del backend deliberado Un servicio onion asigna una conexión a un endpoint de aplicación local. Revise dónde escucha ese endpoint y qué otras redes pueden alcanzarlo. La guía de configuración del Proyecto Tor describe los sockets Unix como una forma útil de evitar exponer el backend a una red local. Elija un enfoque compatible con su servidor y verifique su accesibilidad real. Una conexión que funciona a través de Tor puede coexistir con un listener público no intencionado. Pruebe tanto la ruta de acceso prevista como los límites alrededor del backend. Evite suposiciones de configuración genéricas; lea la configuración de escucha de la aplicación y el enrutamiento de host virtual del servidor web. Mantenga las interfaces de administración distintas del servicio destinado al público y restrinja quién puede cambiar esa configuración. 03 Revise lo que publica la aplicación Inspeccione las páginas, los archivos cargados, la salida de errores y los recursos incrustados tal como los encontraría un lector. Una aplicación puede revelar detalles operativos a través de mensajes de depuración o enlazar a recursos externos sin que eso sea evidente en su diseño principal. Revise las URL generadas y los metadatos del contenido. Sirva solo los recursos que requiere la publicación y comprenda cualquier solicitud de terceros que inicie. Para un sitio de investigación ilustrativo, revise un artículo de muestra, un archivo adjunto y una página de contacto antes del lanzamiento. Verifique que un documento editorial privado y un archivo de entorno estén fuera del directorio público. Use material de prueba no sensible al comprobar las cargas. Una conexión onion exitosa demuestra la accesibilidad; esta revisión de contenido comprueba qué divulga realmente el servicio a su audiencia. 04 Trate la identidad del servicio como material protegido La configuración del servicio onion incluye material de claves que debe permanecer privado. Manténgalo fuera de los archivos públicos del sitio web y limite el acceso a los operadores que lo necesiten. Planifique cómo una recuperación legítima preserva la identidad del servicio prevista y cómo se gestionaría un compromiso. No coloque las claves del servicio en un archivo público, un mensaje de soporte ni un repositorio de proyecto compartido. Incluya la aplicación, los datos y la configuración del servicio requerida en el diseño de recuperación, con la protección adecuada para cada uno. Una copia de seguridad solo del contenido del sitio puede no restaurar la dirección prevista, mientras que una copia que contenga claves privadas crea una copia de seguridad sensible. Documente quién puede descifrarla y restaurarla, y pruebe ese acceso sin exponer las claves en los informes de los ejercicios. 05 Elija acceso público o restringido de forma explícita El inicio de sesión de la aplicación y la autorización del cliente Tor son capas diferentes. El Proyecto Tor documenta la autorización de clientes para hacer que el acceso a un servicio onion v3 dependa de una credencial de cliente. Decida si ese modelo se ajusta a la audiencia y al proceso operativo. No es automáticamente necesario para una publicación pública y no reemplaza los permisos de la aplicación una vez que un cliente se conecta. Considere un portal de proyecto con un pequeño grupo aprobado. Necesita una forma de distribuir, reemplazar y revocar el material de acceso de forma privada, así como gestionar las cuentas de la aplicación. Pruebe la eliminación de un cliente autorizado y de un usuario de la aplicación por separado. La siguiente tabla mantiene estos controles distintos en lugar de prometer que una sola configuración resuelve todos los problemas de acceso. Control Pregunta que responde Responsabilidad separada Listener del backend ¿Quién puede alcanzar el endpoint de la aplicación local? Configuración del servidor web y de la red Autorización de clientes ¿Qué clientes pueden conectarse al servicio onion? Distribución y revocación de credenciales privadas Permisos de la aplicación ¿Qué puede hacer un usuario conectado? Roles de cuenta y acceso a datos Revisión de publicación ¿Qué divulga el sitio? Contenido, cargas y gestión de errores 06 Pruebe a través de la conexión del lector Use un cliente compatible para probar páginas, navegación, formularios y descargas a través de la ruta de acceso onion prevista. Observe los errores y el uso de recursos de la aplicación con tráfico de prueba inofensivo. Evite medir solo una solicitud local al backend, porque no ejercita la conexión completa del lector. Mantenga privadas las cuentas de prueba y cualquier credencial de acceso restringido. Compruebe también los procedimientos de recuperación y mantenimiento. Una actualización de la aplicación debería tener un punto de reversión y una forma de validar la ruta onion después. Defina registros operativos útiles y su retención sin asumir que una etiqueta de distribución o transporte crea una política de cero registros. Conserve suficiente evidencia para diagnosticar fallos mientras evita la recopilación innecesaria. 07 Lea las opciones de alojamiento como partes del diseño SwissOctet Veil enumera opciones de pila de aplicaciones, dirección onion y copia de seguridad. Seleccione la pila que espera su software y suficiente CPU, memoria y almacenamiento para la carga de trabajo. Confirme cómo el servicio real gestiona el despliegue, la identidad del servicio y la restauración antes de depender de él. La ubicación suiza del catálogo es independiente del comportamiento de privacidad de su aplicación. Mantenga el servicio destinado a publicación legítima y usuarios autorizados. Planifique las actualizaciones de administrador, las revisiones de acceso y una respuesta a credenciales de aplicación comprometidas. Una publicación onion funciona mejor cuando el contenido, la exposición del backend y la recuperación son comprensibles; el transporte debería apoyar ese plan en lugar de convertirse en una excusa para omitir la seguridad informática ordinaria. CONVIÉRTALO EN ACCIÓN Su lista de verificación práctica. ✓ Defina el contenido público y restringido antes del despliegue. ✓ Verifique la exposición real del listener del backend. ✓ Revise páginas, cargas y solicitudes de recursos externos. ✓ Proteja y pruebe la recuperación del material de claves del servicio. ✓ Separe la autorización de clientes de los roles de la aplicación. ✓ Pruebe el mantenimiento y los recorridos del lector a través de la ruta onion. Descargar lista de verificación PREGUNTAS FRECUENTES Los detalles que importan. ¿El alojamiento onion hace que una aplicación sea anónima por sí mismo? + No. El contenido publicado, la configuración, las cuentas y las prácticas operativas pueden revelar información. Revise todo el servicio en lugar de confiar en el método de conexión. ¿Debería todo sitio onion usar autorización de clientes? + No. Decídalo según la audiencia prevista. La autorización de clientes restringe el acceso a la conexión y añade un ciclo de vida de credenciales; los permisos de la aplicación siguen siendo independientes. ¿Qué debo proteger en una copia de recuperación? + Los datos del sitio y la configuración necesitan controles de acceso adecuados. Cualquier material de claves de servicio incluido es especialmente sensible y debe permanecer privado durante el almacenamiento y la restauración. REFERENCIAS PRINCIPALES Vaya a la fuente. Estas referencias respaldan los conceptos técnicos de esta guía. Consulte la documentación actual antes de cambiar un sistema de producción. Proyecto Tor: Configure su servicio onion community.torproject.org Proyecto Tor: Configuración avanzada del servicio onion community.torproject.org Proyecto Tor: Autorización de clientes community.torproject.org Orientación editorial de SwissOctet. Los ejemplos son ilustrativos. Las especificaciones del servicio, las opciones disponibles y las condiciones contractuales deben verificarse por separado. CONECTE EL CONOCIMIENTO Infraestructura relacionada. Veil Onion Suiza Vector VPS Suiza Vault Storage Suiza MANTENGA EL HILO Sus próximas notas de campo. Explore todas las guías NOTA DE CAMPO / 01 + Nube y VPS Fundamentos Cómo elegir un VPS sin adivinar Convierta una idea de aplicación en un presupuesto de recursos útil y luego compare CPU, memoria, almacenamiento y transferencia en conjunto. 4 min de lectura Lea la guía NOTA DE CAMPO / 02 + Web y onion Fundamentos Alojamiento web o una VPS: elija el trabajo que quiere asumir Compare los requisitos de la aplicación, el control y las responsabilidades de mantenimiento en lugar de tratar una VPS como el siguiente paso automático para cualquier sitio web. 6 min de lectura Lea la guía NOTA DE CAMPO / 03 + Web y onion Aplicado Un runbook de cambio de dominio, DNS y TLS para un nuevo servidor Prepare el enrutamiento de nombres de host, los certificados y la reversión en conjunto para que una migración cambie el servidor sin romper la identidad del sitio ni las conexiones seguras. 4 min de lectura Lea la guía