Learn Wazuh - Encryption, Keys, and Secure Agent Communication

#Introduction

In episode 15, we secured the API and dashboard. Now we discuss the path that connects the most components: communication between agent and manager. Every host we monitor talks to the manager continuously, and this path is the most often underrated.

Imagine if agent communication were unencrypted. Anyone who could tap the network could read our security events, modify data, or even impersonate an agent. All the hard work of detecting threats would be in vain.

In episode 16, we'll cover how Wazuh secures this path: mTLS with X.509 certificates, automatic and manual enrollment, the UDP versus TCP protocols, the role of headers and shared keys, and why you should never expose the manager to the internet without hardening.

#The Agent-Manager Communication Architecture

Before diving into technical details, let's first understand the communication flow. The agent connects to the manager through two ports:

Port 1514: transport for regular events and logs.
Port 1515: registration and enrollment of new agents.

Both are served by the manager. In Wazuh 4.x, security rests on X.509 certificates. Every agent has a certificate issued by the manager's CA, so both parties can verify each other's identity.

#mTLS and X.509 Certificates

Agent-manager communication uses mutual TLS. That means not only does the agent verify the manager, but the manager also verifies the agent. This prevents attacks where an attacker impersonates the manager to steal events.

The certificate chain is simple:

The manager has a root CA that issues all certificates.
Every agent gets a client certificate signed by that CA.
The indexer also has its own CA, because Filebeat and the dashboard talk to the indexer using mTLS.

With this model, one leaked certificate only affects the related agent, not the entire infrastructure.

#Automatic Enrollment with the -i Flag

The most common way to add agents is automatic enrollment. When an agent is first started, it contacts port 1515 and requests a certificate. The manager responds and immediately issues a certificate for that agent.

On all-in-one installations, automatic enrollment is active by default. The install command shown by the dashboard just needs to be run on the target host.

Install and enroll the agent automatically

WAZUH_MANAGER='10.0.1.11' \
WAZUH_AGENT_NAME='web-server-01' \
  curl -s https://10.0.1.11:443/wazuh-agent.sh | bash

After that, the agent daemon performs a handshake with the manager using the -i flag, which triggers auto-enrollment.

Manual enrollment with the -i flag

/var/ossec/bin/agent-auth -m 10.0.1.11 -A web-server-01 -i

::: code-group

Automatic enrollment is convenient, but there's one important requirement: port 1515 must be reachable by the agent. In closed environments, this approach is often replaced with manual enrollment.

#Manual Enrollment with a Key

Manual enrollment suits environments with strict security policies. Instead of opening port 1515 to all agents, we issue a key on the manager side, then install it on the agent manually.

In older Wazuh versions, this was done with manage_agents. In Wazuh 4.x, the manual flow uses the API: we create a temporary enrollment key, send it to the agent, then deactivate it after use.

Creating an enrollment key via the API

{
  "name": "web-server-01",
  "ip": "any"
}

The generated key is only valid once. After the agent is successfully registered, the key automatically expires. This prevents misuse of an already-used key.

Info

Automatic and manual enrollment both produce an X.509 certificate for the agent. The difference is in the trust distribution process, not in the encryption mechanism used after registration.

#Transport Protocol: UDP versus TCP

Agent events are sent through port 1514. The question is: UDP or TCP? Both work, and the choice affects reliability.

UDP: lighter and faster, good for very high event volumes, but packets can be lost without a trace.
TCP: more reliable because delivery is acknowledged, good for security data that must not be lost.

The Wazuh default is UDP. For environments that prioritize integrity, many switch to TCP. The configuration is done on the manager side in the <remote> section.

Remember, the <connection> value must be consistent between manager and agent. If the manager uses secure with the tcp protocol, agents are configured in their respective ossec.conf files.

::: code-group

#Headers and Shared Keys

Every event sent by an agent contains a fixed-format header. This header carries metadata like the agent ID and name, and is an important part of communication integrity.

Besides certificates, legacy Wazuh communication can also use shared keys. A shared key is a symmetric secret shared between the manager and agent. In the 4.x architecture, the shared key's role is mostly replaced by X.509 certificates, but understanding the concept is still useful, especially when reading old documentation or handling clusters.

The most important thing to remember: a shared key must never be transmitted over the network without encryption. Once the key moves, all communication can be held hostage.

#Don't Expose the Manager to the Internet

The manager is the most attractive target in the entire stack. It holds all events, certificates, and control over agents. Exposing it directly to the internet without hardening is an invitation to be attacked.

Principles we hold:

Don't open ports 1514 and 1515 to the public internet.
Remote agents should connect via VPN or WireGuard.
Limit access to port 55000 for the API to known addresses.
The dashboard should sit behind a reverse proxy with TLS and MFA.
Use a firewall to limit the sources that can reach each port.

The safe port to open is 443 for the enrollment script, and even that should be restricted. For agents spread across different locations, VPN is better than exposing the manager directly.

#Verifying Secure Communication

After all the configuration, we need to make sure communication is truly running on mTLS. The fastest way is looking at the connection details on the manager side.

View agent connections from the manager

ss -tn | grep 1514

The output will show active TCP connections from agents to the manager. To check the certificate in use, inspect the certificate file in the agent's directory.

Check the agent certificate

openssl x509 -in /var/ossec/etc/sslmanager.cert -noout -subject

::: code-group

If the certificate subject matches the agent name, communication is already using the correct identity.

#Conclusion

In episode 16, we covered encryption and security of agent-manager communication. We understand mTLS with X.509 certificates, the difference between automatic enrollment with the -i flag and manual enrollment with a key, the UDP versus TCP protocols, the role of headers and shared keys, and the importance of not exposing the manager to the internet.

Key takeaways:

Agent-manager uses mTLS with certificates issued by the manager's CA.
Automatic enrollment uses port 1515 and the -i flag.
Manual enrollment suits environments with strict policies.
TCP is more reliable than UDP for events that must not be lost.
Headers and shared keys are legacy concepts still worth reading.
The manager must not be opened to the internet without VPN and firewall.

Communication is secure, now it's time for the intelligence. In episode 17, we'll cover custom rules and advanced detection: creating rules for specific use cases, variables, alert overrides, cross-agent correlation, up to GeoIP enrichment and threat intel. See you there!