The commands you'll actually type

Wazuh has hundreds of rules and decoders. In practice, a blue operator lives inside about a dozen management commands. Here they are, in the order you use them.

1 · Agent management — who's talking

The agent_control binary is your heartbeat monitor. It lists registered agents, shows their IP, last connection time, and allows you to restart or remove them.

bash

sudo /var/ossec/bin/agent_control -cl Wazuh agent_control. List of agents: ID Name IP Address Status 001 linux-server 192.168.1.110 active 002 win-server 192.168.1.115 active # 000 is the manager itself. IDs 001+ are your endpoints.

2 · Service control — restart the stack

sudo /var/ossec/bin/wazuh-control start — starts manager, indexer, and dashboard.
sudo /var/ossec/bin/wazuh-control stop — shuts them down cleanly.
sudo /var/ossec/bin/wazuh-control restart — applies config changes.

3 · Checking alerts — where the noise lives

Wazuh writes alerts in JSON format to /var/ossec/logs/alerts/alerts.json. This is your primary query source before you even open the dashboard.

bash

sudo grep "ssh_failed" /var/ossec/logs/alerts/alerts.json {"id":1682910245.123456,"rule":{"level":3,"pci_dss":["10.2.4"],"..."}} {"decoder":{"name":"sshd"},"srcip":"10.10.14.55","user":"admin"} # JSON format -> pipe to jq for filtering by IP or user

4 · Testing rules — does my log fire?

wazuh-logtest is the debugger. You paste a raw log line, and it tells you exactly which rule, decoder, and level it triggers. Essential for tuning noise.

bash

sudo /var/ossec/bin/wazuh-logtest Enter a log event: Failed password for root from 10.10.14.55 port 22 ssh2 Resulting output: Rule: 5710 fired -> 'sshd: authentication failed.' # 5710 = sshd auth failure; repeated failures roll up into 5712 (brute-force)

5 · Managing agents — push certs and keys

When deploying new agents, the manager must sign their certificates. agent_auth handles the secure handshake.

sudo /var/ossec/bin/agent_auth -a # Prompts for agent ID and manager IP. Generates keys.

6 · File Integrity Monitoring (FIM)

FIM watches specific directories for changes. It's configured in /var/ossec/etc/ossec.conf. You don't run a flag for FIM; you configure the paths and let the manager watch them.

directories to_monitor="/etc,/var,/usr" — standard Linux config monitoring.
realtime="yes" — alerts instantly on file creation/modification (requires inotify).
whodata="yes" — uses auditd to track exactly which user/process changed the file.

7 · The Wazuh API — automation

Everything in the dashboard is an API call. curl is your best friend for scripting checks or integrating with SOAR platforms.

bash

curl -k -u wazuh:wazuh -X GET "https://127.0.0.1:55000/agents?pretty" {"error":0,"data":{"totalItems":3,"data":[{"id":"001",...}]}} # Returns JSON. Use -X POST to add agents, -X DELETE to remove.

8 · Indexer health — is the memory full?

If the dashboard is slow or missing data, check OpenSearch directly. curl -k -u admin:admin https://127.0.0.1:9200/_cluster/health?pretty tells you if the cluster is green, yellow, or red.

9 · Log archives — the raw truth

When alerts are suppressed or you need the original unprocessed log, check /var/ossec/logs/archives/. These are gzipped JSON files containing every event the manager received, even if it didn't fire a rule.

10 · Configuration validation

Before restarting, always test your ossec.conf changes. sudo /var/ossec/bin/wazuh-analysisd -t parses the XML and reports syntax errors without taking the stack offline.

OPERATOR PLAYBOOKS