This article is relevant to customers who want to learn how to secure their Elasticsearch deployment by preventing exposure to the internet. Additionally, this article provides clarity on signatures that Alert Logic® released for Elasticsearch exposure and what it means when Alert Logic raises a notification about a certain set of events.
Elasticsearch is a distributed search server that has a full-text search engine and a schema-less datastore. The Elasticsearch solution exposes HTTP APIs (for indexing new data, creating indices, managing clusters, etc.) and a set of client applications (like Kibana, the web client for Elasticsearch or custom clients that use the search API).
By default, the indexing service APIs listen on port 9200 and 9300 and do not perform any authentication on the API calls. This allows an unauthenticated user to call the Elasticsearch APIs to perform unauthorized functions on the target cluster like copying data, deleting data, or encrypting your data (ransomware style). This is similar to allowing anonymous telnet or ssh access on a Unix server.
To mitigate this, Elasticsearch recommends not exposing this service directly to the internet and instead using additional networking controls or security add-ons to enhance the security of this solution.
Actions You Should Take
Alert Logic has seen that customers across our customer-base have deployments that are accessible to the internet. We recommend the following measures:
- Contact the owner of your Elasticsearch deployment to understand the network controls that are in place and ensure that they are not exposed to the internet without authentication.
- Follow the best practices for securing Elasticsearch deployments as recommended in Elastic’s blog.
- Use the procedure at the end of this article to identify IP addresses that require further action.
Alert Logic will continue to monitor our customer assets for this exposure and will have our SOC reach out with further evidence of potentially unsafe deployment practices. We are essentially looking for two patterns of network behavior using signatures specifically developed for this.
Alert Logic Coverage
Alert Logic has deployed Intrusion Detection System (IDS) signatures to monitor traffic from the internet to look for the following patterns:
- We have witnessed TCP connections from sources on the internet (with valid routable external IP addresses indicating they are not from your internal network). See below for a procedure on finding the specific IP addresses that have been involved.
- We observed that the sources could access ports 9200 and 9300 which are default ports for the Elasticsearch APIs.
- We also observed responses from your servers where the network traffic was typical for the protocol that Elasticsearch uses.
This detection is available for Alert Logic Threat Manager™ customers and Alert Logic Cloud Defender™ customers.
Please note that what we detect is evidence that you have or previously had an Elasticsearch deployment that was accessible via the internet. This does not necessarily mean that you are actively under attack. While you might have a legitimate scenario to do so, exposing your Elasticsearch interface to the internet does leave the APIs on ports 9200 and 9300 open to the internet, putting you at risk for future attacks.
Find the specific IP addresses that have been involved
The events that fire on this behavior have specific signatures that you can look up via your the Alert Logic console.
- In the Alert Logic console, navigate to the Threat Manager page.
- In the left navigation area, under Monitoring, choose Monitors.
This is where you can look for specific events. Click on Search Filters on the right to specify a specific event query.
- In the Search Filters pop-up box, set the following properties: Signature > Contains > AL Elasticsearch REST API.
If you need to search further back, click the drop-down next to Range and select your desired time range.
The result set will show the public IP address as the Elasticsearch server address that was seen in the detected behavior. Consult with your local Elasticsearch administrator to find out the deployment and how to prevent worldwide access.