Seguridad de red en n8n: comprobaciones antes de restringir el acceso
Lista de comprobación de seguridad de red en n8n para conservar webhooks, llamadas API, DNS y dependencias del modo de cola al verificar restricciones.
Comprobado con las fuentes citadas el .
Lista de comprobación: identificar las dependencias de seguridad de red de n8n
Antes de cambiar las reglas de seguridad de red de n8n, registra qué conexiones necesita tu despliegue autoalojado. n8n identifica los cortafuegos de infraestructura, los grupos de seguridad y las políticas de red como la principal defensa de red. Consideramos que un inventario de conexiones revisado es un mejor punto de partida que un conjunto de reglas copiado.
Esta es una lista de verificación editorial, no una norma de cumplimiento, un conjunto completo de reglas de cortafuegos ni un tutorial de despliegue. Los puertos, selectores, destinos y rutas del proxy concretos deben obtenerse de tu despliegue. Empieza en un despliegue de práctica aislado con las mismas versiones y topología que producción; utiliza las siguientes comprobaciones sugeridas para definir cuándo dar la revisión por completada.
Lista de comprobación: mantener el acceso entrante de webhooks a través del proxy
n8n atribuye a quienes lo autoalojan la responsabilidad de gestionar TLS mediante un proxy inverso. Su documentación sobre proxy inverso utiliza N8N_WEBHOOK_URL para la dirección pública de los webhooks; WEBHOOK_URL está obsoleta desde n8n 2.35.0. Comprueba la versión instalada antes de modificar un despliegue antiguo.
La configuración de proxy documentada especifica N8N_PROXY_HOPS=1 y las cabeceras X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. Ese número de saltos corresponde a la configuración documentada. Utiliza estas comprobaciones sugeridas para completar la revisión del tráfico entrante.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/configure-webhook-urls-with-reverse-proxy.md at main · n8n-io/n8n-docs · GitHub, Security
Lista de comprobación: conservar las conexiones de infraestructura del modo de cola
La documentación del chart oficial de Helm de n8n indica que el modo de cola requiere PostgreSQL y Redis externos. Describe workers que consumen trabajos de Redis, en lugar de recibir tráfico HTTP entrante de los flujos. La documentación citada cubre una versión en evolución: main describe el chart 2.0 como una versión candidata, mientras que el chart 1.x instala n8n 2.x. Contrasta estas afirmaciones con la versión del chart que tengas instalada.
Para ese chart documentado, el estado de preparación de los workers depende de la conectividad con la base de datos, las migraciones y Redis. Un fallo de preparación es una señal para investigar, no una prueba de un problema de cortafuegos. Las siguientes comprobaciones sugeridas vinculan el acceso a las dependencias con una ejecución observable.
Sources: n8n-hosting/charts/n8n/README.md at main · n8n-io/n8n-hosting · GitHub
Lista de comprobación: restringir el tráfico saliente y revisar las excepciones de SSRF
En n8n autoalojado, la protección contra SSRF está disponible desde la versión 2.12.0. En esa función documentada, las listas de nombres de host permitidos omiten las comprobaciones de la lista de IP bloqueadas. Esto describe el comportamiento de la aplicación, no el del cortafuegos de infraestructura.
En nuestra opinión, las excepciones de nombres de host merecen el mismo escrutinio que los nuevos permisos de salida. Para revisar la seguridad de red de n8n, examina la configuración real de la aplicación junto con las restricciones de infraestructura mediante estas comprobaciones sugeridas.
Lista de comprobación: verificar la aplicación de políticas en Kubernetes y el DNS
Kubernetes aplica NetworkPolicy mediante un complemento de red compatible. Las políticas aplicables suman sus permisos, por lo que una nueva política restrictiva no anula permisos más amplios de otra política. Denegar todo el tráfico saliente por defecto también bloquea el DNS.
En los despliegues de Kubernetes, completar la revisión significa observar en la práctica los permisos previstos. Estas comprobaciones sugeridas se centran en la aplicación de las políticas y en la ruta real de resolución de nombres del despliegue.
Sources: Network Policies | Kubernetes
Lista de comprobación: probar las rutas permitidas y denegadas antes del despliegue
En su artículo de la comunidad de abril de 2026, Nathan Berg recomienda intentar una solicitud saliente no autorizada y verificar que se deniega y queda registrada. Se trata de una recomendación de la comunidad, no de una norma obligatoria ni de pruebas de resultados de seguridad medidos.
Tomaríamos el comportamiento observado como criterio para dar por completado un cambio de seguridad de red en n8n. Las siguientes comprobaciones sugeridas permiten tomar una decisión de despliegue que pueda revisarse.
Sources: n8n Egress Controls for Security Automation | Nathan Berg
