Filebeat, Elastic, Communication

[Alvaro Victoriano]

Hello Team,

I have some doubts about the comunication between Filebeat and Elastic.

I was reading this article of yours https://documentation.wazuh.com/current/getting-started/architecture.html

it says that filebeat uses TLS to comunicate with Elastic, that its configuered by defualt? cz in the documentation part i didnt see something like this.

Iam using Elastic 7.3 and Wazuh 3.9.5.

And I would like to ask, what is the posibilty of hacking the comunication between the "agent and manager" and the worker node to the master "Filebeat to Elastic" (iam talking about the worst that could happen, i know it uses AES)?

If the server Master been hacked for exmaple, what the critic you that could happen to the agents? is there posibilty to spread Ransomewere or any other viruses on the agents for exmaple?

If the agent been hacked, the comunication it uses with the manager, it can be used in a bad way?

I really have a big responsability because of the huge number of the agents i have, so i need to be sure about all of this

Please i need your suggestions and discusion.

Thank you so much

[Pablo Rodríguez Martín]

Hi, Alvaro.

Sorry for the late response. Answering your questions:

Use of TLS by Filebeat
Filebeat uses plain text for its communication with Elasticsearch by default. However, you can configure TLS encryption, making use of SSL/TLS certificates in order to encrypt the HTTP communications with the Elasticsearch machine in a distributed architecture, more concretely, the list of trusted certificate authorities from the operating system where Filebeat is running. You can configure Filebeat to use a specific list of CA certificates instead of the list from the OS or to use the client authentication by specifying the certificate and key to use when the server requires Filebeat to authenticate. In this way, communication with Elasticsearch will be harder to exploit because of its asymmetrical ciphering. Hacking this communication could only be possible by knowing the (de)ciphering keys or by accessing the nodes system. You can check how to do it at the documentation.

Hacking communications
About the possibility of hacking the communication between an agent and its manager, agents do use AES (or optionally Blowfish) for communications with the manager; but also TLSv1.2 for self-registration. In this way, with agent.keys authentication, agents will always validate that they are talking with the correct manager and neither AES or TLS still have got any breach due to their hardiness, so an attacker practically will never be able to impersonate the Wazuh server or sniff its communications. In the worst hypothetical case in which an attacker might know the (de)ciphering keys by brute force (guessing from 2^256=1,158·10^77 possible values with AES-256), both agent and manager have the so-called 'rids', which are in charge of counting the number of messages shared between them. In case these numbers are different between machines, Wazuh will avoid the attacker to continue with the attack by closing the communication.

Then, about the communication between Wazuh cluster's master and worker nodes, the information shared between them is reduced to less information, but crucial for the Wazuh system such as the registered agent.keys with worker nodes. Those keys generated after an agent registration are used for authentication with its manager through an AES encryption and are shared between Wazuh manager cluster nodes for load balancing. Only with them and the AES deciphering key, it is almost impossible to perform.

I hope you find this information useful for your commit.

Regards,
Pablo Rodríguez

[Alvaro Victoriano]

Thank you so much Pablo, Is so good and helpfull what you have explained.

and sorry for the later response

So we can say everything is automaited about security of Wazuh, only I have to configuer manually the communication between:

Filebeat to Elastic

Kibana from/to Elastic

So I have done it accoarading to your docs: https://documentation.wazuh.com/3.9/installation-guide/installing-elastic-stack/protect-installation/xpack.html

But I have some doubts.

instances:
    - name: "wazuh-manager"
      ip:
        - "10.0.0.2"
    - name: "elasticsearch"
      ip:
        - "10.0.0.3"
    - name: "kibana"
      ip:
        - "10.0.0.4"

That in case if the involved components are in diferent instances(so diferent IPs) right? so we generate from the Elastic Node
a certificate for each one of them in form to comunicate with Elastic correct?

If all of those components were in same host like in my case, then is enough to mention only one IP? like this for example:

instances:
    - name: "any-name"
      ip:
        - "10.0.0.2"
and use this generated certificate for Filebeat and Kibana to communicate with Elastic,
as well as filebeat in other workers? becuase I have aother 3 workers

I did a test, the generated .key and .cert i used them to filebeat and to metricbeat as well,
and it worked fine, so what would be the explanation?

Thank you Pablo

[Pablo Rodríguez Martín]

Hi, Alvaro.

I am happy you found it helpful. Now, answering your questions:

The command /usr/share/elasticsearch/bin/elasticsearch-certutil cert ca --pem --in instances.yml --out certs.zip creates the key and the certificates for all the nodes included in /usr/share/elasticsearch/instances.yml.

Those instances are related to their IPs. In this way, you can configure only one instance in case you have the wazuh-manager, Elasticsearch and Kibana in the same machine, so you can do it as you are proposing. Just be careful with the configuration, because you have to use the same certificate and key files for Filebeat, Elasticsearch and Kibana.

However, in this case you have set workers in different machines, add their IPs to the "workers"  instances as a list of nodes with their IPs. This will create certificates and keys for all the nodes. For example, you would be able to do this as follows:

instances:

    - name: "wazuh-ELK"

      ip:

        - "10.0.0.2"

    - name: "worker1"

      ip:

        - "10.0.0.3"

    - name: "worker2"

      ip:

        - "10.0.0.4"

    - name: "worker3"

      ip:

        - "10.0.0.5"

After that, distribute all certificates and keys between nodes and configure all of them.

Please check all the nodes' communications with Elasticsearch because that may not work as the workers are in different machines.

Best regards,

Pablo Rodríguez

[Alvaro Victoriano]

Hello Pablo.

I have done it and its working so good without any problem.

[Pablo Rodríguez Martín]

Hi, Alvaro.

Everything seems to be working properly. Glad to have helped.

Regards,
Pablo Rodríguez

[Alvaro Victoriano]

I have one more question Pablo.

If the certificates are related to the server IP,

What about if iam going to creat a certificate for another Filebeat, this filebeat is in another environment and gonna send his logs to the manager where Wazuh is.

so should i use the certificate been created here?

instances:

    - name: "wazuh-ELK"

      ip:

        - "10.0.0.2"

Thanks

[Pablo Rodríguez Martín]

Hey Alvaro,

Sorry for the late response. As far as I understand from your question, you would like to deploy a new node to your Elasticsearch cluster as you mentioned and then use Filebeat on it in order to forward all its logs to the Wazuh manager, right? I think you may be looking for a Wazuh agent instead.

The Wazuh agent runs on a host you want to monitor. then It will automatically forward all the information gathered to the Wazuh manager, including the logs you mention. As I mentioned in a previous e-mail, the communication between an agent and the manager is already ciphered with AES by default, so you will not have any trouble with this communication channel's security.

Additionally, X-Pack is configured only in the Elastic Stack machines: Filebeat (Wazuh manager machine), Elasticsearch and Kibana (also Logstash in case of use); and not in the Wazuh nodes. In this way, you don´t have to worry about X-Pack and will only have to register and configure the agent to convey the logs to your Wazuh manager.

The overall flow would be the Wazuh manager generates the alerts (after correlating/analyzing the logs coming from the Wazuh agent) under /var/ossec/logs/alerts.json, Filebeat reads the latter and then forwards the logs to Elasticsearch that can be viewed afterward in Kibana UI.

I hope you find this information helpful. Let me know if you have more questions about this.

Best regards,

Pablo Rodríguez

[Alvaro Victoriano]

Hello Pablo.

Sorry if i didtn explain fine, no iam not going to deploy a new node, actually iam getting Metrics by Metricbeat of some agents so i thought i can use the same certificate i been created for ELK.

As well as iam going to deploy ELK in cluster (in 3 nodes) so how i add 3 certificates in filebeat if iam going to generate one of each node? or its enough to use the one i created in the master node and filebeat allready using it? should i just copy this certificate of the master node of ELK to the other nodes?

Thank you Pablo, y me disculpe me siento perdido con este tema de los certificados

Enter code here...

[Pablo Rodríguez Martín]

Hi, Alvaro.

It will depend on the command used to generate those certificates and keys for all the instances you did set before.

The previous one provided (/usr/share/elasticsearch/bin/elasticsearch-certutil cert ca --pem --in instances.yml --out certs.zip)  will not save the ca.key file on the disk so it cannot be used again to sign other certificates, ensuring it will not be used to generate a false identity.

Now, in case you would like to add new nodes to the Elastic Stack's X-Pack set, in your case Metricbeat on agents, you will have to create again new certificates and keys by adding the new instances to /usr/share/elasticsearch/instances.yml and then follow the steps as explained.

However, in case you foresee to expand it, create your own CA certificate and key by using the command /usr/share/elasticsearch/bin/elasticsearch-certutil ca --pem --out ca.zip. Then, unzip it and execute the following command to obtain the certificates and keys for all the machines:

/usr/share/elsticsearch/bin/elasticsearch-certutil cert --pem -ca path/to/ca.cert --ca path/to/ca.key --in instances.yml --out certs.zip

Then, in case you want to add new nodes, you can use the following command:

/usr/share/elsticsearch/bin/elasticsearch-certutil cert --pem -ca path/to/ca.cert --ca path/to/ca.key --ip x.x.x.x --out certs.zip

For more information, please check https://www.elastic.co/guide/en/elasticsearch/reference/current/certutil.html

Please notice that you will need the node's address of your Metricbeat machines and the paths for both CA's certificate and key. Once you have finished the process, keep that key file safe both for security reasons and in order to be able to use it again in the future.

I hope you find this helpful.

Regards,

Pablo Rodríguez

[Alvaro Victoriano]

Thats so good.

Thank you so much for your help Pablo, Everything went fine

Saludos

[Pablo Rodríguez Martín]

Hello, Alvaro.

Thank you for your feedback. I'm very happy to read that. 

Best regards,
Pablo Rodríguez