Important: Security issues with Elasticsearch index

[Sarah Romkey]

Dear AtoM and Archivematica users:

It has come to our attention that there is a security issue with Elasticsearch index. A description of the security issue is here: http://bouk.co/blog/elasticsearch-rce/

This is only a concern for those running an Elasticsearch index on a public server, meaning it is much more likely to affect AtoM servers than Archivematica.  This does not affect ICA-AtoM installations as it does not use ElasticSearch.

A fairly quick fix is to block port 9200 on all Archivematica and AtoM machines from all public ip's, allowing port 9200 from localhost only (or in the case of an AtoM install, it may be necessary to allow access from the atom front end server, if elastic search is running on a separate machine). This can be done by running ufw on Ubuntu (https://help.ubuntu.com/community/UFW) and blocking port 9200.

There are a couple of changes to the Elasticsearch configuration that are also recommended, to help increase security further:

discovery.zen.ping.multicast.enabled: false

script.disable_dynamic:true

Both of those go into the /etc/elasticsearch/

elasticsearch.yml file and then /etc/init.d/elasticsearch restart

The first parameter stops Elasticsearch from advertising its existence.  The default behaviour in Elasticsearch is to allow new nodes to automatically join a cluster which is intended to be used in private vlans only. When the machine running Elasticsearch has a public IP, it is possible for attackers to scan IP's and do simple http get's to port 9200, looking for Elasticsearch instances.

They then exploit a feature in elasticsearch that allows arbitrary java code to be executed by the server. The 2nd parameter above disables that feature.  This parameter is not understood by all versions of Elasticsearch, so blocking port 9200 on public interfaces is the best step to prevent future exploits.

If you are on this list but are not the system administrator for your instance of AtoM or Archivematica, please forward this message to the appropriate person in your organization.

If anyone in our community has questions or concerns about these issues, please do not hesitate to post to the list and we will do our best to respond in a timely manner.

Cheers,

Sarah Romkey, MAS,MLIS

Systems Archivist
Artefactual Systems
604-527-2056

@accesstomemory / @ArchivesSarah

[Jim Adamson]

Dear Sarah,

Do you know which versions of Elasticsearch support `script.disable_dynamic:true` ? 

Version 0.90.11 is installed on our AtoM 2 servers, and it'd be good to know whether enabling the firewall is advisable.

Thank you

Jim Adamson

University of York Library

[Jesús García Crespo]

Hi Jim,

On Tue, Jul 29, 2014 at 6:21 AM, Jim Adamson <jim.a...@york.ac.uk> wrote:

Do you know which versions of Elasticsearch support `script.disable_dynamic:true` ? 

Version 0.90.11 is installed on our AtoM 2 servers, and it'd be good to know whether enabling the firewall is advisable.

Using a firewall is always important. The elasticsearch http module was not designed to be exposed to untrusted networks as it doesn't provide authorization neither authentication mechanisms. By default, elasticsearch listens on two ports: 9200/tcp (restful api) and 9300/tcp (for java node/transport clients and communications between nodes in a cluster).

Regards,

--
Jesús García Crespo,
Software Engineer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056

[Jim Adamson]

Hello Jesús,

Our AtoM machines (Ubuntu VMs, centrally provisioned) are already behind our campus firewall so a low risk (though those ports are still open inside the f/w). The VM's inbuilt firewall is inactive — I would need to check with our central IT whether enabling the firewall would cause any problems at their end.

Looking at the 0.90 elasticsearch scripting doc there is mention of `script.disable_dynamic:true` so I guess it's understood in v0.90.11.

thanks,

Jim

[Jim Adamson]

Just to add that I found that script.disable_dynamic:true should have a space after the colon — this was causing us a problem with Elasticsearch starting properly.

Jim

[Dan Gillean]

Thanks for sharing, Jim!

Dan Gillean, MAS, MLIS
AtoM Product Manager / Systems Analyst,
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at http://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/f032311f-5703-4591-a202-58083f6c70b3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ben Stewart]

This I should have read first when I setup our server or at least should have implemented it right away.

I miss understood a configuration and was having issues with Elasticsearch with CentOS and opened up the port 9200 on the firewall.

Only took a couple of days to get a IPtablex Exploit dropped into the system and run.

Another option I removed form the Iptables was enabling the eth+ that opened to much.

Thank-you for this information. 

~Ben