Securing Your MongoDB Database

Hardening MongoDB

Securing databases is a significant aspect of an organization’s infrastructure and security practices. This article explores the methodologies and steps for securing MongoDB Database, a popular non-relational, flexible, and document-oriented database.

Before starting, you should understand the difference between self-hosted MongoDB and MongoDB Atlas. The former describes the idea of using an external platform to host your MongoDB Database, whereas MongoDB Atlas is a hosting service set up by the people who built MongoDB. While self-hosting can reduce costs, Atlas is more extensive and manageable.

Securing MongoDB

You’re going to learn about securing MongoDB on three security levels:

  • Network security ensures that your database is only accessible to specified and trusted hosts and not throughout the entire network.
  • Transport-level security encrypts all the network traffic so only trusted clients can read it, which involves the use of TLS/SSL.
  • Database security defines the set of privileges and actions available to the user in terms of accessing the database and its activities.

Network-level security for MongoDB

This section provides some best practices for hardening MongoDB on a network level.


Firewalls are the security blocks between the network traffic and the system; they ensure that only trusted traffic reaches the host and system.


iptables is the interface that allows you to filter network traffic that can access the hosts by utilizing the Linux netfilter firewall. We can control this traffic based on hosts, as well as IP addresses.

The following commands will block all ports except 27017 (or the port MongoDB is listening to) using iptables:

However, suppose you want iptables to only accept the inbound connections from a certain IP address or subnets to the port MongoDB is listening to. In that case, you need to make the following changes to the commands:


netsh provides access to the Windows firewall to manage the secure access of network traffic to the hosts. It limits open access to all the traffic, reducing the element of risk. Here’s how you can set up the firewall using netsh:

Note: you can apply the firewall rules on exe, which is the build of mongod for Windows. There’s MongoDB documentation to help you learn more about exe.

Reverse tunneling

Reverse tunneling (also known as SSH tunneling) is a practical approach to direct your traffic to the remote server from the local host with the bastion host in between. The bastion host is an interface that filters the incoming traffic to reduce security risks.

You can utilize the following command for this purpose (applicable on Linux or Mac):

IP Binding

IP binding specifies the IP addresses that MongoDB will listen to, restricting its exposure in the network and safeguarding it against security breaches. Essentially, IP binding removes traffic from all IP addresses save for those specified.

mongod and mongos are bound to the localhost by default. But if you want to make an additional binding of an IP address to MongoDB, IP binding is the option.

To bind an IP address, navigate to the config file of mongod and add the following:

You can also utilize the following command:

Transport-level security for MongoDB

This section explains how you can use transport-level security to encrypt network traffic and ensure only trusted clients have access to your MongoDB.


TLS and SSL are the encryption protocols that utilize signed certificates for the encryption and security of network traffic. The certificate can be self-signed or signed by a third party.

To set this up, you need to include the following in the MongoDB config file:

Now that we’ve added the cert paths in our config we need to have the db service pick up these changes. At the time of connection, the client must mention the path of the certificate key file for access, which can be done using the following command:

If you would like to learn more, we recommend our post on Securing MongoDB.


The Federal Information Processing Standard, or FIPS, is a security standard developed by the National Institute of Standards and Technology (NIST). FIPS has many applications, including setting security standards that govern TLS/SSL.

This section explains the configuration of the database with the FIPS 140-2 certified library for OpenSSL. FIPS 140-2 defines the security standards for cryptography modules, ensuring secure environments.

To enable FIPS for MongoDB, follow the steps below:

FIPS mode ensures that the OpenSSL library used by the database is FIPS 140-2 certified. Note: This method is for Linux; follow the linked tutorial for enabling FIPS for MongoDB on Windows and macOS.

Data-level security for MongoDB

This section details best practices for using database-level security to define the privileges and actions available to a user when accessing the database and its activities.


Authentication is an essential step of database security. The purpose of authentication is to validate the user’s identity so that only trusted users can access the database’s resources.

User authentication can be set up during and after the connection. You can use the following steps for setting up authentication during connection:

To set up the authentication of the user after the connection, you need to make the following changes:


Authorization occurs if authentication has been successful. Once you’ve verified the user’s identity, the next step is to determine their privileges regarding access to resources.

You can set up role-based authorization for the users using the following steps:

These settings allow the user to drop the connections and kill their own operations at the cluster level. The user can remove the role of any user from the specified database at the DB level.

Check out the documentation to learn more about MongoDB users and roles.


Auditing tracks and keeps you updated on system activities at the deployment level. You can view the audits in the command line and store them in a JSON file. There are two ways to do this:

Enterprise-only features

MongoDB Enterprise is a commercial edition with some advanced security add-ons. This section covers two of the most significant enterprise-only features of MongoDB: LDAP proxy and encryption at rest.

LDAP Proxy

Lightweight distributed access protocol, or LDAP, is an industry standard for accessing and maintaining distributed directory information services over an Internet Protocol network.

For a simple understanding, you can utilize the following command to authenticate the database server running with the LDAP authentication and authorization:

To learn more, see the documentation on LDAP proxy authentication.

Encryption at rest

While you’ve seen the encryption of the network traffic in the form of TLS/SSL, encryption at rest defines the encryption of stored data. Database keys are utilized for this purpose.

The following are the steps for setting up encryption at rest for MongoDB with the key file (that is, the file containing your keys):

MongoDB Atlas security considerations

This section covers some of the security features you can utilize in MongoDB Atlas.

API Key Access

With an API key you can configure various permission levels determining who can access your data. To create and configure an API key follow these steps:

  1. Navigate to the API Keys in the Access Manager.
  1. Enter the key name and set the desired permission level under Project Permissions.
  1. The Public Key and Private Key will be generated. Note the private key will disappear once you leave the page, so copy and save it somewhere in the system.
  1. By clicking Add Access List Entry, you can specify the IP addresses you want to access the project.
  1. This creates your API Key with the required details.
Securing access

You can enable further security features like LDAP AuthenticationLDAP AuthorizationEncryption at Rest using your Key ManagementDatabase Auditing, and Self-managed X.509 Authentication from the Advanced option under Security.

Secure access to MongoDB using Remoteler Database Access

Remoteler Database Access is an ideal solution for making your databases secure. This open-source project provides you with secure access to many popular databases, including MongoDB, MySQL, PostgreSQL and more. Remoteler has some great features that can help improve your organization’s MongoDB security. It can:

  • Improve access control and visibility throughout the organization.
  • Certificate authority (CA) management that makes it simple to use TLS auth.
  • Remove regular authentication credentials. Instead, the user can access the database using a single sign-on flow and database certificates.
  • Improve security measures through implementing custom access request workflows.
  • Secure your database with powerful role-based access control configurations.
  • Record all database events via a detailed audit log.

If any of these features align with the requirements of your organization, you can get started with these simple steps:

  1. Watch the Remoteler Database Access Webinar.
  2. Check out the Remoteler documentation for a step-by-step guide to MongoDB Atlas and self-hosted MongoDB.
  3. Explore Remoteler code on GitHub.


Security is an essential component of every system, which requires that data is secure and encrypted. Databases are integral components of software architecture as they often house private data. This makes them a target for hackers and cybercriminals. Therefore, the security of your databases is pivotal to your company’s success.

This article described methods of protecting MongoDB on three levels of security: network, transport and database. You can make all these security measures consistent and efficient by utilizing Remoteler, an identity-aware, multi-protocol access proxy.

If you would like to learn more about securing MongoDB, we recommend our post on Securing MongoDB.

Try Remoteler Today!

Leave a Reply