Elasticsearch: Heed the Warnings

A few posts on this blog have talked about different topologies one can use to deploy Sugar, either for development purposes or production use. Perhaps the most important point in those posts is the matter of ensuring that one should not expose the Elasticsearch server to any other machine besides the one where the web server is running.

Because Elasticsearch data can be read without any sort of user authentication, exposing an Elasticsearch server means one is allowing potentially malicious users to view sensitive data. Despite this risk, it is not uncommon to hear of Sugar implementations that are configured in ways where Elasticsearch can be directly accessed via the internet or local network. 

A few days ago, the dangers of such a configuration were further highlighted by ransomware makers. Reports have recently surfaced that data from exposed Elasticsearch servers is indeed being compromised and held hostage.

This threat may leave some Sugar administrators wondering about the impact this could have on their Sugar implementations and data. 

Fortunately, Sugar does not utilize Elasticsearch as its primary datastore. In other words, should the Sugar data stored in Elasticsearch be stolen, it can be recreated. This is because the primary datastore for Sugar continues to be the chosen database platform, whether it be MySQL, Oracle or any other supported database engine.

However, it is important to note that Elasticsearch does house sensitive data. For example, the Elasticsearch index for a Sugar instance would typically include phone numbers, email addresses, names and potentially other data one would typically want to protect. In addition to potential unauthorized system access issues, the theft of this data from Elasticsearch is the biggest immediate threat posed to Sugar by this type of ransomware. 

What should you do if your Elasticsearch server is compromised?

You should take the necessary steps to harden your servers and address issues that allowed Elasticsearch to be compromised. This may also mean re-installing Elasticsearch. It is also worth underscoring the earlier point about not exposing the Elasticsearch server beyond the web server machine. Isolation of the server and other useful security recommendations can be found here: http://code972.com/blog/2017/01/107-dont-be-ransacked-securing-your-elasticsearch-cluster-properly

Lastly, once secured, recreating the Elasticsearch index for your Sugar needs is as simple as clicking the button labeled Schedule System Index in the Global Search configuration page found at Admin > Search. You will want to make sure you select the option to delete existing data after clicking the button to schedule the indexing.