发布于 2015-09-14 14:55:42 | 162 次阅读 | 评论: 0 | 来源: 网络整理
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 降低风险的策略 section for more information.
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 漏洞通知 document.
The following list includes all default ports used by MongoDB:
By default, listens for connections on the following ports:
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.
重要
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 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.
the rest setting for mongod and mongos instances.
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.
重要
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.
也可以参考
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 authentication using the auth as detailed in the 认证 section.
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:
db.system.users.find()
The admin database is unique. Users with normal access to the admin database have read and write access to all databases. Users with read only access to the admin database have read only access to all databases.
Additionally the admin database exposes several commands and functionality, such as listDatabases.
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 the admin 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:
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 通过认证控制访问 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. |
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 if 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 HIPPA, PCI-DSS, and FERPA. For more information consider the following resources: