Hacker News Reader

Comment by uses | Hacker News Reader

Another MongoDB misconfiguration, wow. How is it still so easy to configure mongo with no creds and an open port? Feels like these alone cause a large % of data leaks.

If I was running a cloud platform of such a massive scale I'd probably scan my own ports to identify glaring problems like this one. Kind of surprising that isn't happening considering how bad it is to have the brand associated with a report like this.

View on HN

If you spin up a server and install mongodb (while forgetting to turn on a firewall that blocks all non-port 443/80 traffic) - everyone has root access to your database.

Easy mistake to make. I've probably done it at least once on publicly accessible test instances.

I don't think this has been true for several years

This just says to me that MongoDB's defaults should be changed.

It's happening too much.

A somewhat random password would at least provide some protection and minimal inconvenience for devs.

The defaults on Ubuntu at least have been changed (not sure since when, though) "since release 2.6.0 we have made localhost binding the default configuration in our most popular deployment package formats, RPM and deb" from https://www.mongodb.com/blog/post/update-how-to-avoid-a-mali...

By default, MongoDB doesn't listen on the public interface so it won't be exposed to the Internet - it only listens to localhost. Old versions of MongoDB had bad defaults but that hasn't been the case in years:

https://blog.shodan.io/its-still-the-data-stupid/

You should really be configuring your AWS security groups for the proper inbound/outbound ports. So a failure at that basic level of even opening up access to the machine so fully. You actually have to whitelist everything to be open like that.

Yet AWS still default to wide-open security groups for their new Cloud9/CodePipeline instances that my devs create, and Trusted Adviser tells me about the insecure configuration...

Defaults matter but I think there’s also a lot of blame for developer culture, especially in the circles where Mongo is popular. Faster, faster, ship it…

... and break things, the part I never understood, but they sure as hell are following it.

And Mongo isn't even faster for development either while it's far harder to optimize and by default insecure.

I think document stores are prone to an early threshold of thinking you’ve gotten a lot done without having to “waste” defining models/types and some people never shake that feeling even after being hip deep in all of the code they’re now writing to migrate, validate, or analyze that data.

Our ORM allows this on a relational database with similar ‘quick dev start’ benefits. But adding all those pesky structure, validation and indexing are much easier to add later. Also, when there are perf issues with Psql and Mysql it is usually a few minutes to find and fix the issue, with Mongo, even if you find it, you might be at a loss to fix it.

Isn't this still the default configuration?

Allowing unauthenticated access is the default configuration, but I think you have to go out of your way to make it accessible from external systems, let alone by anyone on the open internet...

Can you elaborate further?

My thought process is deploying this on digital ocean would make it insecure by default.

It binds to localhost by default (now, didn't used to which caused all the issues in the past).

https://docs.mongodb.com/manual/reference/configuration-opti...

Reply on news.ycombinator.com