Percona Monitoring and Management (PMM) is a great way to monitor your MongoDB deployment for things like memory, CPU, inter-database metrics like wiredTiger cache utilization, read/write ticket utilization, Query Analytics, and many, many more. Did you know that in addition to all that, it also has a security threat tool? In this blog, we’ll go over the Security Threat Tool and its checks for MongoDB. We’ll discuss how they can bring you value by helping you prevent MongoDB data leaks.
What is the Security Threat Tool?
The Security Threat Tool is a widget in your main PMM dashboard that runs regular checks against connected databases, alerting you if any servers pose a potential security threat. By default, these checks are run every 24 hours, so the checks will not be in real-time. You can run them ad-hoc by going to PMM/PMM Database Checks in your PMM Grafana Dashboards and clicking on the “Run DB Checks” button. When you first enable the Security Threat Tool it can take up to 24 hours for the results to populate, assuming you do not use the ad hoc button. In addition to MongoDB, the Security Threat Tool, like PMM itself, can also check MySQL, PostgreSQL, and MariaDB for various security threats. Additionally, if you find a check is too noisy, you do have the ability to silence it in PMM so that it no longer shows as a failed check.
What Does the Security Threat Tool Check for MongoDB?
At present, the Security Threat Tool checks MongoDB for two security-related items, mongodb_auth, and mongodb_version. First, mongodb_auth checks to be sure that MongoDB authentication is enabled on your deployment. Finally, mongodb_version checks to make sure that you’re running the latest version of MongoDB that you’re on.
mongodb_auth
Checking MongoDB to ensure that authentication and authorization are enabled is of paramount importance to the security of your database. If authentication and authorization are disabled for your MongoDB deployment, then anyone who can reach the port that you have MongoDB running on will have access to your data. Disabled authentication and authorization as well as binding to all of your interfaces on your machine have been the cause of many data leaks over the years with MongoDB. Having this check can help you and your MongoDB deployment from leaking data.
This check can also be helpful if you’re performing maintenance and need to temporarily disable authentication on a secondary or hidden node and forget to re-enable authentication and authorization when you’re done.
mongodb_version
Many organizations are requiring more frequent patching or upgrading of software, especially databases that often house the most critical data for your applications, in order to stay on top of changing security requirements. With MongoDB’s replica set and sharded cluster architecture, it’s fairly easy to upgrade in a rolling manner and keep up to date on your MongoDB versions (after appropriate testing of the new versions!). This checks to make sure you’re running on the latest version of the minor release that your MongoDB database is running on. For example, your 3.6 version of MongoDB won’t alert telling you there’s a newer version of MongoDB 4.4 but will tell you when a new minor version of MongoDB 3.6 is released and can be upgraded to. Staying as close as possible to the latest minor release assures that you get as many bug fixes as are available and just as importantly, any security fixes for that version of MongoDB. You want to minimize your security exposure by being up to date and having as many security vulnerabilities patched as are available.
Summary
We hope that this blog post has helped you to see how enabling the Security Threat Tool in Percona Monitoring and Management can help you keep your MongoDB deployment secure. Thanks for reading!
Percona Monitoring and Management is free to download and use. Try it today!
