giohappy
commented
3 years ago Additionalk infos from Toni:
Things that can be done on side of a server admin or developer
Even if all containers are kept up to date there is a fair risk attackers can use a "Zero day attack". To lower the risk these are the steps which currently make sense to me:
a) ROOT USER: As root in a container is root on host don't use root inside the containers but a less priviliged user. This could just read "USER NOBODY" in a Dockerfile. Unfortunately this would most likely need a big refactoring of our stack as shared volumes might miss permissions.
b) USER REMAPPING Fortunately one can lower the risk of running root inside a container by remapping the root user inside a container to a lower prviliged user outside the container (host). This is how it works: https://gist.github.com/t-book/ad82ed949c12932d86985e0deb3ec3dd So even if an attacker can break out the container (which worked in my tests) he will not be able to access critial files and processes at the host system. I've currently tested this step on a staging server of one of our clients but cannot yet see if this can cause problems in production. Testing is ongoing ....
c) LIMIT ACCESS AND CAPS Limit what the user who runs the process inside the container can do. All of our instances run on Ubuntu which by default uses Apparmor to manage User permissions. Different profiles can be attached to different proccess which controll what is actually allowed. As the docker security section describes, processes within a docker-container run with a standard profile called "docker-default". This profile is ~ medium secure. Luckily it's quite easy to start containers with a different profile: This is how it works: https://gist.github.com/t-book/4f8773aba1fa64b07345b825e61eb7b0 My first idea was to write a custom profile for each service, which turned out to be quite hard as one must know what needs actually to be allowed for each process.
My current idea is to review the docker-default profile in contrast to the geonode stack and tighten it if possible. If this leads to something I will share my "one-fits-all-secure-profile" with the community.
d) SECURE THE DAEMON AND PORTS
The current ongoing wave of attacks against docker stacks mainly targets the daemon. Admins should a) secure the docker daemon (https://docs.docker.com/engine/security/https/) b) check if the docker api port is open – and if it is – but not needed close it c) also close not needed ports like 5432 or 8080 and bind them to 127.0.0.1 d) in case of just using UFW be aware of security flaws: https://www.techrepublic.com/article/how-to-fix-the-docker-and-ufw-security-flaw/ e) check what https://www.shodan.io/ knows about your infrastructure
Some notes from Toni regarding the topic:
What can be done here is to start the daemon namespaced. root is root inside the containers, but mapped to a different user on host. This is best done initially on server setup.
In case you like to remap the host <> container user in a running instance it's needed to backeup/restore all of your data.
In hope it helps, this is how it worked quite well in my tests: https://gist.github.com/t-book/ad82ed949c12932d86985e0deb3ec3dd
Further running containers with: security_opt:
stopped escaping from containers in my pentests: https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/
( I will prepare a PR for the later and ask for review ) By the way, an audit with docker bench throws light on some more risks, but that's for 2021 ;)