Results at a glance
- 70+production servers sending security events to one place
- 3Wazuh cluster nodes, so the SIEM is not a single point of failure
- Per rolelog sources chosen by the services each server runs
- Autoactive response for SSH, authentication and web attacks and flooding
The problem
Grafana told us when a server was slow or down. It didn't tell us when someone was guessing SSH passwords, probing a web application, or when a binary on a production host changed. Each server's logs stayed on that server, so spotting an attack meant knowing where to look before you knew there was anything to find.
The goals were simple: one place to see security events from every production server, automatic blocking of the noisiest attacks, a way to notice changed or malicious files, and a list of which servers run vulnerable packages.
Architecture
Wazuh runs as a three-node cluster, so the SIEM itself is not a single point of failure. The pieces each have one job:
- Wazuh agents on each server collect logs, run file-integrity checks and report installed packages.
- Managers decode and match events against rules, raise alerts and trigger active responses.
- Indexer and dashboard store alerts and give the team search and triage.
Onboarding 70+ servers
I installed agents on more than 70 production servers: web, database, SIP/telecom, load-balancer and utility hosts. Each server sends the logs that match the services it runs, rather than one generic configuration for everything.
Log coverage that follows the services
Not every server needs every log. I mapped log collection to what each server actually runs:
- Apache access and error logs on web servers
auth.log/ secure and syslog everywhere- MySQL and PostgreSQL logs on database servers
- OpenSIPS logs on SIP servers
- HAProxy logs on load balancers
- cron and other service logs where they matter
Detection rules and alert triage
I configured multiple anomaly-detection and security-monitoring rules for the events that matter in this environment, on top of Wazuh's default ruleset. The aim is that routine events are recorded while the ones that need a person stand out.
Active response, with care
Active response blocks the source of an attack automatically. I set it up for several scenarios:
- SSH brute-force attempts
- repeated authentication failures on other services
- web attacks seen in Apache logs
- request flooding
Automatic blocking on production systems has to be handled carefully, because a careless rule can lock out real users or monitoring systems. Response scenarios are scoped to clear attack patterns rather than single failed attempts.
File-integrity monitoring and YARA
These are two different jobs. File-integrity monitoring (part of Wazuh) answers "did this file change, and when?". It watches important system and application paths and records additions, deletions and modifications. YARA answers a different question: "does this file look malicious?". I added a separate YARA scanning workflow so that files flagged by FIM can be checked against YARA rules for known malware patterns, instead of only knowing that something changed.
Vulnerable packages
Wazuh's vulnerability detection compares each agent's installed packages with published CVE data. That gives a fleet-wide list of which servers run vulnerable versions, which we use to plan patching instead of guessing.
WhatsApp notifications
Engineers on call don't sit in the Wazuh dashboard. I integrated WhatsApp notifications for selected alerts and anomalies, so the events that need a human reach a phone immediately. Wazuh decides what is an alert; the integration only delivers the high-priority ones, which keeps the channel worth reading.
What makes this hard
- Noise. A SIEM is only useful if people still read its alerts, so rule levels have to be tuned per service.
- Safe automation. Active responses run on production servers, so each scenario needs a clear trigger.
- Different log formats. Services such as OpenSIPS and HAProxy need their logs collected and decoded correctly before rules can match them.
Outcome
Security events from 70+ production servers now arrive in one searchable place. Common attacks are blocked automatically, changed and suspicious files are recorded, vulnerable packages are visible across the fleet, and the alerts that need attention reach engineers on WhatsApp. Configuration details, server names and addresses are left out on purpose.
