02. 10. 2023 Reinhold Trocker Log Management, Log-SIEM

Integration of Elasticsearch Clients without Authentication and without TLS

Introduction

Let’s say… you have a product that has some Elasticsearch output, which deals with parsing and indexes, and also comes with a nice dashboard, etc., and let’s suppose… you would like to use this built-in functionality.

And let’s say… the product in question wants to connect to Elasticsearch in an unauthenticated manner over HTTP.

SOLUTION: We can set up the stunnel config as described below.

ATTENTION THOUGH: We should think of additional countermeasures so that not just anyone can access this unauthenticated HTTP listener that allows direct access to Elasticsearch.

Configure stunnel to accept HTTP on 9100 and forward to Elasticsearch port 9200

# cat /etc/stunnel/stunnel.conf
[remote]
client = yes
accept = 9100
connect = elasticsearch.neteyelocal:9200
cert = /neteye/local/elasticsearch/conf/certs/admin.crt.pem
key = /neteye/local/elasticsearch/conf/certs/private/admin.key.pem

This configuration uses the administrative key for Elasticsearch, allowing the unauthenticated client to have all rights on the Elasticsearch database.

Enable the stunnel service and run it

# systemctl enable stunnel --now

This turns on stunnel immediately.

Enable a local firewall

## run this on all receiving nodes
firewall-cmd --add-port=9100/tcp --permanent
firewall-cmd --reload

These commands are necessary to enable the above configured stunnel to accept incoming connections.

If you want to limit the connections to specific senders, please see the firewall-cmd documentation, or use a firewall that “hides” NetEye from the rest of the network.

Limit specific rights in Elasticsearch

Until now we’ve configured stunnel to allow an unauthorized HTTP client to have full access to Elasticsearch, using the admin certificate specified in the stunnel.conf file above.

If you want to change these full access rights to a more specific, limited role, you should follow all the following steps:

Create a specific limited role for this use case in Stack Management -> Roles within Kibana
Create a specific client certificate for this use case: please see NetEye SIEM Self-Security | www.neteye-blog.com
Create a specific role mapping in Stack Management -> Role Mappings within Kibana, which associates the new certificate with the previously created limited role
Use the new certificate file and the new key file in stunnel.conf

These Solutions are Engineered by Humans

Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find security issues interesting, maybe you could start in a cybersecurity or similar position here at Würth Phoenix.