Davi Ottenheimer

3 results

Exciting New Security Features in MongoDB 4.0

We would like in this blog post to highlight two of the most important security enhancements delivered in MongoDB version 4.0 : SHA-256 support and TLS improvements. The General Availability of 4.0 was announced on June 27, 2018 at MongoDB World 2018. Its multi-document ACID transactions, new native type conversions, Kubernetes integration, as well as new tooling and cloud services , make it our most significant release ever!

October 11, 2018

New MongoDB 3.6 Security Features

MongoDB has always made it quick and easy to iterate -- from prototype to production to maturity, keeping pace in modern agile release cycles. Our 3.6 release is a milestone in security, adding two new features to improve the ease and cost of security management, even for the most fast-paced development environments. Localhost Default Flexibility has led to widespread adoption of MongoDB by users who appreciate the ease of installation and use. These same users also expect a level of balance between performance and safety that only can be achieved with secure-by-default configurations. This is why we are happy to now provide our users with a localhost binding set by default. Upon installation MongoDB (3.6 and later) can only be accessed from the local machine on which it has been installed (using Mongo shell, a MongoDB driver, or tools and utilities such as Ops Manager or Compass). When MongoDB is started it has to have networking explicitly enabled and configured. What happens when you connect your instance to the internet? “If you explicitly turn on [networking], but don’t turn on authentication, we can’t help you at that point. But you have to consciously do that, and we’d hope that people think about it a little” CTO Eliot Horowitz explained to The Next Web . We see this change as fundamentally raising the bar on safety, eliminating whole classes of threats, while still preserving our popular deployment speed and ease. IP Whitelisting for Authentication After enabling whitelisting , a client authenticating against a user account in MongoDB must meet all listed restrictions in any document attached to that user. Clients authenticating against a user account which is a member of a restricted role must meet all listed restrictions in any document attached to that role. For example here is how a document attached to a database user or role can be set to only allow 192.168.17.6 clients to connect. Beyond that it can be set to only connect to the services listening in 10.10.10.0/24. Using the following syntax an IP must be matched during authentication to login. authenticationRestrictions: [{ clientSource: [“192.168.17.6”, “127.0.0.1”] serverAddress: [“10.10.10.0/24”, “127.0.0.1”] }] We’re always striving to make safe development easier. That’s why we have taken an approach to facilitate safe choices within a flexible product, in order to serve the many development community decisions for deploying MongoDB. The security changes in 3.6 remove bottlenecks and obviate workarounds, expanding MongoDB use to an even wider variety of applications, and providing security teams the configurations they demand for mission critical situations. MongoDB 3.6 applies the "safe by default" principle so you can confidently move at the speed of your data. To learn more about everything new in MongoDB 3.6, download the What's New guide . About the Author - Davi Ottenheimer Davi leads Product Security at MongoDB.

December 19, 2017

Update: How to Avoid a Malicious Attack That Ransoms Your Data

A New Wave of Ransomware Attacks Reports have emerged of a new wave of ransomware attackers searching for misconfigured and unmaintained instances of MongoDB. We have been monitoring the situation closely to help investigate and provide assistance. It is important to note this new wave of attacks does not indicate a new risk, just new targets. However, the new wave displayed some characteristics that merit further investigation: for example, we note that just one threat identity has claimed most of the newly targeted deployments. We’ve reviewed these details to understand where and when users left systems insecure – connected to the Internet with no password on their Administrator account – and who is attacking them. Here’s What’s Coming Our approach is to facilitate safe choices for users, within a flexible product serving the many communities developing on and deploying MongoDB. Helping direct users towards safe network options is why since release 2.6.0 we have made localhost binding the default configuration in our most popular deployment package formats, RPM and deb. This means all networked connections to the database are denied unless explicitly configured by an administrator. Beginning with development release version 3.5.7, localhost-only binding is implemented directly in the MongoDB server, making it the default behavior for all distributions. This will also be incorporated into our upcoming production-ready 3.6 release . In addition, we added a warning to our download center to ensure users know the network configuration risks with non-packaged distributions. MongoDB Atlas , our database-as-a-service, further simplifies deployment decisions by providing secure infrastructure by default. Whether users set up a free instance or full production cluster, choosing our cloud option means getting security best practices as a service, which prevents misconfigured instances. We’re Always Striving to Make Safe Deployment Easier Our post from earlier this year – titled “ How to Avoid a Malicious Attack That Ransoms Your Data ” – guided users through the simple steps to prevent or diagnose and respond to such an attack. If you or someone you love runs MongoDB, please point them to our freely available guides to MongoDB’s built-in security features : access controls, encryption, and detailed auditing. For example, our Security Checklist provides current best practices and links to in-depth documentation to ensure deployments are secured. We made it easy for users to run daily security tests to send alerts on whether their instance is exposed to the public Internet. And we offer even broader training for all features and deployment practices through free online MongoDB University courses such as M310: MongoDB Security , covering native and third-party integration security features and resources. We thank the responders and researchers working on this and will continue to monitor and investigate. About the Author - Davi Ottenheimer Davi leads Product Security at MongoDB.

September 8, 2017