MongoDB is over a decade old. Yet, it still holds a certain veneer of being new and shiny. Most of this can be attributed to the entrenched and systematic implementation of SQL and developers’ general experience with it.
If you wanted to introduce MongoDB, there’s a high chance that it’ll be in a startup, or organizations that are open to experimental implementation. While there are cases where tableless databases are the preference, SQL-based systems have mostly dominated the industry.
As a result, most developers are highly skilled and have a solid understanding of SQL and its nuances. But when it comes to tableless structures like MongoDB, things are often implemented at the barebones level. This can often lead to vulnerabilities due to a lack of knowledge or awareness of the issues.
This brings us to our question: how safe is MongoDB?
The problem with unsecured databases
Between December 2016 and to around March 2017, almost 30,000 MongoDB databases were hacked, deleted, or put behind a ransom request. While most of the ransom demands were around $500USD, this was often enough to cause havoc on a company’s reputation, erode user trust, and various flow-on consequences.
So how did this happen?
It turned out that database admins did very little in terms of implementing security on their MongoDB configurations, leaving server images completely open and exposed by using default out-of-the-box values.
While MongoDB has mitigated this problem at the source by shipping with security defaults (rather than just a barebones solution), it still leaves room for security vulnerabilities to occur. The issue here is not because MongoDB is incapable of being secure but rather due to the lack of security protocol implementations on images and servers.
Role-based security in MongoDB
Since the release of MongoDB 2.6.0, access can only be done through local connections. Remote access was only available through an explicit setup that required the admin to be aware of their actions – thus, bringing responsibility on the admin as they are removing a security layer.
Despite the new security-first approach by MongoDB, 2018 still saw 445 million records exposed by a single company. While this may lead us to believe that the fault lies with MongoDB, the actual source of the vulnerability is a human one. The main reason for successful security breaches is because default data presets are used rather than configuring the installation.
While MongoDB has responded by creating stronger default settings, there are still steps that you can implement to prevent a hack or leak from occurring.
One of the easiest ways to implement this is through role-based access control (RBAC). What it does is give admins the ability to create custom roles that tailor to the different access needs and scope of access. Once the role has been created, it can be attached to a user, who is ringfenced off from the rest of the database.
To do this, log into your MongoDB and switch to the admin database via use admin. Create a root user with db.createUser(). From here, you can configure the username, password, and roles you want to attach to this particular user.
To create a role, use db.createRole() method to define the privileges and accessibility allowed. Here is an example of what the role document looks like:
Network encryption is available with MongoDB. This allows you to protect your database and communications through an industry-standard encryption methodology.
TLS and SSL are supported by the x.509 certificates, which clients can use to authenticate their identities. This is different from a username and password-based authentication method and requires the user to have physical permissions in the form of a security certificate.
MongoDB requires 128-bit key length and certificates can be self-signed, but this is often not recommended and best avoided if there is no validation of server identity as part of the process. However, the communications between MongoDB and the server are still encrypted, which means that data transferred is not compromised if it gets hijacked through a man-in-the-middle attack.
To do this, you need to set net.ssl.mode to requireSSL. There are no limitations on which certificate type you choose. MongoDB allows you to use a mix of TLS and SSL modes on a particular port, so you don’t have to exclusively use only one type of certificate and key.
You can find the TLS/SSL certificate and key in the PEMKeyfile, which is a file with a .pem extension.
Authentication Best Practices
There are multiple ways to authenticate and identify a user and a user’s accessibility to the database in MongoDB. The challenge-based defaults are currently set with SCRAM-SHA-1.
SCRAM-SHA-1 is a salted challenge authenticated mechanism that uses a simple text-based username and password with a secret salting key to encrypt and transport accessible data over a TLS based channel.
In addition to this, MongoDB can use LDAP — which stands for Lightweight Directory Access Protocol. This allows users to log in using a centralized password, allowing accessibility through both private and public networks.
Kerberos is also available in MongoDB. This methodology allows for single-use access and users can only log in once using their access tickets. This can come in handy for once-off authorizations where the admin doesn’t have to do a follow-up clean after the user has completed their task.
The best practice for authentication in MongoDB lies in the setup process. It is recommended that you always enable auth on the production install. While version 3.5 onwards is automatically enabled by default, it is still good practice to do a manual check and not just leave it to trust that it is enabled.
Always start your database by creating an admin user, followed by additional users with roles that filter down from the admin. Only the admin should have complete control and access to the database. Consistently track changes and be aware of anomalies in users, their roles and permissions. This will keep stray admin privileges’ from leaking to users that do not need it.
Implementing an encryption method will save your data from getting hijacked during transfer. TLS/SSL is often enough to solve this problem.
MongoDB’s security vulnerability is mostly a human one. Sometimes, the simplest security that you can implement can be as easy as requiring a strong password.
The more you move away from default users and demo databases, the more configured and secured your MongoDB instance will be. Defaults and demo database access is public information, making it easy for malicious users to exploit your data.
It is also good practice to conduct database audits at regular intervals. This means scheduling in the time to run over your trails, user accessibility, roles, and data anomalies that may be occurring. Automated encryption of backup data can also remove the human costs required to perform the task, and prevent errors and ransomware attacks.
Another thing to note is that standard usernames like root, user, admin, or app are easy to guess. Knowing the username is already half of your login security layer setup. If you are going to use an obscure or uncommon admin username, it is also good to have this stored in a separate and secure repository for systems admin transfers and handovers. This can prevent your new handover administrator from getting locked out from admin privileges to your MongoDB database.