The essential guide to MongoDB security

MongoDB security is in the news again. A recent spate of stories reveals how hackers have been seizing MongoDB databases and ransoming the data for bitcoins. Tens of thousands of MongoDB installations have been compromised, according to Rapid7.

We all worry about security. If you run applications, networks, or databases, security is always a top-line issue. With more companies turning to open source software such as MongoDB to store important enterprise data, security becomes an even bigger question. Depending on your business, you might also have multiple government (such as the Health Insurance Portability and Accountability Act, or HIPAA) or business (Payment Card Industry Data Security Standard, or PCI DSS) network security regulatory standards with which you need to comply.

Is MongoDB database software secure? Does it meet these standards? The short answer: Yes it is, and yes it does! It’s simply a matter of knowing how to set up, configure, and work with your particular installation.

In this article, I’m going to address MongoDB security. MongoDB is safe to use -- if you know what to look for and how to configure it.

First of all, how do people go wrong with MongoDB security? There are several key areas that trip up users when it comes to MongoDB security:

• Using the default ports
• Not enabling authentication immediately (the biggest issue!)
• When using authentication, giving everyone broad access
• Not using LDAP to force password rotations
• Not forcing SSL usage on the database
• Not limiting database access to known network devices (application hosts, load balancers, and so on)
• Not limiting which network is listening (however this no longer affects any supported versions)

MongoDB has five core security areas:

• Authentication. LDAP Authentication centralizes items in your company directory.
• Authorization. Authorization defines what role-based access controls the database provides.
• Encryption. Encryption can be broken into At-Rest and In-Transit. Encryption is critical to securing MongoDB.
• Auditing. Auditing refers to the ability to see who did what in the database.
• Governance. Governance refers to document validation and checking for sensitive data (such as an account number, password, Social Security number, or birth date). This refers to both knowing where sensitive data is stored and preventing sensitive data from being introduced into the system.

LDAP authentication

MongoDB has built-in user roles and turns them off by default. However, it misses items like password complexity, age-based rotation, and centralization and identification of user roles versus service functions. These are essential to passing regulations such as PCI DSS compliance. For example, PCI DSS prohibits the use of old passwords and easy-to-break passwords and requires changes to user access whenever status changes (for example, when the user leaves a department or the company).

Thankfully, LDAP can be used to fill many of these gaps. Many connectors allow the use of Windows Active Directory (AD) systems to talk with LDAP.

Note: LDAP support is only available in MongoDB Enterprise. It’s not in the Community version. It is available in other open source versions of MongoDB such as Percona Server for MongoDB. 

MongoDB 3.2 stores users in LDAP, but not roles (these are currently stored on the individual machines). MongoDB 3.4 Enterprise should introduce the ability to store roles in LDAP for centralized access. (We’ll discuss roles later.)

Percona

Utilizing LDAP and AD, you can tie users in with your corporate directory. When they change roles or leave the company, they can be removed by human resources from your database group. Thus, you have an automated system in place to ensure only those you want to access the data manually can do so, without accidentally missing something.

LDAP in Mongo is actually easy. MongoDB has a special command to tell it to check the external LDAP database: $external.

Some other caveats for using LDAP:

• Create a user with .createUser as you normally would, but be sure to go with db/collection resource tags.
• In addition, LDAP authentication requires two more fields:
  • mechanism: “PLAIN”
  • digestPassword: false

Custom roles

Role-based access control (RBAC) is core to MongoDB. Built-in roles have been available in MongoDB since version 2.6. You can even craft your own, right down to the specific actions a particular user might be allowed to do. This allows you to define what a particular user can do or see with razor precision. This is a core MongoDB feature that it is available in nearly every vendor’s version of the open source software.

The five main built-in MongoDB roles you should be aware of:

• read:
  • Read-only access, typically given to most users
• readWrite:
  • readWrite access allows editing data
  • readWrite includes read
• dbOwner:
  • Includes readWrite, dbAdmin, userAdmin (for the database). userAdmin means adding or removing users, granting privileges to users, and creating roles. These privileges are assigned only to the specific database server.
• dbAdminAnyDatabase:
  • Creates dbAdmin on all databases, but doesn’t allow user administration (to create or remove users, for example). You can create indexes, call compactions, and more. This doesn’t provide sharding access.
• root:
  • This is a superuser, but with limits
  • It can do most things, but not all:
    • Unable to change system collection
    • Some commands are still not available to this role, depending on the version. For example, the MongoDB 3.2 root role doesn’t allow you to change the oplog or profiler size, and the MongoDB 3.4 root role doesn’t allow you to read the current views.

Wildcarding databases and collections

Wildcarding means granting permissions to large groups of databases or collections (or all of them) on a server. With a null value, you can specify all databases or collections and avoid the dbAdminAnyDatabase role. This allows specific users to have all the privileges, including administration functions.

This is dangerous.

When you use wildcards, you grant a lot of special privileges, and you should be aware that you are opening up possible avenues of attack:

• readWriteAnyDatabase is extremely wide and exposes user names and roles to a potential attack via the application user
• Using wildcards means you won’t limit specific applications to specific databases
• Wildcarding prevents you from using multitenancy with multiple databases
• New databases aren’t automatically granted access

Creating a custom role

The power of MongoDB roles comes from creating custom roles. In a custom role, you can specify that any action on any resource can be specified for a specific user. With this level of granularity, you can deeply control who can do what in your MongoDB environment.

When it comes to specifying a custom role, there are four distinct types of resources:

• db. Specifies a database. You can use a string for a name, or “” for “any” (no wildcarding).
• collection. Specifies a collection of documents. You can use a string for a name or “” for “any” (no wildcarding).
• cluster. Specifies a sharded cluster or other metadata resources. It is a Boolean value of true/false.
• anyResource. Specifies access to anything, anywhere. It is a Boolean value of true/false.

Any role can inherit the properties of another role. There is an array called “roles,” and you can drop a new role in the array. It will inherit the properties of the specified role.

Use createRole to add a role to the array.

You can add new or existing databases to a user or a role. For example, you could add read and write access to a database by appending the database to a role.

Use the grantPrivilegesToRole command to add new resources to an existing role.

Below is an example of creating a new Super user role. The purpose of this role, again, is to have one user that is in no way restricted in the MongoDB environment (for emergency situations).

db = db.geSiblingDB(“admin”);
db.createRole({     
     role: “superRoot”,     
     privileges:[{          
          resource: {anyResource:true},          
          actions: [‘anyAction’]     
     }]     
     roles:[]
});
db.createUser({     
     user: “comanyDBA”,     
     pwd: “EWqeeFpUt9*8zq”,     
     roles: [“superRoot”]
})

These commands create a new role on the database geSiblingDB called superRoot and assign that role any resource and any action. Then we create a new user on the same database called companyDBA (with a password) and assign it the new superRoot role.

Using SSL for all things

SSL helps ensure the security of your data over unsecured networks. If you employ a database that interacts with the internet, you should use SSL.

There are two very good reasons to use SSL to secure MongoDB: privacy and authentication. Without SSL, your data can be accessed, copied, and used for illegal or harmful ends. With authentication, you have a secondary level of safety. SSL's private key infrastructure (PKI) guarantees that only users with the correct CA certificate can access MongoDB.

MongoDB has had SSL support for a long time, but has dramatically improved SSL support in the last few versions. Previously, if you wanted to use SSL, you had to download it and compile it manually with the MongoDB Community version. As of MongoDB 3.0, SSL is compiled with the software by default. 

Legacy versions of MongoDB also lacked valid host checking; host validation was merely a flag that you could check in the configuration file that satisfied an SSL request from a connection.

The latest versions of SSL in MongoDB include the following key features:

• Checks for valid hosts (optional)
• Ability to point to a specific setup .key file to use
• Custom Certificate Authority (CA) for self-signed certs or alternative signers
• allowSSL, preferSSL, requireSSL modes, which allow you to select a granularity for your SSL use (from less secure to more secure)

SSL: Using a custom CA

The newer versions of SSL in MongoDB allow you to use a custom CA. While this gives you flexibility in specifying how you want to work with SSL, it comes with caveats. If you're simply trying to secure the connection, you might be tempted to opt for sslAllowInvalidCertficates. However, this is generally a bad idea for a few reasons:

• Allows any connection from expired to revoked certificates
• You are not ensuring restrictions to a specific hostname
• You’re not nearly as secure as you think you are

To fix this, simply set net.ssl.CAFile, and MongoDB will use both the key and CA file (you must do this on the client).

Using SSL, however, has a known drawback: performance. You will definitely lose some performance when using SSL.

Disk encryption

Data is either “in transit” or “at rest.” You can encrypt either or both in MongoDB. We’ve discussed data encryption in transit (SSL). Now let’s look at data at rest.

At-rest data is data stored on disk. Data-at-rest encryption typically refers to data saved to an encrypted storage location. This is to prevent theft by physical means and create backups that are stored in a fashion not easily read by any third party. There are practical limits to this. The biggest is trusting your system administrators -- and assuming a hacker hasn’t obtained administrative access to the system.

This is not an issue unique to MongoDB. Preventive measures used in other systems work here as well. They might include encryption tools like LUKS and cryptfs or even more secure methods such as signing encryption keys with LDAP, smart cards, and RSA-type tokens.

When performing this level of encryption, you need to consider factors like automounting and decrypting of drives. But this is not new to your system administrators. They can manage this requirement in the same way they manage it in other parts of the network. The added benefit is a single procedure for storage encryption, not one per whatever technology a particular function uses.

Data-at-rest encryption can be solved with any or all of the following:

• Encrypt the entire volume
• Encrypt only the database files
• Encrypt in the application

The first item can be solved with disk encryption on the file system. It is easy to set up using LUKS and dm-crypt. Only the first and second options are required for PCI DSS compliance and other certification requirements.

Auditing

Central to any good security design is being able to track which user did what action in the database (similar to how you should control your actual servers). Auditing allows you to filter the output of a particular user, database, collection, or source location. This generates a log to review for any security incidents. More important, it shows any security auditor that you’ve taken the correct steps to protect your database from an intrusion and to understand the depth of any intrusion should one occur.

Auditing allows you to fully track the actions of an intruder in your environment.

Note: Auditing is available only in MongoDB Enterprise. It’s not in the Community version. It is available in some other open source versions of MongoDB such as Percona Server for MongoDB.