Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Discuss
  3. N8N Security

N8N Security

Scheduled Pinned Locked Moved Discuss
7 Posts 3 Posters 29 Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    jorrg
    wrote last edited by
    #1

    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!

    jamesJ T 2 Replies Last reply
    2
    • J 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!

      jamesJ Offline
      jamesJ Offline
      james
      Staff
      wrote last edited by
      #2

      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.

      T 1 Reply Last reply
      1
      • J 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!

        T Offline
        T Offline
        Teiluj
        wrote last edited by
        #3

        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?)

        J 1 Reply Last reply
        0
        • jamesJ 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.

          T Offline
          T Offline
          Teiluj
          wrote last edited by
          #4

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

          jamesJ 1 Reply Last reply
          0
          • J Offline
            J Offline
            jorrg
            wrote last edited by
            #5

            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"

            1 Reply Last reply
            1
            • T 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?)

              J Offline
              J Offline
              jorrg
              wrote last edited by jorrg
              #6

              @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!

              1 Reply Last reply
              1
              • T Teiluj

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

                jamesJ Offline
                jamesJ Offline
                james
                Staff
                wrote last edited by
                #7

                @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.

                1 Reply Last reply
                3
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Bookmarks
                • Search