Wazuh 5.0 renamed most of the server-side paths and added a new agent port. The agent side barely moved. These tables put both versions next to each other so you can tell at a glance whether a path you remember still applies. The 5.0 manager and Linux agent entries were read off a 5.0.0-beta5 lab stack, and the Windows agent rows off a Windows 11 endpoint enrolled against it. The macOS rows are from the documentation and were not exercised. Commands that use them are in the commands cheat sheet.

Ports

A stock beta5 manager listens on five ports before you configure anything:

1514 1515 1516 1517 55000
Component Port Protocol Purpose in 4.x Purpose in 5.0
Manager 1517/TCP HTTPS, TLS Not used Wazuh 5.x agent enrolment and connection. Binds 0.0.0.0, path prefix /wazuh-manager/
Manager 1514/TCP Wazuh message protocol, AES Agent connection service (default) Wazuh 4.x agent connection. <legacy><enabled>yes</enabled> in the shipped config
Manager 1514/UDP Wazuh message protocol, AES Agent connection service (optional, off by default) Wazuh 4.x agent connection. The shipped config sets <protocol>tcp</protocol>
Manager 1515/TCP TLS Agent enrolment service Wazuh 4.x agent enrolment, present in the default <auth> block
Manager 1516/TCP Wazuh cluster protocol Cluster daemon Manager cluster communication. Every 5.0 install is a cluster, so this listens on a single node too
Manager 514/TCP and 514/UDP Syslog Syslog collector, off by default Removed. No manager syslog listener in 5.0
Manager 55000/TCP HTTPS, TLS RESTful API Manager API, unchanged port
Indexer 9200/TCP HTTPS, TLS Indexer REST API Indexer REST API, now also the manager’s output target
Indexer 9300-9400/TCP TLS Indexer cluster communication Indexer cluster communication
Dashboard 443/TCP HTTPS Web interface Web interface

The syslog collector is the other one to plan for. Wazuh 5.0 has no manager syslog listener, so network devices that used to send straight to 1514/UDP now need an agent acting as a relay: receive with rsyslog, write to a file, read that file with a localfile block. That pattern is in log collection.

Install paths, central components

What Wazuh 4.x Wazuh 5.0
Manager install directory /var/ossec/ /var/wazuh-manager/
Manager binaries /var/ossec/bin/ /var/wazuh-manager/bin/
Manager configuration directory /var/ossec/etc/ /var/wazuh-manager/etc/
Manager logs directory /var/ossec/logs/ /var/wazuh-manager/logs/
Shared group configuration /var/ossec/etc/shared/<group>/ /var/wazuh-manager/etc/shared/<group>/
Manager certificates /var/ossec/etc/ (sslmanager.cert, sslmanager.key) /var/wazuh-manager/etc/certs/
Manager API configuration /var/ossec/api/configuration/ /var/wazuh-manager/api/configuration/
Indexer configuration /etc/wazuh-indexer/ /etc/wazuh-indexer/
Indexer certificates /etc/wazuh-indexer/certs/ /etc/wazuh-indexer/certs/
Dashboard configuration /etc/wazuh-dashboard/ /etc/wazuh-dashboard/
Dashboard certificates /etc/wazuh-dashboard/certs/ /etc/wazuh-dashboard/certs/
Filebeat /etc/filebeat/ Removed. The manager ships events through the built-in indexer connector

The indexer and dashboard keep their 4.x paths because they are still OpenSearch packages. Only the manager moved.

Configuration files

What Wazuh 4.x Wazuh 5.0
Manager main config /var/ossec/etc/ossec.conf, root element <ossec_config> /var/wazuh-manager/etc/wazuh-manager.conf, root element <wazuh_config>
Manager internal options /var/ossec/etc/internal_options.conf and local_internal_options.conf /var/wazuh-manager/etc/wazuh-manager-internal-options.conf
Manager API config /var/ossec/api/configuration/api.yaml /var/wazuh-manager/api/configuration/api.yaml, with several 4.x options removed
Output configuration Not applicable /var/wazuh-manager/etc/outputs/default/indexer.yml
Shared agent config /var/ossec/etc/shared/<group>/agent.conf /var/wazuh-manager/etc/shared/<group>/agent.conf
Custom rules /var/ossec/etc/rules/local_rules.xml Removed. Sigma YAML rules live in the indexer Content Manager
Custom decoders /var/ossec/etc/decoders/ Removed. YAML decoders live in the indexer Content Manager
CDB lists /var/ossec/etc/lists/ Removed. Replaced by KVDBs in the indexer
Integration scripts /var/ossec/integrations/ Removed. Use indexer Alerting and Notifications
Filebeat config /etc/filebeat/filebeat.yml Removed
Filebeat template /etc/filebeat/wazuh-template.json Removed. The Setup module creates index templates
Indexer config /etc/wazuh-indexer/opensearch.yml /etc/wazuh-indexer/opensearch.yml
Indexer JVM options /etc/wazuh-indexer/jvm.options /etc/wazuh-indexer/jvm.options
Indexer security config /etc/wazuh-indexer/opensearch-security/ /etc/wazuh-indexer/opensearch-security/
Dashboard config /etc/wazuh-dashboard/opensearch_dashboards.yml /etc/wazuh-dashboard/opensearch_dashboards.yml
Dashboard app config /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml
Agent config, Linux /var/ossec/etc/ossec.conf /var/ossec/etc/ossec.conf
Agent config, macOS /Library/Ossec/etc/ossec.conf /Library/Ossec/etc/ossec.conf
Agent config, Windows C:\Program Files (x86)\ossec-agent\ossec.conf C:\Program Files (x86)\ossec-agent\ossec.conf

Log files

What Wazuh 4.x Wazuh 5.0
Manager log /var/ossec/logs/ossec.log /var/wazuh-manager/logs/wazuh-manager.log
Alerts, plain text /var/ossec/logs/alerts/alerts.log Removed. Findings live in wazuh-findings-v5-* on the indexer
Alerts, JSON /var/ossec/logs/alerts/alerts.json Removed. The manager no longer stores alerts
Agent log, Linux /var/ossec/logs/ossec.log /var/ossec/logs/ossec.log
Agent log, macOS /Library/Ossec/logs/ossec.log /Library/Ossec/logs/ossec.log
Agent log, Windows C:\Program Files (x86)\ossec-agent\ossec.log C:\Program Files (x86)\ossec-agent\ossec.log
Active response results, Linux /var/ossec/logs/active-responses.log /var/ossec/logs/active-responses.log
Active response results, macOS /Library/Ossec/logs/active-responses.log /Library/Ossec/logs/active-responses.log
Indexer log /var/log/wazuh-indexer/wazuh-cluster.log (named after the cluster) /var/log/wazuh-indexer/wazuh-indexer.log
Filebeat log /var/log/filebeat/filebeat Removed
Dashboard log journalctl -u wazuh-dashboard journalctl -u wazuh-dashboard

Losing alerts.json is the change that breaks the most homegrown tooling. Anything that tailed that file has to become a query against the indexer, or an OpenSearch Alerting monitor with a webhook. Notifications covers the replacement path.

Statistics files

File Wazuh 5.0 What it holds
wazuh-agentd.state /var/ossec/var/run/wazuh-agentd.state Agent connection status and message counters
wazuh-logcollector.state /var/ossec/var/run/wazuh-logcollector.state Per-file log collection counters
wazuh-remoted.state Removed. GET /cluster/{node_id}/daemons/stats?daemons_list=wazuh-manager-remoted Manager side agent communication counters
wazuh-analysisd.state Removed. GET /cluster/{node_id}/daemons/stats?daemons_list=wazuh-manager-analysisd Event processing and queue counters

The two manager state files are gone in 5.0; daemon statistics are served through the manager API instead. The two agent state files survive at the same paths.

Service users

Component Wazuh 4.x Wazuh 5.0
Manager wazuh wazuh-manager
Agent wazuh wazuh
Indexer wazuh-indexer wazuh-indexer
Dashboard wazuh-dashboard wazuh-dashboard

The agent keeping the wazuh user while the manager moves to wazuh-manager is easy to trip over in configuration management. File ownership examples in the 5.0 documentation show chown root:wazuh-manager on manager files and chown root:wazuh on agent files, on the same page.

Service names

Unchanged in both versions: wazuh-manager, wazuh-indexer, wazuh-dashboard, wazuh-agent. The Windows agent service is WazuhSvc, display name Wazuh, start type Automatic and left stopped by the installer. Start it with NET START WazuhSvc or Start-Service WazuhSvc. Verified on beta5: that is the only service the MSI registers, so beta pages using Restart-Service -Name wazuh are wrong. The macOS agent is a launch daemon at /Library/LaunchDaemons/com.wazuh.agent.plist.

Manager daemons

Daemon Wazuh 4.x name Wazuh 5.0 name What it does
Analysis wazuh-analysisd wazuh-manager-analysisd Runs the normalization engine: decoding, enrichment, output
API Part of the API service wazuh-manager-apid Serves the manager REST API on 55000
Enrolment wazuh-authd wazuh-manager-authd Validates enrolment requests and issues agent keys
Cluster wazuh-clusterd wazuh-manager-clusterd Cluster membership and synchronisation
Database wazuh-db wazuh-manager-db Manages the Wazuh database
Modules wazuh-modulesd wazuh-manager-modulesd Runs the manager modules, now including the Task Manager
Remote wazuh-remoted wazuh-manager-remoted Agent communication, including the 1517 HTTPS listener
Monitoring wazuh-monitord wazuh-manager-monitord Still present and running on beta5. The migration guide says its work (agent disconnection detection, deletion of long-disconnected agents, log rotation) moves into the Task Manager inside wazuh-manager-modulesd, but the daemon has not gone yet
Integrations wazuh-integratord Removed. Use indexer Alerting and Notifications
Email wazuh-maild Removed. Use a Notifications email channel
Syslog output wazuh-csyslogd Removed
Agentless wazuh-agentlessd Removed
Database output wazuh-dbd Removed
Reports wazuh-reportd Removed. Use the indexer Reporting module
Log collection on the manager wazuh-logcollector Agent-side only in 5.0
FIM on the manager wazuh-syscheckd Agent-side only in 5.0
Active response execution wazuh-execd Agent-side only in 5.0

A healthy 5.0.0-beta5 manager shows eight daemons in wazuh-manager-control status: clusterd, modulesd, monitord, remoted, analysisd, db, authd and apid, each with the wazuh-manager- prefix. A 4.x manager shows considerably more, which is a useful quick check that you are looking at the version you think you are. Count on your own build rather than on a table, because monitord is documented as going and had not gone at beta5.

Agent daemons

Same names in both versions.

Daemon What it does
wazuh-agentd Talks to the manager
wazuh-logcollector Reads files, journald, event channels and command output
wazuh-syscheckd File integrity monitoring
wazuh-modulesd Runs agent modules, including Syscollector and SCA
wazuh-execd Executes active response scripts

Agent paths by operating system

What Linux macOS Windows
Install directory /var/ossec/ /Library/Ossec/ C:\Program Files (x86)\ossec-agent
Configuration /var/ossec/etc/ossec.conf /Library/Ossec/etc/ossec.conf C:\Program Files (x86)\ossec-agent\ossec.conf
Control binary /var/ossec/bin/wazuh-control /Library/Ossec/bin/wazuh-control Service WazuhSvc, plus the agent GUI
Log /var/ossec/logs/ossec.log /Library/Ossec/logs/ossec.log C:\Program Files (x86)\ossec-agent\ossec.log
Client key /var/ossec/etc/client.keys /Library/Ossec/etc/client.keys C:\Program Files (x86)\ossec-agent\client.keys
Enrolment password /var/ossec/etc/authd.pass /Library/Ossec/etc/authd.pass C:\Program Files (x86)\ossec-agent\authd.pass
Active response scripts /var/ossec/active-response/bin/ /Library/Ossec/active-response/bin/ C:\Program Files (x86)\ossec-agent\active-response\bin\
Active response results /var/ossec/logs/active-responses.log /Library/Ossec/logs/active-responses.log C:\Program Files (x86)\ossec-agent\active-response\active-responses.log
Merged group config /var/ossec/etc/shared/merged.mg /Library/Ossec/etc/shared/merged.mg C:\Program Files (x86)\ossec-agent\shared\merged.mg
Local internal options /var/ossec/etc/local_internal_options.conf /Library/Ossec/etc/local_internal_options.conf C:\Program Files (x86)\ossec-agent\local_internal_options.conf
Agent state file /var/ossec/var/run/wazuh-agentd.state /Library/Ossec/var/run/wazuh-agentd.state C:\Program Files (x86)\ossec-agent\wazuh-agent.state
Log collector state /var/ossec/var/run/wazuh-logcollector.state /Library/Ossec/var/run/wazuh-logcollector.state C:\Program Files (x86)\ossec-agent\wazuh-logcollector.state (JSON)
Version file /var/ossec/etc/VERSION.json /Library/Ossec/etc/VERSION.json C:\Program Files (x86)\ossec-agent\VERSION.json
Cloud module credentials /var/ossec/wodles/credentials/ Not applicable Not applicable

Two Windows rows differ from Linux in more than the prefix, both read off a beta5 Windows 11 endpoint. The state file is named wazuh-agent.state, not wazuh-agentd.state, and it sits in the agent folder rather than under var/run. And wazuh-logcollector.state on Windows is JSON with a counter per event channel, where the Linux file is a flat listing. The Windows agent folder is also flat: ossec.conf, client.keys, authd.pass, ossec.log and VERSION.json all sit directly in it, with no etc, logs or var subdirectories.

Installation detail per platform is in installing the agent on Linux and installing the agent on Windows.

Key files

File Wazuh 5.0 path What it is
client.keys /var/wazuh-manager/etc/client.keys on the manager, /var/ossec/etc/client.keys on the agent The agent keystore: id, name, registered address and key
authd.pass /var/wazuh-manager/etc/authd.pass Shared enrolment password, 32 hexadecimal characters as generated on beta5. <auth><use_password>yes</use_password> ships enabled. If the file is missing at first start, the manager generates a random password, writes it, and logs A new enrollment password was generated and written to 'etc/authd.pass'
agent.conf /var/wazuh-manager/etc/shared/<group>/agent.conf Centralised configuration pushed to every agent in the group
merged.mg /var/ossec/etc/shared/merged.mg on the agent The merged shared configuration the agent received
remoted.pem / remoted-key.pem /var/wazuh-manager/etc/certs/ TLS certificate and key for the agent listener
apid.pem / apid-key.pem /var/wazuh-manager/etc/certs/ TLS certificate and key for the manager API
indexer-connector.pem / -key.pem /var/wazuh-manager/etc/certs/ Client certificate the manager presents to the indexer
root-ca.pem /var/wazuh-manager/etc/certs/, /etc/wazuh-indexer/certs/, /etc/wazuh-dashboard/certs/ The CA that signs every component certificate
admin.pem / admin-key.pem /etc/wazuh-indexer/certs/ Indexer admin certificate, used by securityadmin.sh
indexer.pem / indexer-key.pem /etc/wazuh-indexer/certs/ Indexer transport and HTTP certificate
dashboard.pem / dashboard-key.pem /etc/wazuh-dashboard/certs/ Dashboard certificate
internal_users.yml /etc/wazuh-indexer/opensearch-security/ Indexer internal users, the primary identity store in 5.0
roles_mapping.yml /etc/wazuh-indexer/opensearch-security/ Maps indexer roles to users and backend roles

Certificate handling and what to rotate on a default install is covered in hardening Wazuh itself.

Where the data went

4.x stored alerts on disk and shipped them to wazuh-alerts-4.x-* with Filebeat. 5.0 indexes everything directly.

4.x 5.0
alerts.json shipped by Filebeat Manager indexer connector writes straight to the indexer
wazuh-alerts-4.x-* wazuh-findings-v5-<category>
wazuh-archives-4.x-* wazuh-events-raw-v5
No equivalent wazuh-events-v5-<category> for normalised events
Agent state in the manager database wazuh-states-fim-files, wazuh-states-fim-registry-keys, wazuh-states-fim-registry-values, wazuh-states-sca, wazuh-states-vulnerabilities and thirteen wazuh-states-inventory-* indices
Active response over the agent channel wazuh-active-responses, polled by the manager
No equivalent wazuh-metrics-agents, wazuh-metrics-comms-v4, wazuh-metrics-normalization
No equivalent wazuh-ai-assistant-sessions
CTI content on disk wazuh-threatintel-{decoders,enrichments,filters,integrations,kvdbs,policies,rules}-a

A stock beta5 install creates 22 data streams: raw events, eight event categories, eight finding categories, active responses, AI assistant sessions and three metrics streams. Note wazuh-metrics-comms-v4, which is the only metrics stream carrying a version suffix, and the -a suffix on every wazuh-threatintel-* index. Both are easy to leave off a hand-written index pattern.

Default retention created by the Setup module: raw events 10 minutes, categorised events 1 hour, findings 90 days, active responses 3 days, metrics 30 days, AI assistant sessions rolled at 1 day and deleted at 7. Rollover happens at 20 GB primary shard size or 200 million documents. The state indices have no retention policy of their own. Changing those is in upgrade, backup and retention, and the full list of indices is on the Wazuh indices page.

Next: Wazuh error messages index.

Frequently asked questions

What port does the Wazuh agent use?

A Wazuh 5.0 agent talks to the manager over HTTPS on port 1517/TCP, which carries enrolment, events, state synchronisation, control messages and downloads. A Wazuh 4.x agent uses 1514/TCP or 1514/UDP for events and 1515/TCP for enrolment. A 5.0 manager keeps 1514 and 1515 enabled by default so that 4.x agents continue to work.

Where is the Wazuh configuration file?

On a Wazuh 5.0 manager it is /var/wazuh-manager/etc/wazuh-manager.conf and the root element is wazuh_config. On a Wazuh agent it is still /var/ossec/etc/ossec.conf on Linux, /Library/Ossec/etc/ossec.conf on macOS and ossec.conf in the agent folder under Program Files on Windows, with ossec_config as the root element.

Where are the Wazuh log files?

The 5.0 manager logs to /var/wazuh-manager/logs/wazuh-manager.log, the agent to /var/ossec/logs/ossec.log, and the indexer to /var/log/wazuh-indexer/wazuh-indexer.log. The dashboard does not write its own log file by default; read it with journalctl -u wazuh-dashboard.