El enfoque de cumplimiento empresarial "Sin-Root": Seguridad en túneles de desarrollador en 2026

Los túneles de desarrollador comenzaron como una conveniencia: un comando, y un servicio en localhost obtiene una URL HTTPS pública para probar un webhook o mostrar una vista previa a un colega. En un entorno de confianza cero, esa misma conveniencia es un camino no gestionado desde una laptop hacia internet público, y los equipos de seguridad lo han notado.

Este artículo cubre qué es lo que realmente aporta “sin raíz”, qué no, qué herramientas funcionan realmente sin privilegios elevados, y cómo implementar una política de túneles que los desarrolladores seguirán en lugar de sortear.

Por qué importa el modelo de amenaza (y dónde está equivocado el relato habitual)

Un túnel inverso es una conexión que una máquina privada abre hacia afuera a un servidor público. Luego, el servidor público reenvía el tráfico entrante por esa conexión. Como nada entrante es aceptado por la máquina privada, funciona desde detrás de un router doméstico, un firewall corporativo o NAT de grado operador sin reenvío de puertos.

Ese diseño solo de salida es la razón por la que los túneles son tan fáciles de adoptar y por qué representan un problema de gobernanza. Las reglas de firewall diseñadas para detener accesos entrantes no los detectan.

¿De dónde viene el privilegio? En dos lugares:

• El propio agente. La mayoría de los clientes de túneles solo necesitan hacer una conexión de salida y comunicarse con un puerto local, que no requiere derechos especiales. Los privilegios elevados suelen aparecer cuando alguien instala el agente como un servicio persistente del sistema, o usa un modo que manipula la pila de red. Por ejemplo, el modo backend VPN de zrok está documentado con sudo, mientras que sus comparticiones proxy normales no.
• La aplicación expuesta. Esta es la parte que la gente pasa por alto. Si un atacante encuentra tu URL de túnel y explota un bug en la app detrás de ella, obtiene los privilegios del proceso de esa app, no del cliente del túnel. Un servidor de desarrollo que corre como administrador, con acceso a sockets Docker o credenciales en la nube, es el verdadero problema de radio de impacto. Ejecutar el cliente de túnel sin privilegios es buena higiene, pero que la app expuesta no tenga privilegios es igual de importante.

En Linux, enlazarse a puertos por debajo de 1024 tradicionalmente requería derechos elevados, por eso los servidores de túneles autohospedados suelen escuchar en puertos altos o sitiarse detrás de un proxy inverso. bore, por ejemplo, por defecto acepta puertos de túnel desde 1024 en adelante.

Rootless es necesario, no suficiente

Es tentador decir que eliminar root hace que un túnel sea conforme, o incluso invisible para la detección en el endpoint. Ninguno de los dos es cierto, y el segundo no es el objetivo correcto para un programa de cumplimiento.

Las utilidades de tunneling son una técnica de atacante bien documentada, catalogada en MITRE ATT6CK como Protocol Tunneling (T1572). Algunos datos concretos:

• La advertencia conjunta de CISA sobre el grupo de ransomware Akira describe actores que usan utilidades de tunneling como ngrok para establecer sesiones cifradas de comando y control que evaden la monitorización perimetral, y también lista Cloudflare Tunnel entre las herramientas usadas para C2.
• El análisis de Cofense de marzo de 2026 documenta actores que abusan de Cloudflare Tunnels, en particular la función gratuita TryCloudflare, para crear conexiones temporales y obfuscadas que ocultan su infraestructura.
• La investigación SERPENTINE#CLOUD de Securonix describe una campaña que alojaba cargas útiles en subdominios de trycloudflare.com.
• El equipo de respuesta a incidentes de GuidePoint documentó el uso de cloudflared en intrusiones desde 2023, señalando que herramientas legítimas y comunes reducen las posibilidades de detección.

Los defensores han respondido con detecciones basadas en comportamiento, no en privilegios. La analítica “Conexión de red potencial de cloudflared en Windows” de Splunk (actualizada en mayo de 2026) se basa en telemetría EDR: nombres de procesos, procesos padres y líneas de comando completas. Elastic ofrece una regla predefinida “Potencial tunneling de protocolo vía Cloudflared” mapeada a T1572.

La conclusión para un programa de cumplimiento: un túnel aprobado, rootless, inventariado y con registros es defendible. Un túnel no aprobado parecerá un túnel de atacante, esté o no en root, porque desde la perspectiva de la red hace lo mismo. Considera “evadir detección” como el anti-objetivo. El objetivo es que los túneles sancionados sean fáciles de reconocer y poner en lista blanca.

La caja de herramientas sin raíz

Herramientas basadas en SSH: nada que instalar

El reenvío remoto SSH es el túnel inverso original, y usa el cliente OpenSSH que viene con versiones actuales de Windows, macOS y casi todas las distribuciones Linux. Eso significa sin binario nuevo que verificar.

localhost.run funciona con un solo comando y sin registro:

ssh -R 80:localhost:8080 nokey@localhost.run

Los dominios gratuitos siguen siendo gratuitos, pero el FAQ señala que los túneles gratuitos cambian de dominio después de unas horas, por lo que no son ideales para registros de webhook que necesitan URL estables. Usar una clave SSH en lugar del usuario nokey mantiene el dominio entre conexiones, y un dominio estable como lhr.rocks o uno personalizado es una suscripción de pago a $9 mensuales facturados anualmente.

Pinggy adopta el mismo enfoque:

ssh -p 443 -R0:localhost:3000 free.pinggy.io

Según la página de ayuda de Pinggy, el plan gratuito tiene un tiempo de espera de 60 minutos, y comenzar un nuevo túnel genera una nueva URL. Una URL persistente o dominio personalizado requiere Pro. Los túneles TCP y TLS son gratuitos. Un punto que los revisores de seguridad deben notar: Pinggy indica que lee el tráfico del túnel para alimentar su función Web Debugger, y recomienda túneles TLS para su modo “confianza cero”, donde no puede leer tus datos. Ejecutarlo en el puerto 443 hace que parezca tráfico HTTPS normal, lo cual es conveniente para los desarrolladores y la razón por la que quieres que esté en una lista aprobada en lugar de ser descubierto por accidente.

Binarios autohospedados: sin terceros en la ruta de datos

frp (Fast Reverse Proxy) es el estándar para autohospedaje. Ejecutas frps en un VPS que controlas y frpc en las máquinas de los desarrolladores, con reenvío TCP, UDP, HTTP y HTTPS. Sigue en desarrollo activo, con la línea v0.70 en la página de lanzamientos del proyecto. Dos detalles importantes para cumplimiento: TLS entre cliente y servidor activado desde v0.50.0, y puedes configurar transport.tls.force = true en el servidor para rechazar clientes sin TLS. Desde v0.69.0, el proyecto también documenta un período de soporte: cada versión menor se soporta hasta que se lancen nueve versiones menores nuevas, garantizando compatibilidad dentro de ese período.

bore es la opción minimalista. Su README lo describe como unas 400 líneas de Rust asíncrono y seguro, un solo binario para cliente y servidor, sin archivo de configuración:

bore local 8000 --to bore.pub

Es solo TCP, y las advertencias de seguridad son importantes: el --secret opcional se usa para un desafío HMAC durante el apretón de manos inicial, pero el README indica que por defecto no cifra el tráfico adicional. Cualquier dato sensible debe llevar su propio TLS. El servidor usa un puerto de control (7835) y, por defecto, solo entrega puertos de túnel desde 1024 en adelante. Eso facilita la gestión, pero es una herramienta para un servidor que ya controlas, no una plataforma empresarial gobernada.

zrok (basado en OpenZiti) adopta un modelo mental diferente: compartición privada. Una compartición privada solo se expone dentro de la red OpenZiti y se alcanza mediante zrok access, en lugar de un frontend público. También existen comparticiones públicas para HTTP/HTTPS, y hay un modo “drive” para compartir archivos vía WebDAV. Nota que zrok 2.0 (lanzado en 2026) renombró el binario a zrok2, movió su directorio de entorno a ~/.zrok2, y reemplazó las comparticiones reservadas por espacios de nombres y nombres reservados. Los tutoriales antiguos usando zrok reserve ya no coincidirán con las versiones actuales.

Opciones de red perimetral y con identidad

Cloudflare Tunnel (cloudflared) realiza una conexión saliente al borde de Cloudflare. La forma rápida no requiere cuenta:

cloudflared tunnel --url http://localhost:8080

La documentación de Cloudflare es explícita en que los túneles rápidos son solo para pruebas: tienen un límite de 200 solicitudes concurrentes y no soportan Server-Sent Events. Para uso en producción, se necesita un túnel nombrado, que requiere una cuenta de Cloudflare y un dominio en DNS de Cloudflare, pero ofrece un hostname estable y políticas de acceso delante de la app. Dado que TryCloudflare aparece mucho en informes de amenazas, muchos equipos de seguridad bloquean *.trycloudflare.com y solo permiten túneles nombrados vinculados a la cuenta corporativa.

Microsoft Dev Tunnels es la opción más claramente diseñada para entornos gestionados. Hospedar un túnel requiere iniciar sesión con un Microsoft Entra ID, Microsoft o GitHub; los usuarios anónimos no pueden crear túneles. Por defecto, solo la cuenta que crea puede hospedar o conectarse. El acceso anónimo es una opción explícita (--allow-anonymous), y la documentación de Microsoft advierte que permite a cualquiera que adivine el ID del túnel acceder a tu servidor local. El acceso puede extenderse a tu tenant de Entra (--tenant) o a una organización de GitHub. Crucial para administradores, hay políticas de grupo para desactivar completamente el acceso anónimo y restringir a los usuarios a una lista de IDs de tenant de Entra. Microsoft también publica los dominios salientes involucrados (por ejemplo *.devtunnels.ms), para que puedas permitirlos o bloquearlos en la capa de red.

ngrok sigue siendo la opción comercial más conocida. Su agente abre una conexión TLS saliente en el puerto 443, y el plan gratuito incluye un agente, un dominio estático, inspección y reproducción de tráfico, y endpoints HTTP, HTTPS y TCP. La autenticación como OAuth o autenticación básica se aplica mediante Traffic Policy. El agente no es solo para root, pero ten en cuenta que ngrok ha sido mencionado junto a Cloudflare Tunnel en la advertencia de CISA, por lo que debe estar en tu inventario como cualquier otro túnel.

Gestionado empresarialmente: Packetriot Spokes

Para equipos que necesitan control central, Packetriot ofrece Spokes, una versión autohospedada (o gestionada por el proveedor) de su servidor de borde. La documentación dice que el cliente estándar de Packetriot funciona igual contra Spokes, con administradores gestionando el registro de clientes y tokens de autenticación.

Lo que realmente dice la página de la empresa:

• Spokes ofrece túneles HTTP/S y TCP para equipos o flotas de dispositivos, con mayor control sobre tráfico, seguridad y auditoría. Una instancia puede escalar a miles de túneles.
• La implementación se realiza mediante un contenedor Docker oficial, Kubernetes, o paquetes RPM y DEB. SQLite es el almacén de datos predeterminado, con opciones para MariaDB y Postgres en despliegues mayores.
• La licencia es anual y basada en el número de túneles: $1,000 por hasta 100 túneles, $2,000 por 250, $3,500 por 500, y precios personalizados para 1,000 o más. Se ofrece una prueba de 30 días.
• La empresa argumenta que el hosting en las instalaciones permite reutilizar controles existentes para regulaciones como HIPAA, GDPR, SOX y PCI. Es una postura del proveedor, no una certificación: Spokes en tu entorno hereda tu postura de cumplimiento, y aún debes validar registros, retención y controles de acceso según tus requisitos de auditoría.

En el lado del cliente, el inicio rápido de Packetriot distingue una configuración solo para usuario, adecuada para hosting y pruebas intermitentes, de una configuración para todo el sistema para hosting persistente ²⁴⁄₇. Eso se alinea con la política: solo usuario para laptops de desarrollador, reservado para dispositivos gestionados.

Alternativas legítimas en este nivel incluyen una implementación autohospedada de frp y planes de pago de Cloudflare o ngrok con SSO y funciones de auditoría. La elección depende de dónde quieres que viva la ruta de datos y el registro de auditoría.

Túneles integrados: una tendencia real, con un compromiso en detección

Algunos equipos se están alejando de binarios de túneles independientes hacia túneles creados dentro del proceso de la aplicación. Esto es real y soportado por proveedores:

• ngrok Agent SDKs para Go, JavaScript, Python y Rust permiten que una app cree sus propios endpoints programáticamente, y la documentación de ngrok dice que el tráfico desde la nube de ngrok se maneja como si la app hubiera abierto un socket de escucha. Recomienda los SDKs cuando no quieres gestionar un proceso de agente separado o empaquetar el agente.
• OpenZiti y zrok ofrecen SDKs para integrar conectividad de confianza cero directamente en una aplicación.
• Pinggy lista un SDK en Python para crear túneles programáticamente.

La ventaja en seguridad es real: el túnel hereda el usuario, límites de recursos y política de red de la app, y desaparece cuando la app termina, sin servicios en segundo plano de larga duración.

La desventaja es la visibilidad. Un túnel creado dentro de tu app no aparecerá como un proceso reconocible de ngrok o cloudflared, por lo que las detecciones basadas en nombres de proceso y líneas de comando fallarán. Para túneles embebidos, tu detección debe basarse en telemetría DNS, proxy y firewall: ¿a qué hosts hablan tus agentes de construcción y máquinas de desarrollo, y esos dominios de proveedores de túneles están en tu lista aprobada?

Una nota sobre “TunnelAPI 2.0.” Puede que veas esto descrito como un estándar emergente para integrar túneles en entornos de ejecución de aplicaciones. No lo es. TunnelAPI es una plataforma hospedada de un solo proveedor (documentada en docs.tunnelapi.in) que combina túneles HTTPS con un gateway API, un controlador de ingreso Kubernetes y autenticación SAML/OAuth/OIDC para túneles. Está listado en los directorios “awesome-tunneling” de la comunidad junto a una herramienta anterior 1.0, y se impulsa con un CLI arm. Puede ser un producto interesante para evaluar, pero no existe una especificación “TunnelAPI 2.0” neutral para construir políticas. Para túneles embebidos hoy, mira los SDKs listados arriba.

Un plan de despliegue que los desarrolladores seguirán realmente

1. Inventario primero. Usa telemetría de EDR, DNS y proxy para encontrar agentes y dominios de túneles ya en uso, incluyendo SSH (sesiones SSH de salida prolongadas a hosts desconocidos, y flags -R en líneas de comando). Marca todo lo que corra con privilegios elevados o instalado como servicio del sistema.
2. Escribe el estándar de uso aceptable. Requiere que los túneles funcionen como usuario estándar, expongan solo un puerto intencionado, tengan autenticación para todo lo que no sea una prueba rápida, y nunca front-end de una app con privilegios de administrador o credenciales de producción.
3. Ofrece un camino sancionado. Bloquear sin una alternativa lleva a desarrolladores a cuentas personales y herramientas de consumo. Escoge una o dos opciones aprobadas: por ejemplo, Dev Tunnels con acceso anónimo desactivado y restricción por tenant, además de una instancia autohospedada de frp o Packetriot Spokes para necesidades compartidas y de largo plazo.
4. Haz cumplir en la capa de red. Lista los dominios de los proveedores sancionados y bloquea o alerta sobre los demás, incluyendo trycloudflare.com si no usas túneles rápidos. Como los túneles en puertos 443 y SSH se mezclan con tráfico normal, los logs DNS y proxy son tu principal punto de control.
5. Agrega detección, no solo prohibición. Usa reglas de proveedores para herramientas de tunneling (como las reglas de Splunk y Elastic para cloudflared, y otras similares) con una lista de excepciones para despliegues aprobados, para que las alertas sean relevantes.
6. Gestiona los túneles embebidos con cuidado. Si frameworks internos crean túneles al iniciar, registra los endpoints y asegúrate que tengan autenticación y sean temporales.
7. Revisa periódicamente. Los términos de las capas gratuitas y el comportamiento de los productos cambian frecuentemente (el cambio de nombre de zrok 2.0 y las reglas de timeout de Pinggy son ejemplos recientes), así que revisa tu lista aprobada contra la documentación del proveedor en un calendario.

Conclusión

Ejecutar clientes de túnel sin root es una línea base sensata. Reduce lo que puede hacer un agente comprometido, y mantiene los túneles fuera de la capa privilegiada y siempre activa. Pero no hace que un túnel sea seguro ni invisible, ni debe hacerlo. La postura de cumplimiento más fuerte es una lista corta de opciones de túneles aprobados, autenticados y con registros, una política de red que trate todo lo demás como sospechoso, y detección que entienda tanto túneles independientes como embebidos.

---

Fuentes

• Packetriot para Enterprise: https://packetriot.com/enterprise
• Documentación de Packetriot Spokes: https://docs.packetriot.com/spokes/
• Inicio rápido de Packetriot: https://docs.packetriot.com/quickstart/
• Ayuda de Pinggy: https://pinggy.io/help/
• FAQ de localhost.run: https://localhost.run/docs/faq/
• Página principal / precios de localhost.run: https://localhost.run/
• Repositorio de frp: https://github.com/fatedier/frp
• Lanzamientos de frp: https://github.com/fatedier/frp/releases
• Repositorio de bore: https://github.com/ekzhang/bore
• Lanzamientos de zrok: https://github.com/openziti/zrok/releases
• Introducción a zrok v2.0: https://blog.openziti.io/introducing-zrok-v2-0
• Documentación de compartición pública de zrok: https://docs.zrok.io/docs/concepts/sharing-public
• Configuración de Cloudflare Tunnel (límites de túnel rápido): https://developers.cloudflare.com/tunnel/get-started/
• Seguridad de Microsoft Dev Tunnels: https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/security
• Políticas de grupo de Microsoft Dev Tunnels: https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/policies
• Referencia CLI de Microsoft Dev Tunnels: https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/cli-commands
• SDKs de ngrok Agent: https://ngrok.com/docs/agent-sdks
• Visión general de ngrok share-localhost: https://ngrok.com/use-cases/share-localhost
• CISA #StopRansomware: Akira: https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-109a
• Cofense, abuso de servicios de Cloudflare: https://cofense.com/blog/how-cloudflare-services-are-abused-for-credential-theft-and-malware-distribution
• Securonix, SERPENTINE#CLOUD: https://www.securonix.com/blog/analyzing_serpentinecloud-threat-actors-abuse-cloudflare-tunnels-threat-research/
• GuidePoint, Cloudflared en uso real: https://www.guidepointsecurity.com/blog/tunnel-vision-cloudflared-abused-in-the-wild/
• Splunk, Conexión de red potencial de cloudflared en Windows: https://research.splunk.com/endpoint/29798d45-c9c7-4240-a5ef-d7648c016024/
• Elastic, Túnel de protocolo potencial vía Cloudflared: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/windows/command_and_control_tunnel_cloudflared
• MITRE ATT6CK T1572, Protocol Tunneling: https://attack.mitre.org/techniques/T1572/
• Documentación de TunnelAPI: https://docs.tunnelapi.in/
• Directorio awesome-tunneling: https://github.com/anderspitman/awesome-tunneling