VM Security based on LDAP accounts
Access to VM administration tools should be secured to the same level or higher as root access to the VM itself.
Currently the VM dashboard uses a shared login with redmine.
Admin systems and communication systems should not have a shared login system, this is a single point of failure.
More details here:
Updated by Nico Schottelius almost 2 years ago
- Subject changed from VM Security to VM Security based on LDAP accounts
Clarification 1: "shared login"¶
We use LDAP servers as a backend to redmine and django (the dashboard). Both systems originally had their own user databases (and passwords), but both have been reconfigured to use the LDAP backend.
Attack vector 1: hacked systems¶
- If redmine is hacked, no passwords/access leak, as the data is not in redmine
Attack vector 2: django is hacked¶
If the django application is hacked, the attacker gains direct access to the VM - nothing changed here.
Attack vector 3: ldap / indirect hack¶
- If either redmine or django don't imply rate limiting, brute force attacks are possible
- This needs to be verified for both systems
- Mondi: can you checkout & if necessary fix on django?
- Timothee: can you checkout & if necessary fix on redmine?
- Access to the LDAP servers
- The LDAP servers should only be reachable from dedicated applications
- Timothee, can you verify/update the nftables on ldap1 and ldap2 that access to the ldap ports is only possible from dynamicweb-production.u and redmine.u?
Further security improvements¶
Moris suggested to disallow VM termination in the web interface and only allow to terminate the VM using ssh keys. Statement from our side to this:
- It's a good idea, but not feasible for many customers
- There could be an optional "dangerous methods only via SSH" checkbox on the web
- If checked, VMs can only be terminated via SSH
- If checked, it cannot be unchecked from the web, but only via SSH
- Opt-in needed, because default users won't
- If somebody (Moris?) provides code/patches to dynamicweb, we are happy to accept it
- However the SSH based restrictions is not high prio in the development queue