Wazuh SIEM + XDR: 500+ Endpoint Deployment

Overview

Full production Wazuh SIEM + XDR deployment at PostEx covering 500+ endpoints across Windows workstations, Linux servers, and network devices. Wazuh functions as the open-source HIDS/XDR layer — providing agent-based host telemetry, file integrity monitoring, vulnerability scanning, compliance monitoring, and automated active response. It operates in parallel with Splunk Enterprise (primary SIEM) and Elastic Fleet (EDR layer) as part of the multi-SIEM security monitoring platform.

Architecture

Wazuh Agents (Windows/Linux/macOS) ──► Wazuh Manager
                                              |
                           ┌─────────────┴────────────┐
                           │ Rules Engine (40+ custom) │
                           │ Active Response Module    │
                           │ FIM (File Integrity Mon.) │
                           │ Vulnerability Detector    │
                           │ Compliance Manager        │
                           └─────────┬───────────┘
                                     |
              ┌──────────────┴─────────────┐
              │                               │
        Elasticsearch                     n8n Webhook
        Kibana (Wazuh App)           (Alert → Telegram)
        Wazuh Dashboard               JIRA Ticket

1. Agent Management

Deployed Wazuh agents across 500+ endpoints using a combination of deployment methods scaled to environment type:

Windows Deployment (via PowerShell + GPO)

# PowerShell deployment script (run via GPO or SCCM)
$MANAGER = "wazuh-manager.postex.internal"
$AGENT_NAME = $env:COMPUTERNAME
$MSI_URL = "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.x-x86_64.msi"

Invoke-WebRequest -Uri $MSI_URL -OutFile C:\Temp\wazuh-agent.msi
Start-Process msiexec.exe -ArgumentList `
  "/i C:\Temp\wazuh-agent.msi",
  "WAZUH_MANAGER=$MANAGER",
  "WAZUH_AGENT_NAME=$AGENT_NAME",
  "WAZUH_AGENT_GROUP=windows-workstations",
  "/quiet","/norestart" -Wait
Net-Service -Name WazuhSvc -StartupType Automatic
Start-Service -Name WazuhSvc

Linux Deployment (via Ansible)

# Ansible playbook: deploy-wazuh-agent.yml
- hosts: linux_servers
  become: yes
  tasks:
    - name: Add Wazuh repository
      shell: curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add -
    - name: Install Wazuh agent
      apt:
        name: wazuh-agent
        state: present
    - name: Configure manager address
      lineinfile:
        path: /var/ossec/etc/ossec.conf
        regexp: "<address>"
        line: "  <address>wazuh-manager.postex.internal</address>"
    - name: Enable and start agent
      systemd:
        name: wazuh-agent
        enabled: yes
        state: started

2. Vulnerability Detection

Wazuh's Vulnerability Detector module scans all agents against the NVD (National Vulnerability Database), Red Hat, Ubuntu, and Debian advisories. Configuration:

<!-- vulnerability-detector in ossec.conf -->
<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>

  <!-- NVD feed (all CVEs) -->
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </provider>

  <!-- OS-specific advisories -->
  <provider name="ubuntu"><enabled>yes</enabled></provider>
  <provider name="redhat"><enabled>yes</enabled></provider>
  <provider name="msu"><enabled>yes</enabled></provider>
</vulnerability-detector>

Outcome: Critical and High CVE alerts auto-create JIRA tickets via n8n. Patch SLA: Critical = 24h, High = 72h, Medium = 2 weeks.

3. File Integrity Monitoring (FIM)

FIM watches critical system files, configs, and binary directories for unauthorized changes — detecting both attacker persistence and accidental misconfigurations.

<!-- FIM configuration in ossec.conf -->
<syscheck>
  <frequency>43200</frequency>  <!-- Full scan every 12 hours -->
  <scan_on_start>yes</scan_on_start>
  <alert_new_files>yes</alert_new_files>

  <!-- Linux critical paths (realtime monitoring) -->
  <directories realtime="yes" report_changes="yes">/etc</directories>
  <directories realtime="yes">/bin,/sbin,/usr/bin</directories>
  <directories realtime="yes">/var/www/html</directories>

  <!-- Windows critical registry -->
  <windows_registry>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
  <windows_registry>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>

  <!-- Ignore noisy paths -->
  <ignore>/etc/mtab</ignore>
  <ignore>/proc</ignore>
</syscheck>

Key detections: Web shell drops in /var/www/html, crontab modification, /etc/passwd changes, new Windows service registration, binary replacement attacks.

4. Compliance Monitoring

Wazuh maps rules to compliance frameworks. Automated compliance dashboards built in Kibana for audit requirements:

5. Custom Detection Rules (XML)

<!-- Brute force: 5+ SSH failures in 2 minutes (T1110.001) -->
<rule id="100001" level="12">
  <if_sid>5720</if_sid>
  <same_source_ip/>
  <occurrence>5</occurrence>
  <timeframe>120</timeframe>
  <description>Brute force SSH attack from $(srcip) [T1110.001]</description>
  <mitre><id>T1110.001</id></mitre>
  <group>authentication_failures,brute_force</group>
</rule>

<!-- Sudo privilege escalation (T1078) -->
<rule id="100002" level="10">
  <if_sid>5402</if_sid>
  <match>COMMAND=/bin/su\|COMMAND=/usr/bin/passwd</match>
  <description>Suspicious sudo command: privilege escalation attempt [T1078]</description>
  <mitre><id>T1078</id></mitre>
</rule>

<!-- Web shell dropped in document root (T1505.003) -->
<rule id="100003" level="15">
  <if_sid>550,554</if_sid>
  <field name="file">\.php$|\.asp$|\.aspx$|\.jsp$</field>
  <match>/var/www|inetpub</match>
  <description>Possible web shell dropped: $(file) [T1505.003]</description>
  <mitre><id>T1505.003</id></mitre>
</rule>

Active Response

Automated response actions triggered by specific rule levels:

<!-- Active response: block IP on brute force -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100001</rules_id>
  <timeout>1800</timeout>  <!-- Block for 30 minutes -->
</active-response>

Results

• 500+ endpoints under continuous 24/7 HIDS monitoring
• Critical vulnerabilities detected and patched within SLA: 100% within 24 hours
• FIM caught 3 unauthorized file modifications (potential web shells) before exploitation
• 40% false positive reduction through systematic rule tuning over 6 months
• PCI-DSS compliance requirements for log collection and FIM fully covered
• Mean time to notify under 2 minutes via automated n8n → Telegram pipeline