Hacker News Reader

Comment by sbarre | Hacker News Reader

Why do all these products have "insecure by default" configurations, anyways?

Didn't we learn anything from register_globals?

The alternative is "asks you lots of questions at install, and/or makes you generate keys or something like that", which makes people say it's too complicated to set up.

Most people want the simple insecure one for their lab to see if it will work for them before they deploy the locked down version on the internet. Of course the part where they make sure to secure the production one is where people forget.

This isn't crazy. If someone asks me to do some benchmarks on an app to see if it would fit our problem, the last thing I want is to spend a week working up a federation of keyservers and a fake domain and everything else that the deployed product will require. If the product doesn't fit our need that's just wasted time.

Or there is middle ground

"Allow easy access with no password or username, but only from localhost"

Not foolproof, but as far as I know both this and mongo did the "bind to all ports AND allow access with no password". It was the combo that really killed it.

It's easier than that - just allow two setup options that generate different config files: "development (insecure)" and "production". First one is quick and easy and relatively more unsafe, second one is fully secured based on whatever best practices. "People will find and set all the configuration options correctly" is what got us into this mess.

I believe this is how Hashicorp's Vault does it.

That only works on a single server, so it's not an option for hdfs in anything but a toy configuration. The nodes in a hdfs cluster must be able to communicate securely, and the way you do that is to set up TLS between the nodes, with Kerberos as authentication, which is quite bothersome to get running.

Or if you feel you have to allow less secure defaults for initial setup (a distributed system needs to bind to something other than localhost so in those cases using that as the key won't work) make sure that a warning is displayed everywhere that an insecure default is still in operation, where "everywhere" includes to stdout when starting/refreshing services, or perhaps stderr, to log files, to the UI if you have one (on all displays not just those exposed to admin users).

The warnings don't stop the initial trial of a service, but are in-your-face enough that any self respecting admin will review the matter before making the service available on a public network (at least with real data and/or on machines/accounts with access to other securables).

Your users may request (in fact, some of them will demand) a setting that turns such warnings off without addressing the issues covered/ You might chose to include such a setting (at least then they make a conscious decision to not address the issues instead of later complaining your product was insecure without warning) or take the high ground and tell people who say "unless you let me get away with an insecure setup I'll use something else" that you;d rather they go use something else instead of potentially tarnishing your product by association when something goes wrong.

Of course like providing good documentation, this is extra work that you may find hard to get by your paymasters at crunch time...

I rather like the way elasticsearch handles this. If the server is only bound to 127.0.0.1 then anything goes. If the server is bound to a network interface then various setting must be configured to ensure it works well in a non-testing environment.

This is annoying when your development environment involves a VM or Docker container, though. You have to figure out how to "run production in development" just to start playing around.

But the idea is that you put the very same docker image to production. I guess most products come with an automated way to setup docker, including a decently secure setup (in this case).

Yeah, but I'm not trying to do development of a product; I'm trying to learn the stack and/or comparatively evaluate the software for fit for a use-case. When it insists on being configured to run in "JVM-eats-all-your-RAM production mode", even though I want to operate it in "stay out of my way because I'm running you as a background service on the puny Pentium-M Macbook I develop on" mode, I get a bit miffed.

And this is the same software that behaves perfectly reasonably when installed as a package directly on a Linux box; it's just when it thinks it's being used over the network because I'm running macOS and it needs to be in a Linux sandbox, that it starts acting all aggressive.

At least give me a flag to let me explicitly tell the software to relax!

I'm sorry that you're frustrated. Maybe the following will help?

There is such a flag for your use case[1]. Start the node in the Docker container with

  discovery.type: single-node

This allows the node to bind HTTP and transport protocols to non-localhost interfaces and not enforce the bootstrap checks[2][3]. The node can not form a cluster with another node, but that's okay for development use cases. It's design was intended to address the Docker development use case.

I hope that helps!

Disclaimer: I work at Elastic; I welcome any and all feedback

[1]: https://www.elastic.co/guide/en/elasticsearch/reference/5.5/...

[2]: https://github.com/elastic/elasticsearch/pull/23595

[3]: https://github.com/elastic/elasticsearch/pull/23598

This isn't an IoT home security camera bought by Joe Sixpack though, where that argument makes more sense. This is supposed to be installed and maintained by developers and/or IT professionals. Are there really so many who are that helpless that they can't use a config wizard? Eek.

There are apparently plenty of IT professionals who only know how to Google and copy/paste commands into a shell. The second that the process deviates from the script they're stumped.

Just look at the comments posted to any "how to install foo" blog post or browse around StackExchange, et al., for a few minutes. As an example, there are still tons of people who do things like "chmod 0777 ..." to "fix" permissions issues.

What else are you expected to do with a product that you don't fully understand (since you're just evaluating it here), and the thing doesn't work and doesn't provide any sort of useful diagnostics?

Oh great, it's saying permission denied, but doesn't tell me where the permission was denied. Now I have to check all permissions everywhere to figure out what the problem is, once I figure out how the product works and where it might have permissions.

I do sysadmin work almost exclusively. The scenario you're describing is, basically, the norm in my life.

I'd take at look at OS and application service logs, then break out the various flavors of diagnostic tools-- strace, ProcMon, etc. It's not ideal, but it's the sorry state of affairs in the industry.

Insecure-by-default isn't the answer to bad error messages.

That argument is fine for initial investigation into a product, when you just want it to work so you can poke the features to see if they are adequate and suitable.

But the problem is people doing it that way and putting the result into production without any sort of security review.

You troubleshoot, investigate, and research -- what systems guys have done since the beginning of computing.

If you're a developer (not you, per se) running into these types of issues, well, now you understand why -- until recently -- there has traditionally been a separate operations group that was responsible for this type of stuff.

Wizard step 1: Enter your Kerberos server information...

Me: Fuck, now I've got to set up Kerberos and get all of the certs lined up before I can even see if this thing will work for us...

Step 2: Enter your CORBA...

Me: How much do we really want this solution...

Long, long ago PostgreSQL gave me a bad first impression because of this.

That must've been extremely long ago, yeah. I remember that Postgres always only allowed local connections by default.

2004 or 2005. It was confusing to set it up. Documentation improved tremendously since.

Why not have a system that requires a shared secret? It's not difficult to set up and while not secure it's so much better than nothing.

My rule of thumb for adoption UX is: every step roughly halves the number of people who will complete the process.

So a 10-step install means that if a million people discover the app only about 900 will get it running.

As complexity and general noise increases this effect will become more pronounced. People just do not have time for time-consuming installs. The information age is the age of distraction and so if something takes a lot of time "plonk" into the trash it goes.

There are ways to secure things with decent UX. At the very least the defaults could allow direct access only from private IP ranges and require explicit configuration to set otherwise. This would prevent people from shooting themselves in the foot this way.

> People just do not have time for time-consuming installs.

I have two quotes printed on the back of my business cards. One of those is: "If you don't the time to do it right, when will you have the time to do it over?"

I remember hearing something to the effect of "temporary setups never are" and, in all but the most disciplined environments, I've generally found that to hold true.

People dealing with masses of data should find it hard to make it accessible, security isn't easy, you should have to learn what you're doing.

But also there should be no way to get it working insecurely. Should just refuse to run until everything is secure, data limits, timeout limits, retry limits, ip limits, account limits, password complexity, etc.

The lesson of history is that people don't learn from history.

Lower the barrier of entry for use.

I don't necessarily agree with it, but having to screw around with authentication/certs/ssl when just playing/trying out a product is annoying.

Not everyone has the patience to deal with this.

Securing an database at the software level is not necessarily ideal for many use cases.

Typically, I secure private resources via firewalls in the networking layer. A properly configured firewall with intelligent routing rules makes up for a lot of sins in both operating system and application security. If you have servers in a private subnet with a well defined gateway, application level security is just needless complication and overhead. Though admittedly, I am not a security expert.

Security is like an onion - you should have plenty of layers. You are describing perimeter security, which is great to have. If an intruder bypasses perimeter security, intrusion detection systems are the next line of defense. They are expensive/tough to setup. So, internal security (SSL everywhere or Kerberos with TLS/SSL for comms between services) is a straightforward way to provide an additional level of security.

In many cases these systems are installed behind firewalls in corporate locations, where this is less of an issue. It becomes a bigger issue when you then just deploy it into the cloud without knowing what or how it works.

If your problem justifies a Hadoop cluster, you probably have the team that can properly set it up.

Insecure by default is not a big issue if it has its own dedicated network with restricted access in or out.

> If your problem justifies a Hadoop cluster, you probably have the team that can properly set it up.

95% of the installations of a Hadoop cluster do not have a problem that justifies a Hadoop cluster.

problem is lots of people think they have a problem that justifies a Hadoop cluster, but they don't really need it; the whole "you don't have big data thing".

Hadoop is just another application that needs to talk to its peers to be useful. It shouldn't have to worry about any outside authentication, something else should handle that...

Maybe to reduce startup effort. For people putting together PoCs, security configuration fiddling is going to be a barrier to their using some software.

Reply on news.ycombinator.com