A recent spate of ransomware attacks on MongoDB databases has taken a different direction. The recent attacks appear to be much like the attacks that have been targeted towards MongoDB databases since 2016 - which I blogged about a while back - with a different twist. Following the news about the MongoDB attacks, the attackers are now contacting the victims General Data Protection Regulation (GDPR) enforcement authorities to report their data leak. The attackers have also been seen to be connecting to the same database they attacked before, leaving a ransom note a few days later. The activity is purported to be a mistake in how the attackers have designed their infrastructure. Interestingly enough, this replay of hacking activities brings out the fact that MongoDB security mis-configurations are still prevalent. In the wake of that realization, we walk you through options you can use to harden your MongoDB instance.
Options for Hardening your MongoDB instance
MongoDB gives you the option to configure username and password-based authentication. With this method of authentication, you can connect to your MongoDB instance by specifying a username and a password with the mongo command-line tool, or you can connect to the database and run the db.auth() or authenticate command to get access to the database.
Also, MongoDB supports quite a lot of authentication mechanisms including:
- Salted Challenge Response Authentication Mechanism (SCRAM) - The default authentication mechanism that verifies the username, password, and authentication database. The authentication database is the database where the user has been created.
- X.509 certificate-based authentication - This authentication mechanism makes use of mutual authentication using certificates. The client can use certificates instead of the typical username and password to authenticate to the MongoDB database.
If you are a MongoDB Enterprise customer you have the opportunity to use LDAP proxy authentication or Kerberos authentication as well. Authentication can also be made more granular by having members of replica sets and shared clusters authenticating their membership to their respective replica sets or sharded clusters.
Configure Role-Based Access Control (RBAC)
MongoDB gives you the option to enable access control which is not enabled by default. With access control enabled you can create users and assign them roles. Before then you can create roles and assign the roles with privileges on different database resources.
You can configure TLS/SSL for all incoming and outgoing connections. You can ensure that there is encrypted communication for your mongod and mongos. Both mongod, the primary daemon process for the MongoDB system, and mongos, which provides an interface between client applications and the MongoDB cluster, can be configured to run with TLS Mode which enables TLS to be used for all network communications. In both cases, you have to also configure a certificate that is issued by a Certificate Authority (CA) or provide a self-signing certificate (although that latter option may be susceptible to man-in-the-middle attacks).
Data encryption can be achieved by employing file-system, device, or physical encryption. With a tool such as dm-crypt, you are able to encrypt your filesystem where your MongoDB data resides. You could also make use of a database backup tool that has an encryption capability when you need backups as we shall see in another section.
Limit Network Exposure
It is important to ensure that you also limit network access to your MongoDB instance by placing it in a trusted network environment and configure a firewall to control inbound or outbound traffic when necessary. Too often, MongoDB instances are getting attacked due to network exposure in cloud environments that may be unnecessary. After doing a MongoDB installation, you can make use of network scanning tools on your MongoDB instance to get a perspective of what ports are exposed on public networks so that you can limit exposure especially to automated attacks like the ransomware attacks we have mentioned at the beginning of this article.
Audit System Activities
Change in systems is inevitable; as such, tracking access and changes to database configurations and data are quite key for your database security.
Run MongoDB with a Dedicated User
When installing and running the MongoDB processes, you need to ensure they run with a dedicated user account. It limits access to your operating system in case there are misconfigurations or vulnerabilities on MongoDB that may otherwise allow attackers to access the underlying operating system by exploiting those misconfigurations or vulnerabilities. Running the MongoDB instance with administrative accounts like root is not ideal.
Other Secure Configuration Options
- Keep input validation enabled - MongoDB input validation by default. That ensures that all the document objects stored by MongoDB are valid BSON.
Request for a Security Technical Implementation Guide (STIG)
The MongoDB team can issue you with a STIG based on your security needs. You can request for the STIG that will help you harden your MongoDB via their website.
For more information about hardening please refer to this link: Security Checklist — MongoDB Manual
Securing your Backups
Over and above the security configurations for your database you also need to keep backups. Backups ensure you are protected in the event that you may lose your data when you succumb to attacks like ransomware, insider threats, or any systemic failures. Also, not forgetting those database backups need to be secured as much as your database. At a minimum, you have to ensure that your database backups are encrypted to prevent data theft.
- Authenticate systems and your users to verify trusted identities.
- Limit your users and system to only what they need to access in your database.
- Encrypt your data at-rest and in-transit.
- Keep track of access and changes within your database.
- Limit network access to only trusted entities.
- Disable unneeded features.
- Backup your data and ensure you backup securely.