This blog was originally published on August 10, 2020, and was updated on August 1, 2023.
“I think most of the time hackers behind the attacks do it just for fun, because they can and because it’s very simple”, — says Diachenko. Source: “Meowing” attack completely destroyed more than 1000 databases
These are the words of Bob Diachenko, one of the most respected cybersecurity researchers in relation to a “Meowing” attack, which destroyed between 1000-4000 databases around the world.
Whether it’s for fun or for money, this is not the first reported attack, and it won’t be the last (of 2020). With an increasing number of databases in the cloud, the question is now not a matter of IF it will happen again, but when.
Because of its NoSQL origin and document architecture design, MongoDB is much more flexible and scalable than SQL databases such as MySQL. As a result, typically, much more data is stored in MongoDB than in traditional SQL databases. MongoDB databases commonly exceed a terabyte of data. The large amount of data exposed in a single database makes breaches involving MongoDB much more devastating.
The good news is that most of the actions you should take to avoid this are simple to execute. If you are using the open-source Percona Distribution for MongoDB, you also have extra features such as LDAP authentication support, which is present in the Enterprise and Atlas MongoDB versions.
What does MongoDB offer to mitigate security threats? Let’s explore the top five measures that we can take when securing MongoDB.
Watch Now: Using Open Source Software to Secure Your MongoDB Database
MongoDB Security Features and Best Practices
Authentication in MongoDB
Most breaches involving MongoDB occur because of a deadly combination of authentication disabled and MongoDB opened to the internet. MongoDB provides support for authentication on a per-database level. Users exist in the context of a single logical database. However, MongoDB does not support items like password complexity, age-based rotation, and centralization and identification of user roles versus service functions.
Thankfully, LDAP can fill many of these gaps. Many connectors allow the use of Windows Active Directory (AD) systems to talk with LDAP.
LDAP support is available in MongoDB Enterprise but not in MongoDB Community Edition. However, it is available in other open-source versions of MongoDB, such as Percona Server for MongoDB.
MongoDB supports other various authentication mechanisms for secure access control. Some mechanisms include the default method starting in MongoDB 4.0, SCRAM-SHA-256 (Salted Challenge Response Authentication Mechanism), as well as SCRAM-SHA-1, and x.509 certificates for SSL/TLS connections for integrating with external directory services.
Note: LDAP in the Percona Distribution for MongoDB will work with MongoDB Compass. In the following links, we describe how to use LDAP:
Percona Server for MongoDB LDAP Enhancements: User-to-DN Mapping
Percona Server for MongoDB Authentication Using Active Directory
Authorization: Role-Based Access Control
Enabling role-based access control on a MongoDB deployment enforces authentication, requiring users to identify themselves. When accessing a MongoDB deployment that has access control enabled, users can only perform the actions determined by their roles. Replica sets and sharded clusters also require internal authentication between members when access control is enabled. It is essential to follow the principle of least privilege. No one should have more permissions than they need to do their job, and even a DBA should log in with a non-elevated account.
MongoDB grants access to data and commands through role-based authorization and include built-in roles that provide the different levels of access commonly needed in a database system. Additionally, it is possible to create user-defined roles.
To create a role in MongoDB and add it to a user:
1 2 3 4 5 6 7 8 | db.createRole({ role : 'write_foo2_Collection', privileges : [ {resource : {db : "percona", collection : "foo2"}, actions : ["insert","remove"]} ], roles : ["read"] }) db.updateUser('client_read', roles : ['write_foo2_Collection']) |
Transport Encryption in MongoDB
MongoDB has support for using transport encryption between the client and the nodes, and between the nodes in the cluster. Encrypting traffic ensures that no one can “sniff” sensitive data on the network. For example, tools like Wireshark or Tcpdump can easily capture unencrypted sensitive data such as usernames and passwords.
MongoDB supports X.509 certificate authentication for use with a secure TLS/SSL connection. Members can use X.509 certificates to verify their membership in the replica set and shards.
It is necessary to create certificates on all nodes and have a certificate authority (CA) that signs them. As using a CA can be costly, it is also possible to use self-signed certificates. Using a public CA is not necessary inside a private infrastructure.
Here are the detailed steps to create the certificates and configure Mongo:
MongoDB: Deploy a Replica Set with Transport Encryption
Data Encryption in MongoDB
One of the most severe problems with MongoDB was that data files didn’t have encryption at rest. Since version 3.6.8, Percona Server for MongoDB has offered at rest encryption for the MongoDB Community Edition. In upstream MongoDB software, data encryption at rest is available in MongoDB Enterprise version only.
The example below shows how to activate WiredTiger encryption for data at rest in Percona Server for MongoDB. First, it is necessary to edit the encryption options in mongod.conf:
1 2 3 4 5 | # Encryption variables in mongod.conf shell [root@app ~]# grep security -A2 /etc/mongod.conf security: enableEncryption: true encryptionKeyFile: /data/key/mongodb.key |
By default, Percona Server for MongoDB uses the AES256-CBC cipher mode. It is necessary to create the key with OpenSSL as below:
1 2 3 4 | # Create Encryption KeyShell [root@app ~]# mkdir /data/key [root@app ~]# openssl rand -base64 32 > /data/key/mongodb.key [root@app ~]# chmod 600 /data/key/mongodb.key |
Now start Percona Server for MongoDB:
1 | [root@app ~]# systemctl start mongod |
To check whether encryption is successfully enabled in the database, use the command below:
1 2 3 | # Security outputShell mongo > db.serverCmdLineOpts().parsed.security { "enableEncryption" : true, "encryptionKeyFile" : "/data/key/mongodb.key" } |
PS: Note that for existing nodes, it is necessary to perform a new initial sync to encrypt the data.
Auditing in MongoDB
Auditing is not designed to mitigate a security threat but helps when investigating unauthorized access or tracking data access and modification. The general database auditing concept is about tracking the use of database records and authority. When we audit a database, each operation on the data can be monitored and logged to an audit trail. This includes information about which database object or data record was touched, which account performed the action, and when the activity occurred.
MongoDB Atlas offers audit logging natively, as does MongoDB Enterprise Edition and Percona Server for MongoDB. To enable the audit log in Percona Server for MongoDB in the command line or the config file, add these entries in the command line:
1 | mongod --dbpath /var/lib/mongodb --auditDestination file --auditFormat BSON --auditPath /var/lib/mongodb/auditLog.bson |
Or in the MongoDB configuration file:
1 2 3 4 | auditLog: destination: file format: BSON path: /var/lib/mongodb/auditLog.bson |
Database monitoring
To detect suspicious behavior in MongoDB, set up a monitoring tool like Percona Monitoring and Management to watch for odd query patterns, failed authentication attempts, and suspicious transactions. You can configure alerts for any unusual activities and flag them for further investigation.
Network Security
Configuring firewalls and network settings for MongoDB involves restricting access to specific ports to trusted IP addresses and limiting incoming traffic from untrusted hosts. Utilizing a Virtual Private Cloud (VPC) isolates MongoDB instances, reducing exposure to potential threats. Properly configured firewall settings are crucial to prevent unauthorized access; for best results, only traffic from trusted sources should be able to reach mongod and mongos instances, and they can only connect to trusted outputs.
Regular Security Updates and Patches
Keeping MongoDB up to date is vital for security. Staying informed and up to date on security patches, bug fixes, releases, and revisions ensures protection against vulnerabilities, minimizes risk and maintains data integrity.
MongoDB Configuration Hardening
Enhancing security in MongoDB database systems involves additional hardening measures, such as:
- VPNs provide a tunnel to link two networks over an encrypted and trusted network, securing remote access.
- Firewalls add an extra layer of defense against unauthorized access.
- IP binding, which restricts connections to only trusted addresses
- Disabling IP forwarding, which can help prevent data leaks
Learn Now: 5 Configuration Options That Impact Security and How to Set Them
Learn How You Can Secure Your MongoDB Environment
It is vital that you secure your database before the deployment phase. The MongoDB security measures mentioned above can be automated using tools like Ansible/Puppet and are a good start to secure your database. A MongoDB database with these security measures taken would not be affected by the Meow attack.
For further information on database security, please watch our recent webinar from Akira Kurogane, MongoDB Lead, Percona – On-Demand Webinar: Securing MongoDB.
Learn more about the history of Oracle, the growth of MongoDB, and what really qualifies software as open source. If you are a DBA or an executive looking to adopt or renew with MongoDB, this is a must-read!
Download “Is MongoDB the New Oracle?”
