Several reports we’re published in the news about how easy it is to access data stored in some NoSQL systems, including MongoDB. This is not surprising because security was rather relaxed in earlier versions of MongoDB . This post lists some of the common vulnerabilities in MongoDB and Percona TokuMX.

Network Security

One key point is to ensure that the bind_ip setting is correctly adjusted: in MongoDB 2.4 and Percona TokuMX, it is not set which means that the server will listen to all available network interfaces. If proper firewall rules (iptables, Security Groups in AWS, …) are not in place, your dataset could easily be queried from anywhere in the world!

In MongoDB 2.6+, bind_ip is set by default to 127.0.0.1 in the official .deb and .rpm packages. This is great from a security point of view, but remember that you’ll still have to adjust the setting if the application servers are not running on the same host.

MongoDB has an HTTP interface that can display statistics, it is available on a port that is 1000 higher than the port used for regular connections. So if mongod is listening on port 27017, the HTTP interface can be reached on port 28017. Although this interface is read only, the stats that are exposed should not be readable by anyone. The best option is then to disable this interface for production systems. This is done by default in MongoDB 2.6+ (and set nohttpinterface: false if you want to use this HTTP interface).

Operating System Security

The mongod and mongos binaries should be run with a dedicated user that has limited privileges. This is done automatically if you have installed MongoDB/Percona TokuMX from a package, but that may not be the case if you have installed from a tarball.

Also make sure that the permissions of the configuration file do not allow any user to make any modifications that would take effect next time MongoDB is restarted.

User Security

MongoDB does not enable authentication by default, this is very handy for development but it is of course not suitable for production servers.

For standalone instances, you will have to set security.authorization: enabled in MongoDB 2.6+ or use the auth setting in MongoDB 2.4/Percona TokuMX.

For replica sets and sharded cluster, you will have to use a key file (security.keyFile or keyFile depending on the version). In this case security.authorization/auth is implied.

Then you will need to create users: start with an administrator user, and then application user(s). This is well explained in the documentation. Note that you will define users and roles in slightly different ways depending on the MongoDB version. It is always good to check the documentation for your specific version.

Also note that the localhost exception allows you to enable authentication before you create the first user.

Conclusion

As you can see, it is not that difficult to get a decently secured MongoDB deployment. However the trap is that some critical pieces (like authentication) are not enabled by default, so if you’re not careful or if you are under heavy time constraints, it can be easy to forget necessary configurations which can result in a weak setup. Don’t let this happen to you! And of course a good place to start is the official documentation.