Respuesta a Tailworm: cómo reforzamos nuestra red Tailscale sin interrumpir la producción

Cómo revisamos nuestra red Tailscale frente a los hallazgos de Tailworm, eliminamos la exposición de Tailscale SSH y mantuvimos en marcha todos los trabajos de producción.

Resumen

El 25 de octubre de 2026, un investigador de seguridad publicó “Tailworm”: 11 hallazgos en Tailscale y headscale, publicados sin divulgación coordinada (coordinated disclosure). En el momento de escribir este artículo, Tailscale no ha publicado ninguna corrección. Esa misma noche revisamos nuestra propia red Tailscale frente a cada hallazgo. Eliminamos la única exposición que nos afectaba, restringimos los accesos y mantuvimos todos los trabajos de producción en marcha durante todo el proceso.

En este artículo contamos qué revisamos, qué cambiamos, cómo evitamos una interrupción del servicio y qué aprendimos. No es una verificación independiente del informe.

Qué informó Tailworm, en breve

Los 11 hallazgos se dividen en unos pocos grupos:

• Tailscale SSH (el más grave). Una sesión SSH autorizada podía escalar a root en la máquina de destino. En el laboratorio del investigador, el ataque se propagó luego de una máquina a otra.
• App connectors. Los destinos no se validan.
• Agotamiento de memoria, en el servidor de control y en los clientes.
• Casos límite de Serve y Funnel.

Todos los hallazgos requieren que el atacante ya tenga un punto de apoyo. Ninguno es un ataque remoto desde internet. Algunos profesionales de la seguridad sostienen que el planteamiento exagera el riesgo, pero la exposición principal, Tailscale SSH, es real y fácil de eliminar.

Paso 1: Revisar antes de cambiar

Empezamos con comprobaciones de solo lectura y registramos los resultados antes de tocar nada:

• las versiones del cliente Tailscale en uso
• qué funciones estaban realmente activadas
• 60 días de registros de sesiones SSH, para ver quién se conectó desde dónde y si alguien usó reenvío de puertos o de sockets
• la lista de dispositivos, incluidos los que llevaban meses sin conectarse

Resultados:

• Tailscale SSH estaba activado en parte de nuestro entorno, por lo que los hallazgos F1–F3 y F5 nos afectaban.
• Las funciones de las que dependen los demás hallazgos no estaban en uso, así que la mayoría no se aplicaba.
• Los registros de SSH no mostraron orígenes inesperados ni solicitudes de reenvío.

Paso 2: Eliminar la exposición sin interrupciones

La solución obvia era desactivar Tailscale SSH y usar en su lugar la autenticación estándar por clave de OpenSSH. Nuestra revisión previa encontró una trampa.

Tailscale SSH autentica por la identidad en la tailnet, no por la clave SSH. Nuestros scripts de automatización pasaban una clave SSH en la línea de comandos, pero esa clave estaba protegida con frase de contraseña y nunca habría podido funcionar de forma desatendida. Los trabajos solo se ejecutaban porque Tailscale SSH nunca miraba la clave. Si simplemente hubiéramos desactivado Tailscale SSH, todos los trabajos automatizados se habrían detenido.

Por eso hicimos el cambio en este orden:

1. Creamos una clave dedicada a la automatización, restringida a una sola máquina de origen y con el reenvío desactivado.
2. Probamos la nueva ruta antes del cambio. Abrimos un puerto OpenSSH temporal, accesible solo dentro de la tailnet, y nos conectamos desde un entorno como el de nuestros trabajos (sin agente SSH, sin terminal), usando todas las formas en que nuestros scripts invocan SSH.
3. Hicimos pruebas negativas. La nueva clave se rechazaba fuera de su origen permitido y las solicitudes de reenvío se denegaban.
4. Preparamos primero una reversión automática. Antes de desactivar Tailscale SSH, programamos un temporizador que lo volvería a activar por sí solo. Esta vía de recuperación no dependía de que SSH funcionara.
5. Hicimos el cambio y comprobamos cada trabajo automatizado con conexiones nuevas. Cada trabajo completó una ejecución real. No consideramos una sesión ya abierta como prueba.
6. Eliminamos los elementos temporales —el puerto adicional, la regla del firewall y el temporizador de reversión— y verificamos una vez más.

Paso 3: Reforzar lo que quedaba

• Vaciamos la política de Tailscale SSH. La política predeterminada permitía que cualquiera de los dispositivos de un usuario abriera sesiones SSH en sus otros dispositivos, incluso como root, con solo una nueva aprobación semanal en el navegador. La vaciamos, de modo que volver a activar Tailscale SSH por error ya no concede acceso.
• Cerramos SSH hacia internet. Antes de cerrarlo, confirmamos que el inicio de sesión mediante una consola fuera de banda (out-of-band) funciona, para no quedarnos sin acceso. Después verificamos desde una red externa que SSH ya no responde.
• Exigimos la aprobación de dispositivos. Los dispositivos nuevos deben ser aprobados por un administrador antes de poder unirse.
• Revisamos las claves de registro. No había ninguna que revocar.
• Confirmamos la MFA en la cuenta de administrador. Cualquiera que se haga con el inicio de sesión de administrador puede deshacer los controles a nivel de red.
• Empezamos a observar el tráfico real entre dispositivos, para que el siguiente paso —limitar qué dispositivos pueden comunicarse con qué servicios— se base en pruebas y no en suposiciones.

Tailnet Lock y la aprobación de dispositivos protegen contra la incorporación de un dispositivo no autorizado, pero no pueden usarse a la vez, así que elija uno de forma deliberada.

Paso 4: Corregir el runbook, no solo el servidor

Nuestro antiguo procedimiento de recuperación indicaba reconectar el servidor con Tailscale SSH activado. Si se hubiera seguido después de este cambio, habría devuelto en silencio la función de riesgo. Lo reescribimos:

• Diagnosticar primero. ¿Se ha caído la conexión de red o el problema es el propio SSH (claves, configuración, firewall)? Ambos casos se resuelven de forma distinta.
• Reconectar sin cambiar la configuración. No use opciones adicionales, guarde la configuración del nodo antes de reconectar y compárela después.
• Abrir el acceso de emergencia solo con temporizador. Obtenga primero la aprobación, programe un cierre automático antes de abrir, restrinja el origen y compruebe IPv4 e IPv6.
• No volver a activar Tailscale SSH, ni siquiera en una emergencia. El cambio de política de acceso que requiere no se puede revertir automáticamente.

Qué aprendimos

1. Sepa qué autentica realmente una función de seguridad antes de quitarla. La clave que indicaban nuestros scripts nunca se había usado.
2. Pruebe exactamente la ruta a la que va a migrar, en el mismo entorno en que se ejecutan sus trabajos, antes de hacer el cambio.
3. Prepare una reversión que no dependa de lo que está cambiando. Un temporizador, no “ya entraremos por SSH y lo arreglaremos”.
4. Compruebe el acceso de recuperación antes de cerrar una puerta. Confirmamos el acceso por consola antes de cerrar SSH hacia internet.
5. Actualice el runbook en el mismo cambio. Un paso de recuperación antiguo puede deshacer una corrección de seguridad meses después.
6. Lea las políticas predeterminadas. “Permitir los propios dispositivos, incluido root” era el valor predeterminado del que partimos.
7. Distinga entre “el cambio funcionó” y “la vulnerabilidad está resuelta”. Ya no estamos expuestos a los hallazgos de Tailscale SSH, pero Tailworm en su conjunto no estará cerrado hasta que se publiquen las correcciones upstream. Actualizaremos nuestros clientes cuando salgan.
8. Medir y después restringir. El tráfico observado y una lista de dependencias reales van antes que unas reglas de acceso más estrictas, para que el refuerzo no afecte al negocio.

Próximos pasos

Estamos limitando el acceso de red entre dispositivos al mínimo que necesita cada servicio, a partir del tráfico observado. Instalaremos las correcciones de Tailscale en cuanto se publiquen.

Referencias: el informe Tailworm (tailworm.com) y la documentación de Tailscale sobre Tailnet Lock.