What it does here
Wazuh is the SIEM — the security team's single pane of glass. It ingests events from across the stack, matches them against rules, and raises alerts. In this lab it is what turns a failed login into a detected incident.
How it is deployed
Three containers — indexer (stores events), manager (analyses them against rules) and dashboard (the UI). Deliberately, none of them publishes a port: Caddy fronts the dashboard, everything else stays internal. See Installation §4.8.
How events reach it
A small event forwarder — the second component written for this lab — polls Keycloak's event API and writes each authentication event as JSON to a shared log the Wazuh manager reads. The Golonex Portal writes its authorization decisions to the same place. Two custom rules then do the detection:
| Rule | Level | Fires when |
|---|---|---|
| 100110 | 12 (high) | a login is attempted for a non-existent or disabled account — the post-termination alert |
| 100210 | 10 | the Portal blocks an action because of a segregation-of-duties violation |
Settings in the web console
Sign in at wazuh.iamlab.genbay.co as admin. Wazuh is a large product; four areas matter here.
Security events
The main alert view. Filter by rule level or by rule ID to find the alerts this lab generates — 100110 is the one the capstone produces. Open an alert to see the full event: username, source address, timestamp and the rule that matched.
Rules
Under server or ruleset management you can read the rule definitions, including the two custom Golonex rules above. Reading rule 100110 is instructive — it is only a few lines, and it shows that detection is just an expressed expectation: we said a login for a non-existent account is suspicious, so now it is an alert.
Discover / search
Free-text and field search across stored events. Useful for answering the auditor's question — show me everything that happened to this account — rather than browsing alerts.
Index patterns and time range
Wazuh is time-driven: if a view looks empty, widen the time picker before assuming nothing happened. It is the single most common reason a SIEM appears broken.
Try this
- Run the capstone: terminate Alice, attempt her old credentials a few times, then find alert 100110 here. The gap between the attempt and the alert is seconds.
- Then ask the auditor's question — search her username and reconstruct the whole story from provisioning to termination to attempted misuse.