Auditing NoSQL Databases (MongoDB) with Nessus v6
To SQL or NoSQL is the big debate among database experts these days. Both types of databases have fundamentally different architectures and support different use cases; hence, they have different pros and cons. On one end you have a mature 40 year old, stable and well understood relational database management system (RDBMS); on the other end you have a young and upcoming, five-year old DBMS which promises the world to you.
With a NoSQL database, there is no need for a predefined schema; sharding is automatic and native (i.e., data is spread across an arbitrary number of servers without much effort) and replication of data is a breeze with no additional tools required to manage the replication. RDBMS experts can't even dream of such prospects. But on the other hand, RDBMS offers a predictable SQL query language. Once you know SQL, you can safely navigate your way around any other RDBMS without losing much sleep. Also, migrating data from one RDBMS to another is well documented and straightforward, so you are not locked in to the same database forever. In its current state, NoSQL databases can't make a claim to any of those benefits.
Nessus v6 includes a TNS MongoDB 2.x Best Practices Database Audit
By now you might be wondering why Tenable is giving you a primer on these databases. Well, it turns out that even with all these differences, when it comes to securing the databases, SQL and NoSQL do have a lot in common. Nessus has been helping customers audit a wide variety of databases (MySQL, MS SQL, Oracle, DB2, PostgreSQL, and Informix) since 2009. And since then, we have built on this technology to offer a wide variety of CIS, DISA STIGs, and vendor based audits in Nessus to provide recommendations for hardening databases. In fact, some of our customers won't deploy an application in production unless there is a Nessus audit for it. This is a humbling proposition, but at the same time, a deployment delay could be a major concern on-site.
Tenable has added support for the MongoDB database to the list of databases that can be audited with Nessus. Nessus v6 includes a TNS MongoDB 2.x Best Practices Database Audit. This is the first NoSQL database that Nessus can audit.
So what are some of the common steps you should take to secure MongoDB?
Secure both the OS and the DB
Your defenses are only as strong as your weakest link. If you focus all your resources on securing the database and you leave the operating system wide open (or vice-versa), sooner or later someone is going to figure out a way to get in. Therefore, you should lock down both the database and the operating system.
Configure Role-Based Access Control (RBAC)
It is said that common sense is not common at all, and for proof you need only look at RBAC (role-based access control). Why should read-only users have read-write privileges? They shouldn't. And the way to enforce that is through RBAC. Make sure roles — and the privileges that go with them — are accurately defined. Also, review users who are assigned one or more roles.
Authentication
Make sure you have authentication enabled. MongoDB supports multiple authentication mechanisms. Make sure MONGODB-CR (password authentication), x.509 cert, Kerberos or authentication is enabled through LDAP.
Encrypt communication
This one is obvious, but you shouldn't stop at just enabling SSL. You should also make sure weak or invalid SSL certificates are not allowed.
Limit network exposure
If you are not using a service, shut it down. For example, MongoDB provides JSON or RESTful interfaces for API interactions. If you are not using APIs to access the databases, shut those services down.
Audit system activity
Log user activity, check who logged in, when they logged in, and what commands they ran.
What does Nessus have to offer?
Now that you know what you need to do to lock down MongoDB, how does Tenable help? With Nessus v6, recently released audits help with all of the items referenced above.
But we didn't stop there. We added a lot more functionality than just the Best Practice audit. Nessus now has checks that might help with asset inventory management, asset discovery, and other use cases. For example, you may want to know the exact version of MongoDB that's running, or whether a specific instance of MongoDB is running in master or slave configuration. The audit will help you determine that. You can also run MongoDB shell commands directly from the .audit
file.
<custom_item>
description : "MongoDB ServerStatus"
collection : "admin.$cmd"
query : '{"serverStatus":1}'
</custom_item>
With the combined OS and DB checks, Nessus audits over 100 settings.
We are also looking out for those hardcore MongoDB fans who aren’t satisfied with pre-packaged policies and who like to chart their own way. The Nessus policies are highly customizable in any text editor so that you can support a multitude of use cases that are not already supported out of the box.
For more technical details, check the Discussion Forum MongoDB audit posts here and here.
Sample result
SecurityCenter Continuous View
SecurityCenter Continuous View (SC CV), using Nessus, also has the ability to audit database systems such as MongoDB, Microsoft SQL Server, Oracle, MySQL, PostgreSQL, DB2, and Informix. The SC CV Database Audit Results dashboard is a collection of components showing audit results over the past 90 days in a trend graph, a summary of compliance status with matrix and bar chart, followed by tables of the most prevalent failed audit checks. Using an asset (such as all servers running MongoDB services), this dashboard can be filtered to reflect data only from the MongoDB servers, or can show a collective status of all RDMS audits.
Conclusion
The database market had stagnated over the past few decades, but with the advent of NoSQL databases such as MongoDB, the fire has been lit again. For a Tenable researcher, it almost feels like being a kid in a candy store. And there is a lot more to come. Stay tuned!
Related Articles
- Dashboards
- Nessus
- Plugins
- Security auditing
- SecurityCenter