Can I make my online server more secure using Docker?

Question

I had my online web server ransacked, they got in through my hosted WordPress site and privilege escalated from there.

I am wondering, if I put the WordPress in a Docker, would that go a decent way to mitigating the risk of WordPress exploits?

Answer 1

As p2k said, docker won't help your Wordpress' problem. But if you mean mitigating the risk of privilege escalation the answer should be yes, probably.

One of the main feature of containers (LXC, openVZ, Solaris Zones, etc) is exactly this: privilege separation. Docker is just a generic framework over different containers (and qemu, or even chroot!). This way, your docker based system will never be more secure than the foundation you've chosen for it. If you're using LXC (with or without docker) you will get the security level of your LXC implementation (which is somewhat incomplete, you must use apparmor or SElinux in order to be safe).

With container technology you can stop the attacker at the gates. But your gate (wordpress) will be wasted. However it's much simpler to restore your website (container) than a whole compromised machine.

Nonetheless, if you run your webserver and db server under a well designed apparmor settings, and you keep basic security rules (no write access anywhere unless required, patch often, use WAF like mod_security, etc), you can reach decent security level anyway without the overhead of using containers.

Answer 2

I will answer this question in two parts, since there is really to points to address here IMO: using a container system and using Docker as container system.

Using a container system

As mentioned in the other answers, using a container system alone will not provide you any better security. However, using a container system will allow you to take actions which will prove to be both easy and effective to detect any other compromission, allowing you to act quickly and early.

• Install tripwire or similar: Tools like Tripwire (or OSSEC which can also scan log files for any suspicious activity, etc.) create a database containing the hashes of various files contained in your file-system. This is design to allow you to detect unexpected file change, i.e. when an attacker enters into your system and begins to replace your Wordpress files for instance. The weakness of these tools is that an attacker having managed to get the proper privileges could alter the database to hide its changes.

  The main advantage of containers is that the guest file-system is directly (and not through some software intermediary as often needed with VM's) accessible to the host, while the host file-system is inaccessible to the guest. This is a dream situation to run a tool like Tripwire on the host to monitor file changes in the guests: it will be able to directly detect any unusual changes while it's own database will be safe (it's one thing to attack a Wordpress server, it's another thing to escalate privileges on the guest system, escape the container, escalate privileges again on the host system, for at last be able to access Tripwire databases).

• Externalize your log: The servers log all activities in the so-called log files. On small systems, these log files are located on the same host, mostly in the /var/log directory. These files are a direct target for attackers in order to hide the system compromise (OSSEC mentioned early regularly parse these files and can send alert emails to warn in case of suspicious activity being logged).

  While corporate environments could invest in a dedicated separate machine to gather the logs from all environment, containers provide a cheap a safe way to setup syslog to store the logs outside of the guest environment, making them far less accessible to attackers.

These are just examples. The fact is that containers will offer you a great deal of flexibility on how you handle you system security.

Using Docker as container system

As a first note, more and more people do not consider Docker as a security-oriented container, see:

• The talk from Daniel Walsh leading the RHEL Docker enablement team and advising to "just assume that privileged processes running within the container are the same as privileged processes running outside of the container.",
• Projects like CoreOS and Kagome which used to rely on Docker are now leaving,
• New projects being setup as a security-minded alternative to Docker like Sandstorm (or CoreOS' Rocket, see link above, but which seems currently in a very early stage).

Docker itself being based on LXC (with some limitations, see below), you basically have the choice between using Docker over LXC or using a full-fledged standalone LXC (or go to an alternative solution, possibly still relying on LXC).

No matter the solution you opt for, there is always a trade-off between functionalities and security to keep in mind: the more functionalities there are, the less security there is.

So, if you need functionalities provided by Docker, then that's fine, you can go for it. However if you don't really need them, then you may think twice about lighter alternatives. Note that the very same dilemma would also occur for hardware virtualization where you would have to choose between using Qemu/KVM standalone or installing Libvirt over it.

As long as you add supplementary software stacks:

• Supplementary dependencies and features may require you to run commands at a higher privilege than their lightweight counterpart (both LXC and Qemu are designed to be run under end-user accounts using limited privileges, Docker and Libvirt however will require to operate as the host system root user). Having code running with such high privilege may make the situation worse in case a security flaw is found.
• You have to face limitations and incompatibilities you wouldn't have encountered using a more basic installation. For instance, in order to provide a real security, the final version 1.0 of LXC provided unpriviledged containers a year and a half ago. However, Docker has still not solved it's multiple libraries incompatibilities issues and is still not able to take advantage of this feature, relying on older, less secure LXC features.
• When you are relying on a pile of software and libraries, an issue anywhere may block your project. The less software and libraries you depend, the less likely you will encounter a blocking issue and the more easy it will be solved (less logs and possibilities to analyse, plus the incompatibilities mentioned above which could make a workaround working for some underlying layer might break something elsewhere),
• At last, while a technical issue could block your project, it could also cause a security vulnerability. The less software you use, the smaller is your attack surface, i.e. the smaller chances are that the right combination of vulnerabilities exists allowing a remote attacker to compromise your environment.

So, this should not prevent you from using Docker or for building any other kind of ambitious complex projects. But you still need to evaluate the functionalities brought by the software you will rely on.

Too often I see people using a labyrinthine system full of bells and whistles where they actually only really know just a little: it is the open door for a compromission.

Answer 3

I am wondering, if I put the Wordpress in a docker would that go a decent way to mitigating the risk of Wordpress exploits?

No - why would a change of your base layer improve something if you still have your vulnerable top layer?

You could apply several concepts in splitting data and service etc. ... But that's a different story. And would be again no change for the service (WordPress here).

Again, the security breach was in WordPress. So the only solution is to exchange the application or harden it. (Regurlar/Fast Updates. Remove (unnecessary) Plugins. And so on)