The MongoDB hack and the importance of secure defaults • Hacker News Board

Re: The MongoDB hack and the importance of secure defaults

#211

Post by gregmac » Thu, Jan 12, 2017, 5:58 PM UTC

cookiecaper wrote: post #209

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…

Check out the ransoms being charged. It's .2 btc, or about $150 at current btc levels (which I acknowledge are unstable). That's pretty cheap. This is probably cheaper than having a single sysadmin spend a few hours restoring from backup just in raw labor time, not to mention everything else. Factor in the cost of downtime and the likelihood that you're going to lose some hours of user data since your last backup occ…

You should read the article I linked though. After taking the data and replacing it with a README that says where to pay the ransom, the server is still left unsecured.. so someone else comes along, takes down that README and puts their own up with their own bitcoin address. Presumably if you pay them, you'll get back the next ransom note that says who to pay next, and so on, and as long as no one screwed up and everyone was honest about the ransom, after you've paid several people you'd eventually get your data back.

Re: The MongoDB hack and the importance of secure defaults

#212

Post by nirajadhikary » Thu, Jan 12, 2017, 6:02 PM UTC

The news is too late for me. Two of our development servers are already compromised. Anyway I added those servers under NAT so those servers are inaccessible from internet. Added admin access credentials also. The news should have been spread without any delay.

Re: The MongoDB hack and the importance of secure defaults

#213

Post by lacampbell » Thu, Jan 12, 2017, 6:23 PM UTC

SoftwareCSpace wrote: post #197

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

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 :)

I'm a developer. I can do some sys admin stuff at a pinch. But it's not my area of expertise at all. I mean you might as well say since experienced sysadmins do a lot of scripting they might as well develop as well.

Re: The MongoDB hack and the importance of secure defaults

#214

Post by nuha » Thu, Jan 12, 2017, 6:30 PM UTC

Education, experience, diligence. I'd expect that of anyone basing their livelihood on delivering production systems.

Secure out of the box is nice, except that when the boxing is done by others, and delivered to under-informed, unexperienced people. It's too easy to npm yourself a "full stack" or just pick a Docker container with full stack on it, then place it on public inter-web... there are dangers to be had, and others can save you. It's up to you.

And yeah, the click-bait titles including the word "hack" are laughable.

Re: The MongoDB hack and the importance of secure defaults

#215

Post by jlaustill » Thu, Jan 12, 2017, 7:51 PM UTC

This was 100% preventable, MongoDB comes with great resources for securing your data. I pity whomever puts ANY database on the internet without taking proper security measures.

Here's some documentation to get you started.

https://www.mongodb.com/blog/post/how-to-avoid-a-malicious-a...

https://docs.mongodb.com/manual/administration/security-chec...

https://www.mongodb.com/collateral/mongodb-security-architec...

This really should have been titled "the importance of good DBA's..."

Re: The MongoDB hack and the importance of secure defaults

#216

Post by beebeebush » Thu, Jan 12, 2017, 8:13 PM UTC

its amazing how most people mock mongodb in forums. I would point fingers to sysadmins and developers. Is anybody taking really care how your business services are really running ?

This tell a lot of current ways of companies, where nobody care/or have time/don't bother to check whole process through.

Re: The MongoDB hack and the importance of secure defaults

#217

Post by stouset » Thu, Jan 12, 2017, 9:52 PM UTC

andreyf wrote: post #152

stouset wrote: post #84

Earlier quoted context omitted.

Tell that to redis. No, seriously. Please. I've been banging that drum for years.

Also, MySQL [1]. Are you sure that you're right and all these major db projects are wrong? 1. note the default value of "bind to *": http://dev.mysql.com/doc/refman/5.7/en/server-options.html#o...

At least MySQL can speak TLS.

Re: The MongoDB hack and the importance of secure defaults

#218

Post by UlrichC » Fri, Jan 13, 2017, 12:59 AM UTC

I cannot believe, that so many users install MongoDB, only using default settings and installed on servers, which are accessible via the internet.

That is fundamentally wrong application design. The application connects to the database, so the database must not be public accessible via internet.

I mean, if you push something into a production environment, you must think a bit about the tools you are using and how they are configured for security.

On a development system, I don't want to setup users or auth-mechanisms.

There are so many resources from MongoDB, how you can secure your MongoDB database: - Security Architecture White Paper: https://www.mongodb.com/collateral/mongodb-security-architec... - Security Best Practices blog post: https://www.mongodb.com/blog/post/how-to-avoid-a-malicious-a...

There is even a checklist which you can work through: https://docs.mongodb.com/manual/administration/security-chec...

And for those, who don't want to read anything ;-), there is a comprehensive Video-Course on the MongoDB-university: https://university.mongodb.com/courses/M310/about

If I enter a car and don't use the seat-belt or switch on the light at night (defaults are off), then I cannot blame the car-manufacturer. If I use something important (here the database in a production environment), then I have to learn the ropes and read the material specifically on security topics.

Re: The MongoDB hack and the importance of secure defaults

#219

Post by z3t4 » Fri, Jan 13, 2017, 9:45 AM UTC

cookiecaper wrote: post #206

z3t4 wrote: post #203

Earlier quoted context omitted.

The problem is that once you work with something every day for years it becomes common sense. You should always assume your users have zero experience and don't RTFM. Messing with configurations does require a lot of specialized knowledge. Not everyone has the knowledge of a Sysadmin.

"Messing with configurations" enough to add a password requires no more specialized knowledge than installing a database server. Personal responsibility has to come in to play at some point here. We're talking about real companies who said "We're going to put all of our data into this system and not set a password", not a fast food worker trying to pick up Rails development in his/her free time. Furthermore, running…

MongoDB has learned the lesson and will no longer listen on public IP by default ... For a while it was common for ISP's to install a router on the customer side, basically creating a firewall because of NAT. But now it's usually up to the customer whether to install a router or not. And most people do not run a dedicated firewall. And with IPv6 rolling out there's really no need to have NAT as there are plenty of IP addresses. With IPv6 it's also possible for one interface to listen to many IP's. You can not assume something will only run on a private network! As a security practice you should assume all networked machines are connected (and accessible) to/from the Internet because 99% of the time they are!

Having something listening on a public IP without any password protection is irresponsible whether it's a database or security camera. Last time I installed mySQL I had to both set a root password and specify socket to listen on, and it took five seconds and no documentation reading was needed, so it is possible to both be user friendly and have good security. With mySQL you also have to explicitly set from what IP a user can connect from.

Secure should always be the default! Making it not secure should require messing with config files, not the other way around. Most people will just stick to the defaults. There are plenty of examples where you do not need a password, for example opening your fridge or turning on your TV, both being connected to the Internet. Being able to connect to it from your friends place should ring a bell, but I don't think most people try that. Just like people don't regularly port-scan their networks.

Re: The MongoDB hack and the importance of secure defaults

#220

Post by at_tt » Fri, Jan 13, 2017, 11:50 PM UTC

pjc50 wrote: post #7

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…

At a guess, it became popular through easy setup. That includes not having to configure login. That's why so many other systems are insecure. Security nearly always increases friction.

Yeah though configuring login is not something that takes more time than to set it up.