Guarding Kibana from Data Hijacking

Editor's Note (August 3, 2021): This post uses deprecated features. Please reference the map custom regions with reverse geocoding documentation for current instructions.

Important note for users of Elastic Stack 6.8/7.1 or later: The default distribution of the Elastic Stack now includes security features that you can enable permanently for free. This includes TLS encryption, user authentication, and role-based access control. Check out Getting Started with Elasticsearch Security for implementation details.

As you may have read, open source applications exposed to the internet have recently been targeted for data ransom attacks in the same spirit as the cryptolocker trojan that targeted desktop computers years ago.  The recent round of attacks are made all the more insidious by the deleting of the data, leaving data owners with few options.

While these attacks are not related to any vulnerability in Kibana, and there are no known ongoing campaigns targeting Kibana installations, there are a few things you can do to mitigate future risk.

Your first line of defense is to not expose Kibana directly to the internet. Kibana 5.x comes pre-configured to bind to localhost by default, as does Elasticsearch.  Note that Kibana 4.x binds to by default, which will make it available on all IPv4 interfaces.  If you must expose Kibana on the internet there are a few step you should take today to protect yourself.

Kibana is designed to prevent deletion or modification of your logging and application data, however the .kibana index must remain writable in order to build visualizations and dashboards, and store other configuration parameters. For this reason we suggest you immediately perform a backup of the .kibana index using the Elasticsearch Snapshot and Restore API. The Elastic Cloud service, which provides Kibana as a service, stores 2 days of cluster data by default.

The next step is to restrict access to known users. Elastic Cloud users are protected by default with the Elastic X-Pack, which comes complete with authorization, authentication and strong HTTPS encrypted communication to the internet.

For on-site deployments of Kibana we strongly recommend the installation and configuration of X-Pack locally.  This should include creating a user with a strong password, creating roles if needed, and enabling HTTPS to protect the communication between the browser and Kibana server.

For those unable to install X-Pack, a reverse proxy may also be deployed. The Basic Authentication section from our blog article on Reverse Proxies and Elasticsearch can be applied to Kibana by substituting port 5601 for the port 9200 in the article. We strongly recommend you also configure HTTPS.

Finally, staying up to date with the latest version of the Elastic stack, and this blog, will ensure you always have the most secure version of Kibana available.   Please ask for help if you need it, either in our forums or via the support portal.