How to secure MongoDB – because it isn't by default and thousands of DBs are being hacked The rise in ransomware attacks on MongoDB installations prompted the database maker last week to issue advice on how to avoid being victimized. As of Sunday, security researcher and Microsoft developer Niall Merrigan identified more than 27,000 MongoDB databases seized by ransomware. By Tuesday afternoon Pacific Time, an …
"MongoDB has the robust security capabilities that one would expect from a modern database"
I would expect that by default any database schemas I create as a user would only be accessible by said user unless I specify otherwise.
Closed by default unless granted permissions, not open by default unless permissions are explicitly added has been the way of databases for decades.
They just don't get it to they...that's the problem.
In 2017 there is absolutely no excuse for a software package (or OS for that matter) not being secure OTB. Christ even, microshaft realised that.
And yet they still patter out the same mince - 'its the users job'.
No it bloody isn't fuckwits - it's YOUR job.
I had a similar argument with a company who make an API creation product - and by default it exposes them over HTTP with 'basic authentication'... i.e. no security at all... even in the original HTTP RFCs it was mentioned that you should never use basic auth without HTTPS.. and that was frecking 20 years ago... and yet we have a major company doing it by default and hoping the user is smart enough to know that them ticking the user basic auth tickbox over HTTP and thinking there APIs are secure is about as much use as a chocolate fireguard.
And yet said company stand fast and say 'its not our job to stop the user doing stupid things'.
sigh... there's no winning that argument - it's like arguing with a christian/muslim/<insert faery believer here> - it's a waste of time if they don't get basic logical thought.
The company's response should have been "mea culpa, we're going to fix this", not "it's very secure if you set it up properly" - unsecure defaults are a sign nobody has even considered the consequences, and generally suggest that security was a rather late afterthought.
It makes it the Microsoft of databases - not to be trusted near a public connection. Given the numerous alternatives out there I'd suggest you drop this DB as soon as possible in favour of something developed by people who are a tad more intelligent. Your data will thank you (and possibly your boss and your customers).
It makes it the Microsoft of databases - not to be trusted near a public connection.
Curiously, Microsoft SQL is locked down to local connections only by default, and requires a certain amount of effort, and joined-up thinking, to make it accessible on a public connection, or even to any other host on the network.
I find it unfair to compare to M$. The latter needed nearly 15 years to figure out the simple fact that security is a must. PC-DOS/MS-DOS had no security whatsoever. Neither did Win 2.x/3.x/9x. The very concept of multi-user, security and authentication came only with WinNT 3.x, and remained unpolished until W2k/WXP. It would be fair to wait until around 2019 for MongoDB to figure the same simple fact. Any implementation of security before the 12-years period expiration could be considered a lesson on someone else's bad experience, i.e. a copyright violation.
> I find it unfair to compare to M$
You're right. They're *worse* than MS. MS at least had the excuse that they had a great deal of inertia to contend with, because most of it's products originated from a time where security wasn't as vital as it was now.
When MongoDB first came out, these problems had not only been well established, but solutions had already been devised. But MongoDB is a perfect example of modern developer mentality that everything old is bad, and everything new is guaranteed to be better. Not only do they not learn from history, but they actively eschew it, and so have to re-learn the hard way, all the hard-won lessons that were solved before.
"...I find it unfair to compare to M$. The latter needed nearly 15 years to figure out the simple fact that security is a must..."
In M$ slight defence here when they launched Windows it was in a world where most PCs were never connected to anything else anyway so there was less need to segregate privileges. Anybody starting to create a system nowadays should assume it's going to be connected to the world at large and configure it accordignly.
The very concept of multi-user, security and authentication came only with WinNT 3.x, and remained unpolished until W2k/WXP
I thin you'll find that concepts of mult-user, security, and arhentication came much sonner in the computer industry - at least by 20 years
There's a very good reason MongoDB doesn't make it secure by default. MongoDB is a clusterfuck from a technical perspective, and the only reason it's as popular as it is, is because they've succeeded at making it *look* simple (by sweeping half the concerns of database management under the carpet).
Incidentally, this is the same reason that users tend to switch to other database over time... because as it turns out, those concerns weren't optional after all, and now they have to suffer the consequences of ignoring them upfront.
But this is precisely why MongoDB can't really make it secure by default - this would make it appear less simple upfront, and thereby tarnish their only real selling point.
Obligatory commitstrip.
The original articles found that 78% of the mongoDB instances on AWS were running 2.4.9 I believe (possibly .8) when mongoDB is at version 3.4.
Not only does this smack of not paying the extra $20 per hour but also having no understanding of updating, software version tracking, and these DB's appear infrequently used suggesting that they were instantiated because of the big data hype then forgotten, so it's unlikely that back ups have been taken or that anyone knows how much or what data has been pilfered.
Unfortunately the oversight of the "gig" economy is such that over at freelancer.com "web scraping" is a valid "skills and expertise" suggestion and today's job adverts are "copying email from another site", "copy product details from another site" and "scrape linkedin profiles in UK". It's not even the money or the experience, it comes down the integrity of the developer and that metric is measured in stars from clients advertising the aforementioned.
"A spokesperson [...] insisted that MongoDB is not less secure than relational databases like MySQL and PostgresSQL, and pointed to the company's list of security best practices."
Translation: So it is not secure, they just tell you how you can make it secure.
"MongoDB has the robust security capabilities that one would expect from a modern database,"
... but for some reason we believe that our users' preference is to not have a secure installation, so we don't make security the default.
"It is the nature of database software that administrators can switch certain options on and off."
Topic missed, failed. Dear marketing drone, please understand that this is not about what a user can do, but what should be the default.
How's the weather on that planet you're living on?
See that ginormous steel door ? See the humongous locking mechanism waiting to be used ? See those thick reinforced concrete walls with blast protection around the doorway ?
If ever you decide to shut the door, you'll be very, very secure, we promise.
In the meantime, you can just leave it open like that, no problem . . .
I'm wondering how much of this is due to people investigating/learning the MEAN stack versus serious usage of Mongo? Combined with free AWS/Azure/other cloud hosting, there may be more than a couple that were poorly setup and abandoned...
That's no excuse for poor security defaults for Mongo installs (i.e. don't recall any package based installs of MySQL/SQLite/Postgres/MS SQL or their derivatives giving access remote hosts out of the box in the last 5 years so they definitely aren't following "industry practices"...) but
Maybe the people who installed Mongo just needed a webscale database or even just sharded /dev/null
DevOps: Hey, operations? We have this idea and we need a honkin big nosql DB to play with, can you set that up tomorrow morning?
OPS: How much space do you need and, No, we'll need 10 days at least.
DevOps: Uhhh, we're not sure how much space we need, its just an idea right now.
OPS: get back to us when you know what you need please.
DevOps: Hey, Look, AWS has these things, and they're cheap, fire up a few and lets use that.
10 Days later:
OPS: Do you folks know what you need for that DB?
DevOps: Oh, hell, no, we're not going through that mess of code, we've got a BETTER idea now...
EndOfQuarter:
VPDev: What the HELL are we paying AWS this much for?
""It is the nature of database software that administrators can switch certain options on and off. This is not specific to MongoDB, and it is important for the way many applications may be developed."
Naive, or misleading, or both? What's specific to MongoDB is out-of-the-box secure=off. Do we really have to rediscover all of the lessons taught by other products over the past three decades?
It's not hard to picture this decision being made based on ease-of-use encouraging adoption. In other words, designed to be insecure as default, because "win."
I don't really understand why everyone is being so supercilious. When you deploy a production database host, you don't just stick it up with the default permissions, even if it is an RDBMS or other DB that is secure by default. At the very least you have a security policy, which you apply and then you test it and pen test it.
Otherwise you are just a cowboy.
I was thinking the same thing, it's like nobody commenting here has ever been subject to a release process.
Plus you would imagine the first install would be a POC / prototype on a dev machine.
You'd want to be able to quickly write code that talks to it with as few obstacles as possible in order to evaluate it.
Having said that, a MongoDB project I was involved with went live before the infrastructure team knew how to maintain it - they were used to RDBMS. Hopefully the enthusiastic developers who wanted to use the new shiny things switched it all on for them...
I wonder how much is due to incompetent deployments coupled with poorly developed web-facing code? There seems to be a two step process; sloppy code coupled with an incorrectly set up db. It almost feels like the devs failed to account for the MongoDB equivalent of SQL injection as well as having a dba who failed to grasp they needed to secure any db that may be reached via the web.
Just how many of these are from one man shops without a dedicated dba to clamp down on the DB with an iron fist?
Also shouldn't the basic install instructions guide the development to make it secure by default? If not I'd also say that's bloody poor documentation not to drive home the need to secure the DB for deployment.
The most comments don't have understood, how a system is pushed into production and how all the components of an application/platform are correctly designed.
First, you must separate between development and production. For development, I don't want to setup an bunch of users or other security constraints. So, no default security, that only would slow down development in the first place.
If you implement a web-application and deploy it to JBoss, where should the application know, which sites should be secured?
So, you have to think about security on your own, and not only for database, but for every component, you use.
If the development went on and a prototype or Alpha-version can be deployed to the outside world, then you have to deal with security and you have two options:
1. synchronize the production environment with the development environment (e.g. have a dedicated process for the authentication and desired users and so on)
2. introduce a develop-mode and a production-mode, and accordingly to the different modes, the connection to the database is established secured (via external configuration, so no different codebase is used) or unsecured
And, of course, if you reach your database-server via a direct internet-connection, this is never a good idea. Your application is the interface, nothing else. So the database should never ever be reachable over the internet, only through the application.
In one comment, it was mentioned before: If you give something to production and only use "defaults", you are lost. You have to deal with your software and the components, you are using like ApplicationServers, Databases, Queues, Distributed/Shared Caches and so on.
And finally, if you don't have the time to administrate the database, then why not trying out MongoDB-ATLAS? These connections are completely secured from the beginning, use SSL, so everything ok here, too.
"First, you must separate between development and production. For development, I don't want to setup an bunch of users or other security constraints. So, no default security, that only would slow down development in the first place."
So now you have two different sets of code, one for production, secure, one in development, not secure. So HTF do you test if Prod is secure if the dev version isnt? Security is a lot more than what connections you have.
And HTF do you avoid bugs in Prod that are there because of the security you have in Prod that isnt there in Dev, so you can't test Prod code fully? "What, you found there is a bug when xyz secure feature or access via port nnn is turned on that deletes transactions at random? Who'd a thunk it eh? I certainly didn't when i shipped my code out direct from non secure Dev to Prod and only then and untested turned on a couple of Db security features"
This is a valid discussion and surely it is always needed to take care of secure database systems, but.. is this really an pure MongoDB issue what is discussed here? Or as perfectly stated from UlrichC it is not only a database issue.
Generally projects start with an POC and results are needed fast, so developers do not put extra power on adding security in this phase. Unfortunately too often the POC is taken as "product" (but this is an other story). Features are added in a rush and everything gets deployed to production as it was developed. How many small and mid size companies have there own securtiy team or clearly defined security rules? How many do a security audit before the release? Software can not be secure in default settings, how ever good the best guess is the default can not know the specialties.
MongoDB has got its security but it is not switched on by default, I assume this is to ease the start using the db.
But that does not mean that there is no security with MongoDB. You can either us MonogDB Atlas to have a full mature frondend to make all needed settings, if switched on Atlas also provides frequent automated
checks and sends out warning messages.
Personally I would wish that there is a simple config setting or command-line option e.g. default_security_off.
With that one could simply, but actively, switch off the security to do things like POCs. This does not save the world but at least it is an action to be taken actively. MongoDB brings even the tools to check the basic setting on its own e.g. Atlas as mentioned. But even these mature systems can not solve all problems - a knowledgeable DBA is still needed. At this point I see some risks with the MEAN stack. It is very easy to get started and run a MongoDB but before putting the new application out to the wild world the developer needs to have some DBA background, or he makes use of the available tooling.
This is not the first instance of MongoDB being flagged up as less than secure, yet people have ignored that in the vain hope that they would not be attacked.
Enabling security is simple but not as simple as just blindly rolling it out and seeing what happens or having something from a few years ago that just worked and leaving it at that.
I think both MongoDB and users have to share the culpability and realise that they can do more to prevent this from happening in future. A default setting of security would certainly help going forwards but if the developers don't update their deployments it wouldn't help.
Mongodb is very easy to deploy and setup at minimum, so most db servers are installed without a DBA approach (by people that do not apply basic common sense and best practices)
My experience as DBA (mostly) show that developers are not keen to consider data access security as a features of their products.
Furthermore, most of the time are developers that drives setup of databases.
So lack of security, is by application feature ...
Following security best practices would no be a huge effort.
I spent most of my entire career to explain data access security risks, but you know, management is not aware of such risks until something very bad happens, so dba and system engineers are alone to try to mitigate such risks...
Unwanted data access risk is a management decision enforced by application designer directions..
DBA's often do not exists or are ignored...
Alex
For what it's worth, we secure MongoDB in two ways: First, we ALWAYS turn on authentication and enforce it at the individual database level. Second, our MongoDB instances are never directly accessed from public-facing web resources. They sit behind the firewall in the private LAN, and are separated from web server resources by an API middle tier. This provides a buffer between the database and the world, and also allows us to make our front end code db platform agnostic...
The majority of the comments here seem to imply that a database should be secure upon installation and we should depend on that. That is scary to me. No database should EVER be deployed without going through a security lock down. Yes, MSSQL doesn't allow remote connections by default, but only an idiot would install it and turn on remote connections without doing other standard lock downs.
Most MySQL installs have default root accounts with default passwords depending on the distro, would anyone open one of those to the internet without changing that root password?
Stop depending on software to be configured a certain way, and start hiring competent dba's. Then, let them do their jobs...
As for MongoDB, they have AMAZING documentation on securing it, and provide many tools to do so. I don't see anyone saying it isn't secure after following their best practices, just sayin...
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
