5 MongoDB Security Tips to Help Keep the Cats Away

The recent Meow attacks on unsecured MongoDB and Elasticsearch instances are yet another reminder that we need to properly secure our databases.

The Meow hackers don’t leave any ransom requests or notes, unlike those in previous MongoDB attacks. Their script simply deletes all data, first by dropping all collections, then creating new ones with the telltale meow string.

1,779 Elasticsearch and 701 MongoDB instances had been already meowed by July 24, according to Bob Diachenko. By July 25, the number had risen to almost 4,000 databases, which by then also included Redis, Cassandra, CouchDB, Redis, Hadoop, Jenkins, and open-file system instances.

The hacking attacks have claimed Zimbabwe’s leading online payments platform and a prominent open-source VPN as victims and appear likely to continue.

MongoDB security must be proactive, not reactive

At Studio 3T, we’ve received the occasional support ticket from customers whose databases were hacked, asking if we’ve maybe stored a backup of their data (we never do – we’re a MongoDB GUI). We know that MongoDB security is a top of mind concern that somehow falls through the cracks, so we’ve written a MongoDB security checklist to keep users on track.

There are two levels of MongoDB security: there’s the database, which you can secure by enforcing user and role access control, using the right authentication, limiting network exposure – the usual suspects.

But there’s also the client side, the handling of actual data which you could secure by enabling read-only mode on a connection or collection-level, using your own cryptographic key store to encrypt passwords, among other things.

No one wants to be hacked, but prevention requires action. Meow-proof your MongoDB (or MongoDB Atlas) instance today by taking these five easy steps on both the database and client side.

Database security best practices

1. Stop whitelisting 0.0.0.0 and limit network exposure to trusted IP addresses.

This is particularly relevant for MongoDB Atlas clusters, which require you to whitelist your IP address during setup.

Most users likely whitelist their current IP address at first – but IP addresses usually change over time. At some point, you’ll likely come across this error:

Could not connect to any servers in your MongoDB Atlas cluster. Make sure your current IP address is on your Atlas cluster's IP whitelist.

MongoDB Atlas has a default “Allow access from anywhere” option, which whitelists all IP addresses (0.0.0.0), an insecure option that grants access to everyone on the web. Do not use this.

A more secure alternative would be to whitelist a range of IP addresses, whitelist multiple IP addresses (like your work and home IPs), or whitelist your current IP address regularly.

2. Enable access control and grant users only the roles they need.

If you aren’t self-hosting your MongoDB server, then your MongoDB instance is already using SCRAM as a default authentication mechanism. With it in place, users are required to provide a login and password first to read or modify data – but what good is a mechanism with no one to authenticate?

If you’re the user administrator, put this preemptive security measure to use by creating additional users on your database and only granting the roles they need, a more secure alternative to passing connection strings around.

3. Enforce authentication – and remember you have options.

If you are self-hosting your MongoDB server, then you must enable authentication first. Otherwise, MongoDB will set bindIp to localhost by default – a feature introduced in MongoDB 3.6 to enforce security – which means only you have access to your data. And as we’ve learned in #1, don’t fall for the easy workaround of setting bindIp to 0.0.0.0.

For users who need a more robust authentication mechanism than SCRAM, MongoDB also supports x.509, LDAP, and Kerberos.

The first three points should already be sufficient Meow-proofing, but here are two additional security measures you can also take on the client side.

Client security best practices

4. Enable read-only mode on either connection or collection level.

Read-only mode within a GUI or client does not replace properly implemented access control.

However, it’s still a handy option to enable if you don’t want to mess anything up, say production data you’ve rightfully been granted access to.

Studio 3T lets you enable read-only mode on MongoDB collections and connections, so you can query collections and explore results, with the peace of mind that nothing could be mistakenly edited.

5. Encrypt MongoDB passwords using your own cryptographic key store.

MongoDB offers encryption at rest, which allows the database to encrypt data files that can only be decoded and accessed by users with the right decryption key – but it’s only available in MongoDB Enterprise.

An alternative would be to use a third-party GUI that supports password encryption using your own cryptographic key store, a more secure way of handling password than the default mechanisms in place.