learn-cyber · lesson 2 · fundamentals

Wazuh's four parts

A precise mental model of the machine you'll be selling — name each component, say what it does, and trace one hotel's data all the way through.

From pipeline to product

In Lesson 1 you learned the pipeline: Collect → Decode → Match rules → Alert → Triage. That was the idea. Wazuh is the thing that does it, and it's split into four components — each one owning a stretch of that pipeline.¹

The four parts, mapped to the pipeline

Here's the shape. Each box is one component; the label under it is the pipeline step it owns.

1. The agent — eyes on each device

The agent is lightweight software you install on each monitored endpoint: servers, laptops, VMs, POS terminals. At a hotel that's the front-desk PCs, the PMS server, the back-office machines. The agent reads that device's logs, watches its files for tampering (File Integrity Monitoring), checks its configuration and known vulnerabilities, and forwards everything to the server.¹ It is the Collect step made real — one agent per device.

Lightweight is the selling point. The agent sips CPU and memory, so it can sit on a busy POS terminal at the hotel bar without slowing the line at checkout.

2. The server (manager) — the brain

The server, also called the manager, receives data from every agent across all your hotels. It runs the decoders and rules that pull fields from each line and decide what's worth an alert, it enrolls and manages the agents, and it exposes the Wazuh API that everything else talks to.¹ This single component owns three pipeline steps: Decode, Match rules, and Alert.

3. The indexer — fast, searchable memory

The indexer is a search-and-storage engine (built on OpenSearch). The server hands it every alert and event, and it stores them in a way that's fast to search and aggregate.¹ This is the component that answers historical questions: "every failed login at the Marriott last week," or "which POS terminal saw new malware on Tuesday." Without it, you'd have alerts but no memory.

4. The dashboard — where you work

The dashboard is the web UI (built on OpenSearch Dashboards). It's where the analyst visualizes alerts, investigates an incident, and manages the whole deployment.¹ This is the Triage step — the screen you'll be staring at when an alert fires at 2 a.m. for a hotel three time zones away.

How data actually flows

The components don't just sit there — they hand data along in a fixed order. Trace one event from a hotel firewall-protected network all the way to your screen:

1. Enroll first. When you install an agent on the hotel's PMS server, it registers with the manager once — the manager's registration service hands it a key so it can be trusted from then on.
2. Stream events. After enrollment, the agent ships log events to the server over an encrypted channel, continuously.
3. Analyze. The server decodes each line, runs rules, and generates alerts.
4. Store. The server writes alerts and events into the indexer.
5. View. You open the dashboard, which queries the indexer and paints the alerts on screen for triage.

Keep the ports light, but know them — they come up the moment something won't connect: 1514 carries agent → manager events, 1515 is the enrollment service that hands out the key, and 443 is HTTPS to the dashboard in your browser.

When a device can't run an agent

Here's the catch that bites every MSSP: not every hotel device can take an agent. The hotel's firewall, its managed network switches, and some sealed POS appliances are closed boxes — you can't install software on them. But they produce exactly the logs you most want.

Wazuh handles these with agentless monitoring: the device sends its logs to the server over syslog, or the server polls the device over SSH or an API.¹ So a hotel's firewall can forward its blocked-connection logs by syslog and you'll see them in the same dashboard as everything else — no agent required.

One host now, a cluster later

You don't need four servers to start. For a small deployment, all four components run on a single host — the all-in-one install you'll do in Lesson 3.² That's plenty for your first hotel or three.

As your MSSP grows and you add clients, the load grows too. At scale, the indexer and the server can each be clustered across multiple nodes — many machines acting as one — so the system keeps up with millions of events from dozens of hotels.² The mental model stays identical; you're just running more copies of the same four parts.

Start single-node, cluster later. Keeping many hotels' data cleanly separated on one deployment is its own skill — agent groups, RBAC, dashboard tenants — and it gets its own lesson further on.

What the agent and server give you

You don't need to master these yet — just learn the names, so you recognize them when they show up in the dashboard later. The agent + server together provide:³

• Log data analysis — the core decode-and-rule pipeline from Lesson 1.
• File Integrity Monitoring (FIM) — alerts when a watched file changes, e.g. a POS binary being swapped for skimmer malware.
• Security Configuration Assessment (SCA) — checks a device against hardening benchmarks and flags weak settings.
• Vulnerability detection — matches installed software against known-vulnerability databases.
• MITRE ATT&CK mapping — tags alerts with attacker techniques so you speak the common defender language.
• Active Response — Wazuh can act, not just watch: block an IP, kill a process. This is the "response" in XDR.

Check yourself

Retrieval practice — answering from memory is what makes this stick. Don't peek back up; take the guess.