Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The MongoDB hack and the importance of secure defaults

snyk.io

Post reply on HN
Print view View original

51–60 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#51

Post by bogomipz »

51Cards wrote: post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

This is not unique to MongoDB however Elasticsearch is similar. The line they seem to tow is "this is made to be run behind a firewall." I agree its unacceptable but its unfortunately not unique to MongoDB.

Re: The MongoDB hack and the importance of secure defaults

#52

Post by niftich »

00deadbeef wrote: post #17
discreditable wrote: post #9

I find it interesting that there's no firewall with a default deny rule between these exposed mongodb installs and the Internet. All I can think is that most of them are on cloud services which are directly exposed. It reminds me of the fiasco with all of the directly-connected vulnerable network cameras on the Internet.

I think the problem is developers running apt-get install mongodb and assuming all other considerations, like a firewall, are somehow magically taken care of, then patting themselves on the back for not needing a sysadmin.

Why shouldn't these be taken care of?

Both Windows and UNIX/Linux programs have had interactive, guided installers, graphical or text-based, for years. Package managers support post-install scripts.

Organizational division-of-responsibility issues are not for applications to solve, but having sane defaults and performing user-supplied configuration is. This could've been handled with:

> Do you want to allow MongoDB to be accessible externally? (WARNING: this means ANYONE on the internet can connect. You will be asked to set up a username and password to protect your database. Don't do this if you're unsure or if your organization has to approve access.)

> Now that your MongoDB is open to the Internet, choose a username and a password to protect it from intruders.

Re: The MongoDB hack and the importance of secure defaults

#53

Post by raverbashing »

richardwhiuk wrote: post #8
51Cards wrote: post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

In production deployments, unsecured remote connections might be fine, because security would be handled at the network layer (e.g. by deploying MongoDB on a VLAN which only was accessible by your MongoDB clients which were on separate servers).

> In production deployments, unsecured remote connections might be fine

No. Absolutely not

Unsecured local connections yes, anything from outside 127.0.0.1 should be explicitly allowed and secured (like port 80/443). Rate-limited, fail2banned, fuzzed during testing, etc

Re: The MongoDB hack and the importance of secure defaults

#54

Post by nailer »

omni wrote: post #35
nailer wrote: post #22

Earlier quoted context omitted.

Even technically sophisticated users should be able to expect secure defaults.

Semantic counterargument: If you put a database into production without understanding its network and auth configuration then you are by definition not "technically sophisticated"

By this standard, every programmer who puts an app into production without understanding assembly is not technically sophisticated.

We could expect every programmer to have domain knowledge of databases, even when it's not normally needed to operate one.

Or we could just make databases not acknowledge writes that haven't happened, not listen on all ports, not hide information about data loss in non-clustered setups deep inside the documentation.

Counterargument: many people who are good at a particular topic enjoy feeling superior to people who don't have their knowledge.

Re: The MongoDB hack and the importance of secure defaults

#55

Post by hinkley »

pjc50 wrote: post #7
51Cards wrote: post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

At a guess, it became popular through easy setup. That includes not having to configure login. That's why so many other systems are insecure. Security nearly always increases friction.

In other disciplines they call this pandering. I'll never know why some of us see it as virtue.

Re: The MongoDB hack and the importance of secure defaults

#57

Post by jcrawfordor »

andersonmvd wrote: post #46
51Cards wrote: post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

We usually can't see the same problems happening in front of our noses. Why shouldn't we discuss why docker images run as root by default then?

I think we absolutely should discuss this - the number of images I see on Docker Hub that run complex network services as the root user really concerns me. The security measures implemented by Docker reduce the risk but absolutely do not eliminate it, you're taking a big risk there.

This issue, along with its related issues with permissions on persistent storage, is one of the major reasons I'm hoping to move away from Docker as soon as possible.

Re: The MongoDB hack and the importance of secure defaults

#58

Post by koolba »

While we should hope that server software is secure by default, you shouldn't rely on it either. A good rule of thumb is: Distrust until verified

If you're running any servers yourself, there's no reason to open up network access to the world. At most the specific ports you want to expose, to the specific IP ranges you want to allow, should be white listed. A default of everything to everywhere is insane.

Even with SSH key based authentication (v.s. say passwords) I'd consider it inept to expose all your infrastructure publicly. Set up a VPC or whatever the local equivalent is for your hosting environment and proxy SSH access via a bastion host. If you whitelist the inbound addresses to the bastion host (let's say to restrict it to just your office) then you've also eliminated the vast majority of auth log spam too.

Unfortunately the people that would understand and implement things like this are the same set of people that wouldn't have publicly exposed MongoDB instances in the first place.

Re: The MongoDB hack and the importance of secure defaults

#59

Post by salvor »

omni wrote: post #35
nailer wrote: post #22

Earlier quoted context omitted.

Even technically sophisticated users should be able to expect secure defaults.

Semantic counterargument: If you put a database into production without understanding its network and auth configuration then you are by definition not "technically sophisticated"

This. So much this.

Re: The MongoDB hack and the importance of secure defaults

#60

Post by tormeh »

golergka wrote: post #45
tormeh wrote: post #36

Who, when wanting to write a secure piece of software, thinks: "I know! I'll use JavaScript!"? Security was always going to be an afterthought at best. There are legitimate reasons for writing things in JavaScript, and none of them apply to a database.

What does this have to do with Javascript?

MongoDB is written in Javascript.
Post reply on HN