Wazuh Network Segmentation and Log Collection

The Core Tension: Visibility vs Exposure

A SIEM needs to see everything, but a system that can reach everything is dangerous. This is the central tension in log collection design. To monitor a segmented network, Wazuh must receive telemetry from every security zone, including sensitive ones. But if the Wazuh manager can be reached from, or can reach into, every zone, it becomes both a high-value target and a potential pivot point that undermines the segmentation it is meant to help protect.

The resolution is directionality and minimal exposure. Telemetry should flow one way: from monitored systems toward the SIEM, never the reverse. The collection paths should be as narrow as possible, carrying only the specific protocols and ports required. And the SIEM's own management plane should be isolated so that compromising a monitored host does not hand an attacker the keys to the monitoring system.

Getting this right matters for compliance as much as security. Frameworks that require network segmentation (PCI DSS most explicitly) also require monitoring of the segmented environment. A monitoring architecture that breaks the segmentation to achieve visibility defeats the control. Assessors look closely at how the SIEM spans zones.

How Wazuh Agent Communication Works

Wazuh's agent model is well suited to segmented networks because communication is agent-initiated and outbound. The agent connects to the manager on TCP 1514 to send events and on TCP 1515 for enrollment and registration. The agent does not open a listening port for the manager to call back into, which means you do not have to allow inbound connections to monitored hosts for collection.

This directionality simplifies firewalling enormously. To monitor a host in a restricted zone, you allow that host to make an outbound connection to the manager on the collection ports, and nothing more. The restricted zone does not accept inbound connections from the management zone for monitoring, preserving its inbound posture. Agent enrollment can be controlled with pre-shared keys or password-based authentication so that only authorised agents register.

All agent-manager communication should run over TLS. Wazuh encrypts the channel, so even where telemetry crosses less-trusted network segments it is protected in transit. Combined with authenticated enrollment, this means a network observer cannot read the telemetry and an unauthorised host cannot impersonate a legitimate agent. Certificate management is part of a sound deployment: use an internal CA for agent communications and rotate as policy dictates.

Collecting Across Segmented Zones

When the network is divided into zones, you have two broad architectural choices for getting telemetry to the manager. The first is direct agent-to-manager flow, where each agent in each zone connects outbound to a centrally placed manager on the collection ports. This is simple and works well when the firewall policy can permit those narrow outbound flows from each zone to the manager.

The second, for stricter environments, is a tiered collection design. Place a local collector or a Wazuh component in each zone that aggregates telemetry from that zone, then relays it to the central manager through a single, tightly controlled path. This minimises the number of cross-zone flows to one per zone rather than one per host, which is easier to firewall, audit and reason about. It also localises syslog from network devices so that raw, often unencrypted, syslog does not traverse zone boundaries.

For very high assurance environments, a data-diode or one-way-gateway pattern can enforce the directionality at the hardware level, guaranteeing that nothing can flow from the SIEM back into the protected zone. This is overkill for most businesses but appears in critical infrastructure and maritime OT contexts. The right choice depends on the sensitivity of the zones and the assurance the environment requires.

Syslog From Network Devices

Network devices, firewalls, switches, routers, load balancers, do not run Wazuh agents. They emit telemetry as syslog, traditionally over UDP 514 and optionally TCP 514. Wazuh receives syslog directly or via a collector, parses it with the relevant decoders, and treats it like any other event source.

Plain syslog is a weak point in a segmented design for two reasons: UDP syslog is unencrypted and unauthenticated, and it is connectionless so delivery is not guaranteed. To handle this safely, place a syslog collector close to the devices, within the same zone or trust boundary, so the unencrypted syslog has the shortest possible path and does not cross zone boundaries in the clear. The collector then relays the data to the manager over the encrypted, agent-style channel.

Where the devices support it, prefer TCP syslog or TLS-encrypted syslog over plain UDP for reliability and confidentiality. Reconcile your device inventory against the sources actually reporting, since a firewall that silently stops sending syslog creates a blind spot in exactly the place you most need visibility. Alert on expected syslog sources going quiet.

Hardening the Collection Architecture

The monitoring system deserves the same security rigour as the assets it monitors, arguably more, because it aggregates sensitive data from across the estate and a compromise would be severe. Several hardening measures together make the collection architecture defensible.

• Isolated management zone: place the manager, indexer and dashboard in a dedicated, protected network segment, never in a user LAN or the DMZ.
• Restrictive firewall rules: permit only the specific collection ports from monitored zones to the manager, and lock down management access to the dashboard behind VPN or a bastion.
• TLS everywhere: encrypt agent communications and, where possible, syslog. Use an internal CA and rotate certificates per policy.
• Authenticated enrollment: control which hosts can register as agents using keys or passwords, so attackers cannot inject rogue agents or telemetry.
• No inbound to agents: rely on the agent-initiated outbound model so monitored zones do not accept inbound monitoring connections.
• Protect the data at rest: restrict access to the indexer, enable role-based access on the dashboard, and monitor the SIEM itself for tampering.

Manager and Indexer Placement

Where you put the Wazuh components is a security decision, not just an operational one. The manager, indexer and dashboard belong in a dedicated management or security zone, segmented from both user networks and internet-facing DMZs. Access to the dashboard for analysts should traverse a VPN or bastion rather than being exposed directly, and administrative access should be tightly controlled and logged.

Capacity and resilience also influence placement. A single manager comfortably handles the agent counts typical of small and mid-size businesses, but where availability matters you can run a manager cluster, and the indexer can scale across nodes for storage and query load. Distribute these within the protected zone with appropriate network paths, keeping the principle of one-way collection flows intact as you scale.

Cloud and hybrid environments follow the same logic expressed in cloud constructs: the management components sit in a private subnet, security groups permit only the necessary collection flows from monitored subnets, and dashboard access is gated. Codesecure designs the collection and placement architecture during scoping, accounting for the client's existing segmentation, compliance scope and growth horizon, so the SIEM strengthens segmentation rather than quietly eroding it.