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

131–140 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#131

Post by tetha »

LinuxBender wrote: post #125
tetha wrote: post #116

Earlier quoted context omitted.

Thoughts like this are, and will forever be, the one dividing thing between a more ops-y person versus a more dev-y person. But that's fine. At our place, our mysql cookbook is maturing. This mysql cookbook makes it really easy to say "hey, we need a mysql master with these 2 databases". The only security overhead consist of generating 4 passwords in that case (and we're planning to automate that). Once you've done t…

ops-y + dev-y, isn't that supposed to evolve into DevOps? I know the term is a bit overloaded. Do the community chef, ansible and puppet cookbooks use secure defaults for MongoDB? Asking because I have never used MongoDB.

> ops-y + dev-y, isn't that supposed to evolve into DevOps? I know the term is a bit overloaded.

Yes, but I've grown to dislike that term, though it's my current job title. There's a number of people who're titled with DevOps and they're yelling about Docker this and CD that, and AWS/RDS those.

That crowd is way to excited about some tools and some solutions in specific use cases, and they sometimes tend to drown out the real value of config management and close cooperation of devs, ops and other involved people with their own specific focus - for a very large amount of use cases.

> Do the community chef, ansible and puppet cookbooks use secure defaults for MongoDB? Asking because I have never used MongoDB.

I'm a chef guy. First google result for "mongodb cookbook" doesn't set authentication, but makes it easy to enable required authentication. Second cookbook result doesn't enable authorization by default.

This makes sense though. If a community cookbook manages mongodb, that cookbook is supposed to support all use cases of mongodb and it usually tries to mimic the default use case of the application in question. To maintain that, the chef cookbooks for mongodb don't enforce authorization.

However, if I was supposed to implement a mongodb cookbook to use in my place, I'd intentionally fail the chef run if authentication is disabled and stop mongodb in that case. This would be trivial in both cookbooks I looked at.

Re: The MongoDB hack and the importance of secure defaults

#132

Post by rodgerd »

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

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

Re: The MongoDB hack and the importance of secure defaults

#133

Post by bogomipz »

jsmthrowaway wrote: post #106
bogomipz wrote: post #89

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…

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

Because getting RBAC right for individual indexes in Elasticsearch is not necessarily trivial. Example, I have multiple groups and users. And lets say I want to give some users access to these indexes but not these other ones and this group can access these indexes read-only and this group can add or delete but not access the admin endpoints etc. Just "putting it behind your company's proxy" doesn't work out of the box. And integrating this on Elasticsearch client Nodes - nodes where node.data is set to false and node.master is set to false, would have been very logical.

Also not every company has AAA with full LDAP integration, i.e any early stage start up that consists of a small handful of people wearing many hats because some of which are not their area of expertise. Lots of these types of companies are also using Elasticsearch for full text indexing.

Re: The MongoDB hack and the importance of secure defaults

#134

Post by jsmthrowaway »

bogomipz wrote: post #133
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…

>"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?" Because getting RBAC right for individual indexes in Elasticsearch is not necessarily trivial. Example, I have multiple groups and users. And lets say I want to give some users access to these indexes but n…

There's a difference between username/password gatekeeping security of an infrastructure service, which my post was quite clearly discussing, and fine-grained RBAC in the data plane. One is itself data within the database, while the other is gatekeeping to the database; they have vastly different impetuses, design constraints, and security strategy.

Conflating the two is wrong and, yes, many services themselves conflate the two which reduces the flexibility of both. Why not let my system do the AA and tell the backend what user it is so that RBAC can be implemented? I haven't used Shield but I'm guessing this is difficult to separate; in a number of other systems it is.

The key to your office is not nearly the same as the key to each drawer of your filing cabinet. Each can be shared independently and serve different purposes. You might decide to never use your office key, for example, because of the armed linebacker in your lobby. In my experience, most of the effort to make an infrastructure service speak authentication is intended for gatekeeping and RBAC comes later. ElasticSearch obviously went all the way with it. This whole conversation about infrastructure authorization tends to make people forget what the actual threat vectors are, which is really the subtext of my thesis here.

Every company has at least a subset of AAA, and hand waving it away as "eh, early startup stuff" is also dangerous. Putting stuff behind Google SSO is nice for startups these days and, boom, AA-sorta-A.

Re: The MongoDB hack and the importance of secure defaults

#135

Post by vacri »

user5994461 wrote: post #79
bogomipz wrote: post #51

Earlier quoted context omitted.

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.

That's not a fair comparison. ElasticSearch doesn't have authentication in the free edition. You gotta pay to get the authentication plugin. ElasticSearch => Dropped authentication (i.e. an important aspect for security) to get a chance at monetization. MongoDB => Dropped everything, including your data. YOLO!

It's an entirely fair comparison. Just because they're hiding a feature from you to make you cough up money doesn't mean that a newbie won't be burned in exactly the same way.

Re: The MongoDB hack and the importance of secure defaults

#136

Post by ajross »

peterwwillis wrote: post #109
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,…

The article's argument is that users have no common sense and don't think about what they're doing, so we should reinforce this same behavior.

Lots of these companies were storing data on behalf of other users who weren't necessarily aware of the level of "common sense" practiced by their suppliers. Whose behavior, exactly, are you trying to avoid "reinforcing" here? Is a world where no one trusts startups because they don't "think about what they're doing" one you really want to live in?

Can I just say I'm horrified at the amount of glibertarian nutjobery in this thread? People are seriously arguing against the most obvious of security practices (seriously: don't open unauthenticated ports by default) because they appear to want the dummies (and their customers) to be punished.

Welcome to Trump's world, I guess.

Re: The MongoDB hack and the importance of secure defaults

#137

Post by BillFinchDba »

It's pretty simple folks, RTFM. If you are running MonogoDB on your laptop to build an MVP, sure you can run it unsecured no worries. When you go to production, you go secure. My hope is that no DBA worth his under-appreciated skills would drop a totally open DB on the public internet. That said, it obviously happens... Read the directions, have a plan, and follow the checklist: https://docs.mongodb.com/manual/administration/security-chec...

Everyone has a different security model. In my case all my DB servers live behind and API layer on the internal network, and the DMZ web layer talks to the API. That makes keeping things secure MUCH easier...

Re: The MongoDB hack and the importance of secure defaults

#138

Post by vacri »

hueving wrote: post #85
andreyf wrote: post #63

No matter what your defaults are, if a sysadmin doesn't understand that some software is OK to connect to a public-internet addressable interface while other software is not, their shit is going to get hacked (or, as in this case, accessed). This is the equivalent of leaving your data in a file cabinet in your lobby and being surprised someone took it. The answer isn't to add self-locking little office locks to the f…

No, it's the equivalent of selling a car that doesn't require the key to be present to start by default. If the software is insecure out of the box, that's crap vendor behavior.

There is plenty of heavy industrial machinery that doesn't have keys - the canonical example is a jumbo jet.

Re: The MongoDB hack and the importance of secure defaults

#139

Post by acobster »

peterwwillis wrote: post #109
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,…

The article's argument is that users have no common sense and don't think about what they're doing, so we should reinforce this same behavior.

> you may decide that not binding a database to local connections would be a reasonable default...But assumptions like that are dangerous because when not if someone does something that breaks that assumption, they’re now vulnerable to attacks—and they may not even know it. Understanding of the potential security risks presented by these defaults is not exactly mainstream knowledge.

I wouldn't call this reinforcing behavior...I'd call it protecting your users. Common sense is something that comes with experience, and MongoDB is popular enough that it's likely to be in many web devs' first projects in production. Is it their fault they haven't developed this "common sense"? Yes and no. On the other hand, is vulnerable-by-default ever a good idea?

Re: The MongoDB hack and the importance of secure defaults

#140

Post by [deleted] »

ajross wrote: post #123
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,…

That's the same logic that says people who get fired from their jobs should be homeless and starve, or that those who get sick without insurance should be denied care. We don't do that in our society. There's a moral distinction between culpability and impact. There are profoundly stupid things that people do, yet still need protection from. Those DB admins were incompetent by lots of measures, but their data still h…

[deleted]
Post reply on HN