This document describes risk mitigation in MongoDB deployments. As with all software running in a networked environment, administrators of MongoDB must consider security and risk exposures for a MongoDB deployment. There are no magic solutions for risk mitigation, and maintaining a secure MongoDB deployment is an ongoing process. This document takes a Defense in Depth approach to securing MongoDB deployments and addresses a number of different methods for managing risk and reducing risk exposure.
The intent of a Defense In Depth approach is to ensure there are no exploitable points of failure in your deployment that could allow an intruder or un-trusted party to access the data stored in the MongoDB database. The easiest and most effective way to reduce the risk of exploitation is to run MongoDB in a trusted environment, limit access, follow a system of least privilege, and follow best development and deployment practices. See the Strategies for Reducing Risk section.
For an outline of all security, authentication, and authorization documentation, see Security.
The most effective way to reduce risk for MongoDB deployments is to run your entire MongoDB deployment, including all MongoDB components (i.e. mongod, mongos and application instances) in a trusted environment. Trusted environments use the following strategies to control access:
You may further reduce risk by:
Continue reading this document for more information on specific strategies and configurations to help reduce the risk exposure of your application.
10gen takes the security of MongoDB and associated products very seriously. If you discover a vulnerability in MongoDB or another 10gen product, or would like to know more about our vulnerability reporting and response process, see the Create a Vulnerability Report document.
For configuration settings that affect security, see Security Considerations.
The following list includes all default ports used by MongoDB:
By default MongoDB programs (i.e. mongos and mongod) will bind to all available network interfaces (i.e. IP addresses) on a system. The next section outlines various runtime options that allow you to limit access to MongoDB programs.
You can limit the network exposure with the following configuration options:
the nohttpinterface setting for mongod and mongos instances.
Disables the “home” status page, which would run on port 28017 by default. The status interface is read-only by default. You may also specify this option on the command line as mongod --nohttpinterface or mongos --nohttpinterface. Authentication does not control or affect access to this interface.
Important
Disable this option for production deployments. If you do leave this interface enabled, you should only allow trusted clients to access this port. See Firewalls.
the port setting for mongod and mongos instances.
Changes the main port on which the mongod or mongos instance listens for connections. Changing the port does not meaningfully reduce risk or limit exposure.
You may also specify this option on the command line as mongod --port or mongos --port.
Whatever port you attach mongod and mongos instances to, you should only allow trusted clients to connect to this port. See Firewalls.
Enables a fully interactive administrative REST interface, which is disabled by default. The status interface, which is enabled by default, is read-only. This configuration makes that interface fully interactive. The REST interface does not support any authentication and you should always restrict access to this interface to only allow trusted clients to connect to this port.
You may also enable this interface on the command line as mongod --rest.
Important
Disable this option for production deployments. If do you leave this interface enabled, you should only allow trusted clients to access this port.
the bind_ip setting for mongod and mongos instances.
Limits the network interfaces on which MongoDB programs will listen for incoming connections. You can also specify a number of interfaces by passing bind_ip a comma separated list of IP addresses. You can use the mongod --bind_ip and mongos --bind_ip option on the command line at run time to limit the network accessibility of a MongoDB program.
Firewalls allow administrators to filter and control access to a system by providing granular control over what network communications. For administrators of MongoDB, the following capabilities are important:
On Linux systems, the iptables interface provides access to the underlying netfilter firewall. On Windows systems netsh command line interface provides access to the underlying Windows Firewall. For additional information about firewall configuration consider the following documents:
For best results and to minimize overall exposure, ensure that only traffic from trusted sources can reach mongod and mongos instances and that the mongod and mongos instances can only connect to trusted outputs.
See also
For MongoDB deployments on Amazon’s web services, see the Amazon EC2 page, which addresses Amazon’s Security Groups and other EC2-specific security features.
Virtual private networks, or VPNs, make it possible to link two networks over an encrypted and limited-access trusted network. Typically MongoDB users who use VPNs use SSL rather than IPSEC VPNs for performance issues.
Depending on configuration and implementation VPNs provide for certificate validation and a choice of encryption protocols, which requires a rigorous level of authentication and identification of all clients. Furthermore, because VPNs provide a secure tunnel, using a VPN connection to control access to your MongoDB instance, you can prevent tampering and “man-in-the-middle” attacks.
Always run the mongod or mongos process as a unique user with the minimum required permissions and access. Never run a MongoDB program as a root or administrative users. The system users that run the MongoDB processes should have robust authentication credentials that prevent unauthorized or casual access.
To further limit the environment, you can run the mongod or mongos process in a chroot environment. Both user-based access restrictions and chroot configuration follow recommended conventions for administering all daemon processes on Unix-like systems.
You can disable anonymous access to the database by enabling MongoDB authentication. See Access Control.
Simply limiting access to a mongod is not sufficient for totally controlling risk exposure. Consider the recommendations in the following section, for limiting exposure other interface-related risks.
Be aware of the following capabilities and behaviors of the mongo shell:
mongo will evaluate a .js file passed to the mongo --eval option. The mongo shell does not validate the input of JavaScript input to --eval.
mongo will evaluate a .mongorc.js file before starting. You can disable this behavior by passing the mongo --norc option.
On Linux and Unix systems, mongo reads the .mongorc.js file from $HOME/.mongorc.js (i.e. ~/.mongorc.js), and Windows mongo.exe reads the .mongorc.js file from %HOME%.mongorc.js or %HOMEDRIVE%%HOMEPATH%.mongorc.js.
The HTTP status interface provides a web-based interface that includes a variety of operational data, logs, and status reports regarding the mongod or mongos instance. The HTTP interface is always available on the port numbered 1000 greater than the primary mongod port. By default this is 28017, but is indirectly set using the port option which allows you to configure the primary mongod port.
Without the rest setting, this interface is entirely read-only, and limited in scope; nevertheless, this interface may represent an exposure. To disable the HTTP interface, set the nohttpinterface run time option or the --nohttpinterface command line option.
The REST API to MongoDB provides additional information and write access on top of the HTTP Status interface. The REST interface is disabled by default, and is not recommended for production use.
While the REST API does not provide any support for insert, update, or remove operations, it does provide administrative access, and its accessibility represents a vulnerability in a secure environment.
If you must use the REST API, please control and limit access to the REST API. The REST API does not include any support for authentication, even when running with auth enabled.
See the following documents for instructions on restricting access to the REST API interface:
To support audit requirements, you may need to encrypt data stored in MongoDB. For best results you can encrypt this data in the application layer, by encrypting the content of fields that hold secure data.
Additionally, 10gen has a partnership with Gazzang to encrypt and secure sensitive data within MongoDB. The solution encrypts data in real time and Gazzang provides advanced key management that ensures only authorized processes and can access this data. The Gazzang software ensures that the cryptographic keys remain safe and ensures compliance with standards including HIPAA, PCI-DSS, and FERPA. For more information consider the following resources: