Scaling Wazuh for Multi-Site Network Security Monitoring

🚀 Introduction: Why Multi-Site Monitoring Matters

In modern organizations, offices and data centers are often spread across regions. Centralized security visibility helps prevent blind spots and improves response times.
Wazuh’s multi-site implementation enables distributed log processing and local site autonomy — while maintaining a unified dashboard that aggregates global threat data.

🧩 1. Multi-Site System Diagram

The diagram below represents a typical Wazuh multi-site architecture from the official Wazuh model — adapted for enterprise deployments such as Cisco network monitoring.

graph TD
subgraph SiteA["🏢 Site A (Bangkok)"]
A1["Cisco Devices / Agents"] --> M1["Wazuh Manager (Master)"]
M1 --> I1["Indexer Node 1"]
M1 --> I2["Indexer Node 2"]
end

subgraph SiteB["🏭 Site B (Tokyo)"]
B1["Cisco Devices / Agents"] --> M2["Wazuh Manager (Worker)"]
M2 --> I3["Indexer Node 3"]
end

subgraph SiteC["☁️ Site C (Singapore - Cloud Backup)"]
C1["Agents / Cloud Logs"] --> M3["Wazuh Manager (Worker)"]
M3 --> I4["Indexer Node 4"]
end

I1 <--> I2
I2 <--> I3
I3 <--> I4
I4 <--> I1

subgraph HQ["🌐 Central Dashboard"]
D1["Wazuh Dashboard"] --> D2["Unified View of All Sites"]
end

I1 & I2 & I3 & I4 --> D1

Explanation:

Each site runs its own Wazuh Manager + Indexers.
Indexers form one replicated cluster, ensuring resilience and redundancy.
The central dashboard connects to all indexers for global visualization.
Sites can still operate independently even if inter-site connections drop.

⚙️ 2. Configuration Highlights from Wazuh’s Official Setup

Generate certificates using wazuh-certs-tool.sh -A (root CA + node certs).
Configure opensearch.yml and ossec.conf for each site’s nodes:
Related Posts
- <node_type>master</node_type> for the primary site
- <node_type>worker</node_type> for remote sites
Use wazuh.yml with ip.selector: true to let dashboard users switch between sites.
Define opensearch.hosts in opensearch_dashboards.yml for all indexers.
Apply RBAC roles to limit user access per site (e.g., custom_read_site_a).

🛰️ 3. Cisco & SNMP Integration (Per-Site)

Each site handles its own network telemetry locally:

Source	Collection Method	Sent To	Notes
Cisco Routers	Syslog	Local Wazuh Manager	Use site-local syslog servers
Cisco Switches	SNMP	Local Wazuh Manager	Add Cisco MIB rules
Firewalls	Agentless	Local Indexers	Use custom decoders
Endpoints	Wazuh Agents	Nearest Manager	Reduces WAN dependency

🔄 4. Cross-Site Synchronization and High Availability

Multi-node clusters replicate indices for fault tolerance.
Site A can continue local operations if WAN to HQ is lost.
Central dashboard reconnects automatically once connectivity resumes.
Backups are distributed: each site retains local searchable history.

📊 5. Dashboard and Data Access Flow

sequenceDiagram
participant User as Admin
participant Dashboard as Wazuh Dashboard
participant Indexers as Cluster
participant Sites as Local Managers

User->>Dashboard: Select Site (Bangkok / Tokyo / Cloud)
Dashboard->>Indexers: Fetch Alerts for Selected Index
Indexers->>Sites: Request Log Metadata
Sites-->>Indexers: Return Parsed Alerts
Indexers-->>Dashboard: Send Aggregated Data
Dashboard-->>User: Display Unified View

🧠 6. Best Practices Summary

✅ Use site-specific index names (e.g. alerts-bkk-*, alerts-tokyo-*)
✅ Configure certificate-based trust between sites
✅ Apply ILM policies to rotate and archive old data
✅ Assign role-based access control per location
✅ Monitor cluster health via /api/status
✅ Document IPs, DNS names, and ports for inter-site connections

🔐 Conclusion

Wazuh’s multi-site model delivers a scalable, fault-tolerant solution for distributed enterprises.
By localizing data collection while maintaining global control, you gain faster threat detection, simpler management, and better resilience across your Cisco-based infrastructure.