# Securing Data in Elasticsearch **URL:** \ **Category:** Elasticsearch\ **Created:** [June 12, 2014, 2:48pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070 "2014-06-12T14:48:47Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![Harvii\_Dent](https://avatars.discourse-cdn.com/v4/letter/h/96bed5/32.png) [@Harvii\_Dent](https://discuss.elastic.co/u/Harvii_Dent)\ **Post date:** [June 12, 2014, 2:48pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/1 "2014-06-12T14:48:47Z")
Hello, I'm planning to use Elasticsearch with Logstash for logs management and search, however, one thing I'm unable to find an answer for is making sure that the data cannot be modified once it reaches Elasticsearch. "action.destructive\_requires\_name" prevents deleting all indices at once, but they can still be deleted. Are there any options to prevent deleting indices altogether? And on the document level, is it possible to disable 'delete' _AND_ 'update' operations without setting the entire index as read-only (ie. 'index.blocks.read\_only')? Lastly, does setting 'index.blocks.read\_only' ensure that the index files on disk are not changed (so they can be monitored using a file integrity monitoring solution)? as many regulatory and compliance bodies have requirements for ensuring logs integrity. Thanks -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [June 12, 2014, 3:21pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/2 "2014-06-12T15:21:29Z")
There are a lot of methods to tamper with ES files, and physically, everything is possible to modify in files as long as your operating system permits more than something like "append-only" mode for ES files (not that I know this would work) So it depends on your requirements about the security level you want to reach, if ES settings alone can help you or if you need more (paranoid) configurations. Jörg On Thu, Jun 12, 2014 at 4:48 PM, Harvii Dent [harviident@gmail.com](mailto:harviident@gmail.com) wrote: > Hello, > > I'm planning to use Elasticsearch with Logstash for logs management and > search, however, one thing I'm unable to find an answer for is making sure > that the data cannot be modified once it reaches Elasticsearch. > > "action.destructive\_requires\_name" prevents deleting all indices at once, > but they can still be deleted. Are there any options to prevent deleting > indices altogether? > > And on the document level, is it possible to disable 'delete' _AND_ > 'update' operations without setting the entire index as read-only (ie. > 'index.blocks.read\_only')? > > Lastly, does setting 'index.blocks.read\_only' ensure that the index files > on disk are not changed (so they can be monitored using a file integrity > monitoring solution)? as many regulatory and compliance bodies have > requirements for ensuring logs integrity. > > Thanks > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGzpQ\_A3vwMB%3DF0YBHA3dpQGVuXBLUAVWddGa8HZJ2U7g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGzpQ_A3vwMB%3DF0YBHA3dpQGVuXBLUAVWddGa8HZJ2U7g%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Harvii\_Dent](https://avatars.discourse-cdn.com/v4/letter/h/96bed5/32.png) [@Harvii\_Dent](https://discuss.elastic.co/u/Harvii_Dent)\ **Post date:** [June 12, 2014, 3:30pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/3 "2014-06-12T15:30:15Z")
ES settings alone would be great, are there other options that I could have missed? right now the main priority is preventing document updates/deletes (and index deletes) via the ES rest api. Thanks On Thursday, June 12, 2014 6:21:36 PM UTC+3, Jörg Prante wrote: > There are a lot of methods to tamper with ES files, and physically, > everything is possible to modify in files as long as your operating system > permits more than something like "append-only" mode for ES files (not that > I know this would work) > > So it depends on your requirements about the security level you want to > reach, if ES settings alone can help you or if you need more (paranoid) > configurations. > > Jörg > > On Thu, Jun 12, 2014 at 4:48 PM, Harvii Dent \<[harvi...@gmail.com](mailto:harvi...@gmail.com) > \\> wrote: > > > Hello, > > > > I'm planning to use Elasticsearch with Logstash for logs management and > > search, however, one thing I'm unable to find an answer for is making sure > > that the data cannot be modified once it reaches Elasticsearch. > > > > "action.destructive\_requires\_name" prevents deleting all indices at once, > > but they can still be deleted. Are there any options to prevent deleting > > indices altogether? > > > > And on the document level, is it possible to disable 'delete' _AND_ > > 'update' operations without setting the entire index as read-only (ie. > > 'index.blocks.read\_only')? > > > > Lastly, does setting 'index.blocks.read\_only' ensure that the index files > > on disk are not changed (so they can be monitored using a file integrity > > monitoring solution)? as many regulatory and compliance bodies have > > requirements for ensuring logs integrity. > > > > Thanks > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [June 12, 2014, 3:44pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/4 "2014-06-12T15:44:26Z")
If you want ES-level security, you should first reduce attack vectors, by closing down all the open ports and resources that are not necessary. One step would be to disable HTTP REST API completely (port 9200) and run Logstash Elasticsearch output only > **[Elasticsearch output plugin | Logstash Reference \[8.11\] | Elastic](https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html)** As a consequence, you could only kill the ES process on a node, or send Java API commands. It is not possible to block Java API commands over port 9300, this is how nodes talk to each other. You could imagine a self-written tool for administering your cluster that uses the Java API only (from a J2EE web app for example) On the node on OS level, you would have to protect the OS user of ES node is running under from being accessed by third party users. Jörg On Thu, Jun 12, 2014 at 5:30 PM, Harvii Dent [harviident@gmail.com](mailto:harviident@gmail.com) wrote: > ES settings alone would be great, are there other options that I could > have missed? right now the main priority is preventing document > updates/deletes (and index deletes) via the ES rest api. > > Thanks > > On Thursday, June 12, 2014 6:21:36 PM UTC+3, Jörg Prante wrote: > > > There are a lot of methods to tamper with ES files, and physically, > > everything is possible to modify in files as long as your operating system > > permits more than something like "append-only" mode for ES files (not that > > I know this would work) > > > > So it depends on your requirements about the security level you want to > > reach, if ES settings alone can help you or if you need more (paranoid) > > configurations. > > > > Jörg > > > > On Thu, Jun 12, 2014 at 4:48 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) wrote: > > > > > Hello, > > > > > > I'm planning to use Elasticsearch with Logstash for logs management and > > > search, however, one thing I'm unable to find an answer for is making sure > > > that the data cannot be modified once it reaches Elasticsearch. > > > > > > "action.destructive\_requires\_name" prevents deleting all indices at > > > once, but they can still be deleted. Are there any options to prevent > > > deleting indices altogether? > > > > > > And on the document level, is it possible to disable 'delete' _AND_ > > > 'update' operations without setting the entire index as read-only (ie. > > > 'index.blocks.read\_only')? > > > > > > Lastly, does setting 'index.blocks.read\_only' ensure that the index > > > files on disk are not changed (so they can be monitored using a file > > > integrity monitoring solution)? as many regulatory and compliance bodies > > > have requirements for ensuring logs integrity. > > > > > > Thanks > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c% > > > [40googlegroups.com](http://40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHVdFqaPgsjVgBWFtC%3DTm5SpsS6S8LKooSi%3DYP60A8s8g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHVdFqaPgsjVgBWFtC%3DTm5SpsS6S8LKooSi%3DYP60A8s8g%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Harvii\_Dent](https://avatars.discourse-cdn.com/v4/letter/h/96bed5/32.png) [@Harvii\_Dent](https://discuss.elastic.co/u/Harvii_Dent)\ **Post date:** [June 13, 2014, 6:18pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/5 "2014-06-13T18:18:33Z")
ES nodes would be locked down and accessible only to authorized users on the OS level; it's the ability to delete and update indices/documents remotely that's worrisome in this case. Disabling HTTP REST API completely is not possible since it's required by Kibana (running behind a reverse proxy), although I suppose I could restrict the ES node to only accept traffic from Logstash on port 9300 and from the reverse proxy on port 9200, would this provide sufficient protection? Thanks On Thursday, June 12, 2014 6:44:33 PM UTC+3, Jörg Prante wrote: > If you want ES-level security, you should first reduce attack vectors, by > closing down all the open ports and resources that are not necessary. > > One step would be to disable HTTP REST API completely (port 9200) and run > Logstash Elasticsearch output only > [Elasticsearch output plugin | Logstash Reference [8.11] | Elastic](http://logstash.net/docs/1.4.1/outputs/elasticsearch) > > As a consequence, you could only kill the ES process on a node, or send > Java API commands. It is not possible to block Java API commands over port > 9300, this is how nodes talk to each other. You could imagine a > self-written tool for administering your cluster that uses the Java API > only (from a J2EE web app for example) > > On the node on OS level, you would have to protect the OS user of ES node > is running under from being accessed by third party users. > > Jörg > > On Thu, Jun 12, 2014 at 5:30 PM, Harvii Dent \<[harvi...@gmail.com](mailto:harvi...@gmail.com) > \\> wrote: > > > ES settings alone would be great, are there other options that I could > > have missed? right now the main priority is preventing document > > updates/deletes (and index deletes) via the ES rest api. > > > > Thanks > > > > On Thursday, June 12, 2014 6:21:36 PM UTC+3, Jörg Prante wrote: > > > > > There are a lot of methods to tamper with ES files, and physically, > > > everything is possible to modify in files as long as your operating system > > > permits more than something like "append-only" mode for ES files (not that > > > I know this would work) > > > > > > So it depends on your requirements about the security level you want to > > > reach, if ES settings alone can help you or if you need more (paranoid) > > > configurations. > > > > > > Jörg > > > > > > On Thu, Jun 12, 2014 at 4:48 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) wrote: > > > > > > > Hello, > > > > > > > > I'm planning to use Elasticsearch with Logstash for logs management and > > > > search, however, one thing I'm unable to find an answer for is making sure > > > > that the data cannot be modified once it reaches Elasticsearch. > > > > > > > > "action.destructive\_requires\_name" prevents deleting all indices at > > > > once, but they can still be deleted. Are there any options to prevent > > > > deleting indices altogether? > > > > > > > > And on the document level, is it possible to disable 'delete' _AND_ > > > > 'update' operations without setting the entire index as read-only (ie. > > > > 'index.blocks.read\_only')? > > > > > > > > Lastly, does setting 'index.blocks.read\_only' ensure that the index > > > > files on disk are not changed (so they can be monitored using a file > > > > integrity monitoring solution)? as many regulatory and compliance bodies > > > > have requirements for ensuring logs integrity. > > > > > > > > Thanks > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c% > > > > [40googlegroups.com](http://40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [June 13, 2014, 9:44pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/6 "2014-06-13T21:44:23Z")
You should start HTTP only on localhost then and run Kibana on a selected number of nodes only. There are some authentication solutions for Kibana. I am not able to find security features like audit trails or preventing writes in Kibana/ES so you have to take care. Assessing Kibana for attacks over the web (intrusion detection, executing commands etc) is useful, I don't know if anyone has tried such a thing, but it is a very complex task. Because this variant is tedious and maybe not successful, I would opt for a different approach. Keep a checksummed copy of an index at a safe restricted place on a "private" ES cluster (or burn it even to optical media) and rsync a copy of it to an unsafe place, to another "public" ES cluster where Kibana runs. Checksum verification can prove if index is modified in the meantime at the public place. Jörg On Fri, Jun 13, 2014 at 8:18 PM, Harvii Dent [harviident@gmail.com](mailto:harviident@gmail.com) wrote: > ES nodes would be locked down and accessible only to authorized users on > the OS level; it's the ability to delete and update indices/documents > remotely that's worrisome in this case. > > Disabling HTTP REST API completely is not possible since it's required by > Kibana (running behind a reverse proxy), although I suppose I could > restrict the ES node to only accept traffic from Logstash on port 9300 and > from the reverse proxy on port 9200, would this provide sufficient > protection? > > Thanks > > On Thursday, June 12, 2014 6:44:33 PM UTC+3, Jörg Prante wrote: > > > If you want ES-level security, you should first reduce attack vectors, by > > closing down all the open ports and resources that are not necessary. > > > > One step would be to disable HTTP REST API completely (port 9200) and run > > Logstash Elasticsearch output only [Logstash Reference [8.11] | Elastic](http://logstash.net/docs/1.4). > > 1/outputs/elasticsearch > > > > As a consequence, you could only kill the ES process on a node, or send > > Java API commands. It is not possible to block Java API commands over port > > 9300, this is how nodes talk to each other. You could imagine a > > self-written tool for administering your cluster that uses the Java API > > only (from a J2EE web app for example) > > > > On the node on OS level, you would have to protect the OS user of ES node > > is running under from being accessed by third party users. > > > > Jörg > > > > On Thu, Jun 12, 2014 at 5:30 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) wrote: > > > > > ES settings alone would be great, are there other options that I could > > > have missed? right now the main priority is preventing document > > > updates/deletes (and index deletes) via the ES rest api. > > > > > > Thanks > > > > > > On Thursday, June 12, 2014 6:21:36 PM UTC+3, Jörg Prante wrote: > > > > > > > There are a lot of methods to tamper with ES files, and physically, > > > > everything is possible to modify in files as long as your operating system > > > > permits more than something like "append-only" mode for ES files (not that > > > > I know this would work) > > > > > > > > So it depends on your requirements about the security level you want to > > > > reach, if ES settings alone can help you or if you need more (paranoid) > > > > configurations. > > > > > > > > Jörg > > > > > > > > On Thu, Jun 12, 2014 at 4:48 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > I'm planning to use Elasticsearch with Logstash for logs management > > > > > and search, however, one thing I'm unable to find an answer for is making > > > > > sure that the data cannot be modified once it reaches Elasticsearch. > > > > > > > > > > "action.destructive\_requires\_name" prevents deleting all indices at > > > > > once, but they can still be deleted. Are there any options to prevent > > > > > deleting indices altogether? > > > > > > > > > > And on the document level, is it possible to disable 'delete' _AND_ > > > > > 'update' operations without setting the entire index as read-only (ie. > > > > > 'index.blocks.read\_only')? > > > > > > > > > > Lastly, does setting 'index.blocks.read\_only' ensure that the index > > > > > files on disk are not changed (so they can be monitored using a file > > > > > integrity monitoring solution)? as many regulatory and compliance bodies > > > > > have requirements for ensuring logs integrity. > > > > > > > > > > Thanks > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "elasticsearch" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40goo > > > > > [glegroups.com](http://glegroups.com) > > > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > . > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209% > > > > [40googlegroups.com](http://40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEhU8w%2BemP0gsNCphJ5c-dQTh25409K8ozGx\_aKP5E-TA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEhU8w%2BemP0gsNCphJ5c-dQTh25409K8ozGx_aKP5E-TA%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Harvii\_Dent](https://avatars.discourse-cdn.com/v4/letter/h/96bed5/32.png) [@Harvii\_Dent](https://discuss.elastic.co/u/Harvii_Dent)\ **Post date:** [June 15, 2014, 2:31pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/7 "2014-06-15T14:31:15Z")
Thanks Jörg. Something like OSSEC ([www.ossec.net](http://www.ossec.net)) can provide the checksumming you mention below but I guess it would only work on indices that have been finalized and marked as read-only (assuming ES does not modify the files on disk at this point). As for active indices, is there anything that can be done on the reverse proxy to prevent delete and update operations coming from Kibana's side? I believe some requests can be filtered but I'm not sure exactly which without affecting the main functionality of Kibana. Regards On Saturday, June 14, 2014 12:44:31 AM UTC+3, Jörg Prante wrote: > You should start HTTP only on localhost then and run Kibana on a selected > number of nodes only. > > There are some authentication solutions for Kibana. > > I am not able to find security features like audit trails or preventing > writes in Kibana/ES so you have to take care. Assessing Kibana for attacks > over the web (intrusion detection, executing commands etc) is useful, I > don't know if anyone has tried such a thing, but it is a very complex task. > > Because this variant is tedious and maybe not successful, I would opt for > a different approach. Keep a checksummed copy of an index at a safe > restricted place on a "private" ES cluster (or burn it even to optical > media) and rsync a copy of it to an unsafe place, to another "public" ES > cluster where Kibana runs. Checksum verification can prove if index is > modified in the meantime at the public place. > > Jörg > > On Fri, Jun 13, 2014 at 8:18 PM, Harvii Dent \<[harvi...@gmail.com](mailto:harvi...@gmail.com) > \\> wrote: > > > ES nodes would be locked down and accessible only to authorized users on > > the OS level; it's the ability to delete and update indices/documents > > remotely that's worrisome in this case. > > > > Disabling HTTP REST API completely is not possible since it's required by > > Kibana (running behind a reverse proxy), although I suppose I could > > restrict the ES node to only accept traffic from Logstash on port 9300 and > > from the reverse proxy on port 9200, would this provide sufficient > > protection? > > > > Thanks > > > > On Thursday, June 12, 2014 6:44:33 PM UTC+3, Jörg Prante wrote: > > > > > If you want ES-level security, you should first reduce attack vectors, > > > by closing down all the open ports and resources that are not necessary. > > > > > > One step would be to disable HTTP REST API completely (port 9200) and > > > run Logstash Elasticsearch output only [Logstash Reference [8.11] | Elastic](http://logstash.net/docs/1.4). > > > 1/outputs/elasticsearch > > > > > > As a consequence, you could only kill the ES process on a node, or send > > > Java API commands. It is not possible to block Java API commands over port > > > 9300, this is how nodes talk to each other. You could imagine a > > > self-written tool for administering your cluster that uses the Java API > > > only (from a J2EE web app for example) > > > > > > On the node on OS level, you would have to protect the OS user of ES > > > node is running under from being accessed by third party users. > > > > > > Jörg > > > > > > On Thu, Jun 12, 2014 at 5:30 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) wrote: > > > > > > > ES settings alone would be great, are there other options that I > > > > could have missed? right now the main priority is preventing document > > > > updates/deletes (and index deletes) via the ES rest api. > > > > > > > > Thanks > > > > > > > > On Thursday, June 12, 2014 6:21:36 PM UTC+3, Jörg Prante wrote: > > > > > > > > > There are a lot of methods to tamper with ES files, and physically, > > > > > everything is possible to modify in files as long as your operating system > > > > > permits more than something like "append-only" mode for ES files (not that > > > > > I know this would work) > > > > > > > > > > So it depends on your requirements about the security level you want > > > > > to reach, if ES settings alone can help you or if you need more (paranoid) > > > > > configurations. > > > > > > > > > > Jörg > > > > > > > > > > On Thu, Jun 12, 2014 at 4:48 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) > > > > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > I'm planning to use Elasticsearch with Logstash for logs management > > > > > > and search, however, one thing I'm unable to find an answer for is making > > > > > > sure that the data cannot be modified once it reaches Elasticsearch. > > > > > > > > > > > > "action.destructive\_requires\_name" prevents deleting all indices at > > > > > > once, but they can still be deleted. Are there any options to prevent > > > > > > deleting indices altogether? > > > > > > > > > > > > And on the document level, is it possible to disable 'delete' _AND_ > > > > > > 'update' operations without setting the entire index as read-only (ie. > > > > > > 'index.blocks.read\_only')? > > > > > > > > > > > > Lastly, does setting 'index.blocks.read\_only' ensure that the index > > > > > > files on disk are not changed (so they can be monitored using a file > > > > > > integrity monitoring solution)? as many regulatory and compliance bodies > > > > > > have requirements for ensuring logs integrity. > > > > > > > > > > > > Thanks > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups "elasticsearch" group. > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > > msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40goo > > > > > > [glegroups.com](http://glegroups.com) > > > > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > . > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "elasticsearch" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209% > > > > > [40googlegroups.com](http://40googlegroups.com) > > > > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > . > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [June 15, 2014, 2:40pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/8 "2014-06-15T14:40:08Z")
From what I know about Kibana, it just uses the HTTP API \_search endpoint, but I have not examined it more thoroughly. It is quite simple to set up an nginx/apache reverse proxy to filter requests. You should add http: host: 127.0.0.1 to your config/elasticsearch.yml to ensure that HTTP REST ES API is not exposed to other hosts, so nginx/apache must take the job to accept Kibana HTTP on port 80 (443) only. Jörg On Sun, Jun 15, 2014 at 4:31 PM, Harvii Dent [harviident@gmail.com](mailto:harviident@gmail.com) wrote: > Thanks Jörg. Something like OSSEC ([www.ossec.net](http://www.ossec.net)) can provide the > checksumming you mention below but I guess it would only work on indices > that have been finalized and marked as read-only (assuming ES does not > modify the files on disk at this point). > > As for active indices, is there anything that can be done on the reverse > proxy to prevent delete and update operations coming from Kibana's side? I > believe some requests can be filtered but I'm not sure exactly which > without affecting the main functionality of Kibana. > > Regards > > On Saturday, June 14, 2014 12:44:31 AM UTC+3, Jörg Prante wrote: > > > You should start HTTP only on localhost then and run Kibana on a selected > > number of nodes only. > > > > There are some authentication solutions for Kibana. > > > > I am not able to find security features like audit trails or preventing > > writes in Kibana/ES so you have to take care. Assessing Kibana for attacks > > over the web (intrusion detection, executing commands etc) is useful, I > > don't know if anyone has tried such a thing, but it is a very complex task. > > > > Because this variant is tedious and maybe not successful, I would opt for > > a different approach. Keep a checksummed copy of an index at a safe > > restricted place on a "private" ES cluster (or burn it even to optical > > media) and rsync a copy of it to an unsafe place, to another "public" ES > > cluster where Kibana runs. Checksum verification can prove if index is > > modified in the meantime at the public place. > > > > Jörg > > > > On Fri, Jun 13, 2014 at 8:18 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) wrote: > > > > > ES nodes would be locked down and accessible only to authorized users on > > > the OS level; it's the ability to delete and update indices/documents > > > remotely that's worrisome in this case. > > > > > > Disabling HTTP REST API completely is not possible since it's required > > > by Kibana (running behind a reverse proxy), although I suppose I could > > > restrict the ES node to only accept traffic from Logstash on port 9300 and > > > from the reverse proxy on port 9200, would this provide sufficient > > > protection? > > > > > > Thanks > > > > > > On Thursday, June 12, 2014 6:44:33 PM UTC+3, Jörg Prante wrote: > > > > > > > If you want ES-level security, you should first reduce attack vectors, > > > > by closing down all the open ports and resources that are not necessary. > > > > > > > > One step would be to disable HTTP REST API completely (port 9200) and > > > > run Logstash Elasticsearch output only [Logstash Reference [8.11] | Elastic](http://logstash.net/docs/1.4). > > > > 1/outputs/elasticsearch > > > > > > > > As a consequence, you could only kill the ES process on a node, or send > > > > Java API commands. It is not possible to block Java API commands over port > > > > 9300, this is how nodes talk to each other. You could imagine a > > > > self-written tool for administering your cluster that uses the Java API > > > > only (from a J2EE web app for example) > > > > > > > > On the node on OS level, you would have to protect the OS user of ES > > > > node is running under from being accessed by third party users. > > > > > > > > Jörg > > > > > > > > On Thu, Jun 12, 2014 at 5:30 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) > > > > wrote: > > > > > > > > > ES settings alone would be great, are there other options that I > > > > > could have missed? right now the main priority is preventing document > > > > > updates/deletes (and index deletes) via the ES rest api. > > > > > > > > > > Thanks > > > > > > > > > > On Thursday, June 12, 2014 6:21:36 PM UTC+3, Jörg Prante wrote: > > > > > > > > > > > There are a lot of methods to tamper with ES files, and physically, > > > > > > everything is possible to modify in files as long as your operating system > > > > > > permits more than something like "append-only" mode for ES files (not that > > > > > > I know this would work) > > > > > > > > > > > > So it depends on your requirements about the security level you want > > > > > > to reach, if ES settings alone can help you or if you need more (paranoid) > > > > > > configurations. > > > > > > > > > > > > Jörg > > > > > > > > > > > > On Thu, Jun 12, 2014 at 4:48 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) > > > > > > wrote: > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > I'm planning to use Elasticsearch with Logstash for logs management > > > > > > > and search, however, one thing I'm unable to find an answer for is making > > > > > > > sure that the data cannot be modified once it reaches Elasticsearch. > > > > > > > > > > > > > > "action.destructive\_requires\_name" prevents deleting all indices at > > > > > > > once, but they can still be deleted. Are there any options to prevent > > > > > > > deleting indices altogether? > > > > > > > > > > > > > > And on the document level, is it possible to disable 'delete' _AND_ > > > > > > > 'update' operations without setting the entire index as read-only (ie. > > > > > > > 'index.blocks.read\_only')? > > > > > > > > > > > > > > Lastly, does setting 'index.blocks.read\_only' ensure that the index > > > > > > > files on disk are not changed (so they can be monitored using a file > > > > > > > integrity monitoring solution)? as many regulatory and compliance bodies > > > > > > > have requirements for ensuring logs integrity. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > -- > > > > > > > You received this message because you are subscribed to the Google > > > > > > > Groups "elasticsearch" group. > > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > > send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > > > > > To view this discussion on the web visit > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18a](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18a) > > > > > > > c-405e-8929-68be32b01a6c%[40googlegroups.com](http://40googlegroups.com) > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > > . > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups "elasticsearch" group. > > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > > msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40goo > > > > > > [glegroups.com](http://glegroups.com) > > > > > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > . > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db% > > > > [40googlegroups.com](http://40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHZYK1gnNFdD4HL8aRK\_pR\_ao55BPgctTb2BamH1z19cQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHZYK1gnNFdD4HL8aRK_pR_ao55BPgctTb2BamH1z19cQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Harvii\_Dent](https://avatars.discourse-cdn.com/v4/letter/h/96bed5/32.png) [@Harvii\_Dent](https://discuss.elastic.co/u/Harvii_Dent)\ **Post date:** [June 15, 2014, 2:58pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/9 "2014-06-15T14:58:09Z")
Interesting, but this assumes that both Logstash and Kibana are on the on same host as ES, correct? While this is how everything is running in my test environment, I was thinking of separating ES from Logstash when going to production since each would require significant resources, although I'm not sure how accurate that is; would there be any downsides to running Logstash and ES on the same node? Thanks On Sunday, June 15, 2014 5:40:25 PM UTC+3, Jörg Prante wrote: > From what I know about Kibana, it just uses the HTTP API \_search endpoint, > but I have not examined it more thoroughly. > > It is quite simple to set up an nginx/apache reverse proxy to filter > requests. > > You should add > > http: > host: 127.0.0.1 > > to your config/elasticsearch.yml to ensure that HTTP REST ES API is not > exposed to other hosts, so nginx/apache must take the job to accept Kibana > HTTP on port 80 (443) only. > > Jörg > > On Sun, Jun 15, 2014 at 4:31 PM, Harvii Dent \<[harvi...@gmail.com](mailto:harvi...@gmail.com) > \\> wrote: > > > Thanks Jörg. Something like OSSEC ([www.ossec.net](http://www.ossec.net)) can provide the > > checksumming you mention below but I guess it would only work on indices > > that have been finalized and marked as read-only (assuming ES does not > > modify the files on disk at this point). > > > > As for active indices, is there anything that can be done on the reverse > > proxy to prevent delete and update operations coming from Kibana's side? I > > believe some requests can be filtered but I'm not sure exactly which > > without affecting the main functionality of Kibana. > > > > Regards > > > > On Saturday, June 14, 2014 12:44:31 AM UTC+3, Jörg Prante wrote: > > > > > You should start HTTP only on localhost then and run Kibana on a > > > selected number of nodes only. > > > > > > There are some authentication solutions for Kibana. > > > > > > I am not able to find security features like audit trails or preventing > > > writes in Kibana/ES so you have to take care. Assessing Kibana for attacks > > > over the web (intrusion detection, executing commands etc) is useful, I > > > don't know if anyone has tried such a thing, but it is a very complex task. > > > > > > Because this variant is tedious and maybe not successful, I would opt > > > for a different approach. Keep a checksummed copy of an index at a safe > > > restricted place on a "private" ES cluster (or burn it even to optical > > > media) and rsync a copy of it to an unsafe place, to another "public" ES > > > cluster where Kibana runs. Checksum verification can prove if index is > > > modified in the meantime at the public place. > > > > > > Jörg > > > > > > On Fri, Jun 13, 2014 at 8:18 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) wrote: > > > > > > > ES nodes would be locked down and accessible only to authorized users > > > > on the OS level; it's the ability to delete and update indices/documents > > > > remotely that's worrisome in this case. > > > > > > > > Disabling HTTP REST API completely is not possible since it's required > > > > by Kibana (running behind a reverse proxy), although I suppose I could > > > > restrict the ES node to only accept traffic from Logstash on port 9300 and > > > > from the reverse proxy on port 9200, would this provide sufficient > > > > protection? > > > > > > > > Thanks > > > > > > > > On Thursday, June 12, 2014 6:44:33 PM UTC+3, Jörg Prante wrote: > > > > > > > > > If you want ES-level security, you should first reduce attack vectors, > > > > > by closing down all the open ports and resources that are not necessary. > > > > > > > > > > One step would be to disable HTTP REST API completely (port 9200) and > > > > > run Logstash Elasticsearch output only [Logstash Reference [8.11] | Elastic](http://logstash.net/docs/1.4). > > > > > 1/outputs/elasticsearch > > > > > > > > > > As a consequence, you could only kill the ES process on a node, or > > > > > send Java API commands. It is not possible to block Java API commands over > > > > > port 9300, this is how nodes talk to each other. You could imagine a > > > > > self-written tool for administering your cluster that uses the Java API > > > > > only (from a J2EE web app for example) > > > > > > > > > > On the node on OS level, you would have to protect the OS user of ES > > > > > node is running under from being accessed by third party users. > > > > > > > > > > Jörg > > > > > > > > > > On Thu, Jun 12, 2014 at 5:30 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) > > > > > wrote: > > > > > > > > > > > ES settings alone would be great, are there other options that I > > > > > > could have missed? right now the main priority is preventing document > > > > > > updates/deletes (and index deletes) via the ES rest api. > > > > > > > > > > > > Thanks > > > > > > > > > > > > On Thursday, June 12, 2014 6:21:36 PM UTC+3, Jörg Prante wrote: > > > > > > > > > > > > > There are a lot of methods to tamper with ES files, and physically, > > > > > > > everything is possible to modify in files as long as your operating system > > > > > > > permits more than something like "append-only" mode for ES files (not that > > > > > > > I know this would work) > > > > > > > > > > > > > > So it depends on your requirements about the security level you want > > > > > > > to reach, if ES settings alone can help you or if you need more (paranoid) > > > > > > > configurations. > > > > > > > > > > > > > > Jörg > > > > > > > > > > > > > > On Thu, Jun 12, 2014 at 4:48 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) > > > > > > > wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > I'm planning to use Elasticsearch with Logstash for logs management > > > > > > > > and search, however, one thing I'm unable to find an answer for is making > > > > > > > > sure that the data cannot be modified once it reaches Elasticsearch. > > > > > > > > > > > > > > > > "action.destructive\_requires\_name" prevents deleting all indices > > > > > > > > at once, but they can still be deleted. Are there any options to prevent > > > > > > > > deleting indices altogether? > > > > > > > > > > > > > > > > And on the document level, is it possible to disable 'delete' _AND_ > > > > > > > > 'update' operations without setting the entire index as read-only (ie. > > > > > > > > 'index.blocks.read\_only')? > > > > > > > > > > > > > > > > Lastly, does setting 'index.blocks.read\_only' ensure that the index > > > > > > > > files on disk are not changed (so they can be monitored using a file > > > > > > > > integrity monitoring solution)? as many regulatory and compliance bodies > > > > > > > > have requirements for ensuring logs integrity. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the Google > > > > > > > > Groups "elasticsearch" group. > > > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > > > send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > > > > > > > To view this discussion on the web visit > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18a](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18a) > > > > > > > > c-405e-8929-68be32b01a6c%[40googlegroups.com](http://40googlegroups.com) > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > > > . > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > > > > > -- > > > > > > > You received this message because you are subscribed to the Google > > > > > > > Groups "elasticsearch" group. > > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > > send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > > > msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40goo > > > > > > > [glegroups.com](http://glegroups.com) > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > > . > > > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "elasticsearch" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db% > > > > > [40googlegroups.com](http://40googlegroups.com) > > > > > [https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > . > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/899eab77-fd55-4216-80f7-159e85f9248b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/899eab77-fd55-4216-80f7-159e85f9248b%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [June 15, 2014, 3:12pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/10 "2014-06-15T15:12:15Z")
No, with the setting, you can run Logstash and Kibana on different hosts. Only on ES node side, you start an additional nginx/apache, to wrap the HTTP 9200 port service with a HTTP port 80 reverse proxy service. On Kibana, you change all port 9200 configs to port 80 configs (also the remote host name instead of localhost) On Logstash, you configure the native ES port 9300 output, not the HTTP ES output. Jörg On Sun, Jun 15, 2014 at 4:58 PM, Harvii Dent [harviident@gmail.com](mailto:harviident@gmail.com) wrote: > Interesting, but this assumes that both Logstash and Kibana are on the on > same host as ES, correct? > > While this is how everything is running in my test environment, I was > thinking of separating ES from Logstash when going to production since each > would require significant resources, although I'm not sure how accurate > that is; would there be any downsides to running Logstash and ES on the > same node? > > Thanks > > On Sunday, June 15, 2014 5:40:25 PM UTC+3, Jörg Prante wrote: > > > From what I know about Kibana, it just uses the HTTP API \_search > > endpoint, but I have not examined it more thoroughly. > > > > It is quite simple to set up an nginx/apache reverse proxy to filter > > requests. > > > > You should add > > > > http: > > host: 127.0.0.1 > > > > to your config/elasticsearch.yml to ensure that HTTP REST ES API is not > > exposed to other hosts, so nginx/apache must take the job to accept Kibana > > HTTP on port 80 (443) only. > > > > Jörg > > > > On Sun, Jun 15, 2014 at 4:31 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) wrote: > > > > > Thanks Jörg. Something like OSSEC ([www.ossec.net](http://www.ossec.net)) can provide the > > > checksumming you mention below but I guess it would only work on indices > > > that have been finalized and marked as read-only (assuming ES does not > > > modify the files on disk at this point). > > > > > > As for active indices, is there anything that can be done on the reverse > > > proxy to prevent delete and update operations coming from Kibana's side? I > > > believe some requests can be filtered but I'm not sure exactly which > > > without affecting the main functionality of Kibana. > > > > > > Regards > > > > > > On Saturday, June 14, 2014 12:44:31 AM UTC+3, Jörg Prante wrote: > > > > > > > You should start HTTP only on localhost then and run Kibana on a > > > > selected number of nodes only. > > > > > > > > There are some authentication solutions for Kibana. > > > > > > > > I am not able to find security features like audit trails or preventing > > > > writes in Kibana/ES so you have to take care. Assessing Kibana for attacks > > > > over the web (intrusion detection, executing commands etc) is useful, I > > > > don't know if anyone has tried such a thing, but it is a very complex task. > > > > > > > > Because this variant is tedious and maybe not successful, I would opt > > > > for a different approach. Keep a checksummed copy of an index at a safe > > > > restricted place on a "private" ES cluster (or burn it even to optical > > > > media) and rsync a copy of it to an unsafe place, to another "public" ES > > > > cluster where Kibana runs. Checksum verification can prove if index is > > > > modified in the meantime at the public place. > > > > > > > > Jörg > > > > > > > > On Fri, Jun 13, 2014 at 8:18 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) > > > > wrote: > > > > > > > > > ES nodes would be locked down and accessible only to authorized users > > > > > on the OS level; it's the ability to delete and update indices/documents > > > > > remotely that's worrisome in this case. > > > > > > > > > > Disabling HTTP REST API completely is not possible since it's required > > > > > by Kibana (running behind a reverse proxy), although I suppose I could > > > > > restrict the ES node to only accept traffic from Logstash on port 9300 and > > > > > from the reverse proxy on port 9200, would this provide sufficient > > > > > protection? > > > > > > > > > > Thanks > > > > > > > > > > On Thursday, June 12, 2014 6:44:33 PM UTC+3, Jörg Prante wrote: > > > > > > > > > > > If you want ES-level security, you should first reduce attack > > > > > > vectors, by closing down all the open ports and resources that are not > > > > > > necessary. > > > > > > > > > > > > One step would be to disable HTTP REST API completely (port 9200) and > > > > > > run Logstash Elasticsearch output only [Logstash Reference [8.11] | Elastic](http://logstash.net/docs/1.4). > > > > > > 1/outputs/elasticsearch > > > > > > > > > > > > As a consequence, you could only kill the ES process on a node, or > > > > > > send Java API commands. It is not possible to block Java API commands over > > > > > > port 9300, this is how nodes talk to each other. You could imagine a > > > > > > self-written tool for administering your cluster that uses the Java API > > > > > > only (from a J2EE web app for example) > > > > > > > > > > > > On the node on OS level, you would have to protect the OS user of ES > > > > > > node is running under from being accessed by third party users. > > > > > > > > > > > > Jörg > > > > > > > > > > > > On Thu, Jun 12, 2014 at 5:30 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) > > > > > > wrote: > > > > > > > > > > > > > ES settings alone would be great, are there other options that I > > > > > > > could have missed? right now the main priority is preventing document > > > > > > > updates/deletes (and index deletes) via the ES rest api. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > On Thursday, June 12, 2014 6:21:36 PM UTC+3, Jörg Prante wrote: > > > > > > > > > > > > > > > There are a lot of methods to tamper with ES files, and physically, > > > > > > > > everything is possible to modify in files as long as your operating system > > > > > > > > permits more than something like "append-only" mode for ES files (not that > > > > > > > > I know this would work) > > > > > > > > > > > > > > > > So it depends on your requirements about the security level you > > > > > > > > want to reach, if ES settings alone can help you or if you need more > > > > > > > > (paranoid) configurations. > > > > > > > > > > > > > > > > Jörg > > > > > > > > > > > > > > > > On Thu, Jun 12, 2014 at 4:48 PM, Harvii Dent [harvi...@gmail.com](mailto:harvi...@gmail.com) > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > I'm planning to use Elasticsearch with Logstash for logs > > > > > > > > > management and search, however, one thing I'm unable to find an answer for > > > > > > > > > is making sure that the data cannot be modified once it reaches > > > > > > > > > Elasticsearch. > > > > > > > > > > > > > > > > > > "action.destructive\_requires\_name" prevents deleting all indices > > > > > > > > > at once, but they can still be deleted. Are there any options to prevent > > > > > > > > > deleting indices altogether? > > > > > > > > > > > > > > > > > > And on the document level, is it possible to disable 'delete' > > > > > > > > > _AND_ 'update' operations without setting the entire index as > > > > > > > > > read-only (ie. 'index.blocks.read\_only')? > > > > > > > > > > > > > > > > > > Lastly, does setting 'index.blocks.read\_only' ensure that the > > > > > > > > > index files on disk are not changed (so they can be monitored using a file > > > > > > > > > integrity monitoring solution)? as many regulatory and compliance bodies > > > > > > > > > have requirements for ensuring logs integrity. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > -- > > > > > > > > > You received this message because you are subscribed to the Google > > > > > > > > > Groups "elasticsearch" group. > > > > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > > > > send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > > > > > > > > > To view this discussion on the web visit > > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18a](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18a) > > > > > > > > > c-405e-8929-68be32b01a6c%[40googlegroups.com](http://40googlegroups.com) > > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > > > > . > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the Google > > > > > > > > Groups "elasticsearch" group. > > > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > > > send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > > To view this discussion on the web visit > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9ed](https://groups.google.com/d/msgid/elasticsearch/190a707b-9ed) > > > > > > > > f-4128-9740-79d59f0bc209%[40googlegroups.com](http://40googlegroups.com) > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/190a707b-9edf-4128-9740-79d59f0bc209%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > > > . > > > > > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups "elasticsearch" group. > > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > > msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40goo > > > > > > [glegroups.com](http://glegroups.com) > > > > > > [https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/9339cfd0-9300-496e-bc00-4179725e02db%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > . > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805% > > > > [40googlegroups.com](http://40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/899eab77-fd55-4216-80f7-159e85f9248b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/899eab77-fd55-4216-80f7-159e85f9248b%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/899eab77-fd55-4216-80f7-159e85f9248b%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/899eab77-fd55-4216-80f7-159e85f9248b%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEjmz4SuyS2\_LCwc\_rBzNa16OBa9cerh268FP2zEEWXpw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEjmz4SuyS2_LCwc_rBzNa16OBa9cerh268FP2zEEWXpw%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Zennet\_Wheatcroft](https://avatars.discourse-cdn.com/v4/letter/z/8491ac/32.png) [@Zennet\_Wheatcroft](https://discuss.elastic.co/u/Zennet_Wheatcroft)\ **Post date:** [June 18, 2014, 6:01pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/11 "2014-06-18T18:01:07Z")
If we want to use Kibana we will run into the same issue. I heard Shay say that Kibana really was not developed for the use case of exposing to external customers but he did not elaborate on that. What I was thinking of doing is wrapping ES in a simple web app that forwards GET requests from Kibana on to ES (keeping the same API) but blocks DELETE, PUT, and POST requests returning a 501 Not Implemented. Do you think that would work for maintaining functionality and disallowing updates and deletes? Would that work for your requirements? Zennet On Thursday, June 12, 2014 7:48:47 AM UTC-7, Harvii Dent wrote: > Hello, > > I'm planning to use Elasticsearch with Logstash for logs management and > search, however, one thing I'm unable to find an answer for is making sure > that the data cannot be modified once it reaches Elasticsearch. > > "action.destructive\_requires\_name" prevents deleting all indices at once, > but they can still be deleted. Are there any options to prevent deleting > indices altogether? > > And on the document level, is it possible to disable 'delete' _AND_ > 'update' operations without setting the entire index as read-only (ie. > 'index.blocks.read\_only')? > > Lastly, does setting 'index.blocks.read\_only' ensure that the index files > on disk are not changed (so they can be monitored using a file integrity > monitoring solution)? as many regulatory and compliance bodies have > requirements for ensuring logs integrity. > > Thanks -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/e4ce0c9a-30a4-4077-b3eb-e4bb5ab2dc0b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/e4ce0c9a-30a4-4077-b3eb-e4bb5ab2dc0b%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [June 18, 2014, 11:51pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/12 "2014-06-18T23:51:57Z")
As said, you can wrap HTTP REST, and filter for GET, or just for \_search endpoint but that is only one part, and it is an incomplete solution. More important is to isolate ES in a private network and to maintain a safe and trusted environment (where every operation on OS level is logged and must be authorized, and also the network and the connected devices such as gateways and routers are known to be secure). This makes it possible to ensure writings can be prevented. Also, append-only file systems should be considered. In such an environment, it is possible to create a copy from a master index, that has not been modified in the meantime, to let others play with it. Why is wrapping HTTP REST not enough? If you do not consider to take special care of port 9300-9400, it is possible for attackers to craft malevolent binary packets and submit these packets to the ES transport protocol ports if they are exposed to outer network access. If Kibana (or other plugins), when exposed for network access from outside, can be used for such operations (by accident or not), I don't know for sure. I hope it is not possible. It all looks like Kibana just uses search methods and can not be used for attacks. But hope is not enough for security. You have to prove by a security audit that everything is "secure", up to a certain level of trust. Jörg On Wed, Jun 18, 2014 at 8:01 PM, Zennet Wheatcroft [zwheatcroft@atypon.com](mailto:zwheatcroft@atypon.com) wrote: > If we want to use Kibana we will run into the same issue. I heard Shay say > that Kibana really was not developed for the use case of exposing to > external customers but he did not elaborate on that. What I was thinking of > doing is wrapping ES in a simple web app that forwards GET requests from > Kibana on to ES (keeping the same API) but blocks DELETE, PUT, and POST > requests returning a 501 Not Implemented. Do you think that would work for > maintaining functionality and disallowing updates and deletes? Would that > work for your requirements? > > Zennet > > On Thursday, June 12, 2014 7:48:47 AM UTC-7, Harvii Dent wrote: > > > Hello, > > > > I'm planning to use Elasticsearch with Logstash for logs management and > > search, however, one thing I'm unable to find an answer for is making sure > > that the data cannot be modified once it reaches Elasticsearch. > > > > "action.destructive\_requires\_name" prevents deleting all indices at > > once, but they can still be deleted. Are there any options to prevent > > deleting indices altogether? > > > > And on the document level, is it possible to disable 'delete' _AND_ > > 'update' operations without setting the entire index as read-only (ie. > > 'index.blocks.read\_only')? > > > > Lastly, does setting 'index.blocks.read\_only' ensure that the index files > > on disk are not changed (so they can be monitored using a file integrity > > monitoring solution)? as many regulatory and compliance bodies have > > requirements for ensuring logs integrity. > > > > Thanks > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/e4ce0c9a-30a4-4077-b3eb-e4bb5ab2dc0b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/e4ce0c9a-30a4-4077-b3eb-e4bb5ab2dc0b%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/e4ce0c9a-30a4-4077-b3eb-e4bb5ab2dc0b%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/e4ce0c9a-30a4-4077-b3eb-e4bb5ab2dc0b%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEmjWGXihmXcObSvzaHduO2%3DXoGdohmUWs3CbBb81SxyQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEmjWGXihmXcObSvzaHduO2%3DXoGdohmUWs3CbBb81SxyQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Jaguar](https://avatars.discourse-cdn.com/v4/letter/j/4af34b/32.png) [@Jaguar](https://discuss.elastic.co/u/Jaguar)\ **Post date:** [June 19, 2014, 2:43am UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/13 "2014-06-19T02:43:49Z")
It's good to hear more demands on security, as that's one big concern for commercial usage. If you are fine with the model of "open to only given group of people", you could try plugin( jetty ) and try enable authentication from there(not something out of box). But that is just some workaround. You don't have control over which REST API to be exposed. And you still can't secure you transport interface. My 2 cents! -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAP0hgQ39F-aXZ6nc4VyzvDFx\_-PVKcNrkhjaqi19qeUOf\_smzw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAP0hgQ39F-aXZ6nc4VyzvDFx_-PVKcNrkhjaqi19qeUOf_smzw%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Harvii\_Dent](https://avatars.discourse-cdn.com/v4/letter/h/96bed5/32.png) [@Harvii\_Dent](https://discuss.elastic.co/u/Harvii_Dent)\ **Post date:** [June 19, 2014, 2:32pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/14 "2014-06-19T14:32:04Z")
@Zennet: I was thinking of doing something similar via a reverse-proxy in front of Kibana, however I believe Kibana still uses DELETE, PUT, and POST requests to save its dashboards, so I'm not sure what to block exactly. @Jaguar: jetty plugin looks interesting, especially the "jetty-restrict-writes.xml" part, I'll be taking a look at that. As Jörg said, it shouldn't be too difficult to create a DELETE request and spoof its source to appear as if coming from a trusted source; I just wish there was an option built into ES to disable deletes/updates or at least authenticate them first. Thanks everyone -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/ec799ca8-a833-49c7-9794-cbb23435e98b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/ec799ca8-a833-49c7-9794-cbb23435e98b%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Harvii\_Dent](https://avatars.discourse-cdn.com/v4/letter/h/96bed5/32.png) [@Harvii\_Dent](https://discuss.elastic.co/u/Harvii_Dent)\ **Post date:** [June 23, 2014, 1:35pm UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/15 "2014-06-23T13:35:41Z")
Just an update, it should be possible to protect ES from most malicious requests that are generated from Kibana's end by only allowing requests as described in this nginx config: [https://github.com/elasticsearch/kibana/blob/master/sample/nginx.conf](https://github.com/elasticsearch/kibana/blob/master/sample/nginx.conf) I've been looking at the ES API references but I didn't find any other ways to do update/delete operations that bypass the above config, although it would be great if someone could confirm that. Thanks -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/3eb483d3-ab1a-425c-b629-c490a67c668a%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/3eb483d3-ab1a-425c-b629-c490a67c668a%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:20am UTC](https://discuss.elastic.co/t/securing-data-in-elasticsearch/18070/16 "2017-07-06T01:20:35Z")