Wazuh system call monitoring with Linux Audit

The data path starts on each monitored host, where audit rules decide which events the Linux audit subsystem records. A rule can match a system call such as execve, a write or attribute change on a sensitive file path, or a privileged action tied to a user ID. Every matching event is written to the Linux audit log. The Wazuh server can only classify what reaches it, so the first decision is which rules belong on which host classes, written down before any agent starts forwarding. Confirm on a test host that the rules load and that the audit log receives the expected records.

The Wazuh agent is the link between that log and the server. The agent reads the audit log through its log collection settings and forwards the records to the Wazuh server over the agent channel. The exact collection configuration, including the log path and any required format settings, depends on the agent version in use, so confirm it in the documentation for that version rather than copying settings from an older deployment. The same applies to the rules bundled with Wazuh for audit records: confirm which rule files ship with your version, which rule IDs and groups they use, and whether they match your host operating system and audit configuration.

On the Wazuh server, decoders parse each raw audit record into named fields such as the executable, the working directory, the user and the audit key. Rules then evaluate those fields and assign severity and grouping, and only matching events become alerts. The Wazuh indexer stores those alerts as a full-text and analytics store, and the Wazuh dashboard queries the indexer to show them. The data path has several places where volume can be shaped, so know which layer you are tuning when an alert count changes. Test a sample event through each layer and record what the dashboard shows at the end.

The Wazuh server can run as a cluster for horizontal scaling, and it manages agent configuration remotely. This matters for audit work because a change to a collection setting or a rule file is a fleet-wide change, and a poorly scoped audit rule can flood the server with events from many hosts at once. Plan rule changes through agent groups, roll them to a small staging group first, and watch event volume and alert volume before widening the scope. Ask your implementation partner or your own team to document how the remote configuration process behaves in your cluster layout, including what happens to agents that are offline during a change.

Audit rule volume grows for a few predictable reasons, and the first control is to find them before they reach the Wazuh server. Broad rules that match every process execution on busy build or application hosts generate most of the noise. Watches on high-traffic directories, such as temporary paths, spool directories or large log directories, add events that rarely matter for security. Rules that repeat what journald, syslog or an application already records also multiply the same activity across two pipelines. Each audit event travels from the Linux audit subsystem through the Wazuh agent to the Wazuh server, where decoders and rules run, and then into the Wazuh indexer. Volume becomes a problem at every one of those stages, so the review should cover all of them.

Scope is the first decision. Assign audit rules by host group and role, so a database server, a CI runner and a bastion host each receive only the rules their risk profile justifies. Within a rule set, prefer specific path and action filters over broad ones. For example, watching write and attribute changes on named files such as the sudoers configuration is far more contained than watching an entire directory tree. Keep a short register for each rule that records the owner, the reason it exists, the host groups it applies to and the Wazuh rule IDs it feeds. A rule without a stated reason is the first candidate for removal during a pilot review.

Separate the rules used for alerting from the rules used to retain evidence. Alerting rules should be narrow enough that each match is worth a person's attention, and they should map to Wazuh rule levels that match your escalation process. Evidence rules can be broader, but they should be kept on a deliberate retention plan so that investigators can reconstruct activity without every broad event triggering an alert. Where known benign activity creates repeat alerts, such as a scheduled backup job or a configuration management run, use the suppression or rule-level tuning methods described in the Wazuh documentation for your release. Confirm the exact syntax for your version, and store each change in version control with an owner and a review date.

Review volume after every change to a rule, host group or Wazuh rule file. Measure audit events per agent over a representative period, alert counts by Wazuh rule ID, and growth in indexer storage before and after the change. Thresholds for alert levels, event rates and storage capacity should come from measured pilot data gathered on hosts that represent your production roles, not from assumptions about what a typical server produces. Ask the team that operates the platform to confirm the sizing method in writing before the rule set goes into production, and repeat the measurement whenever a new application or host role is added.

An audit rule set only protects you if each risk area produces an alert that reaches the Wazuh dashboard, so verify the full chain on a pilot host before production relies on it. Use a host that matches production in its auditd configuration, Wazuh agent version and log paths. For each risk area in scope, command execution, privilege escalation and sensitive file access, run one controlled action that a specific rule should catch. For example, an illustrative test could run a harmless binary from a watched directory, invoke sudo from a dedicated test account, or read a file on your watch list. Write down the action, the test account, the expected rule and the time you performed it. Label the host and the account clearly so the resulting events are easy to find during review.

Each test event should be checked at four points. First, confirm the raw audit record exists on the endpoint and carries the audit key and fields you expected. Second, confirm the Wazuh agent read and forwarded that record, using the agent's own logs and, if you archive events, the archive on the server. Third, confirm the server decoded the record into fields and matched a rule, using the server's log test tool if your release provides one (confirm this in the documentation for your version). Fourth, confirm the alert appears in the Wazuh indexer and dashboard with the correct agent name, rule description and severity. Record the first checkpoint that fails. In practice, breaks tend to appear at decoding or where audit field names do not match what the rule expects, so note the exact field that differed.

Measure the time from the controlled action to the alert timestamp, and record the gap at each checkpoint so you can see where latency accumulates. Agree on an acceptable delay with the security operations team before testing starts, and record it in the test plan, so the result is judged against a pre-agreed expectation. Then run the negative test. Generate the routine activity this host normally produces, such as scheduled package updates, backup jobs, routine service restarts and ordinary administrator logins, and confirm that the alerts raised stay within the volume and severity your threshold allows. If benign activity triggers the rules at a level that would flood analysts, the rule scope needs adjusting before go-live, because the alert path would be working but unusable.

Keep these tests as a repeatable check rather than a one-time exercise. Store the test definitions, expected outcomes, audit rule file checksum, and the agent and server versions in version control, so each run is reproducible. Re-run the full routine after every Wazuh agent upgrade, every server or indexer upgrade, and every change to the audit rules. Before scheduling upgrades, read the release notes for each patch to see which components changed, and decide which tests cover those changes. A passing run on the previous version proves little about the new one. Keep the pilot host one step ahead of production in the upgrade order, and retain each run's results as change records for later review.