Cómo proteger una instancia pública de n8n

Una instancia pública de n8n puede recibir información mediante webhooks, conectarse a servicios externos y almacenar credenciales con acceso a otras plataformas. Por eso no debe desplegarse como un contenedor aislado sin controles adicionales. En esta guía veremos cómo reducir su exposición utilizando Docker, redes separadas, un proxy inverso, HTTPS y Cloudflare.

La arquitectura utilizada como ejemplo es la misma que aplicamos en BreachReel: Cloudflare recibe las conexiones públicas, Caddy actúa como proxy inverso en el VPS, n8n permanece en una red interna de Docker y PostgreSQL no publica ningún puerto en el servidor.

Arquitectura recomendada

• Cloudflare protege el dominio público y filtra parte del tráfico malicioso.
• Caddy es el único servicio web que publica el puerto 443 del VPS.
• n8n escucha en el puerto 5678 únicamente dentro de Docker.
• PostgreSQL escucha en el puerto 5432 únicamente dentro de su red privada.
• Caddy comparte una red frontal con n8n, pero no necesita conectarse a PostgreSQL.
• n8n comparte una segunda red privada exclusivamente con PostgreSQL.

Esta segmentación evita que la base de datos sea accesible desde Internet y reduce el número de componentes expuestos. Ver 5678/tcp o 5432/tcp en docker compose ps no significa necesariamente que esos puertos sean públicos. Solo lo son cuando aparece una publicación como 0.0.0.0:5678->5678/tcp.

Comprobar los puertos expuestos

Desde el VPS podemos revisar qué servicios escuchan en los puertos relevantes:

ss -lntp | grep -E ':(443|5678|5432)\b'
docker compose ps

En este diseño, el host debe publicar el puerto 443 de Caddy. Los puertos 5678 de n8n y 5432 de PostgreSQL deben aparecer solamente como puertos internos de sus contenedores. Tampoco debemos utilizar network_mode: host para estos servicios.

Configurar correctamente el proxy y HTTPS

n8n necesita conocer su URL pública para generar correctamente enlaces, callbacks y webhooks. En un despliegue detrás de un proxy inverso conviene revisar variables como estas:

N8N_HOST=n8n.ejemplo.com
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://n8n.ejemplo.com/
N8N_WEBHOOK_URL=https://n8n.ejemplo.com/
N8N_PROXY_HOPS=NUMERO_DE_PROXIES

N8N_PROXY_HOPS debe corresponderse con la cadena real de proxies que utilizamos. No conviene aumentar este valor sin entender la ruta de la petición, porque los encabezados reenviados influyen en cómo n8n interpreta la conexión original. La documentación oficial de n8n explica la configuración de webhooks detrás de un proxy.

En Cloudflare debe utilizarse el modo SSL/TLS Full (strict). El modo Flexible cifra la conexión entre el visitante y Cloudflare, pero deja sin cifrar el tramo entre Cloudflare y el VPS. Caddy puede utilizar un certificado público válido o un certificado de origen compatible con la configuración seleccionada.

Evitar que se omita Cloudflare

La nube naranja oculta la IP actual en las consultas DNS, pero no garantiza que la dirección del VPS nunca haya quedado registrada. Si alguien conoce la IP de origen, podría intentar conectarse directamente y evitar las reglas de Cloudflare.

Una protección avanzada consiste en aceptar conexiones web únicamente desde las redes de Cloudflare o utilizar Cloudflare Tunnel. Esta modificación debe planificarse con cuidado: si Caddy obtiene certificados públicos mediante validación directa, bloquear conexiones externas podría impedir futuras renovaciones. Antes de cerrar el firewall hay que preparar validación DNS, un certificado de origen o el mecanismo adecuado para el despliegue.

Cloudflare documenta varias opciones para proteger el servidor de origen, incluyendo listas de IP permitidas, Authenticated Origin Pulls y túneles.

Proteger credenciales y secretos

Las contraseñas de PostgreSQL, claves API y secretos de cifrado no deben escribirse directamente en un repositorio público. Es preferible almacenarlos en un archivo .env con permisos restringidos o utilizar un gestor de secretos.

chmod 600 .env
ls -l .env

n8n utiliza una clave para cifrar las credenciales almacenadas. Debemos conservar una copia segura de esa clave junto con las copias de seguridad. Perderla puede impedir recuperar las credenciales existentes, mientras que publicarla comprometería su confidencialidad. La variable correspondiente es N8N_ENCRYPTION_KEY.

Autenticación y permisos

• Utiliza una contraseña larga y exclusiva para la cuenta propietaria.
• Activa autenticación en dos pasos cuando esté disponible.
• No compartas una cuenta administrativa entre varias personas.
• Entrega a cada usuario únicamente los permisos necesarios.
• Desactiva o elimina rápidamente las cuentas que ya no se utilicen.
• No publiques capturas que muestren credenciales, tokens o URLs privadas.

Si no utilizas la API pública de n8n, puedes estudiar su desactivación mediante N8N_PUBLIC_API_DISABLED=true. Antes de hacerlo, comprueba que ninguna integración propia dependa de ella. Los webhooks de los workflows son una función diferente y no deben confundirse con la API administrativa.

Proteger los webhooks

Una dirección difícil de adivinar no sustituye a la autenticación. Cuando el servicio emisor lo permita, utiliza firmas HMAC, encabezados con secretos, OAuth o credenciales específicas. Compara los secretos de forma segura y rechaza la petición antes de realizar acciones sensibles.

• Valida el método HTTP y el tipo de contenido.
• Limita el tamaño de la petición.
• Comprueba los campos obligatorios y sus formatos.
• No confíes directamente en nombres de archivo, URLs o instrucciones recibidas.
• No devuelvas trazas, variables internas ni credenciales en la respuesta.
• Aplica límites de frecuencia cuando el endpoint pueda recibir abuso.
• Registra únicamente la información necesaria para diagnosticar errores.

Actualizar sin perder información

No conviene actualizar una instalación importante ejecutando automáticamente la etiqueta latest sin revisar cambios. Una estrategia más segura consiste en fijar una versión, leer las notas de publicación, crear una copia de seguridad y probar la actualización antes de sustituir el contenedor activo.

• Guarda el archivo Compose y la configuración del proxy.
• Copia el volumen persistente de n8n.
• Realiza una copia consistente de PostgreSQL.
• Conserva el archivo de variables y la clave de cifrado en un lugar protegido.
• Prueba periódicamente que las copias pueden restaurarse.

Una copia que nunca se ha restaurado es solamente una suposición. El procedimiento de recuperación debe documentarse antes de que ocurra una incidencia.

Auditoría y monitorización

n8n incluye una auditoría de seguridad que puede ejecutarse desde el contenedor:

docker compose exec n8n n8n audit

La auditoría ayuda a detectar configuraciones arriesgadas, pero no reemplaza la revisión del VPS. También debemos vigilar reinicios de contenedores, consumo de disco, respuestas 5xx, workflows modificados y ejecuciones fallidas.

docker compose ps
docker compose logs --tail=100 n8n
docker stats --no-stream
df -h

La documentación de n8n permite consultar las diferentes formas de ejecutar esta auditoría.

Preguntas frecuentes

¿Una contraseña es suficiente?

No. La contraseña protege una cuenta, pero no corrige puertos expuestos, imágenes desactualizadas, webhooks sin validar, secretos publicados o una base de datos accesible desde Internet.

¿Cloudflare protege automáticamente el puerto 5678?

No si el puerto se publica directamente en la IP del VPS. La opción más segura es no publicarlo en el host y permitir que Caddy acceda a n8n mediante una red interna de Docker.

¿Debo guardar todas las ejecuciones?

No necesariamente. Las ejecuciones pueden contener datos personales, respuestas de APIs y otra información sensible. Define una política de conservación acorde con tus necesidades y elimina datos antiguos cuando ya no sean útiles.

Conclusión

Proteger n8n no depende de una única opción. El resultado proviene de varias capas: Cloudflare en el perímetro, HTTPS estricto, Caddy como único punto de entrada, redes Docker segmentadas, PostgreSQL sin puertos públicos, secretos protegidos, webhooks validados y copias de seguridad restaurables.

Empieza comprobando qué puertos escucha realmente el VPS. Después revisa las redes de Docker, la configuración del proxy, las cuentas, los webhooks y el proceso de actualización. Esta revisión periódica es más útil que instalar controles que después nadie supervisa.