Wazuh SIEM and Cross-Stack Automation
The integration layer. Wazuh ingests every upstream component, fires correlated alerts, drives active response, and turns the stack into more than the sum of its parts.
Parts 1–5 complete and exporting data
~90 minutes
Closed-loop SecOps with correlated alerts and active blocking
Wazuh Architecture
Wazuh is three components: the manager (rules engine, agent control, active response), the indexer (OpenSearch fork that stores alerts), and the dashboard (Kibana fork). Endpoints run lightweight agents that ship logs and execute response scripts. All four components colocate on the operations VPS for this stack.
Deploying Manager, Indexer, Dashboard
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
bash wazuh-install.sh -a # all-in-one install
# Capture the printed admin credentials immediatelyThe installer handles the certificates dance via wazuh-certs-tool.sh. For a clustered setup, run with --generate-config-files first and split nodes onto separate VPSes.
Dashboard Behind the Bastion with SSO
Bind the dashboard to 10.88.0.40:443 only and let Caddy on the management VPS publish it under wazuh.tip.example with Authelia in front. The Wazuh dashboard supports OIDC, so once Authelia is in place you can map groups to Wazuh roles cleanly.
Agent Deployment Across the Platform
Install the agent on every other VPS in the stack:
WAZUH_MANAGER='10.88.0.40' apt install -y wazuh-agent
systemctl enable --now wazuh-agentGroup agents by zone (deception, detection, intelligence, management) so rules and active response can target precisely.
Custom Decoders for Honeypot and IDS Logs
<decoder name="cowrie-json">
<prematch>^{"eventid":"cowrie\.</prematch>
<plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>
<decoder name="beelzebub-json">
<prematch>^{"event":"beelzebub\.</prematch>
<plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder><group name="cowrie,">
<rule id="100100" level="6">
<decoded_as>cowrie-json</decoded_as>
<field name="eventid">cowrie.session.connect</field>
<description>Cowrie: new SSH session from $(src_ip)</description>
</rule>
<rule id="100101" level="10">
<if_sid>100100</if_sid>
<field name="eventid">cowrie.command.input</field>
<description>Cowrie: command executed in honeypot session</description>
</rule>
</group>MISP CDB Integration
The MISP exports from Part 5 land in /var/ossec/etc/lists/misp-ip. Compile the list and reference it from a rule:
/var/ossec/bin/wazuh-control reload
# In local_rules.xml:
# <rule id="100200" level="12">
# <list field="srcip" lookup="address_match_key">etc/lists/misp-ip</list>
# <description>Connection from MISP-listed malicious IP</description>
# </rule>Webhook Alerting Replacing Email
<integration>
<name>custom-tip-notify</name>
<hook_url>https://hooks.slack.com/services/T000/B000/XXXX</hook_url>
<level>10</level>
<alert_format>json</alert_format>
</integration>The custom-tip-notify script lives in /var/ossec/integrations/ and reuses the shared tip-notify wrapper from Part 1.
Purpose-Built Dashboards
- • Deception layer — top source ASNs, Cowrie command frequency, Beelzebub LLM jailbreak count.
- • Detection layer — Suricata signatures fired, Zeek notice categories, JA4 hits against MISP.
- • Aggregate threat trends — overlap between honeypot sources and MISP-known actors, time-of-day heatmap, response actions taken.
Active Response
<command>
<name>tip-block</name>
<executable>tip-block.sh</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<command>tip-block</command>
<location>local</location>
<rules_id>100200</rules_id>
<timeout>3600</timeout>
</active-response>The tip-block.sh script applies a UFW deny on the deception VPSes when a confirmed-bad source escalates to scanning a production target.
The End-to-End Automation Pipeline
Worked example, every step automated:
- Cowrie captures a novel SSH brute force from IP
X. - Beelzebub on the same IP captures a follow-up command pattern, raising confidence.
- The PyMISP ingester tags the attribute with
tlp:amberand elevates the event's threat level to high. - MISP's scheduled exports refresh the Suricata rules file and the Zeek intel feed.
- Wazuh's CDB list update detects the IOC match on a monitored production VPS.
- Wazuh active response blocks the IP across all deception and production hosts and fires a webhook to Slack with the full context.
Orchestrator Options
- • Lightweight Python on the management VPS — simplest, version-control the scripts, cron + systemd timers. Recommended default.
- • n8n self-hosted — graphical workflows, easy to onboard analysts, more moving parts.
- • Temporal — overkill for this stack but pays off if you grow into a multi-tenant MSSP shape.
Maintenance and Upgrade Ordering
The integration ordering that avoids breakage: upgrade MISP first (export schemas are stable across minor versions), then Suricata + Zeek (they consume MISP exports), then Wazuh manager + indexer + dashboard together (they must match versions), then T-Pot last (its Elastic stack is independent).
Where to Go from Here
- • TheHive + Cortex for case management and analyst workflow.
- • OpenCTI for graph-based intel modelling on top of MISP.
- • Velociraptor for endpoint forensics across the agents Wazuh already manages.
- • A second region: replicate the deception zone in a different RamNode location to capture geographically diverse attacker behaviour.
