How to Protect Against Elasticsearch Ransomware Attacks
By Fei Huang, Co-Founder and CEO, NeuVector
As if it wasn’t already bad enough, the ransomware attacks on MongoDB users continue to spread and have now targeted exposed Elasticsearch clusters. Like MongoDB, Elasticsearch is one of the most popular containerized applications and is widely used all over the world in datacenters.
In these Elasticsearch ransomware attacks, the attackers wipe out user data and leave a single index with a ransom message like,
“SEND 0.2 BTC TO THIS WALLET: 1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r IF YOU WANT RECOVER YOUR DATABASE! SEND TO THIS EMAIL YOUR SERVER IP AFTER SENDING THE BITCOINS.”
It is also reported that it’s not clear if victims actually get their data back after paying the ransom.
The attacks are actually super simple but it turns out that the results are surprisingly effective. To date more than 9750 servers were damaged and more than 450TB of data was deleted. Some estimates put the number of internet-accessible Elasticsearch deployments at around 68,000.
So why this is happening and what lessons have we learned?
These types of ransomware attacks are targeting wide open cloud servers which are mostly misconfigured or weakly secured. The concept is very simple: keep scanning and trying to identify servers. There are even web sites that help attackers know where these public facing Elasticsearch servers are. And once attackers get the list of IP addresses the rest of the job is relatively easy. They simply try to access well-known ports and interfaces, then use default passwords to gain access to the server. After that is accomplished, they encrypt or delete user data and block the application until a sum of money is paid.
Basic Protections Against Elasticsearch Ransomware Attacks
To prevent this, most security companies or researchers would suggest:
- Don’t expose your internal servers to the public unnecessarily. If a server needs to be accessed externally, limit the IP ranges or groups to make sure it is not open to everyone. For example: HTTP enabled nodes need to listen only to private IP addresses.
- Leverage existed application’s security settings. Enable security plugins or configuration options of Elasticsearch.
- Upgrade and patch to the most recent versions.
- Apply good security practices like using strong passwords, proxies and network segmentation to have certain levels of isolation. Configure interface properly so you’re not using default ports. Disable HTTP, scripting and other interfaces if you don’t need them.
- Enable some form of access control and/or authentication.
- Of course, if you have additional security devices or software in place, customize them and turn on policies for servers, ports, IPs etc.
From a security perspective, these are all good and valid suggestions. But how realistic it is to expect these to be done consistently can be a big concern. It’s really hard for a traditional security solution or your security configuration process to keep up with these cloud application servers, especially in the hyper dynamic container environment. Remember that these all need to keep updated as the MongoDB or Elasticsearch container clusters keep scaling in and out, in addition to adapting to auto-scaled host VMs. How can you maintain security for containers when they keep changing, without slowing everything down?
Intelligent Container Security
NeuVector has the perfect solution for automating security policies for dynamic containers. After deploying the software as containers, NeuVector will automatically learn your container’s normal application behavior then lock it down to protect it from attacks. It will minimize every container’s attack surface regardless of whether attacks originate from external or internal sources. This approach is one of the most efficient methods for protecting your application containers against ransomware attacks. Even misconfigured and weakly secured applications will gain good protection at run-time.
Here’s a quick example. Let’s say I have several applications which only talk within my private network. The Elasticsearch micro service normally would only communicate with one of my internal virtual machine 10.1.0.10, but say by accident this Elasticsearch container was wide open without any restrictions.
When NeuVector protection is in place of this environment, a ransomware attack will try to attack my Elasticsearch container from an external network or even from an internal VM. NeuVector will be able catch these violations at run-time.
If NeuVector is in Enforce mode, these attack attempts will be blocked right away. But at same time my Elasticsearch container can still talk to 10.1.0.10 as it used to, so the protection does not affect normal application traffic.
There are other security concerns for running containers. Many users have outdated versions, and new vulnerabilities are being discovered and patched. Even the latest official Elasticsearch container also has some known vulnerabilities, as shown from the scan below. In the security space, a vulnerability scanning solution is like a never ending chase. It helps and is better than nothing, but alone is not a good enough complete solution. To gain adequate protection for cloud application containers a multi-layered run-time solution is needed. The NeuVector solution provides this multi-layered continuous security protection for your running containers.
Today MongoDB and Elasticsearch are being targeted by attackers, but there are hundreds or thousands of other cloud applications running all over the world which also may be vulnerable. One of them could be yours, and you may not be aware of it yet. It is critical to make sure all servers and the containers running on them are well protected at runtime, even if they have been misconfigured or weakly configured. Intelligent, application aware protection for containerized applications provides a better way to help address these MongoDB and Elasticsearch ransomware attacks.