Protecting Against Attacks that Hold Your Data for Ransom | Elastic Blog
Engineering

Protecting Against Attacks that Hold Your Data for Ransom

Editor's Note (September 7, 2018): This post refers to X-Pack. Starting with the 6.3 release, the X-Pack code is now open and fully integrated as features into the Elastic Stack.

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:

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.