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
  • 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. Support
  3. Secure LDAP?

Secure LDAP?

Scheduled Pinned Locked Moved Solved Support
securityldap
6 Posts 3 Posters 1.2k 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.
  • W Offline
    W Offline
    will
    wrote on last edited by girish
    #1

    Guys,
    I noticed while fooling around in nextcloud that it is using LDAP as opposed to LDAPS to connect to cloudron LDAP. This means that requests and creds are sent in plain text. Now somebody would have to be on the container network to sniff these, but still a big no no. (I once had my enterprise admin credentials exposed on a webex because my boss used LDAP instead of LDAPS and was reviewing a PCAP live.)

    1 Reply Last reply
    0
    • nebulonN Offline
      nebulonN Offline
      nebulon
      Staff
      wrote on last edited by
      #2

      As you said this is only happening within the server local container network. If a person has access to that, that person has numerous ways to get a user's password. For example just adding a console.log() in the code which validates the password. I don't really see how the security is improved by making the local connection using locally available certificates.

      1 Reply Last reply
      1
      • girishG Offline
        girishG Offline
        girish
        Staff
        wrote on last edited by girish
        #3

        I have pondered adding CapDrop NET_RAW in the past to all our containers but this will break some tools like ping. But the real reason I haven't added it is that because as @nebulon said, if user gets access to container network, then all is lost already. This is why in our previous release, we started making sure that apps that use the docker addon can can only be installed by owner privileges (i.e a user who already has ssh access).

        One attack I can think of is if the app container image is itself compromised. Atleast, right now, all app images are personally tested by us and we only install upstream apt packages and we don't allow 3rd party packagers. So, maybe dropping NET_RAW is worth it for future proofing. AFAIK, this won't break anything.

        1 Reply Last reply
        2
        • girishG Offline
          girishG Offline
          girish
          Staff
          wrote on last edited by
          #4

          @will Just wanted to follow up on this. I did end up removing NET_RAW caps from the app containers in 5.2. So, containers cannot sniff each other's traffic anymore.

          W 1 Reply Last reply
          3
          • girishG girish

            @will Just wanted to follow up on this. I did end up removing NET_RAW caps from the app containers in 5.2. So, containers cannot sniff each other's traffic anymore.

            W Offline
            W Offline
            will
            wrote on last edited by
            #5

            @girish Thanks, might be paranoid, but the little things add up.

            1 Reply Last reply
            1
            • girishG Offline
              girishG Offline
              girish
              Staff
              wrote on last edited by girish
              #6

              I think there's a genuine case in the future where if we introduce per-app admins, then app admin can access terminal of one app to see traffic (and sniff ldap/db creds) of another app. I think it's an excellent suggestion to remove it!

              1 Reply Last reply
              1
              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