Skip to main content

Command Palette

Search for a command to run...

03. What is Wazuh? A Real-World Perspective

Published
9 min read
F

PT FPT Metrodata Indonesia (FMI) is a joint venture between FPT IS and Metrodata Electronics, focusing on providing Cybersecurity-as-a-Service—including SOC, managed security, professional services, consulting, and threat intelligence—to support Indonesia’s rapidly growing digital economy. FMI is expanding into AI and cloud GPU services to deliver innovative protection and solutions for enterprises. Learn more at https://fmisec.com.


I've been deploying Wazuh in production environments and honestly, it's one of the few security tools that actually delivers on its promises. It's not just another SIEM, it's a complete security monitoring ecosystem.

Here's what makes Wazuh special: Unlike those $100k+ annual SIEM licenses that promise the world and deliver headaches, Wazuh gives you enterprise-grade capabilities for free. But (and this is important) it does require some understanding to unlock its full potential. I've seen teams struggle because they didn't take the time to understand how it works.

The Three Pillars of Wazuh

Wazuh gives you three core capabilities that work together (and honestly, this is where most people get confused):

  • Host-based Intrusion Detection (HIDS) - This is like having a security guard watching every file change, process, and system call on your endpoints

  • Security Information and Event Management (SIEM) - Think of this as the central brain that analyzes all your logs and connects the dots

  • Extended Detection and Response (XDR) - This is the advanced stuff, threat hunting and incident response across your entire environment

Here's what I've learned: Most organizations start with HIDS (it's the easiest to understand), then gradually realize they need the SIEM capabilities. The key is understanding how these components actually work together, I've seen too many deployments fail because teams tried to use them in isolation.

Understanding Wazuh's Architecture: A Deep Dive

┌─────────────────────────────────────────────────────────────┐
│                    WAZUH PLATFORM                           │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐ │
│  │  WAZUH INDEXER  │  │  WAZUH MANAGER  │  │   WAZUH      │ │
│  │  (Data Storage) │  │ (Central Brain) │  │  DASHBOARD   │ │
│  │                 │  │                 │  │ (Web UI)     │ │
│  │ • OpenSearch    │  │ • Log Analysis  │  │ • Kibana-    │ │
│  │ • Data Store    │  │ • Rule Engine   │  │   based UI   │ │
│  │ • Search Engine │  │ • API Server    │  │ • Reports    │ │
│  │ • Clustering    │  │ • Filebeat      │  │ • Analytics  │ │
│  └─────────────────┘  └─────────────────┘  └──────────────┘ │
└─────────────────────────────────────────────────────────────┘
                            ▲
                            │ Port 1514/1515
                   ┌─────────────────────┐
                   │    WAZUH AGENTS     │
                   │                     │
                   │ ┌─────┐ ┌─────┐ ┌───┴───┐
                   │ │Linux│ │Win  │ │ macOS │
                   │ │Agent│ │Agent│ │ Agent │
                   │ └─────┘ └─────┘ └───────┘
                   └─────────────────────────┘

Component Deep Dive: What Each Part Actually Does

1. Wazuh Manager - The Brain of Your Security Operations

The Manager is where all the magic happens. I've seen it process over more than 20,000 events per second in production environments, and honestly, it's pretty impressive when it's running smoothly.

Let me break down the core components (this is where most people get lost):

  • wazuh-analysisd - This is the rule engine that does all the heavy lifting

    • Real-world tip: This process is a CPU hog. I always recommend at least 4 cores for production, and I've seen it use 8+ cores on busy systems

    • Common gotcha: If you have too many complex rules, this process will slow down. Start simple, then add complexity gradually

  • wazuh-remoted - This handles all the agent communications

    • Critical insight: 90% of agent connection problems are in this service. When agents can't connect, check this first

    • Performance reality: I've seen it handle 1000+ concurrent agents, but it needs proper resources

  • wazuh-authd - This handles agent authentication and enrollment

    • Security reality: Always use SSL/TLS in production. I've seen too many deployments compromised because of this

    • Troubleshooting tip: When agents fail to enroll, this is usually where the problem is

  • wazuh-db - Internal SQLite database for configuration and state

    • Important gotcha: This database grows over time and can become huge. I've seen it hit 10GB+ on busy systems

    • Backup reality: You need to include this in your backup strategy, it contains all your agent configurations

  • wazuh-modulesd - Handles additional modules like vulnerability scanning

    • Resource warning: Vulnerability scanning is CPU and memory intensive. I always schedule it during off-peak hours

    • Integration point: This is where you'd add custom modules for specific use cases

  • wazuh-apid - REST API for external integrations

    • Rate limiting: Default is 100 requests/minute, which is usually fine, but adjust based on your needs

    • Authentication tip: Use API keys for production, not basic auth

Ports and Communication:

  • 1514/1515: Agent communication (TCP/UDP)

  • 55000: REST API access

  • Internal: Various ports for inter-component communication

2. Wazuh Indexer - Your Data Warehouse

The Indexer is based on OpenSearch (formerly Elasticsearch), and honestly, this is where most people underestimate the resource requirements.

Here's what I've learned the hard way:

  • Storage reality: Plan for 3-5x your daily log volume for indexing overhead. I've seen too many deployments run out of space

  • Memory allocation: Allocate 50% of available RAM to the JVM heap (but never more than 32GB, trust me on this)

  • Disk performance: Use SSD storage. I've seen 10x performance improvement over HDD, and it's worth every penny

  • Clustering: For high availability, always run at least 3 indexer nodes. Single points of failure are not your friend

Key Features:

  • Full-text search: Find specific events across millions of logs

  • Data clustering: Distribute data across multiple nodes for scalability

  • Index management: Automatic rollover and cleanup of old data

  • Security plugins: Authentication and authorization for data access

3. Wazuh Dashboard - Your Security Command Center

The Dashboard is your window into the security world. It's based on OpenSearch Dashboards (Kibana fork), and honestly, it's pretty good once you get the hang of it.

Here's what I've learned from real deployments:

  • Custom dashboards: You can create role-based dashboards for different teams (SOC analysts, managers, compliance), and this is actually really useful

  • Real-time monitoring: Set up auto-refresh for critical events, but don't go crazy, it can impact performance

  • Report generation: Automated compliance reports save hours of manual work (this alone justifies the platform for some organizations)

  • Agent management: Centralized agent deployment and configuration makes life so much easier

Performance reality check:

  • Browser compatibility: Works best with Chrome/Firefox. IE support is basically non-existent

  • Concurrent users: I've seen it handle 50+ concurrent users, but it needs proper resources

  • Dashboard complexity: Too many visualizations will slow it down. Keep dashboards focused and simple

4. Wazuh Agents - Your Eyes and Ears

Agents are surprisingly lightweight but powerful. I've deployed them on everything from Raspberry Pis to enterprise servers, and they just work.

Here's what agents actually monitor (this is where it gets interesting):

  • File integrity monitoring: This catches unauthorized changes to critical files

    • Best practice: Monitor /etc, /usr/bin, and application directories (but be careful not to over-monitor)

    • Performance reality: Minimal CPU usage, but it can generate a lot of events if you're not careful

  • Log collection: This forwards system and application logs to the manager

    • Log rotation: Make sure you have proper log rotation, or you'll run out of disk space

    • Filtering: Use log filtering to reduce noise, this is crucial for performance

  • System inventory: This tracks hardware, software, and network configurations

    • Compliance: Essential for compliance reporting and asset management

    • Change detection: Automatically detects system changes and updates (this is actually really useful)

  • Malware detection: Real-time scanning using YARA rules

    • Rule updates: Keep YARA rules updated for latest threat detection

    • Performance warning: This can impact system performance on resource-constrained devices

  • Rootkit detection: This identifies hidden malware and backdoors

    • Scheduling: Run during off-peak hours, it's resource intensive

    • False positives: You'll need to tune rules to reduce false positives in your environment

  • Configuration assessment: This checks system hardening and compliance

    • Custom rules: You can create environment-specific compliance rules

    • Reporting: Generates compliance reports for audits (this alone justifies the platform for some organizations)

Real-World Architecture Considerations

Performance Tuning Tips from Production

After managing Wazuh deployments for 3+ years, here are the critical performance considerations (and the mistakes I've made so you don't have to):

Memory Allocation (this is crucial):

  • Manager: Minimum 8GB RAM, 16GB+ for production (I've seen 8GB work, but it's not pretty)

  • Indexer: 50% of available RAM to JVM heap (but never more than 32GB, trust me on this)

  • Dashboard: 4GB RAM minimum, 8GB+ for multiple concurrent users

Storage Planning (this is where most people mess up):

  • Indexer storage: 3-5x your daily log volume (I've seen too many deployments run out of space)

  • Use SSDs: 10x performance improvement over HDDs (it's worth every penny)

  • Separate data/logs: Keep OS and Wazuh data on different disks (this makes troubleshooting much easier)

Network Considerations (often overlooked):

  • Agent bandwidth: ~1-2KB per agent per minute (varies by configuration, but this is usually fine)

  • Manager network: Gigabit Ethernet minimum for production (don't try to run this on 100Mbps)

  • Latency: Keep agents within 100ms of manager for optimal performance (this matters more than you'd think)

Common Architecture Mistakes I've Seen (and Made)

  1. Under-provisioning resources - Wazuh is resource-intensive, especially the indexer. I've seen too many deployments struggle because of this

  2. Single point of failure - Always plan for high availability in production. I learned this the hard way

  3. Poor network design - Agents need reliable connectivity to the manager. Don't underestimate this

  4. Inadequate monitoring - Monitor Wazuh components themselves for health. You need to know when something is wrong

Scaling Strategies

Small Environment (< 100 agents):

  • Single-node deployment (All-in-One)

  • 8GB RAM, 4 CPU cores minimum

  • 100GB+ storage

Medium Environment (100-1000 agents):

  • Separate indexer and manager nodes

  • 3-node indexer cluster for HA

  • Load balancer for dashboard access

Large Environment (1000+ agents):

  • Distributed architecture with dedicated nodes

  • Multiple manager nodes with load balancing

  • Dedicated indexer cluster with proper sharding

Troubleshooting Common Issues

Agent Connection Problems

# Check agent status
sudo systemctl status wazuh-agent

# Check manager connectivity
telnet YOUR_MANAGER_IP 1514

# View agent logs
tail -f /var/ossec/logs/ossec.log

Performance Issues

# Check manager performance
top -p $(pgrep wazuh-analysisd)

# Monitor indexer health
curl -X GET "localhost:9200/_cluster/health?pretty"

# Check disk usage
df -h /var/ossec/

Memory Issues

# Check JVM heap usage
curl -X GET "localhost:9200/_nodes/stats/jvm?pretty"

# Monitor system memory
free -h

Next Steps: From Architecture to Implementation

Now that you understand how Wazuh's components work together, you're ready to see it in action. The architecture might seem complex at first, but here's the thing: start simple, then scale. I've seen too many teams try to implement everything at once and get overwhelmed.

My advice: Don't try to implement everything at once. Start with basic HIDS monitoring, then gradually add SIEM capabilities as you become comfortable with the platform. Trust me on this.

In the next article, we'll dive into a hands-on installation guide where you'll see these components come to life on a real Ubuntu VM. You'll learn not just how to install Wazuh, but how to configure it properly for your specific environment (and avoid the mistakes I've made).

49 views

More from this blog

F

FPT Metrodata Indonesia Cyber Security

683 posts

FPT Metrodata Indonesia (FMI) provides news, analysis & guides on cybersecurity and threat intelligence for Indonesia & Vietnam. Visit https://news.fmisec.com. FMI: https://fmisec.com