learn-cyber · lesson 11 · hands-on

Switch on Wazuh's capabilities

You already have a server and an agent. Now turn a bare install into a real hotel-monitoring sensor — from the terminal.

Where you are Your Wazuh is running but mostly idle — it's collecting some logs and little else. This lesson switches on the four capabilities that make it earn its keep at a hotel: File Integrity Monitoring, Security Configuration Assessment, Vulnerability Detection, and Active Response. Keep the config cheat-sheet open beside this — it has every block to copy.

The one idea that prevents 90% of frustration

Every capability is configured by editing XML in /var/ossec/etc/ossec.conf and restarting a service. But there are two such files — one on the agent, one on the manager — and editing the wrong one does nothing.

Agent-side vs Manager-side On the AGENT (it watches the endpoint): File Integrity Monitoring, SCA, log collection.
On the MANAGER (it analyses centrally): Vulnerability Detection, Active Response, remote syslog.
Wrong file = silent no-op. This is the most common beginner mistake.1

The safe edit loop — use it every single time

There is no config-test command in Wazuh. A typo means the service fails to start. So you always back up first.2

# 0. Know your version — it changes how Vulnerability Detection is configured
sudo /var/ossec/bin/wazuh-control info

# 1. Back up before touching anything
sudo cp /var/ossec/etc/ossec.conf /var/ossec/etc/ossec.conf.bak

# 2. Edit the file (the RIGHT one — agent or manager) ...

# 3. Restart the matching service
sudo systemctl restart wazuh-agent       # if you edited the agent
sudo systemctl restart wazuh-manager     # if you edited the manager

# 4. Confirm it came back up, and check for config errors
sudo systemctl status wazuh-manager
sudo tail -n 40 /var/ossec/logs/ossec.log   # hunt for ERROR / CRITICAL

If a service won't start after an edit, restore the backup (sudo cp …ossec.conf.bak …ossec.conf), restart, and re-read your change against the cheat-sheet. Calm and reversible beats clever.

Step 1 — File Integrity Monitoring (on the agent)

FIM alerts you when watched files change — exactly how you catch POS malware swapping a binary, or someone tampering with the PMS config. Edit the agent's ossec.conf and extend the <syscheck> block:3

<syscheck>
  <disabled>no</disabled>
  <directories whodata="yes" report_changes="yes" check_all="yes">/opt/pms/conf</directories>
  <directories whodata="yes" check_all="yes">/opt/pos/bin</directories>
</syscheck>

whodata="yes" records who made the change (via the Linux audit subsystem); report_changes="yes" captures the actual diff. Restart wazuh-agent, then edit a watched file (sudo touch /opt/pms/conf/test) and watch the alert appear in the dashboard's Integrity Monitoring module. That's the Lesson 1 pipeline firing on demand.

Step 2 — Security Configuration Assessment (on the agent)

SCA runs CIS-benchmark hardening checks and scores the host — "SSH root login enabled," "password policy weak," and hundreds more. For a hotel this is gold: it's concrete, per-machine compliance evidence. Add to the agent config:4

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

Wazuh auto-selects the right CIS policy for the detected OS — you don't list policies unless you want to override. Restart wazuh-agent; results land in the SCA module as pass/fail per check, with a score.

Step 3 — Vulnerability Detection (on the manager)

This flags unpatched, vulnerable software on your endpoints — critically, on the PMS host. Here version matters (that's why we checked it in Step 0). In 4.8+ it's a small block on the manager, and results live in the indexer:5

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

On 4.7 or older, this is instead a <vulnerability-detector> block with per-OS <provider> feeds — see the cheat-sheet for that form. If wazuh-control info showed 4.8 or higher, use the block above. Restart wazuh-manager; results appear in the Vulnerability Detection dashboard module — not in alerts.json, because it's indexer-state data.

Step 4 — Active Response (on the manager)

This is the "R" in XDR: Wazuh doesn't just alert, it acts — e.g. auto-blocks an IP brute-forcing SSH on the PMS. The built-in <command> blocks usually already exist in your manager config; you add the trigger:6

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710,5712</rules_id>   <!-- SSH auth-failure rules -->
  <timeout>600</timeout>            <!-- auto-unblock after 10 min -->
</active-response>
⚠ Safety first — automation can lock you out Active Response acts with no human in the loop. Bind it to specific rule IDs (not a broad level), always set a <timeout> so blocks self-revert, test on one agent first, and whitelist your own admin IPs so it can never block you. Execution is logged at /var/ossec/logs/active-responses.log.

Doing this for many hotels (the MSSP move)

Editing each agent by hand doesn't scale. The agent-side blocks (FIM, SCA, log collection) can be dropped into a hotel's group file at /var/ossec/etc/shared/<group>/agent.conf on the manager — and they push to every agent in that group automatically, no agent restart needed.7 Define "what we monitor at the Seaside Inn" once; it lands on all their machines. (That's Lesson 6 doing real work.)

Check yourself

From memory — no peeking.

Question 1 of 3

You enabled Vulnerability Detection but edited the agent's config. What happens?

Vulnerability Detection is a manager-side module. Editing the agent's ossec.conf for it is a silent no-op — the classic "wrong file" mistake. FIM and SCA are agent-side; vuln detection and active response are not.

Question 2 of 3

In an Active Response rule, what does the <timeout> value actually do?

Timeout makes the response stateful: a blocked IP is automatically un-blocked after the timeout. It's your safety net against permanently locking out an IP — including your own.

Question 3 of 3

Why back up ossec.conf before every edit?

Wazuh has no pre-flight config-test command. A malformed config makes the service fail to start — the backup is your one-command path back to a working state.

Primary source to read next
Wazuh — Active Response: how to configure. It's the capability with the most ways to surprise you, so read it before going live. For the others, the cheat-sheet links each capability's reference page.
I'm your teacher — ask me anything. Tell me your exact OS and which PMS /POS paths you want watched and I'll write the precise <syscheck> block. Want me to design an Active Response that's safe for your network, or help read an ossec.log error? Just paste it in.

You just earned: the agent-vs-manager model, the safe edit loop, and the exact blocks to switch on FIM, SCA, Vulnerability Detection, and Active Response on the deployment you already run.

Good next move: enable FIM + SCA on your one agent today, confirm alerts/scores appear, then add Vulnerability Detection on the manager. Save Active Response for last and test it carefully.

Sources

  1. Wazuh — Centralized configuration (agent vs manager config, agent.conf push).
  2. Wazuh — wazuh-control (service control; no configtest).
  3. Wazuh — syscheck (FIM) reference.
  4. Wazuh — SCA: how to configure.
  5. Wazuh — Vulnerability Detection: configuring scans (4.8+).
  6. Wazuh — Active Response: how to configure.
  7. Wazuh — Centralized configuration (group agent.conf auto-push).

Reference: Config cheat-sheet · Glossary · Course home · ← Onboarding runbook