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

161–170 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#161

Post by twelvedogs »

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

this is why we have botnets running on security cameras.

you can't just demand the user be smarter, you put sane defaults on there so they actually have to go to at least a small amount of effort to shoot themselves in the foot.

Re: The MongoDB hack and the importance of secure defaults

#162

Post by Pxtl »

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

Re: The MongoDB hack and the importance of secure defaults

#163

Post by aioprisan »

tormeh wrote: post #158
aioprisan wrote: post #148

Earlier quoted context omitted.

The JS is from docs and examples, not from core MongoDB code.

So https://en.wikipedia.org/wiki/MongoDB is wrong? Well, guess I trusted Wikipedia a bit too much.

I'm confused, what about that page are you claiming to be right or wrong? The code is here for all to see: https://github.com/mongodb/mongo/tree/master/src/mongo

Re: The MongoDB hack and the importance of secure defaults

#164

Post by gator-io »

I had a situation where their cloud backup product was not backing up data and not issuing alerts when it wasn't working.

I gave them full access to logs, etc. and the support response was basically that they couldn't determine why it wasn't working or alerting, but it it works for them, so I should migrate to their hosted solution.

I sometimes think of the potential company-ending cluster-fudge that could have caused, while I stare wide-eyed at the ceiling at night.

Re: The MongoDB hack and the importance of secure defaults

#165

Post by gregmac »

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

> 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 development database but oops: they didn't notice they were connected to the production server?

Even if you're using a hosted service, what if they go down? Get hacked? Lock you out because of a billing dispute/TOS violation/DMCA takedown/accident? Hired bad sysadmins that didn't do backups (correctly)?

Not having backups of your data is inexcusable and just reeks of utter incompetence, and has nothing to do with configuration defaults or documentation.

[0] https://krebsonsecurity.com/2017/01/extortionists-wipe-thous...

Re: The MongoDB hack and the importance of secure defaults

#166

Post by fuzzy2 »

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…

> Security and usability are always at odds.

Absolutely not. How does having to log in affect usability of a system itself in any way?

Security and convenience are often (but not always!) at odds.

Re: The MongoDB hack and the importance of secure defaults

#167

Post by edgan »

pmlnr wrote: post #129
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,…

sysadmin - that title is becoming rare. Would you expect the same competancy from a devops, or a site reliability engineer? ( Not trolling, real question; as a sysadmin myself I do see that priorities differ in many cases when a dev or a manager wants to see a service running and you have until yesterday. )

It is becoming rare, because management who ultimately hires and fires people, wants things done faster. They think that making devs responsible for ops stuff, combined with automation and new technology will magically make it all good.

I am a former Sr. Systems Administrator, and Sr. Systems Engineer. My current title is Sr. Devops Engineer.

Re: The MongoDB hack and the importance of secure defaults

#168

Post by scott_karana »

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…

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)

Re: The MongoDB hack and the importance of secure defaults

#169

Post by edgan »

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…

Elasticsearch is still this way, and actually tries to make you pay for Shield, their way of securing it.

Re: The MongoDB hack and the importance of secure defaults

#170

Post by anarazel »

kosma wrote: post #100
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 .

FWIW, I'm a postgresql committer these days, and pg_hba.conf was probably the bit I was uncomfortable with for the longest (user level, not code level).
Post reply on HN