This is the second in our 3-part series on MongoDB Security by Andreas Nilsson, Lead Security Engineer at MongoDB
This post outlines 10 things to avoid when configuring security for MongoDB. These types of mistakes can lead to the loss of sensitive data, disrupted operations and have the potential to put entire companies out of business. These recommendations are based on my experience working with MongoDB users, and building security systems for databases and financial services organizations. Items are ordered by a combination of severity and frequency.
Mistake #1: Directly exposing a MongoDB server to the Internet
It is surprisingly common to deploy MongoDB database servers directly online or in a DMZ. The MongoDB server network interface is designed to be stable under rogue conditions but exposing the database to the Internet is an unnecessary risk. This holds true for any backend system and is not specific for MongoDB.
If public network exposure is combined with lack of access control, the entire content of the database is up for grabs for anyone who cares to look. In addition, an attacker could intentionally or accidentally change the database configuration, modify the application behavior or perform a Denial of Service (DoS) attack.
Design web applications with a multi-tier architecture in mind, use firewalls to segment the network layers appropriately, and place your database server at the inner data storage layer.
Mistake #2: No access control
Always enable access control, unless it is guaranteed that no untrusted entities will gain access to the server, see the section on Role-Based Access Control in the MongoDB security manual.
Mistake #3 - Not enabling SSL
It is fairly straightforward to protect the network communication using SSL, and enabling SSL in MongoDB does not impact the database performance. SSL also protects against man-in-the-middle attacks, where an attacker would intercept and modify communication between two parties.
Enable SSL to protect network communication against eavesdropping between the clients and the servers and within MongoDB clusters and replica sets.
Mistake #4 - Unnecessary exposure of interfaces
MongoDB ships with an HTTP server and REST interface. By default this interface is turned off in MongoDB 2.6. Do not enable the HTTP server interface unless it is used for backwards compatibility. Instead use the wire API for communication with the server.
We also recommend only binding to necessary network interfaces and turn off server side Javacript execution if not needed.
Run MongoDB with secure configuration options as described in the documentation.
Mistake #5 - Poor user account configuration
There are a few ways to configure user accounts incorrectly, for MongoDB as well as for other systems. These include but are not limited to:
- Use of a single high-privilege admin account for all purposes.
- Granting high privileges and roles to users who do not need them.
- Use of weak passwords or the same password for multiple accounts.
- Orphaned user accounts belonging to decommissioned users or applications.
Use the principle of least privilege when configuring user accounts and utilize the flexibility available in the MongoDB access control system. Use unique, complex passwords and be mindful to decommission deprecated user accounts.
Mistake #6 - Insecure OS privileges
Running the mongod or mongos processes using a non-dedicated, high-privilege account like root puts your Operating System at unnecessary risk. Instead use a dedicated, special purpose account.
Avoid lax, insecure OS file permissions on * Data files * Keyfile * SSL private key files * Log files
Database data files, the keyfile and SSL private key files should only be readable by the mongod/mongos user. Log files should only be writable by the mongod/mongos user and readable only by root.
Mistake #7 - Insecure replica set keyfile configuration
The content of the keyfile used for authentication in sharded clusters and replicasets is in essence a password and should as such be long and of high entropy. Avoid:
- Short or low-entropy password in the keyfile
- Inadequate protection of the keyfile
Use a long, complex password if using a keyfile and protect it using adequate file permissions.
Mistake #8 - Poor SSL configuration
SSL is a complex protocol that needs to be configured properly to avoid leaving unexpected security holes.
Always provide MongoDB servers or the mongo shell with one or several CA certificates to establish a basis of trust.
Do not use self-signed certificates unless you are only looking for the encryption parts of SSL. Using a self-signed certificate invalidates substantial parts of SSL. Use certificates issued by a commercial or internal Certificate Authority.
Avoid using the same certificate across servers or clients. This exposes the private key in multiple places and unless a wildcard (*) certificate is used no hostname validation can be performed.
Mistake #9 - Unprotected backups
Care should be taken to adequately protect backup files generated by copying the data files or using the mongodump tool. If the content of the database is sensitive, the content of the backup is equally sensitive and should be treated as such.
Treat database backup files with the same level of care as the original database storage files.
Mistake #10 - Conscious or unconscious ignorance
A guaranteed way to create an insecure system is to ignore the topic altogether, or hope someone else thinks about it.
Before deploying a MongoDB instance with sensitive data, please consult the MongoDB Security Manual and the MongoDB Security Architecture Whitepaper and stay conscious about potential threats to your application.
MongoDB subscriptions provide access to additional enterprise grade capabilities. The subscription includes all the ease-of-use, broad driver support and scalability features of MongoDB, while addressing the more demanding security and certification requirements of corporate and government information security environments. To see more, download the development version of the MongoDB Enterprise edition here