All the recent reports of ransomware targeting MongoDB installations has every system admin worked up over the past couple of weeks. Sure, it’s a disastrous to have someone break into your database server and steal all your data. But maybe, if someone can break into your database server and steal all your data and leave you a note about it, you’re a pretty shitty administrator. You take all the necessary security steps when it comes to securing your box, you disabled password and use a key to login to your server (if you don’t do this, you should consider it, otherwise, you’re an extremely shitty administrator) and all the stuff like that; but the one think you forgot to do was enforce a password on your database server. And to put a cherry on top, you left your server all exposed to the public internet with no IP based access control in place. At this point I must ask, how dumb can you get. If you’re dumb enough to leave a database server on the public internet with no password, then maybe you don’t have what it takes to be an administrator.
One of the first rules of administering a system, one that we learn when starting out on the field, is that you put a password on everything as a first level of defense against attacks. The password is meant to be only a first level because it’s the easiest to crack. If you need to have a database server facing the public internet (which, as a matter of fact, you should not be having), you at least implement an IP based filter to only allow your legitimate servers to connect to your all critical data. That way, one has to first go through the trouble of breaking into your front facing server before they can get to your data. I should point out that, if someone manages to break into your application, there’s not much you can do; and, it’s not your fault if someone compromises the application. It’s the developer’s fault for not fixing a bug like that. And, as a third level of security, you should implement SSL connections between your remote application server and your database server. In an ideal case, an administrator should configure a VPN between the two servers and connect to the database over that so the database is not open to the internet at all.
I should lay out a standard guideline at this point for properly configuring a MongoDB instance (or for that matter, any database server):
- Always configure a password
- Implement a firewall rule to filter connections based on their origin IP address
- Configure SSL connections between your servers
- Try to setup a VPN connection between your application and database server. This option may not always be possible, but the above 3 points should be enough to secure a server.
Last but not least, setup an automated backup mechanism. In it’s simplest form, an automated backup can be set up by using mongodump, tar, a simple bash script and cron.
And if you ever find yourself in a situation where your server have been compromised and you don’t have a workable backup, may God have mercy on your soul. Actually, you should burn in hell for what you’ve done.