“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 the last “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.
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.
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 in MongoDB
Enabling 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:
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:
# 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:
# 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:
[root@app ~]# systemctl start mongod
To check whether encryption is successfully enabled in the database, use the command below:
# 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:
mongod --dbpath /var/lib/mongodb --auditDestination file --auditFormat BSON --auditPath /var/lib/mongodb/auditLog.bson
Or in the MongoDB configuration file:
auditLog: destination: file format: BSON path: /var/lib/mongodb/auditLog.bson
Conclusion
It is vital that you secure your database before the deployment phase. The five mentioned measures above can be automated using tools like Ansible/Puppet, and are a good start to secure your database. A MongoDB database with these five 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.
You can also access additional expert guidance and thought-leadership via our website.
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!