How to secure a MongoDB instance?

NoSQL databases are relatively new (although arguably an old concept), I haven't seen any specific MongoDB hardening guides and the usual places I look (CISSecurity, vendor publications, Sans etc all come up short). Suggests it would be a good project for an organisation, uni student, infosec community to write one and maintain it.

There is some basic information in Mongodb.org. All the steps in here should be followed including enabling security. The site itself states MongoDB only has a very basic level of security. http://www.mongodb.org/display/DOCS/Security+and+Authentication

MongoDB and other NoSQL databases also have a lot less (especially security) features than mature SQL databases, so you are unlikely to find fine-grained permissions or data encryption, it uses MD5 for password hashing with the username as the seed. There are also limitations such as authentication not being available with sharding before version 1.9.1 so as always performing a risk assessment and building a threat model to work out your security needs and threats faced is good idea. Based on this output MongoDB or NoSQL databases in general may not be suitable for your needs, or you may need to use it in a different way that maximizes its advantages and minimizes its weaknesses (e.g. for extracts of data rather than your most sensitive information, or on behind a number of layers of network controls rather than directly connected to your web application).

That said, I firmly believe security principles are technology agnostic. If you analyse even the latest attacks, and a good list on datalossdb.org it is amazing how many are still related to default passwords and missing patches. With defense in depth if you follow the following practices should have sufficient security to protect most assets (e.g. individual, commercial) maybe probably not military.

Database hardening principles:

• Authentication - require authentication, for admin or privileged users have two factor if possible (do this at the platform level or via a network device as the database itself doesn't support it). Use key based authentication to avoid passwords if possible.
• Authorization - minimal number of required accounts with minimal required permissions, read only accounts are supported so use them. As granular access control does not exist use alternate means e.g a web service in front of the database which contains business logic including access control rules or within the application. Minimize the permissions that Mongodb runs as on the platform e.g. should not run as root.
• Default and system accounts - change the passwords of all default accounts, remove/lock/disable what you can, disable login where you can.
• Logging and monitoring - enable logging and export these to a central monitoring system. Define specific alerts and investigation procedures for your monitoring staff
• Input validation - NoSQL databases are still vulnerable to injection attacks so only passing it validated known good input, use of paramaterisation in your application frameworks, all the good practices for passing un-trusted input to a database is required
• Encryption - depending on the sensitivity of the data, as you cannot encrypt at the database level, encrypting or hashing any sensitive data at the application layer is required. Transport encryption also via the network layer (e.g. VPN).
• Minimize services and change the default listening port
• Remove any sample or test databases
• Have a patch management process in place to identify, evaluate and install all relevant security patches in a timely manner
• Harden the platform and virtualization platform if used
• Configure appropriate network controls e.g. firewalls, VLAN's to minimize access to the database, upstream denial of service filtering service, fully qualified DNS, seperate production and non production databases
• Physically secure environment
• Have a change management process

Few very initial things to remember are:

• Remove IP Binding from all to just the IP (private or localhost), you expect to get Connection Request
• Change the default Port Bindings
• Give only required permissions (like no update/delete permissions to select query users)
• Setup ssh keys for required master-slave connection, removing involvement of passwords
• You can even setup an encrypted tunnel for connection between your application and mongodb

actually they are applicable on all DataStorage Services

PS: very limited mongodb experience

Here is a checklist for MongoDB security

Enable auth – Even if you have deployed your Mongodb servers in a trusted network it is good security practice to enable auth. It provides you “Defense in depth” if your network is compromised. Edit your mongod configuration file to enable auth

Don’t expose your production db to the internet – Restricting physical access to your database is an important aspect of security. If it is not necessary do not expose your production database to the internet. In case of any compromise if an attacker cannot physically connect to your MongoDB server, your data is that much more secure. If you are on AWS you can place your db’s in a VPC private subnet. Read the blog post Deploying MongoDB in a VPC for more information.

Use firewalls – Use firewalls to restrict which other entities are allowed to connect to your mongodb server. Best practice is to only allow your application servers access to the database. If you are hosted on AWS use ‘Security groups’ to restrict access. If you are hosted on a provider that does not support firewall constructs you can easily configure it yourself using ‘iptables’. Refer to the mongodb documentation to configure iptables for your scenario.

Use key files to setup the replica set – Specify a shared key file to enable communication between your mongodb instances in a replica set. To enable this add the keyfile parameter to the config file as below. The contents of the file need to be the same on all the machines.

Disable HTTP status interface Mongodb by default provides a http interface running by default on port 28017 which provides the “home” status page. This interface is not recommended for production use and is best disabled. Use the “nohttpinterface” configuration setting to disable the http interface.

Disable the REST interface The monogdb REST interface is not recommended for production. It does not support any authentication. It is turned off by default. If you have turned it on using the “rest” configuration option you should turn it off for production systems.

Configure Bind_ip If your system has multiple network interfaces you can use the “bind_ip” option to restrict your mongodb server to listen only on the interfaces that are relevant. By default mongodb will bind to all the interfaces

Enable SSL – If you don’t use SSL your data is traveling between your Mongo client and Mongo server unencrypted and is susceptible to eavesdropping, tampering and “man in the middle” attacks. This is especially important if you are connecting to your Mongodb server over unsecure networks like the internet.

Role based authorization – MongoDB supports role based authentication to give you fine grained control over the actions that can be performed by each user. Use role based constructs to restrict access instead of making all your users admins. Refer to the roles documentation for more details.

Enterprise mongodb & Kerberos Enterprise mongodb integrates with Kerberos for authentication. Refer to the mongodb documentation for more details. Username/password systems are inherently insecure – use kerb based authentication if possible.

https://scalegrid.io/blog/10-tips-to-improve-your-mongodb-security/

Disclaimer: I am the founder of scalegrid.io

In addition I would recommend you also encrypt your mongodb data at rest as the other comments have indicated. You can use LUKS (Linux unified key setup) to setup volume level encryption.