Authorization

NetEye Log Analytics

The log management functionality granted by the SIEM feature module is reflected in Log Analytics module of your NetEye installation. Log Analytics serves as platform for analysis and visualization of SIEM processes, and is designed to work with Elasticsearch. You can use it to search, view, and interact with data stored in Elasticsearch indices, then easily perform advanced data analysis and visualize your data in a variety of charts, tables, and maps.

To support the configuration of datasources, NetEye comes with a preconfigured Elasticsearch Data Source called Elasticsearch-Logstash, which points to the Logstash indices present on Elasticsearch. This Data Source can be used to build Grafana dashboards, similarly to what is done in the ITOA module.

This Elasticsearch-Logstash data source uses the grafana user’s TLS certificates (generated during NetEye installation) to authenticate X-Pack Security. The grafana user by default has no permissions on any Elasticsearch index, but you can add necessary permissions from within X-Pack Security, just by mapping its role to the user grafana.

You can also change the configuration of the Elasticsearch-Logstash data source should you need to personalize it, but be aware that if you change its name, a new data source named Elasticsearch-Logstash source will be regenerated the next time neteye_secure_install is run.

Configuring access Roles

The permissions and roles must be configured as described in the Authentication section.

Note

Kibana Users who are managed by NetEye will be overwritten at each login.

If you modify such a user using the Kibana admin panel, those changes will be lost!

User Management

Elasticsearch user management is based on three main entities:

• User: The authenticated user is defined by a username and password and should be assigned to a role. The users will be automatically created during the NetEye login.

• Role mapping: in NetEye this is used for granting access to all those users that are authenticated via certificates. You can check roles in Elastic in the dedicated Elasticsearch Access Control section.

• Role: A named set of permissions that translate to privileges on resources. A more detailed description of how the user authorization works in Elasticsearch can be found at the following link Elasticsearch provides some built-in roles you can explicitly assign to users. You can always refer to the official documentation for delving into the topic.

A complete guide on how to create new roles within Elasticsearch can be found on Elasticsearch official documentation about Defining roles.

Each NetEye Role can be mapped to one or more Kibana roles.

If a user belongs to more than one NetEye Role with different Kibana roles, the same mapping will be reflected within Kibana.

The Kibana module adds a kibana/roles field for each role (i.e., a comma-separated list of kibana roles which must be correctly defined in Kibana) and also a new role neteye_kibana_sso, which allows to carry out operations on tokens of Elasticsearch Token Service.

All the users with Administrative Access role in NetEye or belonging to a NetEye role that set Full module access for Kibana, will be by default mapped with all the following built-in Kibana roles:

• kibana_admin

• superuser

With the introduction of X-Pack security in Elasticsearch, additional roles are available to allow communication with other modules: they are described in Elasticsearch Access Control.

Elasticsearch Access Control

Elasticsearch Access Control is organised in the following three sections, in which are defined roles, users and role mappings. Each section explains which roles can be assigned to a user and their mapping, which allows to communicate with other modules like neteye, kibana, logstash, filebeat, and tornado.

Warning

Default roles, users and role mappings will be owerwritten every time neteye_secure_install is executed, therefore the user should not overwrite them but instead create its own roles, users and role mappings.

Elasticsearch Roles

Each of these roles enables a user to access the authenticated endpoint.

• logstash_neteye : This role will enable access for logstash-* and *beat-* indices with all privileges.

• filebeat_neteye : This role will enable access for filebeat-* indices with all privileges.

• tornado_neteye : This role will enable access for tornado-* indices with “create_index”, “create”, “write”, “read” privileges.

• neteye_es_check : This role allows the communication of NetEye with Elasticsearch for monitoring purposes via NetEyeElasticCheck certificate.

• neteye_kibana_sso : This role allows to perform operations on tokens that are generated by the Elasticsearch Token Service.

• ebp_user_write_only_neteye : This role allow to create and write any index but does not allow read or other operation. It is intended to write data through the El Proxy.

• elastic_blockchain_proxy_neteye : This role allows only to read “ES_BLOCKCHAIN.iteration” and “ES_BLOCKCHAIN.hash” fields on any index in order to allow the El Proxy retrieve information required to handle the blockchain.

Elasticsearch User

Each user has a fixed set of privileges.

• kibana_root : This is the root user of kibana and is mapped with kibana_admin, and superuser built-in roles.

• ebp_user : This is the default El Proxy user used in the ebp_persistent pipeline and is mapped with ebp_user_write_only_neteye built-in role.

Note

Starting from NetEye 4.13, the Elastic Logstash user pre-configured in NetEye will be deprecated and only authenticated via certificates and not via basic authentication. Hence, we strongly suggest to remove the user manually using the Kibana GUI (Log Analytics / Management / Users).

For more details on built-in roles, please refer to the official Elasticsearch guide.

Elasticsearch Roles Mapping

Role mappings define which roles are assigned to each user. Each mapping has rules that identify users and a list of roles that are granted to those users.

• filebeat_neteye : This role mapping allows a user filebeat mapped with beats_system (built-in role) and filebeat_neteye role to communicate between filebeat and elasticsearch.

• neteye_es_check : This role mapping allows the communication between neteye and elasticsearch via NetEyeElasticCheck certificate.

• tornado : This role mapping is used for the Tornado Elasticsearch executor to allow a user tornado to write events according to tornado_neteye role.

• logstash : This role mapping allows a user logstash mapped with beats_admin, logstash_admin, logstash_system (built-in roles) and logstash_neteye role to communicate between logstash and neteye.

• elastic_blockchain_proxy_neteye : This role mapping allows the communication between El Proxy and Elasticsearch via NeteyeElasticBlockchainProxy

Debug Elasticsearch Access Control

If you need some extended information about the Elasticsearch access control, for example for troubleshooting, you can add the following lines to the configuration file of Elasticsearch log facility (i.e.``/neteye/local/elasticsearch/conf/log4j2.properties``) for each node in the cluster:

# elasticsearch debug
logger.authc.name = org.elasticsearch.xpack.security.authc
logger.authc.level = DEBUG

Then, Elasticsearch must be restarted on each node and the Elasticsearch log /neteye/local/elasticsearch/log/neteye.log will then contain advanced debug information, useful to understand your problem.