Securing elasticsearch servers

In a sharded OMS system, orders and shipments that are placed online, at a call center or at stores can be stored in different database shards. The OMS uses a centralized search index to efficiently find orders or shipments across the shards. An order or shipment search in OMS results in a request to the search engine, which will return a list of shards, identified by Colony IDs, that contain the orders or shipments. OMS will then search the appropriate shards in parallel. The OMS search index uses an open source project called elasticsearch, which is based on top of Apache Lucene.

The elasticsearch architecture uses two types of nodes:

  • The elasticsearch servers, or server nodes, store the index data and process the search requests.
  • The elasticsearch clients, or client nodes, reside within each application server, agent server or integration server, and act as clients to the search index. The OMS makes its search requests through these clients.

elasticsearch uses a proprietary protocol to communicate between the elasticsearch clients and servers.

From a security perspective, keep the following in mind when you plan and implement elasticsearch:

  • Access to elasticsearch, including its management APIs, is over unauthorized and unauthenticated REST-based APIs over unsecured HTTP. These management APIs can be used for various tasks, such as dropping the index or modifying the index definition to store more data.

    As a result, you should consider the following security countermeasures:

    • Ensure the elasticsearch is only accessible from OMS, possibly through the use of firewalls.
    • Additionally, if you have a cluster of elasticsearch servers, enable HTTP access on only one server. Browser access to that HTTP-enabled server should be protected, possibly through a firewall that restricts access to a few internal IP addresses. The HTTP access to the remaining servers can be disabled by setting the following elasticsearch.yml property. Setting this property will disable Netty, the HTTP server that provides access through REST-based APIs, in the elasticsearch server.
      	http.enabled: false
    • Alternatively, you could add the elasticsearch Jetty plugin (GitHub) to elasticsearch nodes to implement authentication and encryption.
  • elasticsearch uses Lucene internally to index and search data. Lucene, in turn, stores data on disk in its own format that is not encrypted. An attacker who gains unauthorized access to the elasticsearch nodes could steal the Lucene data store, which stores index key values that have Personally Identifiable Information (PII), such as email IDs and phone numbers. You should, at a minimum, use file-system permissions to control access to the Lucene files. Depending on your security risk assessment, you may add disk encryption to protect the Lucene data while it is being stored on the disks.
  • elasticsearch, by default, allows multicast mode of discovery. In this mode, a new elasticsearch node instance could be started and automatically absorbed into the cluster as long as the new node shares the same cluster.name as the cluster. Although this is convenient, it allows the possibility for an attacker to start a new elasticsearch server node and have it join the cluster.

    Depending on your security risk assessment, you could set the following parameters in the elasticsearch.yml properties to allow only a few specific servers to join the cluster: 

    discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: host:port, host[port1-port2]