>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 <[email protected]> wrote: > 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]> 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-18a >>>>>>> c-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> >>>>>>> . >>>>>>> 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%40goo >>>>> glegroups.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]. >>> 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 > <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. > -- 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/CAKdsXoHZYK1gnNFdD4HL8aRK_pR_ao55BPgctTb2BamH1z19cQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
