7 ms·

Why do all these products have "insecure by default" configurations, anyways? Didn't we learn anything from register_globals?

by sbarre 9y ago

PaulHoule 9y ago
The lesson of history is that people don't learn from history.
ivanbakel 9y ago
Maybe to reduce startup effort. For people putting together PoCs, security configuration fiddling is going to be a barrier to their using some software.
jandrese 9y ago
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.
- chx 9y ago
  Long, long ago PostgreSQL gave me a bad first impression because of this.
  - floatboth 9y ago
    That must've been extremely long ago, yeah. I remember that Postgres always only allowed local connections by default.
    - chx 9y ago
      2004 or 2005. It was confusing to set it up. Documentation improved tremendously since.
- brianwawok 9y ago
  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.
  - makmanalp 9y ago
    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.
    - brazzledazzle 9y ago
      I believe this is how Hashicorp's Vault does it.
  - Joeri 9y ago
    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.
  - dspillett 9y ago
    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...
- Analemma_ 9y ago
  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.
  - jlgaddis 9y ago
    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.
    - jandrese 9y ago
      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.
      - deleted 9y ago
        [deleted]
      - EvanAnderson 9y ago
        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.
      - jlgaddis 9y ago
- lacksconfidence 9y ago
  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.
  - derefr 9y ago
    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.
    - dullgiulio 9y ago
      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).
      - derefr 9y ago
        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!
        jasontedor 9y ago
        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/bootstrap-checks.html#_development_vs_production_mode https://www.elastic.co/guide/en/elasticsearch/reference/5.5/... [2]: https://github.com/elastic/elasticsearch/pull/23595 https://github.com/elastic/elasticsearch/pull/23595 [3]: https://github.com/elastic/elasticsearch/pull/23598 https://github.com/elastic/elasticsearch/pull/23598
- tinus_hn 9y ago
  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.
NikolaeVarius 9y ago
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.
X-Istence 9y ago
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.
api 9y ago
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.
- jlgaddis 9y ago
  > 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.
- mavhc 9y ago
  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.
cjhanks 9y ago
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.
- jamesblonde 9y ago
  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.
rbanffy 9y ago
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.
- jdc0589 9y ago
  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".
- random023987 9y ago
  > 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.
res0nat0r 9y ago
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...

Why do all these products have "insecure by default" configurations, anyways? Didn't we learn anything from register_globals?

by sbarre 9y ago

Why do all these products have "insecure by default" configurations, anyways? Didn't we learn anything from register_globals?

PaulHoule 9y ago

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

ivanbakel 9y ago

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

jandrese 9y ago

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.

chx 9y ago
Long, long ago PostgreSQL gave me a bad first impression because of this.
- floatboth 9y ago
  That must've been extremely long ago, yeah. I remember that Postgres always only allowed local connections by default.
  - chx 9y ago
    2004 or 2005. It was confusing to set it up. Documentation improved tremendously since.
brianwawok 9y ago
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.
- makmanalp 9y ago
  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.
  - brazzledazzle 9y ago
    I believe this is how Hashicorp's Vault does it.
- Joeri 9y ago
  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.
- dspillett 9y ago
  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...
Analemma_ 9y ago
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.
- jlgaddis 9y ago
  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.
  - jandrese 9y ago
    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.
    - deleted 9y ago
      [deleted]
    - EvanAnderson 9y ago
      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.
    - jlgaddis 9y ago
lacksconfidence 9y ago
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.
- derefr 9y ago
  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.
  - dullgiulio 9y ago
    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).
    - derefr 9y ago
      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!
      - jasontedor 9y ago
        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/bootstrap-checks.html#_development_vs_production_mode https://www.elastic.co/guide/en/elasticsearch/reference/5.5/... [2]: https://github.com/elastic/elasticsearch/pull/23595 https://github.com/elastic/elasticsearch/pull/23595 [3]: https://github.com/elastic/elasticsearch/pull/23598 https://github.com/elastic/elasticsearch/pull/23598
tinus_hn 9y ago
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.

NikolaeVarius 9y ago

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.

X-Istence 9y ago

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.

api 9y ago

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.

jlgaddis 9y ago
> 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.
mavhc 9y ago
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.

cjhanks 9y ago

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.

jamesblonde 9y ago
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.

rbanffy 9y ago

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.

jdc0589 9y ago
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".
random023987 9y ago
> 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.

res0nat0r 9y ago

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