learn-cyber · reference

Wazuh config cheat-sheet

The verified config blocks for switching on Wazuh's capabilities from the terminal. Copy, adapt, restart the right service.

First: where does each feature live?

The #1 mistake is editing the wrong file. Agent-side features go in the agent's config; manager-side features go on the server.

Main config: /var/ossec/etc/ossec.conf (exists on both). Centralized per-group config (manager): /var/ossec/etc/shared/<group>/agent.conf — push agent-side blocks (FIM, SCA, localfile) to every agent in a hotel's group at once, no agent restart needed.

The safe edit loop

# 0. Know your version (4.8+ changes vuln detection)
sudo /var/ossec/bin/wazuh-control info

# 1. ALWAYS back up before editing — there is no "configtest";
#    a bad config makes the service fail to START.
sudo cp /var/ossec/etc/ossec.conf /var/ossec/etc/ossec.conf.bak

# 2. edit the file ... then restart the RIGHT service:
sudo systemctl restart wazuh-agent      # agent-side change
sudo systemctl restart wazuh-manager    # manager-side change

# 3. verify it came back up + no config errors
sudo systemctl status wazuh-manager
sudo tail -n 40 /var/ossec/logs/ossec.log     # look for ERROR/CRITICAL

1 · File Integrity Monitoring agent

Ref: syscheck reference. Hotel example: watch PMS config and POS binaries for tampering.

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>          <!-- full scan every 12h -->

  <!-- realtime + content diff + who changed it (uses Linux audit) -->
  <directories realtime="yes" report_changes="yes" check_all="yes">/etc</directories>
  <directories whodata="yes"  report_changes="yes" check_all="yes">/opt/pms/conf</directories>
  <directories whodata="yes"  check_all="yes">/opt/pos/bin</directories>

  <ignore type="sregex">.log$|.tmp$</ignore>
  <nodiff>/opt/pms/conf/secret.key</nodiff>  <!-- watch, never store contents -->
</syscheck>

Attributes: realtime="yes" = instant (inotify); whodata="yes" = also records the user/process (implies realtime, needs auditd); report_changes="yes" = capture the diff; check_all="yes" = size, perms, owner, mtime, inode, hashes. Results → Integrity Monitoring module.

2 · Security Configuration Assessment agent

Ref: SCA how-to. CIS-benchmark hardening checks — strong PCI evidence. Wazuh auto-picks the policy for the detected OS; you only need a <policies> block to override.

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <skip_nfs>yes</skip_nfs>
</sca>

CIS policy files ship on the agent at /var/ossec/ruleset/sca. Disable one with <policy enabled="no">…</policy> or by renaming the file .disabled. Results → SCA module (pass/fail per check).

3 · Vulnerability Detection manager

Ref: configuring scans. 4.8+ (current): a small manager-side block; results live in the indexer, not alerts.json.

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Requires the <indexer> block (usually already present from install). Results → Vulnerability Detection module in the dashboard.

Pre-4.8 only (do NOT use on 4.8+) — the old per-OS feed style:

<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <provider name="canonical"><enabled>yes</enabled><os>focal</os></provider>
  <provider name="nvd"><enabled>yes</enabled><update_from_year>2010</update_from_year></provider>
</vulnerability-detector>

4 · Active Response manager

Ref: active response how-to. The built-in <command> blocks already ship in your default ossec.conf — you mainly add the <active-response> trigger. Example: auto-block an SSH brute-forcer for 10 min.

<!-- command (usually already present) -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- trigger: block the source IP on the agent that fired rules 5710/5712 -->
<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710,5712</rules_id>
  <timeout>600</timeout>        <!-- auto-revert after 600s -->
</active-response>

<location>: local (agent that alerted), server, defined-agent, or all. Trigger by <level> (minimum) OR <rules_id>. <timeout> reverts the action (needs timeout_allowed=yes). Built-ins: firewall-drop (iptables), host-deny (/etc/hosts.deny), disable-account. Execution log: /var/ossec/logs/active-responses.log.

Bonus · Ingest a hotel firewall (remote syslog) manager

Ref: remote reference. Devices that can't run an agent send syslog to the manager. Add this alongside your existing secure block — don't replace it.

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.10.0/24</allowed-ips>   <!-- required: the firewall's net -->
</remote>

Test before you trust it

# paste a real log line; see which decoder + rule fire, at what level
sudo /var/ossec/bin/wazuh-logtest
sudo /var/ossec/bin/wazuh-logtest -v     # verbose, for debugging