← Proyectos
Incidente · Superficie de ataque

El panel de control de n8n
ya no existe en Internet

Un buscador marcó el dominio por posible suplantación de identidad. La causa no era código inyectado ni un servidor comprometido: era el panel de control de n8n expuesto en Internet. La respuesta no fue protegerlo mejor, sino eliminar esa superficie de ataque: lo que no está publicado no se puede atacar, ni indexar, ni sondear.

Antes y después
ANTES Internet cualquiera webhook panel de acceso ← indexado como login DESPUÉS Internet cualquiera webhook 404 red privada WireGuard único acceso al panel administrador clave propia

El endpoint que el pipeline necesita sigue siendo público, porque su autenticidad no depende del secreto de la URL sino de una firma. Todo lo demás responde 404 — deliberadamente, y no 403: un 403 confirmaría a quien sondea que ahí hay algo protegido.

Las decisiones, y su porqué
01
Verificar antes de suponer
ProblemaUna herramienta comercial de análisis avisaba de "contenido dañino". Ese tipo de herramientas tiene incentivo en alarmar, y un aviso previo del navegador ya había resultado ser caché local.
AlternativasActuar de inmediato sobre la base del aviso, o descartarlo como falso positivo. Ambas son suposiciones.
DecisiónContrastarlo en la fuente oficial. El aviso era real. A partir de ahí se trató como incidente: comprobar integridad, localizar la causa, corregir, y solo entonces solicitar la revisión. Una revisión rechazada retrasa las siguientes.
02
Descartar el compromiso con evidencias
Problema¿Había alguien dentro? La hipótesis debía descartarse con datos, no con confianza en el propio trabajo previo.
AlternativasAsumir que la plataforma es segura porque se diseñó para serlo.
DecisiónSe verificó que los contenedores en ejecución eran los esperados, que la imagen desplegada coincidía con el último digest firmado, que no existía DNS comodín y que las únicas rutas servidas con éxito eran las propias. Los intentos contra rutas de WordPress o ficheros de entorno eran ruido de escáneres, sin respuesta útil. No había compromiso.
03
La causa: un formulario donde no debía estar
ProblemaEl aviso hablaba de suplantación de identidad "en inicios de sesión de usuarios". El sitio principal es estático y no tiene formularios.
AlternativasBuscar contenido inyectado en las páginas publicadas.
DecisiónEl único formulario de credenciales del ecosistema era el panel de control de n8n, accesible públicamente en su subdominio. Los buscadores clasifican los logins de herramientas autoalojadas como posible phishing: es un patrón conocido. El sitio público nunca fue el problema.
04
Eliminar en vez de proteger
ProblemaLa contención inmediata fue una autenticación HTTP básica. Funciona, pero es pobre en presentación y, sobre todo, sigue siendo un formulario de credenciales expuesto al mundo.
AlternativasSe evaluaron tres vías. Un portal SSO propio (Authelia): login con marca y segundo factor, vistoso como escaparate técnico, pero sigue siendo un formulario público —con riesgo de reincidencia— y es el montaje más pesado. Una lista blanca de IP en Nginx: sencilla y sin formularios, pero deja fuera al administrador en cuanto el proveedor cambia la IP dinámica. Una red privada (VPN): el panel deja de estar publicado.
DecisiónLa red privada. Las dos primeras siguen exponiendo algo: un formulario, o una regla que depende de una IP que no controlas. La tercera elimina la superficie por completo. Para Internet, esa ruta pasa a devolver 404: no hay panel que atacar, ni que indexar, ni que sondear.
05
WireGuard autoalojado frente a Tailscale
ProblemaElegida la red privada, faltaba decidir con qué construirla. Ambas cifran extremo a extremo y ambas resuelven el problema técnico.
AlternativasTailscale: se instala, se inicia sesión y funciona. Resuelve el NAT traversal solo, emite certificados para nombres internos y añadir un dispositivo nuevo es trivial. A cambio, la identidad y el control de acceso dependen de un servidor de coordinación de terceros.
DecisiónWireGuard autoalojado: claves propias, servidor propio, sin intermediarios en la cadena de confianza. El precio es gestionar manualmente los peers y abrir un puerto UDP. Es el mismo criterio que se aplicó al firmar las imágenes, cuando se descartó el modo keyless de Cosign para no delegar la confianza en servicios externos: coherencia por encima de comodidad.
06
No cambiar el nombre, cambiar quién lo resuelve
ProblemaLa herramienta ancla su configuración al dominio. Acceder por una dirección distinta rompe el inicio de sesión por la política de cookies seguras: el fallo clásico al meter estos paneles tras un túnel.
AlternativasReconfigurar la aplicación para el nuevo punto de acceso, arriesgando las URLs de webhook que el pipeline necesita.
DecisiónSe sigue usando el mismo dominio y el mismo certificado; lo que cambia es que, desde el equipo administrador, ese nombre resuelve a la dirección privada del túnel. Cero cambios en la aplicación, certificado válido, y los webhooks del pipeline intactos.
El resultado

La superficie de ataque pasó de dos puntos expuestos a uno: desaparece el panel de control y queda solo el endpoint del pipeline, que acepta únicamente peticiones firmadas. n8n devuelve 404 desde Internet y solo es alcanzable por el túnel privado — sin tocar la configuración de la aplicación ni el pipeline de despliegue. Se implantó además la política de seguridad de contenido que faltaba. Revisión del buscador en curso.

WireGuardNginxUFWDockersystemdLet's EncryptCSP
Connect → Automate → Augment → Deploy.
La superficie más segura es la que no existe.