Hi, just a quick question regarding potential Kibana vulnerability. Does anyone think that because requests such as get _node/... are executable by any user with access to Kibana return so much detailed data about the entire cluster that that leaves the cluster open to all sorts of attacks from IT savvy malicious individuals?
Hi @nh45,
Kibana itself does not provide any authentication by default. The X-Pack plugin's security feature however provides authentication and authorization support for Elasticsearch and Kibana.
Could you provide more details about the attack scenario you have in mind?
Hi,
I don't have any particular attack scenarios in mind. I am a new ELK user and I was blown away by the amount of detailed info that the get requests returns. In our ELK configuration we do use the X-Pack plugin but we do our authorisation and authentication through Active Directory user accounts and group allocations. So I am not sure to what extent the X-Pack login is contributing to the ELK security.
I am not a security expert so I am not sure if this is a good approach or not. But the scenario I was imagining is that if an authorised user's account was hacked then they could gain access to Kibana and learn an awful lot about the ELK infrastructure including the eco-system in which it lives. Armed with this knowledge the malicious perpetrator may attack ELK or any weak component in its eco-system. Is that plausible? and if so, how might we prevent it?
X-Pack's security component allows for LDAP/AD integration into its role based access control system. Based on that, detailed priviliges may be assigned to users and roles. Due to its monitoring and management features, Kibana requires the logged-in user to have a certain set of privileges in order to access the appropriate Elasticsearch APIs. The Security Chapter of the X-Pack Documentation provides detailed descriptions.
Protecting against a compromise of the user's credentials is outside of the scope of what Elasticsearch or Kibana can provide. There are several best practices that can reduce the damage of a compromise though. Elasticsearch an Kibana could be set up in a way that the user accessing Kibana does not have direct network access to Elasticsearch. Additionally, a separate monitoring cluster can be created with its own Kibana instance, which is only made available to a smaller set of users. Since the Elasticsearch API is http(s), arbitrarily restrictive firewall rules could be put in place in front of Elasticsearch, although this might of course break features.
Other common operational/structural security practices apply to the Elastic Stack as they do to the rest of the IT environment.
edited for typos
Sorry if that sounds a bit vague, but the question was pretty open-ended too 
Hi @weltenwort,
I totally agree my original question was a bit woolly entirely due to the fact that I have a limited understanding of ELK and its security features. However, I am glad that I asked it and I am very pleased with your prompt and detailed response.
Thank you very much.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.