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

ElasticSearch Security Advisory

Discussion in 'Enhanced Search Support' started by Slavik, May 29, 2014.

  1. Slavik

    Slavik XenForo Moderator Staff Member

    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: May 29, 2014
    Xon, thedude, AndyB and 1 other person like this.
  2. MattW

    MattW Well-Known Member

    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.
     
    Slavik likes this.
  3. Slavik

    Slavik XenForo Moderator Staff Member

    So the problem has been confirmed, as has the fix, please ensure your Enhanced Search is running in local mode only.
     
    Last edited: May 30, 2014
    AndyB and MattW like this.
  4. arr0w

    arr0w Member

    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: May 31, 2014
  5. Floren

    Floren Well-Known Member

    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.
    Also, there is no need to define the http.port, it defaults to 9200.
     
    Last edited: Jun 8, 2014
  6. MattW

    MattW Well-Known Member

  7. Floren

    Floren Well-Known Member

    Last edited: Jun 8, 2014
  8. MattW

    MattW Well-Known Member

    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 ~]# 
     
  9. Floren

    Floren Well-Known Member

    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.
     
    jeffwidman likes this.
  10. MattW

    MattW Well-Known Member

    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
     
  11. Slavik

    Slavik XenForo Moderator Staff Member

    Would that not be exactly what I have said?

     
  12. Floren

    Floren Well-Known Member

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

    Floren Well-Known Member

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

    kontrabass Well-Known Member

    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...
     
  15. Slavik

    Slavik XenForo Moderator Staff Member

    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).
     
    HWS likes this.
  16. DRaver

    DRaver Active Member

    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 ?
     
  17. DRaver

    DRaver Active Member

  18. Floren

    Floren Well-Known Member

  19. DRaver

    DRaver Active Member

    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?
     
  20. Slavik

    Slavik XenForo Moderator Staff Member

    No, uncomment it.
     

Share This Page