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

191–200 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#191

Post by lacampbell »

jlgaddis wrote: post #190
lacampbell wrote: post #183

Earlier quoted context omitted.

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

Oh god. That's a crazy thought process. People use VPSs more than physical servers these days. But someone still has to spin them up and configure them and deploy stuff to them. Seems insane for that to be a job for devs.

Re: The MongoDB hack and the importance of secure defaults

#192

Post by jsmthrowaway »

dd-pwc wrote: post #181
jsmthrowaway wrote: post #106

Earlier quoted context omitted.

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?

Exactly that, yes. It's not the software I was talking about in my essay, but I've used Openresty to do the JWT lifting in about 100 lines of lovely, readable Lua. Made a nice page with a "Sign on with Google" button from their docs, served it statically from nginx, and had it mostly working in a day. I wouldn't write it again, though; I wasn't confident in its complete security owing to there being far more clever people in the world than me, and I'd do that specific task differently this time around.

Openresty/nginx is like an operations Leatherman. Very handy.

Re: The MongoDB hack and the importance of secure defaults

#193

Post by developer2 »

mike-cardwell wrote: post #88

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

These kinds of articles about "attacks" are annoying. Let's be absolutely clear: there is no "attack" or "hack" involved. No real company was affected by this. There is no operating system bug involved. No software vulnerability. No zero-day exploit. No social engineering angle. There's no real problem.

This is simply first-time developers with no server experience, deploying their first project, who don't understand the first thing about having a server on the internet. Publicly exposing an open port for software that is innately designed to run on a private network has nothing to do with... whatever you want to call all these "exposé" pieces about "attacks".

You could write an article to explain the introductory concepts of system administration to newcomers to the industry. But to even mention the word "attack" when the only thing involved is an open port is... sigh.

I feel for newcomers who need to learn. I really do; the amount of information one needs to absorb to be even remotely competent is vast, and takes at least a few years to pick up (and then another decade or two to fine tune that knowledge). But this is not a situation where the maintainers of software packages are to blame for not educating their users, or insinuating that their products are not "secure out of the box". It has nothing to do with individual software packages, and everything to do with the very core aspects of having a computer connected to a public network.

Re: The MongoDB hack and the importance of secure defaults

#194

Post by fulafel »

lacampbell wrote: post #184
scott_karana wrote: post #168

Earlier quoted context omitted.

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.

Yes.

Re: The MongoDB hack and the importance of secure defaults

#195

Post by gregmac »

btown wrote: post #187
gregmac wrote: post #165

Earlier quoted context omitted.

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

If you're also hosting your data with them though, it's not a complete backup solution. You're still subject to essentially a single point of failure: if they are hacked, or suspend your account, get a DMCA notice against you, or are shut down by the SEC[1], both your live database and backups are subject to loss.

You still need to do external backups. You may have a lot of trust in the provider and these less frequently, but you should still do them.

[1] Had this happen to me once in the early 2000's: company I worked for had a dedicated server at a colo facility. After several days of them not responding to phone/email/etc, their answering machine was changed to a message saying the SEC had seized all assets and had all the owners 'under investigation' or something like that. We had external backups, but immediately took the latest stuff and got everything migrated to a new system in a new facility. Server stayed up for a few weeks after that, but then suddenly their whole IP space went offline. We never did get our server back.

Re: The MongoDB hack and the importance of secure defaults

#196

Post by lenkite »

tedunangst wrote: post #156
danielweber wrote: post #146

Earlier quoted context omitted.

Meanwhile, the FTC sued D-Link over insecure defaults in their cameras. We need good and consistent rules about this, and "well I was giving it away for free" isn't as clear a boundary as people will think it is.

The FTC sued over insecure defaults because it said "secure" on the box.

So MongoDB should state 'insecure out of the box' on their home page ? Just kidding sorry.

Re: The MongoDB hack and the importance of secure defaults

#197

Post by SoftwareCSpace »

lacampbell wrote: post #183
rodgerd wrote: post #132

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!?

It depends on the developers mate, properly experienced ones are often up to the task, while the latest fad chasing buzzword inducing cool kids probably aren't .. it's no coincidence they are the demographic that put Mongo on the map :)

Re: The MongoDB hack and the importance of secure defaults

#198

Post by scott_karana »

Pxtl wrote: post #162

To play devil's advocate for a second, isn't Mongo following the unix philosophy here? Small, composable tools instead of bolting on redundant features to everything? Opening/closing ports is the firewall's job. Mongo's job is storing and retrieving data (now, how poorly it does at that is another conversation). Having both Mongo and the Firewall handle ports means you do everything twice, which violates OnceAndOnlyO…

If that's the case, it should be behind something like inetd, instead of being able to daemonize itself ;)

Re: The MongoDB hack and the importance of secure defaults

#199

Post by nevi-me »

btown wrote: post #187
gregmac wrote: post #165

Earlier quoted context omitted.

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

I used to use Cloud Manager until they started charging a fee of I think $99 per server per month. I pay $150 for my hardware per month, so I stopped using their backup and monitoring tools.

Other than the cost, I recommend it for people who can afford it. Wonderful service that I was happy with for a long time.

Re: The MongoDB hack and the importance of secure defaults

#200

Post by raesene6 »

developer2 wrote: post #193
mike-cardwell wrote: post #88

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

These kinds of articles about "attacks" are annoying. Let's be absolutely clear: there is no "attack" or "hack" involved. No real company was affected by this. There is no operating system bug involved. No software vulnerability. No zero-day exploit. No social engineering angle. There's no real problem. This is simply first-time developers with no server experience, deploying their first project, who don't understand…

I'm afraid your suggestion that "No real company was affected by this" doesn't bear out with the evidence that I've seen or the experiences I've had in security.

Real companies with real data make some pretty elementary mistakes with regards to security. I'm a security tester and the number of times I've got access to systems deployed by real companies who've really paid money for an external security reviewer using things like default creds is quite high.

It's tempting to think that this is just an education issue and that once people know how to do security well things will get better but personally, my opinion after 16 years in security is that this isn't the case.

Effort spent on security is a trade-off with other things and in many cases people make the choice (either unconsciously or deliberately) not to prioritise it.

Post reply on HN