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

171–180 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#171

Post by jsmthrowaway »

edgan wrote: post #167
pmlnr wrote: post #129

Earlier quoted context omitted.

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.

Sr. Site Reliability Engineer here. (Itself a complex title, varying by employer.) I have taken to identifying myself as an Operations Engineer for this very reason. I'm an engineer focused on operations. Tada. You want some operating and I do some engineering to get there, and all of that is clearly printed on my tin. Some might disagree with my reduction, but I feel that it fits well what I do.

Pretty much everybody who knows their way around a compiler and administers systems could probably take this title and be fine, and then you're not suffering under the yoke of devops or whatever. Because when I hear "developer," I can't help but think a feature engineer on the product side for some reason. Same with that word creeping into "devops," and that leads to things like "full stack" engineering -- creating the impression that only a select few work with or consider "the whole stack," which is a scary subliminal message. Even if you're a developer simply changing the colors on the Facebook feed or something, you should always be thinking about the full scope of things and how your changes will be operated. (Your operations nerds will love you if you think about us ahead of time.)

As an aside, systems administrator with no software skills is a totally and completely fine career, with a number of very smart people (and friends, still proudly announcing every year of uptime in texts), and in a lot of these discussions I see them denigrated. Just remember that, not saying anyone is doing it.

Re: The MongoDB hack and the importance of secure defaults

#172

Post by virtuabhi »

I just had to deal with an insecure default in our Hadoop cluster.

Hadoop, by default, enables WebHDFS, which provides read+write access to HDFS over HTTP. The service runs on name node using the same port which displays the Hadoop Jobs Web UI.

Now, it is very easy to not know anything about WebHDFS and every day authenticate/login to server, submit jobs, and track the status on WebUI (which is public). But then anyone can send a POST request pretending to be any user and Hadoop will happily execute the command (including deleting all files).

Maybe Hadoop developers believe that all Hadoop installations are behind a firewall (ours was, but an exception was made for Jobs Web UI as it seemed to be a read-only status page for running jobs) and/or have Kerberos integrated with Hadoop for authentication.

But that being said, enabling HDFS access over HTTP by default seems to a debatable choice. Also, if you have a small Hadoop cluster running, do set "dfs.webhdfs.enabled" property to False in hdfs-site.xml.

Re: The MongoDB hack and the importance of secure defaults

#173

Post by jldugger »

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

Well, mysql was started before 2000, so it gets a pass. But I'm also pretty sure mysql doesn't allow unauthenticated writes, so it doesn't need one?

Re: The MongoDB hack and the importance of secure defaults

#174

Post by jldugger »

andreyf wrote: post #154
jldugger wrote: post #70

Earlier quoted context omitted.

Network oriented software created after 2000 has zero excuse for allowing unauthenticated writes from the general internet by default.

What about the "this is the most common setting used by our clients"? Is that not a good "excuse" for being the default?

Here's a semi-sane default for people who want the simple case to just work:

- require authentication for remote network connections

- allow r/w from any local connection, tcp or unix

Random devs installing mongo on their workstation will Just Work, but won't expose customer data to the internet.

Re: The MongoDB hack and the importance of secure defaults

#175

Post by hackits »

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.

IP Cameras from China have a number of issues of `calling home` adhoc. Granted to say even looking at their kernel's I tend to keep them completely on their own sub-net away from the net.

Re: The MongoDB hack and the importance of secure defaults

#176

Post by Sanddancer »

aioprisan wrote: post #144
morgo wrote: post #98

Earlier quoted context omitted.

It is much harder to do this with MySQL. The default is now a randomly generated password. You have to overwrite it with --initialize-insecure if you want to setup with a blank password.

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.

Re: The MongoDB hack and the importance of secure defaults

#177

Post by ns8sl »

Speaking of defaults, if you install Mongo on EC2 using a default instance of Ubuntu using the default engine, Wired Tiger, you will get ceaseless server crashes. Wired Tiger is NOT STABLE on the default volume - ext4. You have to use xfs.

This was only recently added as a startup check.

Re: The MongoDB hack and the importance of secure defaults

#178

Post by StavrosK »

scott_karana wrote: post #168
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)

I don't know, to me, these sound like things you have to do for those dinosaur databases, along with their antiquated notions of "authentication" and "actually persisting data you confirmed". Who has time for that?

Re: The MongoDB hack and the importance of secure defaults

#179

Post by StavrosK »

stouset wrote: post #84
jldugger wrote: post #70

Earlier quoted context omitted.

Network oriented software created after 2000 has zero excuse for allowing unauthenticated writes from the general internet by default.

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

Redis doesn't listen on localhost by default? I've deployed countless redis instances and that's news to me. Did Debian/Ubuntu change the default default?

Re: The MongoDB hack and the importance of secure defaults

#180

Post by StavrosK »

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…

Yes, it is. Apparently there's a time and a place to be following the Unix philosophy, and this is not that.
Post reply on HN