Lesson 12 — The whole system, in production

Every Wazuh component named, each one wired to a concrete hotel-security job — and the checklist that turns your lab into something you can charge a hotel for.

Your mission You've installed Wazuh, written a rule, switched on capabilities. Now zoom out: see all the moving parts as one machine, understand what each part does for a hotel, and learn the gap between "it runs in my lab" and "it's safe to put a paying hotel's data through it." This is the lesson you re-read the night before you onboard for real.

The full inventory — more than four parts

Lesson 2 gave you the famous four: agent · server · indexer · dashboard. That's the right first map. But "the server" is really a bundle of internal daemons, and there are a couple of components that the four-part picture hides. To run this in production you need the complete list.¹

On the endpoint — the agent and its modules

The agent isn't one thing; it's a host of small collectors, each owning a hotel-security job:²

Inside the server — the daemons that do the work

The manager is where raw logs become alerts. The names matter because when something breaks, the log tells you which daemon:²

The component the four-part map hides: Filebeat

Filebeat — the courier between server and indexer The manager writes alerts to a file (alerts.json). A small shipper called Filebeat, running on the manager, reads that file and pushes each alert into the indexer.³ When alerts stop showing up in the dashboard but the manager is clearly firing them, Filebeat is the first suspect — it's the link most people forget exists.

Storage & screen

Every component → its hotel-security job

This is the table to internalize. If you can't say the hotel job a component does, you can't justify it on an invoice.

How it all connects — the production data flow

Component	Side	What it does for the hotel
Log collector	agent	Ships PMS/POS/auth logs — the evidence everything else is built from.
Syscheck / FIM	agent	Catches tampering with POS binaries & PMS config — card-skimmer defence.
SCA	agent	CIS hardening score per machine — concrete PCI-DSS evidence.
Rootcheck	agent	Finds rootkits / hidden malware on back-office boxes.
analysisd (decoders+rules)	manager	Turns the flood into the few alerts worth waking up for.
Vulnerability Detection	manager	Flags unpatched software on the PMS host before an attacker does.
Active Response (execd)	manager	Auto-blocks an IP brute-forcing the PMS — the "R" in XDR.
remoted / authd	manager	Securely enrols and receives every hotel device.
Agentless / syslog	manager	Covers the firewall & switches — the perimeter you can't put an agent on.
Filebeat	manager	Delivers alerts to storage so nothing is lost between brain and memory.
Indexer	storage	Searchable history — investigations, trends, the audit trail you show an assessor.
Dashboard + RBAC/tenants	screen	Where you triage — and the wall that keeps Hotel A from seeing Hotel B.

Active Response runs backwards along this path: the manager decides, then execd pushes the command back down to the agent's executor over the same 1514 channel. Detection flows up; response flows down.

Lab → production: the readiness checklist

Your lab install (Lesson 3) works, but it is not production-safe until you've closed these. Each one maps to a real way a hotel deployment gets you in trouble. This is the headline skill of this lesson.

① Identity & trust

Replace the self-signed certificates with proper TLS, so staff never train themselves to click through warnings.⁴
Change every default password (admin, internal indexer users) with the password tool — defaults are public knowledge.⁵
Lock down enrolment: set an authd registration password so a stranger on the network can't enrol a rogue agent.⁶

② Network exposure — open only what's needed

1514/1515 reachable only from hotel agent networks; 443 for the dashboard; 55000 (API) restricted to you/automation.
Never expose the indexer (9200) to the internet — it's your whole data lake. Firewall it to localhost / internal only.

③ Data lifecycle — or the disk fills and it dies

Set index retention (e.g. ~90 days) with an ISM policy so old indices roll off instead of filling the disk.⁷
Size the indexer JVM heap to ≈50% of RAM (and under ~32 GB) — the #1 cause of an indexer that won't start.⁸
Back up /var/ossec/etc (your configs + custom rules/decoders) and take indexer snapshots. Your detections are the product.

④ Operate it safely

NTP / time sync on every host — correlation and timeframes are meaningless if clocks drift.
Per-hotel isolation before client #2: an agent group per hotel and an RBAC role / tenant per client.
Active Response with a leash: specific rule IDs, a <timeout>, and your own admin IPs whitelisted.
Monitor the monitor: alert on low disk, a down manager, or Filebeat falling behind — if the SIEM is blind, so are you.

Check yourself

Question 1 of 3

Alerts are firing on the manager but none reach the dashboard. Which component is the first thing you check?

Filebeat reads the manager's alerts.json and pushes alerts into the indexer. If the manager is clearly firing alerts but the dashboard shows none, the courier between brain and memory — Filebeat — is the classic culprit.

Question 2 of 3

Which port should you make sure is never exposed to the public internet on a production deployment?

The indexer on 9200 is your entire data lake of alerts and history. Exposed, it's a direct path to every hotel's security data. Firewall it to internal/localhost; reach it through the dashboard, not directly.

Question 3 of 3

Your single-node deployment runs fine for weeks, then the indexer suddenly won't start. What's the most likely cause?

With no index retention policy, alert indices grow forever until the disk fills and the indexer can't start. An ISM policy that rolls off old indices (and right-sized JVM heap) is what keeps a long-running node alive.

I'm your teacher — ask me anything. Want me to turn any checklist item into the exact commands for your host — generate the TLS certs, rotate the passwords, write the ISM retention policy, or design the per-hotel RBAC roles? Or want a "production readiness" dry-run where I quiz you on what's still open before you onboard? Just ask.

You just earned: the complete component map — agent modules, manager daemons, the hidden Filebeat courier, indexer and dashboard — each tied to a hotel-security job, the full production data flow with ports, and a four-part readiness checklist for going live.

Good next move: run the checklist against your own box and fix the gaps one at a time. A natural follow-on lesson is reading & triaging a live alert in the dashboard — the anatomy of an alert (level, rule ID, srcip, MITRE) and what each severity means you should do.

Sources

Wazuh — Components (agent · server · indexer · dashboard; data flow).
Wazuh — Daemons reference (analysisd, remoted, authd, modulesd, execd, logcollector, syscheckd).
Wazuh — Filebeat & the indexer pipeline (manager writes alerts.json; Filebeat ships to indexer).
Wazuh — Custom certificates (replace self-signed TLS).
Wazuh — Password management (change default credentials).
Wazuh — Agent enrollment with a password.
Wazuh — Index lifecycle / retention (ISM).
Wazuh — Indexer tuning (JVM heap sizing).

Reference: Production architecture blueprint · Config cheat-sheet · Glossary · Course home · ← Lesson 11