Thanks Jörg. Something like OSSEC (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 <[email protected] > <javascript:>> 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 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 <[email protected]> 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 <[email protected]> >>>>> 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 [email protected]. >>>>>> >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/elasticsearch/dfc73db4-18ac-405e-8929-68be32b01a6c%40goo >>>>>> glegroups.com >>>>>> <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. >>>>>> >>>>> >>>>> -- >>>> 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 [email protected]. >>>> 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?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit 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 [email protected] <javascript:>. >> 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?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/9f7a8514-0e2c-44bf-a798-220ea0c85805%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
