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?
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.
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.
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.
As a first note, more and more people do not consider Docker as a security-oriented container, see:
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:
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.
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)