13 January 2017 Engineering

Protecting Against Attacks that Hold Your Data for Ransom

By Mike Paquette

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 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 region selected by the customer.  Encrypted TLS communication from the Internet is provided in the default configuration, and Elastic maintains backups of cluster data for 2 days.

For other deployments, we’ve 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: