Live data from Hacker News

The MongoDB hack and the importance of secure defaults

snyk.io

181–190 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#181

Earlier quoted context omitted.

Elasticsearch never had authentication. So they never dropped it from the free version. I feel like it is an appropriate comparison. The general response to Elasticsearch's lack of security was "your'e supposed to run it behind a firewall" Elasticsearch got all the way to version 1.4 with no authentication as part of the design. Between 1.4.1 and 1.5 release candidates is when they announced Shield as part of their e…

Because it absolutely wasn't, and still isn't, necessary. Full stop. ElasticSearch speaks HTTP. Why would I want it to reimplement HTTP authentication when I can place it behind a reverse proxy that's already integrated with my company's AAA and has been doing nothing but HTTP for oh, three decades or so? Separation of concerns. This is how this goes, and I've seen the pattern followed with several infrastructure ser…

This is a most excellent summary of how the technologies-de-jour seep their way into an organization!

Out of interest how did you handle the Google OAuth integration? Some kind of JWT module for httpd/nginx that validates the token, and acts on the subject?

Re: The MongoDB hack and the importance of secure defaults

#183

When our sysadmin set up our Mongo cluster, he firewalled out all IPs except our production systems, turned on authentication, set things up to ensure we used SSL, and configured backups. He didn't do this because he's an amazing sysadmin. He did it because he's competent, knows how to put a service on the Internet, and RTFM. I mean. If you can connect to something and use it without having to authenticate yourself,…

> When our sysadmin Yeah, well, we're in the middle of a trend to act as though dedicated systems people are bad, pains in the arse, you shouldn't need or want them.

Wait, then who is supposed to administer our systems? Do people think developers are up to the task!?

Re: The MongoDB hack and the importance of secure defaults

#184
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…

A "hellscape of configuration"? `apt-get install mysql-server` makes you enter a "root" password out of the box. `apt-get install postgresql` create a local user `postgres` with access the local database. Both bind to only localhost by default. Those sound like easy, reasonable defaults to me. (And this isn't exclusive to Debian-likes: RHEL almost certainly shares the exact same benefits)

`apt-get install postgresql` create a local user `postgres` with access the local database.

Does it!? I'm sure I've had to do that myself.

Re: The MongoDB hack and the importance of secure defaults

#185
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…

Just making it bind to localhost and not 0.0.0.0 would have zero impact on out-of-the-box usability and would prevent 99% of these drive-by hackings.

Re: The MongoDB hack and the importance of secure defaults

#186

I don't mean to defend Mongo here, but as a counter argument to the broad principle: Ubuntu doesn't ship with iptables blocking all incoming connections by default. Should it?

Honestly, in this day and age, it probably should. As well as whitelisting software that is allowed to make outgoing connections. At least for server installations. Network security is still a complete joke.

Re: The MongoDB hack and the importance of secure defaults

#187

When our sysadmin set up our Mongo cluster, he firewalled out all IPs except our production systems, turned on authentication, set things up to ensure we used SSL, and configured backups. He didn't do this because he's an amazing sysadmin. He did it because he's competent, knows how to put a service on the Internet, and RTFM. I mean. If you can connect to something and use it without having to authenticate yourself,…

> configured backups. This part seems to be glossed over but is a HUGE issue. It sounds like several companies have tried to pay the ransom with varying levels of success [0] ... why are they not just restoring from backup? I can only assume they don't have backups. (!) What is their DR plan if the server dies? Or someone accidentally pushes code that messes up the contents of the DB? Or someone tries to drop the dev…

For small data volumes, MongoDB Inc. will actually back things up for you for $2.50/GB/mo storage (free bandwidth), and it's a live backup with multiple historical versions (an agent on your database machine tails the oplog, so you're at most a couple seconds out of date). And their free monitoring tier is great alongside it. I'm truly surprised that they don't sell it harder; it took me years of using Mongo before I knew this service existed.

https://www.mongodb.com/cloud/cloud-manager

Re: The MongoDB hack and the importance of secure defaults

#188

Earlier quoted context omitted.

I don't buy that. Just did an apt-get install mysql-server and it let me install with a blank password (Ubuntu 16.04 MySQL Server 5.7)

That's ubuntu screwing things up, not mysql. When you run the init manually -- mysqld --initialize -- it does require a password.

Since we're just talking about defaults, you'd get an equally unsecured MySQL install on the latest and most popular AWS AMI today, as you would with old MongoDB installs.

Re: The MongoDB hack and the importance of secure defaults

#189

When our sysadmin set up our Mongo cluster, he firewalled out all IPs except our production systems, turned on authentication, set things up to ensure we used SSL, and configured backups. He didn't do this because he's an amazing sysadmin. He did it because he's competent, knows how to put a service on the Internet, and RTFM. I mean. If you can connect to something and use it without having to authenticate yourself,…

In the new, DevOps-centered world, doing all that is unnecessary and only serves to slow down the launching of $product.

Besides, you should be using containers for everything anyways. If something happens to it, just throw it out and spin up a new one.

/s

Re: The MongoDB hack and the importance of secure defaults

#190

Earlier quoted context omitted.

> When our sysadmin Yeah, well, we're in the middle of a trend to act as though dedicated systems people are bad, pains in the arse, you shouldn't need or want them.

Wait, then who is supposed to administer our systems? Do people think developers are up to the task!?

What administration? If something happens to the system, just toss it out and spin up a new one.

Come on, man, this is 2017. Get with the program.

/s

Post reply on HN