TPTito Pinardo Gutiérrez
← Back to the rack
Español
1U · WAZUHSIEM · FIM · CVE · CIS In production

Slot 17 of 25 in the rack · In production

1U unit · Security

Wazuh · who did what

2,195 → 1,801 vulnerability entries

An agent on every machine sends its logs, watches the files that shouldn't change and takes a package inventory. Wazuh matches them against its rules, known vulnerabilities and CIS checks, and alerts by severity: the serious stuff, encrypted to my phone.

How it's isolated
Unprivileged container with no SSH; the API, indexer and mail only listen inwards, and agent enrolment is closed: they're registered from the hypervisor.
What it watches
Logins, changes to critical files, packages with vulnerabilities and configuration checks on the containers and the server itself.
How it alerts
Grouping repeats in 5-minute windows and never sending raw logs. Only high-level stuff reaches my phone.
  • 9,500 → ~100alerts a week on Discord
  • 342distinct CVEs reviewed one by one
  • 3 han upgrade hung, because of the disk
  • 0raw logs in the alerts

Its code, in the open Public version of the repo: no IPs or secrets.

Inside the security

Every machine sends its logs; here it's decided what's suspicious and who gets told. Pick a flow.

Flows Pick one and follow the packet.

Outside Wazuh container · Proxmox manager, indexer and dashboard On every machine The manager Alerts Review and patch Me Discord Element Hypervisor Hermes Agent Logs Integrity Inventory Manager Rules Indexer Dashboard Levels De-duplication Email Failed logins CVE CIS Patch Snapshot
Hermesvisiting the unit

Click a part or pick a flow. If you came from a skill, the parts where I use it are already lit.

      Someone tries passwords
      1. Logs — An authentication log shows repeated failures.
      2. Wazuh agent — The agent sends it.
      3. Wazuh manager — The manager receives it.
      4. Rules — A rule classifies it by level.
      5. Routing by level — If it reaches 12, it goes to my phone.
      6. Group repeats — Grouped: one alert with the count, not one per attempt.
      7. Alerts room — To the alerts room, encrypted.
      8. Me — I read it and decide.
      A critical file changes
      1. File integrity — A container's SSH configuration changes.
      2. Wazuh agent — The agent detects it.
      3. Wazuh manager — The manager receives it.
      4. Rules — A rule flags it.
      5. Indexer — It's stored to search later.
      6. Dashboard — And it shows on the dashboard: which file, where and when.
      Vulnerability review
      1. Package inventory — The inventory says which version of each package is installed.
      2. Wazuh manager — The manager matches it with known vulnerabilities.
      3. Vulnerabilities — I review them one by one against the distribution: fixed, pending or not affected.
      4. Patching — I patch only official fixes, simulating first.
      5. Prior snapshot — With a prior snapshot.
      6. Patching — I apply.
      7. Package inventory — And the inventory refreshes.
      The morning summary
      1. Wazuh manager — The manager has the day's failed logins.
      2. Failed-login summary — Hermes' watcher collects them.
      3. Hermes — Hermes summarises them.
      4. Alerts room — In its room.
      5. Me — And I read it with my coffee.
      An upgrade that hangs
      1. Patching — I run the fleet-wide update.
      2. Hypervisor — The hypervisor's disk is saturated.
      3. Prior snapshot — And the Wazuh container carries two old snapshots.
      4. Hypervisor — The container's file system stops moving: three hours.
      5. Wazuh manager — With the snapshots deleted and write cache on, the manager starts.
      6. Indexer — The indexer needs more start-up time: it gets it.

      1. Me

        The one who has to decide whether something is an attack or just me.

      2. Discord

        From level 7: what deserves a look.

      3. Alerts room

        From level 12, end-to-end encrypted.

      4. Hypervisor

        Has its own agent too, with auditing of account files, sudo and SSH.

        • Proxmox VE

      5. Hermes

        Its failed-login watcher summarises what no longer reaches Discord.

      6. Wazuh agent

        In every container. Registered through the hypervisor, not through an open port.

        • Wazuh

      7. Logs

        Authentication, sudo, services, auditd and Docker.

        • Wazuh
        • Linux (Debian, Alpine, Arch)

      8. File integrity

        Warns if files that shouldn't change do: configuration, accounts, services. Without storing the change's content.

        • Wazuh

      9. Package inventory

        Which version of each package is on each machine, to match it against vulnerabilities.

        • Wazuh

      10. Wazuh manager

        Receives everything and analyses it.

        • Wazuh

      11. Rules

        Wazuh's own plus a few of mine for the home log.

        • Wazuh

      12. Indexer

        Keeps alerts for 30 days to search them.

        • Wazuh

      13. Dashboard

        Only behind the internal door with two-factor.

        • Wazuh

      14. Routing by level

        Discord from 7, email from 10, phone from 12.

        • Wazuh

      15. Group repeats

        An integration of my own groups repeats in 5-minute windows and sends a summary, never the log.

        • Python

      16. Email

        From level 10: about 15 a week.

        • Wazuh

      17. Failed-login summary

        What leaves Discord isn't lost: Hermes summarises it in its room.

      18. Vulnerabilities

        Each package matched against known vulnerabilities. One CVE can show up many times: they aren't attacks.

        • Wazuh
        • Linux (Debian, Alpine, Arch)

      19. CIS checks

        Secure-configuration controls. Accepted exceptions are documented with their reason.

        • Wazuh
        • Linux / SSH hardening

      20. Patching

        Official fixes only, simulated first, rejecting kernel, driver or critical-service changes.

        • Ansible
        • Linux (Debian, Alpine, Arch)

      21. Prior snapshot

        Before patching, a container snapshot. Useful… but it can't be kept forever.

        • Proxmox VE

      What I use from my skill tree

      Pick a skill: the parts where I use it light up on the map and I tell you what for.

      Ansible
      Fleet updates, simulated first and without touching kernel or drivers.
      Proxmox VE
      The hypervisor has its agent and auditd; agents are registered through it.
      LXC
      Wazuh runs in its own unprivileged container.
      Linux (Debian, Alpine, Arch)
      auditd, journald, AppArmor and spare services reviewed on every machine.
      Wazuh
      Manager, indexer and dashboard; agents with logs, file integrity, inventory and vulnerabilities; alert levels measured and tuned.
      Linux / SSH hardening
      CIS checks reviewed, auditing of critical files and alerts without raw data.
      Python
      The integration that groups repeats and sends summaries to Discord and Matrix.

      Incident log

      Real failures. Read the symptom, pick the cause you think it was and see how it was fixed.

      1. #1

        9,517 alerts in a week

        05-10-2026 · noise

        Security alerts were «unbearable»: thousands a day on Discord.

        What do you think was going on?

        Show the fix
        Cause
        Discord got everything from level 3. Two thirds were session opens and closes from my own automations, and the rest successful SSH logins and routine checks.
        Fix
        Measure a week by rule and agent, and raise Discord to level 7 and email to 10. What stops being sent stays on the dashboard and Hermes summarises failed logins.
        Lesson
        If almost everything that arrives is routine, what matters gets lost in between. Decide with the count in front of you, not by eye.

      2. #2

        Eleven «suspicious» changes a day on the hypervisor

        08-09-2026 · integrity

        File integrity warned every day about changes to the hypervisor's configuration files, keys included.

        What do you think was going on?

        Show the fix
        Cause
        That hypervisor folder isn't normal files: it's a view of its internal database, rewritten all the time by normal operation.
        Fix
        Take it out of integrity monitoring and keep the paths that matter: accounts, sudo, SSH and services. On top of that, auditd watches those files on the hypervisor.
        Lesson
        Watching something that always changes doesn't protect you: it trains you to ignore the alert. Know what each path is before watching it.

      3. #3

        Three hours stuck on «apt upgrade»

        25-09-2026 · disk

        The fleet update sat for three hours on the Wazuh container. It wasn't Ansible or an apt prompt: the processes were waiting for the disk.

        What do you think was going on?

        Show the fix
        Cause
        The whole system and about 16 containers share a mirror of two spinning disks, with write cache off. And Wazuh's nearly full volume carried two snapshots that turned each write into several.
        Fix
        Delete the snapshots, restart the container and finish configuration. Turn on write cache on the system disks. Give the indexer 15 minutes to start.
        Lesson
        A «just in case» snapshot costs something on every write for as long as it exists. Delete it once it's no longer needed.

      How it was built

      1. 06-07-09-2026

        Installation

        • A first attempt failed under disk pressure; a second one separated the initial vulnerability download.
        • Unprivileged container, no SSH and internal ports only inwards.
        • Agents across the fleet.

      2. 14-09-2026

        Full review

        • 342 CVEs checked against the distribution and official patches applied.
        • Failed CIS checks reviewed one by one, with documented exceptions.
        • Auditing of account files on the hypervisor and spare services switched off.

      3. September and October 2026

        Less noise

        • Integrity without the folder that changes by itself.
        • Alert levels tuned against a measured week.

      Decisions (and why)

      • How vulnerabilities are counted

        Against the distribution, not the raw number

        A CVE in a shared library shows up on every machine. What matters is whether the installed version is already fixed, pending or not affected.

      • What goes in an alert

        A summary, never the log

        A log can carry data that mustn't leave the server. The alert says what, where and how many times; the detail is on the dashboard.

      • CIS scores

        Don't chase the number

        Some controls, applied blindly, would break the hypervisor's firewall or needed services. They're accepted with a written reason.

      What I learned

      • A security system that alerts on everything alerts on nothing.
      • Count properly: one CVE in a hundred places is one patch, not a hundred attacks.
      • Snapshots get deleted.

      What's next

      • Repeat the alert measurement in a few weeks.
      • Move the system to faster disks so an update doesn't compete with the whole server.

      Shall we talk?

      I can walk through any of these decisions in detail in an interview.

      Download CV Get in touch ← Back to the rack

      Rebuilt from my documentation: no addresses, agents, local rules or details useful for an attack.