The most frequently asked question for ElasticSearch and security is “how do I require login”?
Once you’ve answered and implemented the answer to that question; a larger, truly more troublesome issue looms. The same principals used to secure ElasticSearch; typically a proxy fronted by Apache/nginx use various auth techniques. If you know what you’re doing, you have different endpoints in that proxy for controlling who can do GET/POST/DELETE requests, possibly pre-determining the index and type.
If you REALLY know what you’re doing, you’ll be far more concerned over the payload.
While reading through the documentation, I was surprised; no, SHOCKED to see that ElasticSearch ships with a security flaw as severe as remote code execution as an intentional feature through the dynamic scripting component of a body payload for ES.
If you’re responsible for running ElasticSearch servers…
You must examine how queries are sent into the server. If your web developers are sending near-verbatim DSL queries to ElasticSearch without any further filtration except auth and index constriction, please read this.
A malicious person could modify the payload directly to read files directly off of your filesystem and serve them up in ES.
The article contains a proof of concept (POC) link – simply download and modify the file and point it to your ES server and see if you’re vulnerable.
I think in most cases, dynamic remote scripting isn’t a big deal to turn off. So I’d strongly suggest following the advice on this page: script.disable_dynamic: true
Stay tuned for Part 2 of a more obsessive approach to securing ElasticSearch for use on public search interfaces.
2 Comments on Securing Elasticsearch – Part 1