- Security >
- Security Practices and Management
Security Practices and Management¶
On this page
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 Defense In Depth approaches are 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 more information.
Strategies for Reducing Risk¶
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:
- network filter (e.g. firewall) rules that block all connections from unknown systems to MongoDB components.
- bind
mongod
andmongos
instances to specific IP addresses to limit accessibility. - limit MongoDB programs to non-public local networks, and virtual private networks.
You may further reduce risk by:
- requiring authentication for access to MongoDB instances.
- requiring strong, complex, single purpose authentication credentials. This should be part of your internal security policy but is not currently configurable in MongoDB.
- deploying a model of least privilege, where all users have only the amount of access they need to accomplish required tasks, and no more.
- following the best application development and deployment practices, which includes: validating all inputs, managing sessions, and application-level access control.
Continue reading this document for more information on specific strategies and configurations to help reduce the risk exposure of your application.
Vulnerability Notification¶
MongoDB, Inc. takes the security of MongoDB and associated products very seriously. If you discover a vulnerability in MongoDB, or would like to know more about our vulnerability reporting and response process, see the Vulnerability Notification document.
Networking Risk Exposure¶
Interfaces and Port Numbers¶
The following list includes all default ports used by MongoDB:
By default, listens for connections on the following ports:
27017
- This is the default port
mongod
andmongos
instances. You can change this port withport
or--port
. 27018
- This is the default port when running with
--shardsvr
runtime operation orshardsvr
setting. 27019
- This is the default port when running with
--configsvr
runtime operation orconfigsvr
setting. 28017
- This is the default port for the web status page. This is always
accessible at a port that is
1000
greater than the port determined byport
.
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.
Network Interface Limitation¶
You can limit the network exposure with the following configuration options:
the
nohttpinterface
setting formongod
andmongos
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 asmongod --nohttpinterface
ormongos --nohttpinterface
. Authentication does not control or affect access to this interface.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
port
setting formongod
andmongos
instances.Changes the main port on which the
mongod
ormongos
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
ormongos --port
.Whatever port you attach
mongod
andmongos
instances to, you should only allow trusted clients to connect to this port.-
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 formongod
andmongos
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 themongod --bind_ip
andmongos --bind_ip
option on the command line at run time to limit the network accessibility of a MongoDB program.
Firewalls¶
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:
- limiting incoming traffic on a specific port to specific systems.
- limiting incoming traffic from untrusted hosts.
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¶
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.
Operations¶
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
authentication using the auth
as detailed in the
Authentication section.
Authentication¶
MongoDB provides basic support for authentication with the
auth
setting. For multi-instance deployments
(i.e. replica sets, and sharded clusters) use the keyFile
setting, which implies
auth
, and allows intra-deployment authentication and
operation. Be aware of the following behaviors of MongoDB’s
authentication system:
Authentication is disabled by default.
MongoDB provisions access on a per-database level. Users either have read only access to a database or normal access to a database that permits full read and write access to the database. Normal access conveys the ability to add additional users to the database.
The
system.users
collection in each database stores all credentials. You can query the authorized users with the following operation:The
admin
database is unique. Users with normal access to theadmin
database have read and write access to all databases. Users with read only access to theadmin
database have read only access to all databases, with the exception of thesystem.users
collection, which is protected to prevent privilege escalation attacks.Additionally the
admin
database exposes several commands and functionality, such aslistDatabases
.Once authenticated a normal user has full read and write access to a database.
If you have authenticated to a database as a normal, read and write, user; authenticating as a read-only user on the same database will invalidate the earlier authentication, leaving the current connection with read only access.
If you have authenticated to the
admin
database as normal, read and write, user; logging into a different database as a read only user will not invalidate the authentication to theadmin
database. In this situation, this client will be able to read and write data to this second database.When setting up authentication for the first time you must either:
New in version 2.0: Support for authentication with sharded clusters. Before 2.0 sharded clusters had to run with trusted applications and a trusted networking configuration.
Consider the Control Access to MongoDB Instances with Authentication document which outlines procedures for configuring and maintaining users and access with MongoDB’s authentication system.
[1] | Because of SERVER-6591, you cannot
add the first user to a sharded cluster using the localhost
connection in 2.2. If you are running a 2.2 sharded cluster, and
want to enable authentication, you must deploy the cluster and add
the first user to the admin database before restarting the
cluster to run with keyFile . |
Interfaces¶
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.
JavaScript and the Security of the mongo
Shell¶
Be aware of the following capabilities and behaviors of the
mongo
shell:
mongo
will evaluate a.js
file passed to themongo --eval
option. Themongo
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 themongo --norc
option.On Linux and Unix systems,
mongo
reads the.mongorc.js
file from$HOME/.mongorc.js
(i.e.~/.mongorc.js
), and Windowsmongo.exe
reads the.mongorc.js
file from%HOME%.mongorc.js
or%HOMEDRIVE%%HOMEPATH%.mongorc.js
.
HTTP Status Interface¶
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.
REST API¶
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 if when running with auth
enabled.
See the following documents for instructions on restricting access to the REST API interface:
Data Encryption¶
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.