• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

ElasticSearch Security Advisory

Slavik

XenForo moderator
Staff member
#1
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

Code:
# network.host: 192.168.0.1
to

Code:
network.host: 127.0.0.1
and

Code:
# http.port: 9200
to

Code:
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).

Code:
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.
 
Last edited:

MattW

Well-known member
#2
I always add this to the config file if it's a localhost only install:
Code:
network.tcp.block: true
node.local: true
Should also save on a bit of resources from what I've read.
 
#4
I always add this to the config file if it's a localhost only install:
Code:
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.
 
Last edited:

Floren

Well-known member
#5
I always add this to the config file if it's a localhost only install:
Code:
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:
Code:
[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:
Code:
# 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.
 
Last edited:

MattW

Well-known member
#8
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;
Code:
[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:
Code:
[root@host ~]# netstat -an | grep 9300
[root@host ~]#
 

Floren

Well-known member
#9
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

Well-known member
#10
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

XenForo moderator
Staff member
#11
@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
 

kontrabass

Well-known member
#14
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

XenForo moderator
Staff member
#15
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

Active member
#16
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

Active member
#19
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?