Protecting Against Attacks that Hold Your Data for Ransom
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. |
Late last week, a malicious attack was initiated, in which data from thousands of open source databases was copied, deleted and held for ransom. Although no malware, or “ransomware” was used in these attacks, and they are not related to product vulnerabilities, they nonetheless represent serious security incidents involving a data loss, or even a data breach. The good news is that data loss from similar attacks is easily preventable with proper configuration.
So, let’s use this as a timely reminder of how important it is to secure all Elasticsearch instances, especially those that are accessible over the Internet.
Customers choosing Elastic Cloud SaaS Offerings can be assured that their clusters are protected with X-Pack security with randomly assigned individual passwords. They are deployed behind redundant firewalls and proxies within the AWS or GCP region selected by the customer. Encrypted TLS communication from the Internet is provided in the default configuration, data is encrypted at rest, and while in transit between cluster nodes, and Elastic performs backups of cluster data every 30 minutes and maintains them for at least 2 days.
For other deployments, we continue to strongly recommended that unsecured Elasticsearch instances should not be directly exposed to the Internet. See our 2013 blog post. We’ve also put this into practice by having our default installation bind to localhost. Nonetheless, we’ve become aware that there are an increasing number of unsecured, Internet-accessible instances.
If you have an unsecured, Internet-facing instance of Elasticsearch, we urgently recommend that you take immediate steps to protect your data:
- Perform backups of all your data to a secure location and consider Curator snapshots
- Reconfigure your environment to run Elasticsearch on an isolated non-routable network
- Or if you must access the cluster over the Internet, restrict access to your cluster from the Internet via firewall, VPN, reverse proxy, or other technology
And as a set of best practices, we always recommend:
- Upgrade to the latest versions of the Elastic Stack
- If you’re running v2.x, check your scripting settings, or check out new Painless scripting in v5.x
- Add TLS encryption, authentication, authorization, and IP filtering to secure your Elasticsearch instance with X-Pack security
Finally, if you’re not comfortable taking these measures yourself, please consider using our Elasticsearch Service in Elastic Cloud, where security is always enabled.
Editor's Note (December 3, 2018): This post was updated to reflect additional security features available on Elastic Cloud.