03. What is Wazuh? A Real-World Perspective
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 liftingReal-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 communicationsCritical 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 enrollmentSecurity 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 stateImportant 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 scanningResource 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 integrationsRate 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)
Under-provisioning resources - Wazuh is resource-intensive, especially the indexer. I've seen too many deployments struggle because of this
Single point of failure - Always plan for high availability in production. I learned this the hard way
Poor network design - Agents need reliable connectivity to the manager. Don't underestimate this
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).





