Over the past year, there have been many leaks from Elasticsearch databases. In many cases, personal data was stored in the database. These leaks could have been avoided if, after deploying the database, the administrators took the trouble to check a few simple settings. Today we’ll talk about them.

Let’s make a notice right away that in our practice we use Elasticsearch for storing logs and analyzing the logs of information security tools, OS and software in our IaaS platform.

Checking whether the database is  “out” on the Internet

In most of the known cases of leaks, the attacker got access to the data simply and unpretentiously: the database was published on the Internet, and it was possible to connect to it without authentication.

First, let’s deal with publishing on the Internet. Why does this happen? The fact is that for more flexible Elasticsearch operation, it is recommended to create a cluster of three servers. For the databases to communicate with each other, you need to open ports. As a result, administrators do not restrict access to the database in any way, and you can connect to the database from anywhere. It’s easy to check if the database is accessible from the outside.

Just enter http: // [IP / Elasticsearch Name]: 9200 / _cat / nodes? V

If you manage to enter, directly close.

Securing the connection to the database

Now we will make it impossible to connect to the database without authentication.

Elasticsearch has an authentication module that restricts access to the database, but it is only in the paid X-Pack plugin (1 month free use).

The good news is that in the fall of 2019, Amazon revealed its developments that overlap with the X-Pack. The authentication function when connecting to the database has become available under a free license for the Elasticsearch version 7.3.2., And a new release for Elasticsearch 7.4.0 is already in the works.

Installing this plugin is simple. We go to the server console and connect the repository:

RPM Based:

DEB Based:

Setting up communication between servers via SSL

When installing the plugin, the configuration of the port for connecting to the base is changed. SSL encryption is enabled on it. In order for the cluster servers to continue to work with each other, you need to set up communication between them using SSL.

Trust between hosts can be established with or without your own SA. With the first method, everything is clear: you just need to contact the SA specialists. Let’s go straight to the second.

  1. Create a variable with the fully qualified domain name:

2. Create a private key:

Sign the root certificate. Keep it like the apple of your eye: if it is lost or compromised, trust between all hosts will need to be reconfigured.

Create an admin key:

Create a certificate signing request:

Create an administrator certificate:

Create a signature request:

Sign the certificate:

Put the certificate to Elasticsearch nodes into a folder:

/ etc / elasticsearch /

we need files:

Configure /etc/elasticsearch/elasticsearch.yml – change the name of the files with certificates, to those generated by us:

Change passwords for internal users.

Using the command below, we output the password hash to the console:

Change the hash in the file to the received one:

/usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml

Configure a firewall in the OS

Allow the launch of the firewall:

Launch it:

Allowing connection to Elasticsearch:

Display working rules:

Apply all our changes to Elasticsearch.

Create a variable with the full path to the plugin folder:

Run the script that will update passwords and check the settings:

That’s all, these are the minimum settings that close Elasticsearch from unauthorized connections.