N8N Security

[jorrg]

Hi everyone,

n8n instances are targets for automated attacks and brute-force attempts. Now, I know that Cloudron offers the "proxyAuth": {} feature in the CloudronManifest.json for custom-packaged apps, which puts the Cloudron login screen in front of the app.

My question is:

• Is there a way to enable proxyAuth for the official App Store version of n8n? (e.g., via a manual config change or a CLI flag?)

Ideally, it would be amazing if we could protect the main UI/API via Cloudron Auth, accepting that I have to double-log-in, while explicitly keeping certain webhook paths /webhook/... open so that external services can still trigger workflows. We would still be vulnerable, but with this feature less likely the victim of an automated attack...

Thanks!

[james]

Hello @jorrg

@jorrg said in N8N Security:

Is there a way to enable proxyAuth for the official App Store version of n8n? (e.g., via a manual config change or a CLI flag?)

Unfortunately, no.

Also, the only thing this would do is move the brute force from N8N to the Cloudron Proxy Auth.
So nothing really changes.

[Teiluj]

Hi @jorrg - I am also interested generally on the idea of a Cloudron proxyAuth in front of a publicly accessible Cloudron app, to prevent the kind of scenario you describe.

This kind of functionality seems to be high on demand for Cloudron (see here and here for example)

However, in the meantime, maybe you've seen this post about OIDC and n8n from @luckow ?
Hopefully this could help in this particular case, even if not officially supported by Cloudron (yet?)

[Teiluj]

@james Would this obfuscate the n8n frontend, at least partially?

[jorrg]

Yeah, I know.

The thing that I was worried about were automated scrapes for N8N.

So the only thing that I presume would change that if some automated scraper comes passing by my IP asking: "Do you run N8N?" my server would answer: "Please log in with your cloudron details" instead of "Sure I am running this N8N version"

[jorrg]

@Teiluj said in N8N Security:

However, in the meantime, maybe you've seen this post about OIDC and n8n from @luckow ?

Haven't seen it, before!

[james]

@Teiluj said in N8N Security:

Would this obfuscate the n8n frontend, at least partially?

Yes, but security via obscurity is useless.

@jorrg said in N8N Security:

So the only thing that I presume would change that if some automated scraper comes passing by my IP asking: "Do you run N8N?" my server would answer: "Please log in with your cloudron details" instead of "Sure I am running this N8N version"

If your IP is scraped it will not even reply with N8N but would return Cloudron.
They would need to know the subdomain of your N8N Cloudron app, which is also possible from e.g. the SSL/TLS certificate if wildcard is not used.
Example for cloudron.io https://www.merklemap.com/search?query=cloudron.io&page=0

Anything that is publicly accessible in the World Wide Web is subjected to access attempts.
And again, if N8N would use the custom OIDC plugin, the brute force would just move to a new target, the OIDC login.

We are planning to add per app IP-Whitelisting.
With that, apps could be gated behind e.g.: the Cloudron VPN app.
This would be a reliable way to block public access.