Posted inSecurity

Deploying Wazuh SIEM and XDR on Linux: Centralized Security and Active Response

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Comparing Threat Detection Approaches: Standalone Logs vs. SIEM/XDR

It was 2 AM when my phone started buzzing relentlessly with high-load alerts. A distributed botnet had launched over 15,000 parallel requests against our edge API gateway. Trying to grep raw /var/log/auth.log files across six different nodes in an SSH panic while production crashes is an operational nightmare. That incident taught me a simple lesson: you cannot secure a modern fleet with isolated log files.

When defending Linux infrastructure, teams typically rely on one of three visibility and incident response models:

  • Decentralized Local Scripting (Fail2ban & Logrotate): Runs on individual servers to parse local logs and inject firewall drop rules. Setup takes five minutes, but it leaves you blind to coordinated multi-node attacks.
  • Traditional Centralized Log Aggregation (ELK / Loki): Ships every log line into an Elasticsearch or Grafana Loki cluster. It works well for debugging application crashes. However, you have to build detection rules, state machines, and threat intelligence pipelines from scratch.
  • Open-Source SIEM/XDR (Wazuh): Unifies centralized logging, real-time File Integrity Monitoring (FIM), vulnerability scanning, and compliance auditing. Crucially, it includes bidirectional Active Response to stop attackers directly at the host level.

Pros and Cons of Running Wazuh

Wazuh offers enterprise-grade detection, but it requires upfront capacity planning.

Advantages

  • Automated Active Response: Executes instant remediation scripts—such as dropping IPs via iptables/nftables, locking compromised accounts, or killing rogue processes—the millisecond a rule matches.
  • Unified Security Telemetry: Merges system audit events, rootkit alerts, package vulnerability CVEs, and MITRE ATT&CK mappings inside one unified dashboard.
  • Extensive Built-In Ruleset: Ships with over 4,000 pre-configured rules covering Linux system calls, Docker containers, Nginx, Apache, OpenSSH, and AWS/GCP audit logs.

Disadvantages

  • Resource Footprint: The Wazuh Indexer and Dashboard run on OpenSearch. They need at least 4 GB to 8 GB of RAM on the manager node, making them too heavy for low-spec $5 VPS instances.
  • Tuning Curve: Default out-of-the-box rule collections will generate noisy alerts on busy servers until you tailor whitelist rules to your workloads.

Recommended Architecture Setup

For small-to-medium topologies (1 to 100 monitored nodes), a single-host Wazuh Central Node managing lightweight endpoint agents delivers reliable isolation without complex cluster maintenance.

  • Central Manager Node: Ubuntu 22.04 or 24.04 LTS, 4 vCPUs, 8 GB RAM, and at least 50 GB NVMe/SSD storage.
  • Endpoint Agent Nodes: Linux servers running the lightweight C-based agent. Each daemon consumes less than 1% CPU and roughly 35 MB to 50 MB of RAM.
  • Firewall Ingress Ports on Manager: TCP port 1514 (Agent event traffic), TCP port 1515 (Agent registration service), and TCP port 443 (HTTPS Web UI).

Implementation Guide: Deploying Manager, Agents, and Active Response

Step 1: Install the Wazuh All-in-One Manager

On your dedicated central server, run the official installation assistant. This script provisions the Wazuh Manager, OpenSearch Indexer, and Web Dashboard with generated TLS certificates.

# Download and run the unattended installation assistant
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

When the script finishes, it prints generated credentials for the admin user alongside the web UI URL (https://<YOUR_MANAGER_IP>). Copy and store these in your password manager immediately.

Confirm that all three core services are active and healthy:

sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard

Step 2: Deploy and Enroll Wazuh Agents on Endpoint Servers

SSH into any target Linux server you want to monitor and install the official agent package.

# Add the Wazuh GPG key and APT repository
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /usr/share/keyrings/wazuh.gpg

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt-get update

# Install the agent, pointing it directly to your manager's private IP
sudo WAZUH_MANAGER='192.168.1.100' apt-get install wazuh-agent

# Enable and launch the agent service
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

Within thirty seconds, the new endpoint will register and show up as Active in your Wazuh Dashboard.

Step 3: Configure Automated IP Banning with Active Response

Active Response gives Wazuh real defensive teeth. When an agent spots suspicious behavior, it immediately runs an automated fix locally. Let’s configure Wazuh to automatically drop attacking IPs for 30 minutes after repeated SSH authentication failures.

On your Wazuh Manager host, open /var/ossec/etc/ossec.conf:

sudo nano /var/ossec/etc/ossec.conf

Locate the <ossec_config> block and add the following command and active-response rules:

<!-- Reference the built-in firewall-drop script -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- Trigger firewall-drop on SSH brute-force alert groups -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_group>authentication_failed|authentication_failures</rules_group>
  <timeout>1800</timeout> <!-- Ban offensive IP for 30 minutes -->
</active-response>

Restart the manager to apply your new detection logic:

sudo systemctl restart wazuh-manager

Step 4: Enable Real-Time File Integrity Monitoring (FIM)

Attackers often drop web shells into document roots or modify system binaries after gaining access. FIM tracks file checksums and alerts you to unauthorized changes.

On the monitored agent node, edit /var/ossec/etc/ossec.conf to watch your critical directories in real time:

<syscheck>
  <disabled>no</disabled>
  <frequency>3600</frequency>
  <directories realtime="yes" check_all="yes" report_changes="yes">/etc,/var/www,/usr/bin,/usr/sbin</directories>
</syscheck>

Restart the agent to start monitoring file system events:

sudo systemctl restart wazuh-agent

Step 5: Testing and Validating Active Defense

To verify the response chain, simulate five failed SSH login attempts against the agent from an external IP address. Then monitor the active response log on the target agent in real time:

sudo tail -f /var/ossec/logs/active-responses.log

When the threshold triggers, you will see the script add a temporary firewall drop entry:

/var/ossec/active-response/bin/firewall-drop add - 203.0.113.45 1718929200.12845 5716

Finally, open the Wazuh Dashboard and navigate to Security Events. You will find correlated event graphs, rule levels, MITRE tactic tags, and exact remediation logs reflected across your entire fleet.

Share:
Tags: