Description of Elasticsearch setup at CERN for Computer Security and the SOC

The CERN Computer Security team is using two different clusters managed by the CERN IT Centralised Elasticsearch Service. The goal of this service is to consolidate and centralise Elasticsearch installations within the CERN IT department and the CERN experiments.

Glossary

  • Elasticsearch cluster: an Elasticsearch cluster is a stand-alone Elasticsearch installation. It can have one or more entry points.
  • Entry point: A DNS alias pointing to a specific Elasticsearch cluster.

Security

The free version of ReadonlyREST is used to implement ACLs. There is no support at CERN for any commercial security plugins.

Default installation

Access methods

A default installation has the following features: * Access to the Elasticsearch REST interface using basic authentication and kerberos * Access to Kibana on port 443 using SSO and 2FA.

Restrictions

A default installation has the following restrictions: * The Java API is not supported due to security restrictions

Available features

The following features are available by default (on port 443): * egroup based full kibana access (create, update and save dashboards and visualisations) * kibana read-only access (view dashboards, no rights to change or save them though) * egroup based read / write Elasticsearch access * egroup based read only Elasticsearch access

Access to Elasticsearch is granted both using basic authentication or via Kerberos / egroups. Basic authentication is still useful if you need to run clients which do not support Kerberos authentication, like Logstash.

Entry Point configuration

Dedicated git repositories contain the configuration of the CERN Computer Security Elasticsearch clusters. The settings include: curator, kibana settings, template management, etc.

Curator configuration

We are using curator as a tool to close and delete old indices. The official documentation of the tool can be found at https://www.elastic.co/guide/en/elasticsearch/client/curator/current/index.html

The current version of curator, curator 4, can interact with elasticsearch 2 and elasticsearch 5. Please, note that the syntax has changed from the previous version of curator.

The 'curator4.actions' yaml file contains all the actions that curator should do on the cluster. As an example, the next two actions will close any index that is older than 7 days, and delete them when they are older than 90 days

actions: 
  1:
    action: close
    description: Close indices older than 30 days
    options:
      extra_settings:
      timeout_override:
      continue_if_exception: False
      disable_action: False
      ignore_empty_list: True
    filters:
      - filtertype: age
        direction: older
        unit: days
        unit_count: 30
        source: name
        timestring:  '%Y.%m.%d'
      - filtertype: pattern
        kind: prefix
        value: bro_
        exclude:
      - filtertype: closed
        exclude: True
  2:
    action: delete_indices
    description: Delete indices older than 90 days
    options:
      extra_settings:
      timeout_override:
      continue_if_exception: False
      disable_action: False
      ignore_empty_list: True
    filters:
      - filtertype: age
        direction: older
        unit: days
        unit_count: 90
        source: name
        timestring:  '%Y.%m.%d'
      - filtertype: pattern
        kind: prefix
        value: bro_
        exclude:

Elasticsearch templates in git

Elasticsearch accepts the definition of templates that will be applied at the creation of new indices. This is very useful to ensure that the types are correctly specified, and to define aliases. The documentation is available at https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-templates.html

The CERN centralised Elasticsearch service offers the possibility to store those templates on a git repository, and apply them to the cluster. The user will send the requests to the git repo, and those templates will be synchronized every half an hour.