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

91–100 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#91

Post by sneakymichael »

reqres wrote: post #47
bqe wrote: post #44

Earlier quoted context omitted.

This is also the case for Elasticsearch. In fact, to get a proper username/password/ACL setup, you need to pay for professional support.

IIRC, there was also a time when Elasticsearch used multicast by default to detect other ES nodes on the network and to add them to the cluster automatically. So any node joining the same network will join a cluster and have shards allocated to it

It seemingly still does; I'm just getting started with Elasticsearch & your description aligns with what I've read in the introduction guide

Re: The MongoDB hack and the importance of secure defaults

#92

Post by Pxtl »

Realistically, insecure defaults are part of the reason Mongo was adopted in the first place. Other databases are a hellscape of configuration, meanwhile Mongo is starting to get work done from the moment it's installed.

Security and usability are always at odds. If you make security a pain, people will give up on security. Mongo is the ultimate manifestation of that principle. Developers were driven to Mongo by opaque and painful admin tasks.

Re: The MongoDB hack and the importance of secure defaults

#93

Post by Pxtl »

raverbashing wrote: post #53
richardwhiuk wrote: post #8

Earlier quoted context omitted.

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

"I opened the ports on the firewall and gave the user access, why doesn't it work!? This system is stupid."

"I changed my password on one system and then on the other, but somehow my account got locked up in that brief time between changeover, how the hell do you unlock an account? This system is stupid."

"We're scaling up and we're running into outdated rate-limiting settings on every service we use, some of them even having multiple layers of rate-limiting within a single service, and each setting requires hours of debugging to figure out which setting is taking down the whole project. This system is stupid."

There's a reason Mongo got adoption while "secure" systems did not.

Re: The MongoDB hack and the importance of secure defaults

#94

Post by extrapickles »

raverbashing wrote: post #53
richardwhiuk wrote: post #8

Earlier quoted context omitted.

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

I agree. You always want to have at least two mistakes between you and getting harmed (more if you are handling anything valuable).

If you only have a VLAN separating you from harm, it only takes 1 bad switch configuration or any other device on the VLAN to accidentally be running a proxy or router.

Re: The MongoDB hack and the importance of secure defaults

#95

Post by achillean »

The most common MongoDB versions that are being exploited with the ransomware come with secure defaults!

https://www.shodan.io/report/kjVzjr3O

Originally, I thought the problem would disappear once MongoDB changed the default from "0.0.0.0" to "localhost". However, that has had no impact on the number of exposed MongoDB instances on the Internet. Bad defaults are definitely a problem but in this case that isn't what's happened.

Also note that the most popular location where these instances are hosted is on AWS where you explicitly have to open up the firewall.

Re: The MongoDB hack and the importance of secure defaults

#96

Post by Florin_Andrei »

Pxtl wrote: post #92

Realistically, insecure defaults are part of the reason Mongo was adopted in the first place. Other databases are a hellscape of configuration, meanwhile Mongo is starting to get work done from the moment it's installed. Security and usability are always at odds. If you make security a pain, people will give up on security. Mongo is the ultimate manifestation of that principle. Developers were driven to Mongo by opaq…

Yes, but there is such a thing as minimum viable security. You know, that magical place where you're one step above absolute zero.

Re: The MongoDB hack and the importance of secure defaults

#98

Post by morgo »

aioprisan wrote: post #78
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…

You can set up the latest MySQL with a blank root password and open to the world as well. The lack of good security options is a 1.x-ism, now there are plenty of security mechanisms now https://docs.mongodb.com/v3.2/administration/security-checkl...

It is much harder to do this with MySQL.

The default is now a randomly generated password. You have to overwrite it with --initialize-insecure if you want to setup with a blank password.

Re: The MongoDB hack and the importance of secure defaults

#99

Post by kccqzy »

tannhaeuser wrote: post #86
jcrawfordor wrote: post #57

Earlier quoted context omitted.

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 fr…

What Docker security measures do you mean? Actually, I was wondering recently what isolation Docker provides that a basic chroot-jail doesn't. Re root permisions I guess if you're running a typical network daemon (Apache, say), then requiring Docker to run as root is no worse than running the service on the host; root would be a requisite anyway for the daemon to open privileged ports/gain logging permissions etc. be…

Docker drops capabilities of root by default. It doesn't drop everything but better than not dropping at all.

If you are not using docker, you can manually add the specific privilege to open low-numbered ports without running the program in question as root.

Re: The MongoDB hack and the importance of secure defaults

#100

Post by kosma »

hashkb wrote: post #34

Postgres' defaults barely let you connect to the DB. You don't hear stories like this about Postgres.

pg_hba.conf is one of the reasons it took me so long to learn Postgres. Of course, now that I know it, I don't look back - but making the first step in learning a database "understand this weird model of AF_UNIX username == dbname trust" delayed the learning process by years.
Post reply on HN