ElasticSearch Security Advisory

[Slavik]

I was informed earlier today about a potential security problem relating to the ElasticSearch service. In very specific cases its appears (but are still investigating) that an attacker has gained access to a users server via an ElasticSearch service that is listening on a public IP address.

The fix is simple, just ensure that the service only listening for localhost connections.


Open up your *ESdirectory*/config/elasticsearch.yml and edit

# network.host: 192.168.0.1

to

network.host: 127.0.0.1

and

# http.port: 9200

to

http.port: 9200

Additionally some IPTables rules can add an additional layer of security, generally if your IPTables rule set includes iptables -P INPUT DROP, and you haven't opened your ElasticSearch port publicly via IPTables, likewise you should be safe. These specific rules can be added if required (alter the port if you have ElasticSearch bound to a different port obviously).

iptables -A INPUT -p tcp -s localhost --dport 9200 -j ACCEPT
iptables -A INPUT -p tcp --dport 9200 -j DROP

Anyone who has had ElasticSearch installed and configured by myself should have already had the network host set to 127.0.01 as part and parcel of the install process (I will of usually sent confirmation of my install settings including this one to you when the install was finished), however if you wish me to check for you, just drop me a conversation with your relevant details.

 

[MattW]

I always add this to the config file if it's a localhost only install:

network.tcp.block: true
node.local: true

Should also save on a bit of resources from what I've read.

 

[Slavik]

So the problem has been confirmed, as has the fix, please ensure your Enhanced Search is running in local mode only.

 

[arr0w]

I always add this to the config file if it's a localhost only install:

network.tcp.block: true
node.local: true

Should also save on a bit of resources from what I've read.

A friend's server was just hacked because of this exploit. The server got infected with two files/services called .IptabLes and .IptabLex, that were being used to DDOS a remote server.

 

[Floren]

I always add this to the config file if it's a localhost only install:

network.tcp.block: true
node.local: true

Should also save on a bit of resources from what I've read.

I don't see anywhere this setting on elasticsearch.org: network.tcp.block. Where did you get that info? I mean is there any documentation on their site about that variable?
IMO, having the network.host set to localhost should suffice, no?

My log entries:

[INFO ][http                     ] [Uni-Mind] bound_address {inet[/127.0.0.1:9200]}, publish_address {inet[/127.0.0.1:9200]}
[INFO ][transport                ] [Uni-Mind] bound_address {inet[/127.0.0.1:9300]}, publish_address {inet[/127.0.0.1:9300]}

Service:

# ss -aln | grep 9200
LISTEN     0      50         127.0.0.1:9200

@Slavik, if the network.host is set to an internal address, there is no way someone will access it from outside world. iptables will block it by default, so there is no need to define any rules.

$ nc -z chronos.axivo.com 22
Connection to chronos.axivo.com 22 port [tcp/*] succeeded!
$ nc -z chronos.axivo.com 9200
$ nc -z chronos.axivo.com 9300

Also, there is no need to define the http.port, it defaults to 9200.

 

[MattW]

This is where I found it from: http://blog.lavoie.sl/2012/09/configure-elasticsearch-on-a-single-host.html
It's never thrown an error adding it to the config file. I dunno, maybe it's an old depreciated setting?

 

[Floren]

@MattW, pretty sure it is. All current network settings are here:
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-network.html

Same goes for node.local, I don't see any reference into documentation. Using logic, binding the IP to localhost will force it local, mixed with the index.number_of_shards.
https://www.axivo.com/resources/elasticsearch-setup.11/

 

[MattW]

I've removed
network.tcp.block: true

but leaving in node.local:true, as that stops node discovery and stops listening on port 9300

removed;

[root@host ~]# netstat -an | grep 9300
tcp        0      0 ::ffff:127.0.0.1:9300       :::*                        LISTEN     
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42950      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42962      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42951      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42960      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42959      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42957      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42956      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42950      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42954      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42951      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42957      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42953      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42958      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42953      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42958      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42959      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42954      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42961      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42956      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42952      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42955      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42961      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42952      ::ffff:127.0.0.1:9300       ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42955      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:9300       ::ffff:127.0.0.1:42962      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:42960      ::ffff:127.0.0.1:9300       ESTABLISHED

added:

[root@host ~]# netstat -an | grep 9300
[root@host ~]#

 

[Floren]

I've removed network.tcp.block: true but leaving in node.local: true, as that stops node discovery and stops listening on port 9300

Doing that does not do what you think. Setting node.local to true will disable the node discovery through network and force it through local JVM. The discovery will always take place, you should remove that option also. I'm pretty sure this is adding unneeded overhead and additional memory usage. I believe they deprecated the option because of that, network was a better choice.

 

[MattW]

So the only thing you are changing in your elasticsearch.yaml is setting network.host to 127.0.0.1?

All the info I've found suggests:

discovery.zen.ping.multicast.enabled=false
node.local=true

 

[Slavik]

@Slavik, if the network.host is set to an internal address, there is no way someone will access it from outside world. iptables will block it by default, so there is no need to define any rules.

Would that not be exactly what I have said?

you haven't opened your ElasticSearch port publicly via IPTables, likewise you should be safe

 

[Floren]

Would that not be exactly what I have said?

Sorry, I missed that in your post. I apologize for the confusion.

 

[Floren]

So the only thing you are changing in your elasticsearch.yaml is setting network.host to 127.0.0.1?

I personally changed the host and the number of shards like into tutorial, anything else is default.

 

[kontrabass]

If I set this
network.host: 127.0.0.1

then my elasticsearch fails to restart. Maybe my settings are screwed up.

I've got XF's "Elasticsearch Server Details" set to my database server's internal IP, port 9200. The config file is all default, only thing I uncommented and customized is the cluster.name. Everything works fine, but I'm guessing I'm not very secure...

 

[Slavik]

If I set this
network.host: 127.0.0.1

then my elasticsearch fails to restart. Maybe my settings are screwed up.

I've got XF's "Elasticsearch Server Details" set to my database server's internal IP, port 9200. The config file is all default, only thing I uncommented and customized is the cluster.name. Everything works fine, but I'm guessing I'm not very secure...

Well this thread discusses other options (ip tables, other config options to change etc, you can also disable dynamic scripting which is the cause of the exploit).

 

[DRaver]

All you need ist change network.host: 127.0.0.1 ?

What ist with network.bind_host: and network.publish_host: ?

Leave it commented out ?

 

[DRaver]

@Slavik and @Floren . Can you answer my question?

 

[Floren]

@DRaver https://www.axivo.com/resources/elasticsearch-setup.11/

 

[DRaver]

Thanks Floren but that is not an answer to my question.

If I change network.host to 127.0.0.1. Will this set network.bind_host and network.publish_host to the same value (127.0.0.1) automatically?

 

[Slavik]

All you need ist change network.host: 127.0.0.1 ?

What ist with network.bind_host: and network.publish_host: ?

Leave it commented out ?

No, uncomment it.