Modern organizations generate millions of security events every day across endpoints, servers, cloud infrastructure, containers, applications, and network devices.

Without centralized visibility, identifying malicious activity before it becomes a serious security incident becomes increasingly difficult. This is where Wazuh monitoring plays a critical role.

Whether you’re monitoring Windows event logs, Linux authentication attempts, Kubernetes clusters, AWS services, web servers, or firewall activity, Wazuh provides a centralized platform for detecting threats in real time.

Unlike traditional log management tools that simply store data, Wazuh actively analyzes events using thousands of built-in detection rules, file integrity monitoring, vulnerability detection, security configuration assessment, and threat intelligence integrations.

This enables security teams to identify attacks, investigate suspicious behavior, and respond quickly before damage occurs.

According to the MITRE ATT&CK Framework, attackers typically progress through multiple stages before achieving their objectives.

Continuous monitoring helps organizations detect malicious activity at every stage of the attack lifecycle rather than discovering breaches weeks or months later.

IBM Cost of a Data Breach Report – https://www.ibm.com/reports/data-breach

Cyberattacks rarely happen instantly. Attackers typically perform reconnaissance, gain initial access, establish persistence, move laterally, and escalate privileges before reaching their objectives.

Continuous monitoring allows defenders to detect indicators throughout this attack chain.

Some of the biggest benefits include:

Faster threat detection
Reduced attacker dwell time
Improved incident response
Better compliance reporting
Centralized visibility across infrastructure
Reduced manual log analysis
Automated correlation of security events
Better prioritization through rule severity

As noted by the Cybersecurity and Infrastructure Security Agency (CISA), organizations should continuously monitor systems to rapidly detect unauthorized activity and reduce operational risk.

What You’ll Learn in This Guide

This guide walks through every major aspect of Wazuh monitoring, including:

How the Wazuh monitoring pipeline works
The core components involved in data collection
Planning a monitoring deployment
Selecting the right log sources
Monitoring Windows, Linux, Kubernetes, AWS, Apache, and firewalls
Detecting ransomware and authentication attacks
Best practices for scaling monitoring environments
Common monitoring mistakes to avoid
Performance optimization techniques
Troubleshooting monitoring issues

Throughout the guide, you’ll also find links to detailed step-by-step tutorials covering each monitoring scenario in greater depth.

Other complete guides:

Understanding Wazuh Monitoring

Wazuh monitoring is built around a continuous pipeline that collects security data, enriches it, analyzes it against detection rules, stores it for searching, and presents actionable alerts through dashboards.

Understanding each stage of this pipeline makes it much easier to design reliable monitoring environments and troubleshoot issues when they occur.

How Wazuh Monitoring Works

At a high level, the monitoring workflow follows these stages:

Data collection
Event normalization
Rule evaluation
Alert generation
Storage and visualization

Each component contributes to transforming raw system activity into actionable security intelligence.

Log Collection

Monitoring begins with collecting logs from various sources.

These may include:

Windows Event Logs
Linux syslog
Apache access logs
SSH authentication logs
Kubernetes audit logs
AWS CloudTrail
Firewall logs
Application logs
File integrity events

Wazuh agents continuously monitor configured log sources and securely transmit events to the Wazuh manager.

Agentless sources such as syslog devices and cloud APIs can also send data directly into the monitoring pipeline.

For a complete walkthrough, see the following guides:

Event Normalization

Raw logs from different systems often have completely different formats.

Wazuh uses decoders to normalize incoming events into a consistent structure regardless of their source.

Normalization makes it possible to:

Correlate events
Apply common detection rules
Search efficiently
Build dashboards
Generate standardized alerts

Without normalization, creating reliable detections across heterogeneous environments would be extremely difficult.

Rule-Based Detection

Once normalized, events are evaluated against Wazuh’s extensive rule library.

Rules can detect:

Failed logins
Privilege escalation
Malware indicators
Brute-force attacks
Suspicious PowerShell activity
File modifications
Compliance violations
Cloud security events

Organizations can also create custom rules tailored to their environment.

See our custom detection rules guide: How to Create Custom Detection Rules in Wazuh (With Examples)

Alert Generation

When a rule matches an event, Wazuh generates an alert containing:

Rule ID
Severity level
Timestamp
Host information
Source log
MITRE ATT&CK mapping (where applicable)
Event description

Alerts can trigger automated response workflows or integrate with SIEM and ticketing platforms.

Dashboard Visualization

Processed alerts are indexed and displayed in the Wazuh Dashboard.

Security analysts can:

Search logs
Filter alerts
Build dashboards
Investigate incidents
View trends
Analyze timelines
Monitor agent health

Dashboards significantly reduce investigation time by centralizing information that would otherwise be spread across multiple systems.

Core Components Involved in Monitoring

Several core services work together to provide end-to-end monitoring.

Wazuh Agents

Agents run on monitored endpoints.

Their responsibilities include:

Collecting logs
Monitoring file integrity
Executing vulnerability scans
Performing security configuration assessment
Sending events securely to the manager

Agents support Windows, Linux, macOS, and numerous Unix-based operating systems.

See our guides:

Wazuh Manager

The manager acts as the central analysis engine.

Its responsibilities include:

Receiving events
Decoding logs
Running detection rules
Correlating activity
Triggering Active Response
Forwarding alerts

It is the heart of the monitoring architecture.

Wazuh Indexer

The indexer stores processed events for fast querying.

Its distributed architecture enables:

High-performance searches
Long-term storage
Dashboard queries
Historical investigations
Cluster scalability

Larger deployments often use multiple indexer nodes.

See our guide: How to Build a Wazuh Indexer Cluster

Wazuh Dashboard

The dashboard provides the graphical interface used by analysts.

Typical activities include:

Viewing alerts
Searching logs
Building dashboards
Monitoring agents
Investigating incidents
Reviewing compliance reports

Filebeat and Data Flow

Filebeat forwards alerts from the manager to the indexer.

The simplified data flow is:

Agent → Manager → Filebeat → Indexer → Dashboard

Understanding this pipeline helps troubleshoot ingestion problems when alerts fail to appear.

Types of Monitoring Wazuh Supports

Wazuh supports a broad range of monitoring use cases beyond simple log collection.

Endpoint Monitoring

Endpoints remain one of the primary attack surfaces.

Wazuh continuously monitors:

Processes
Authentication events
System changes
Security logs
Malware indicators

Log Monitoring

Nearly every security event generates a log.

Wazuh centralizes logs from:

Operating systems
Applications
Databases
Authentication systems
Security appliances

Cloud Monitoring

Cloud-native environments produce valuable audit trails.

Supported monitoring scenarios include:

AWS CloudTrail
Cloud configuration changes
IAM events
API activity

Container Monitoring

Containers introduce unique security challenges.

Wazuh can monitor:

Kubernetes audit logs
Node activity
Container runtime events
Cluster security

Related Guide: How to Monitor Kubernetes Using Wazuh

Network Device Monitoring

Network infrastructure produces valuable telemetry.

Examples include:

Firewalls
Routers
Switches
IDS/IPS platforms
VPN gateways

Syslog integration allows Wazuh to centralize these events for correlation.

See our guides:

File Integrity Monitoring

File Integrity Monitoring (FIM) detects unauthorized changes to important files.

Typical monitored objects include:

System binaries
Configuration files
Registry entries
Website files
Critical application data

Security Configuration Assessment

Security Configuration Assessment (SCA) evaluates systems against predefined security baselines.

Examples include:

CIS Benchmarks
Password policies
Service configuration
File permissions
System hardening

Continuous SCA monitoring helps identify configuration drift before it introduces security risk.

Vulnerability Detection

Wazuh continuously correlates installed software with vulnerability databases to identify known CVEs affecting monitored systems.

This allows security teams to prioritize remediation based on actual exposure.

Planning Your Wazuh Monitoring Deployment

Successful monitoring begins long before installing software.

A well-planned deployment ensures that Wazuh collects meaningful security data, scales with organizational growth, and supports compliance and incident response objectives.

Rather than enabling every available log source, organizations should identify what needs to be monitored, why it matters, and how the resulting data will be used.

Define Monitoring Objectives

Clear objectives help determine which data sources, rules, dashboards, and alerting workflows should be implemented.

Compliance

Many organizations deploy Wazuh to satisfy regulatory requirements.

Common frameworks requiring continuous monitoring include:

PCI DSS
HIPAA
ISO 27001
NIST Cybersecurity Framework
CIS Controls

Monitoring evidence also simplifies security audits.

Threat Detection

Security teams often prioritize monitoring that detects:

Malware
Unauthorized access
Privilege escalation
Lateral movement
Data exfiltration
Ransomware

Mapping monitoring objectives to the MITRE ATT&CK framework helps ensure broad attack coverage.

Incident Response

Monitoring should provide investigators with sufficient context to rapidly understand:

What happened
When it occurred
Which systems were affected
Who initiated the activity
Whether the attack is ongoing

Operational Visibility

Wazuh monitoring also improves operational awareness by highlighting:

System failures
Service disruptions
Configuration changes
Authentication issues
Performance anomalies

Identify Critical Assets

Not every system requires the same level of monitoring.

Prioritize assets based on business impact and risk.

Servers

Critical production servers should receive the highest monitoring priority because they often host sensitive applications and data.

Workstations

Employee devices frequently represent the initial entry point for attackers through phishing, malware, or credential theft.

Cloud Resources

Cloud workloads should be monitored for:

API activity
Identity changes
Resource modifications
Security group changes
Administrative actions

Containers

Containerized environments require monitoring for:

Runtime activity
Cluster events
Pod creation
Unauthorized deployments

Firewalls

Firewalls provide valuable information about:

Blocked connections
Allowed traffic
VPN usage
Port scanning
Intrusion attempts

Applications

Business applications often generate logs that reveal:

Authentication failures
Permission issues
Administrative activity
Application errors
Suspicious user behavior

Determine Log Sources

Choosing the right log sources is one of the most important planning decisions.

Collecting excessive data increases storage costs, while insufficient logging creates blind spots.

Windows Event Logs

Windows logs provide visibility into:

User logins
PowerShell
Services
Group Policy
Security events

Linux System Logs

Linux systems generate logs covering:

SSH
sudo
systemd
kernel events
authentication

Application Logs

Applications often provide the earliest indicators of compromise through:

Failed logins
Access violations
Administrative actions
Unexpected errors

Related Guide: How to Monitor Apache Logs with Wazuh

Cloud Logs

Cloud platforms generate detailed audit logs that track API activity and administrative changes.

Firewall Logs

Firewall logs help identify:

Network scanning
Blocked traffic
Suspicious IP addresses
Connection attempts

Related guide: How to Collect Firewall Logs in Wazuh

Authentication Logs

Authentication logs are essential for detecting:

Brute-force attacks
Credential stuffing
Account misuse
Privilege escalation

Design Your Monitoring Architecture

Your architecture should align with both current requirements and future growth.

Single Server Deployment

Suitable for:

Labs
Home environments
Small businesses
Proof-of-concept deployments

Advantages include simplicity and lower infrastructure costs.

Distributed Deployment

Growing organizations often separate management, indexing, and dashboard services across multiple systems to improve scalability and resilience.

Clustered Environment

Large enterprises typically deploy clustered Wazuh managers and indexers to achieve:

High availability
Horizontal scaling
Load balancing
Improved fault tolerance
Better search performance

Related guide: How to Build a Wazuh Indexer Cluster

Configuring Wazuh Monitoring

After planning your monitoring architecture, the next step is configuring Wazuh to collect, analyze, and alert on security events.

A properly configured monitoring environment ensures that important events are captured without overwhelming analysts with unnecessary data.

The goal is to collect meaningful security telemetry, apply the appropriate detection rules, and validate that events flow correctly from monitored systems into the Wazuh Dashboard.

Installing and Registering Agents

Wazuh agents are responsible for collecting logs and security information from monitored endpoints.

Before any monitoring can occur, each endpoint must be enrolled with the Wazuh manager.

The typical deployment process involves:

Installing the Wazuh agent
Registering it with the manager
Verifying secure communication
Confirming the agent appears as active
Testing basic event collection

For larger environments, organizations often automate deployment using configuration management tools such as Ansible, Puppet, or Microsoft Group Policy.

See our guides:

Configuring Log Collection

Once agents are connected, configure the log sources that should be monitored.

Typical log sources include:

Windows Event Logs
Linux syslog
Apache logs
Authentication logs
Audit logs
Application logs
Firewall syslog
Cloud audit logs

Avoid collecting every available log by default.

Excessive logging increases storage requirements and may generate unnecessary alerts.

Instead, focus on security-relevant events aligned with your monitoring objectives.

Enabling Real-Time Monitoring

Real-time monitoring allows Wazuh to analyze security events immediately after they occur.

Common real-time monitoring features include:

File Integrity Monitoring (FIM)
Authentication monitoring
Log monitoring
Process monitoring
Cloud event monitoring
Kubernetes audit monitoring

Immediate event processing enables security teams to respond quickly to suspicious behavior rather than waiting for scheduled scans.

Creating Custom Monitoring Rules

Although Wazuh includes thousands of built-in detection rules, every environment has unique monitoring requirements.

Custom rules can detect organization-specific events such as:

Internal application errors
Proprietary software logs
Custom authentication events
Business-critical file changes
Industry-specific compliance violations

When writing custom rules:

Reuse existing decoders whenever possible.
Assign appropriate severity levels.
Avoid duplicate rule logic.
Test rules thoroughly before deploying them into production.
Document custom rule behavior for future maintenance.

See our guides:

Configuring Alert Levels

Not every event deserves the same response.

Wazuh assigns severity levels to alerts based on the associated rule. Proper tuning helps analysts focus on the most important incidents.

A practical severity strategy might include:

Low severity: Informational events and expected administrative activity
Medium severity: Suspicious behavior requiring investigation
High severity: Confirmed attacks, malware, privilege escalation, or policy violations
Critical severity: Active compromise requiring immediate response

Alert tuning should be reviewed regularly to reduce false positives while ensuring high-risk events are never ignored.

Related Guide: How to Reduce False Positives in Wazuh

Verifying Data Collection

After configuration, verify that events successfully travel through the entire monitoring pipeline.

A validation checklist includes:

Confirming agents are connected
Generating test security events
Verifying alerts appear in the Dashboard
Checking manager logs for processing errors
Reviewing Filebeat status
Ensuring events are indexed correctly
Confirming timestamps and hostnames are accurate

Routine validation helps identify configuration issues before they create monitoring blind spots.

See our guides:

Common Monitoring Use Cases

One of Wazuh’s greatest strengths is its flexibility.

Rather than focusing on a single security domain, Wazuh can monitor endpoints, cloud infrastructure, web servers, authentication systems, firewalls, and containers from a centralized platform.

The following use cases represent some of the most common deployments found in production environments.

Monitoring Windows Event Logs

Windows Event Logs contain some of the most valuable forensic information available during incident investigations.

They provide visibility into authentication activity, privilege changes, system events, malware detection, and administrative actions.

Organizations running Windows desktops or servers should prioritize monitoring these logs.

What Events Should You Monitor?

Not every Windows log needs equal attention.

Prioritize security-relevant event categories.

Security Events

Monitor events related to:

Successful logins
Failed logins
Account lockouts
Group membership changes
Privilege assignments
User creation and deletion

System Events

System logs reveal:

Service failures
Driver problems
Unexpected shutdowns
System restarts
Critical operating system errors

PowerShell Logs

PowerShell logging helps detect:

Malicious scripts
Encoded commands
Remote execution
Offensive security frameworks
Persistence mechanisms

Defender Events

Microsoft Defender logs provide insight into:

Malware detection
Quarantined files
Threat remediation
Antivirus configuration changes

RDP Activity

Remote Desktop logs can identify:

Unauthorized access attempts
Successful remote logins
Brute-force attacks
Unusual login locations
Administrative sessions

Monitoring AWS CloudTrail Logs

CloudTrail records nearly every API action performed within AWS, making it one of the most valuable monitoring sources for cloud security.

Continuous monitoring helps detect unauthorized administrative activity before attackers gain persistence.

Key Cloud Events

IAM Changes

Monitor events involving:

User creation
Role modifications
Policy changes
Permission escalation
Credential updates

Root Account Usage

Root account activity should be extremely rare.

Unexpected usage may indicate:

Credential compromise
Emergency administrative access
Insider activity

AWS itself recommends minimizing root account usage except when absolutely necessary.

Security Group Changes

Unexpected firewall rule modifications may expose cloud resources to the public Internet.

Monitor for:

New inbound rules
Open management ports
Removed restrictions
Security group deletions

Console Logins

Watch for:

Failed login attempts
Logins without MFA
Unusual login locations
Newly created sessions

API Calls

API monitoring can identify:

Infrastructure changes
Resource creation
Instance termination
Storage access
Identity modifications

Monitoring Kubernetes Clusters

Kubernetes environments generate enormous amounts of operational and security data.

Monitoring these events helps detect unauthorized deployments, privilege abuse, and configuration drift.

See the following guide: How to Monitor Kubernetes Using Wazuh

Kubernetes Monitoring Areas

API Server Events

API server logs reveal:

Administrative actions
Cluster configuration changes
Authentication attempts
Authorization failures

Audit Logs

Audit logs provide a complete history of cluster activity, making them invaluable during investigations.

Container Runtime Logs

Monitor runtime logs for:

Container crashes
Unexpected execution
Privilege escalation
Image changes

Pod Activity

Track:

Pod creation
Pod deletion
Namespace changes
Scaling events
Resource anomalies

Cluster Security

Monitor security controls including:

RBAC changes
Admission controller events
Secrets access
Network policy modifications

The Kubernetes Security Best Practices documentation recommends enabling audit logging as a foundational security control.

Monitoring Apache Web Server Logs

Apache access and error logs provide valuable insight into reconnaissance activity and web application attacks.

Continuous monitoring enables early detection of malicious traffic before exploitation succeeds.

See the following guide: How to Monitor Apache Logs with Wazuh

Detecting Web Threats

Brute Force Attempts

Watch for repeated authentication failures against:

Admin portals
Login pages
APIs

Directory Traversal

Monitor requests attempting to access:

../ sequences
Sensitive files
Configuration directories

SQL Injection Indicators

Common indicators include:

UNION SELECT
OR 1=1
SQL keywords in URLs
Suspicious POST requests

HTTP Errors

Repeated 403, 404, and 500 responses may indicate reconnaissance or exploitation attempts.

Suspicious Requests

Look for:

Automated scanners
Known exploit paths
Encoded payloads
Abnormal user agents
Large request volumes

Monitoring Failed SSH Login Attempts

SSH remains one of the most frequently targeted services on Internet-facing Linux systems.

Monitoring failed authentication attempts helps identify brute-force attacks before credentials are compromised.

See the following guide: How to Monitor Failed SSH Login Attempts Using Wazuh

Detecting Authentication Attacks

Password Spraying

Password spraying targets many accounts using a small number of common passwords.

Indicators include:

One password
Many usernames
Low failure rate per account

Brute Force

Traditional brute-force attacks generate:

Numerous failures
Rapid connection attempts
Repeated retries from identical IP addresses

Repeated Failed Logins

Investigate users experiencing persistent authentication failures, particularly when failures occur outside normal working hours.

Unauthorized Access Attempts

Monitor for:

Invalid usernames
Disabled accounts
Unknown IP addresses
Geographic anomalies

Monitoring Firewall Logs

Firewalls often provide the earliest evidence of reconnaissance and attempted compromise.

Centralizing firewall logs enables correlation with endpoint and application events.

See the following guide: How to Collect Firewall Logs in Wazuh

Supported Firewall Sources

Wazuh supports log collection from numerous firewall platforms.

pfSense

Monitor:

Blocked traffic
NAT changes
VPN activity
Rule matches

Fortinet

Collect:

Threat prevention logs
IPS events
Antivirus detections
Traffic analysis

Cisco

Monitor:

ACL violations
VPN events
Connection attempts
Administrative changes

Palo Alto

Collect:

Threat logs
URL filtering
WildFire detections
User-ID events

Sophos

Monitor:

Firewall events
Web filtering
IPS detections
Malware prevention

Linux Firewalls

Collect logs from:

iptables
nftables
UFW
firewalld

Detecting Ransomware Activity

Modern ransomware attacks typically generate numerous behavioral indicators long before encryption completes.

Monitoring these indicators enables earlier detection and response.

See the following guide: How to Detect Ransomware Activity Using Wazuh

Behavioral Indicators

Rapid File Changes

Sudden modification of thousands of files is one of the strongest ransomware indicators.

Suspicious Process Activity

Watch for:

Unknown executables
Script interpreters
Living-off-the-land binaries
Unexpected child processes

Privilege Escalation

Many ransomware families attempt to obtain elevated privileges before deployment.

Shadow Copy Deletion

Deletion of Windows Volume Shadow Copies is commonly used to prevent recovery.

Commands such as vssadmin delete shadows should generate immediate alerts.

Mass Encryption Events

Indicators include:

Rapid file renaming
Extension changes
High disk activity
Simultaneous file modifications across directories

The joint CISA ransomware guidance recommends monitoring these behaviors as part of a layered detection strategy.

Monitoring Dashboards and Visualization

Collecting security data is only half of the monitoring process.

Security analysts must also be able to search, visualize, prioritize, and investigate events efficiently.

The Wazuh Dashboard transforms raw alerts into actionable intelligence through interactive dashboards, filters, saved searches, and visualizations.

Using the Wazuh Dashboard

The Dashboard serves as the primary interface for monitoring security events.

Common analyst activities include:

Reviewing alerts
Investigating incidents
Searching historical logs
Monitoring agent status
Viewing compliance reports
Examining MITRE ATT&CK mappings

Creating Custom Dashboards

Custom dashboards allow teams to monitor the metrics most relevant to their environment.

Popular dashboard widgets include:

Alert volume by severity
Top affected hosts
Authentication failures
Malware detections
Cloud activity
Firewall events
Kubernetes alerts

Filtering Alerts

Filtering helps analysts quickly isolate relevant security events.

Common filters include:

Severity
Agent
Rule ID
Hostname
Username
Time range
MITRE technique
Event category

Well-designed filters significantly reduce investigation time.

Building Saved Searches

Saved searches provide quick access to frequently used investigations.

Examples include:

Failed SSH logins
Windows authentication events
CloudTrail administrative actions
Apache attack attempts
Firewall blocks
High-severity alerts

These searches are particularly valuable for SOC analysts who perform repetitive investigations.

Monitoring Trends Over Time

Historical visualization helps identify patterns that individual alerts may not reveal.

Useful trend analyses include:

Daily alert volume
Failed authentication trends
Malware detections
Agent connectivity
Compliance violations
Cloud activity
Firewall traffic

Long-term trends can also reveal slow-moving attacks and recurring operational issues.

Prioritizing Critical Alerts

Not all alerts require immediate action.

A mature monitoring strategy prioritizes alerts based on:

Business impact
Asset criticality
Threat severity
Attack progression
Confidence level
Compliance implications

Combining severity scoring with contextual information allows security teams to focus on incidents that pose the greatest organizational risk while minimizing alert fatigue.

Alert Management

Effective monitoring doesn’t end when Wazuh generates an alert.

Security teams must be able to prioritize, investigate, and respond to alerts quickly while minimizing unnecessary noise.

A well-designed alert management strategy improves detection accuracy, reduces analyst fatigue, and shortens incident response times.

The following best practices will help you build an efficient alert management workflow.

Understanding Alert Severity Levels

Each Wazuh rule is assigned a severity level that indicates the importance of the detected event.

Higher severity alerts generally require faster investigation and response.

Although organizations may customize their own severity model, alerts are commonly categorized as:

Severity	Typical Meaning	Example Events
Informational	Expected system activity	Successful service startup
Low	Minor security events	Normal administrative actions
Medium	Suspicious activity	Multiple failed logins
High	Likely malicious behavior	Privilege escalation attempts
Critical	Active security incident	Ransomware indicators or malware execution

Severity should never be considered in isolation.

Analysts should also evaluate:

Asset criticality
User context
Attack history
Threat intelligence
MITRE ATT&CK mappings
Related alerts occurring around the same time

A medium-severity alert on a domain controller may require more immediate attention than a high-severity alert on a non-production test system.

Reducing False Positives

False positives consume valuable analyst time and increase the likelihood that genuine threats will be overlooked.

Common causes include:

Overly broad detection rules
Legitimate administrative activity
Frequent software updates
Backup operations
Scheduled automation jobs
Misconfigured decoders

To reduce unnecessary alerts:

Tune rule thresholds
Exclude trusted processes where appropriate
Suppress known benign events
Use whitelists carefully
Review alert trends regularly
Validate new rules before production deployment

Rather than disabling noisy rules entirely, adjust them so they continue detecting genuinely suspicious behavior while ignoring expected activity.

Related Guides:

Creating Custom Alert Rules

Every organization has unique infrastructure, applications, and security requirements.

Custom rules allow Wazuh to detect activity specific to your environment.

Examples include:

Monitoring proprietary application logs
Detecting unauthorized configuration changes
Tracking privileged administrative actions
Alerting on business-critical file modifications
Identifying unauthorized software execution

When designing custom rules:

Build on existing decoders whenever possible.
Assign meaningful severity levels.
Include descriptive rule names.
Test using realistic log samples.
Keep documentation for future maintenance.
Periodically review rule effectiveness.

Organizations that regularly refine custom rules typically achieve higher detection accuracy while reducing alert fatigue.

Related Guides

Configuring Notifications

Critical alerts should reach responders as quickly as possible.

Wazuh supports multiple notification mechanisms, allowing organizations to integrate alerts into existing workflows.

Common notification methods include:

Email
Slack
Microsoft Teams
Webhooks
Security orchestration platforms
SIEM integrations

Consider sending notifications based on severity rather than alerting on every event.

For example:

Critical alerts → Immediate notification
High severity → SOC notification
Medium severity → Queue for analyst review
Low severity → Dashboard only

This approach significantly reduces unnecessary interruptions while ensuring high-priority incidents receive immediate attention.

Related Guides

Integrating with SIEM and Ticketing Systems

Many organizations use Wazuh as part of a broader security ecosystem.

Alerts can be forwarded to SIEM, SOAR, and ticketing platforms for centralized investigation and automated response.

Common integrations include:

OpenSearch
Splunk
Microsoft Sentinel
ServiceNow
Jira
TheHive
Shuffle

Integration enables:

Centralized alert management
Automated ticket creation
Threat correlation
Incident tracking
Compliance reporting
Long-term analytics

For enterprise environments, integrating Wazuh with existing security tooling often produces a more efficient Security Operations Center (SOC).

Performance Optimization

As monitoring environments grow, performance optimization becomes increasingly important.

Collecting excessive logs, monitoring unnecessary systems, or using inefficient configurations can increase storage costs, consume CPU resources, and overwhelm analysts.

The goal is to maximize security visibility while minimizing operational overhead.

Monitor Only What Matters

Collecting every available log may seem like the safest option, but it often creates more problems than it solves.

Instead, prioritize monitoring based on:

Critical business systems
Sensitive data repositories
Internet-facing services
Authentication infrastructure
Administrative activity
High-risk applications

Risk-based monitoring provides better visibility while reducing unnecessary resource consumption.

Reduce Log Noise

Large volumes of low-value logs make it more difficult to identify genuine threats.

Reduce unnecessary logging by:

Disabling irrelevant log sources
Filtering repetitive events
Suppressing expected administrative actions
Excluding trusted maintenance tasks
Reviewing noisy rules regularly

Reducing log noise not only improves analyst efficiency but also decreases indexing and storage requirements.

Related Guide: How to Reduce False Positives in Wazuh

Configure Log Rotation

Log files should be rotated and retained according to operational and compliance requirements.

Proper log rotation helps:

Prevent disk exhaustion
Improve indexing performance
Simplify backup operations
Meet retention requirements
Reduce maintenance complexity

Retention policies should balance storage costs with investigative and regulatory needs.

Related Guide: How to Configure Wazuh Log Retention

Optimize Agent Performance

Poorly configured agents can consume unnecessary CPU, memory, and network bandwidth.

Optimization strategies include:

Monitor only required directories
Exclude temporary files
Tune File Integrity Monitoring frequency
Reduce excessive log collection
Schedule resource-intensive scans appropriately
Keep agents updated

Regularly reviewing agent performance ensures endpoints remain secure without affecting user productivity.

Related Guides

Scale Monitoring Across Large Environments

As infrastructure grows, monitoring architecture must scale accordingly.

Recommended practices include:

Deploy multiple Wazuh managers where appropriate
Build indexer clusters for high availability
Separate indexing from management services
Use load balancing for larger deployments
Monitor storage utilization
Continuously review cluster health

Scaling incrementally helps maintain consistent performance while supporting future growth.

The OpenSearch documentation recommends distributing indexing workloads across multiple nodes to improve resilience and search performance in large deployments.

Related Guides:

Security Best Practices

Implementing Wazuh is only the first step.

Maintaining an effective monitoring environment requires continuous tuning, validation, and improvement.

The following best practices help maximize detection capabilities while keeping monitoring manageable over time.

Monitor High-Value Systems First

Organizations rarely have unlimited monitoring resources.

Begin with systems that present the highest business risk, including:

Domain controllers
Production servers
Database servers
Cloud management accounts
Internet-facing applications
VPN gateways
Administrative workstations

Expanding monitoring gradually ensures the most important assets receive protection first.

Enable File Integrity Monitoring

Unauthorized changes to critical files are often among the earliest indicators of compromise.

File Integrity Monitoring should be enabled for:

Operating system files
Security configurations
Web application directories
Registry keys
Configuration files
Executables

Review monitored directories periodically to ensure they continue reflecting business priorities.

Continuously Review Alert Rules

Threats evolve constantly, and monitoring rules should evolve with them.

Review your rule set regularly to:

Remove obsolete rules
Improve detection accuracy
Reduce false positives
Add coverage for emerging attack techniques
Reflect infrastructure changes

Quarterly rule reviews are a practical starting point for most organizations.

Keep Wazuh Updated

Security platforms should be updated regularly to receive:

Security patches
New detection rules
Performance improvements
Bug fixes
Compatibility updates

Before upgrading production environments:

Test upgrades in staging
Back up configurations
Review release notes
Verify agent compatibility
Validate monitoring after deployment

Test Detection Rules Regularly

Detection rules should never be assumed to work indefinitely.

Routine validation helps ensure monitoring remains effective after software upgrades, configuration changes, or infrastructure expansion.

Testing should include:

Authentication attacks
Malware simulations
File modifications
Privilege escalation
Cloud events
Web attacks

Frameworks such as the MITRE ATT&CK Evaluations and controlled adversary emulation exercises can help assess detection coverage against real-world attack techniques.

Use Custom Rules for Your Environment

Built-in rules provide an excellent foundation, but they cannot account for every organization’s infrastructure or business logic.

Custom rules allow you to detect events unique to your environment, such as:

Internal application behavior
Organization-specific compliance requirements
Custom authentication workflows
Proprietary software logs
Business-critical processes

Review custom rules periodically to ensure they remain accurate as applications and infrastructure evolve.

A combination of well-maintained built-in rules and carefully designed custom rules typically provides the best balance between broad threat coverage and operational efficiency.

Troubleshooting Wazuh Monitoring

Even a well-designed monitoring deployment can experience issues that reduce visibility into your environment.

Missing logs, disconnected agents, dashboard problems, or excessive false positives can all create security blind spots if left unresolved.

Fortunately, most monitoring issues follow predictable patterns. By troubleshooting the monitoring pipeline, from the endpoint to the dashboard, you can usually identify the root cause quickly.

No Events Are Appearing

If no alerts or logs are appearing in the Wazuh Dashboard, begin by validating each stage of the data pipeline.

Check the following:

Verify the Wazuh agent is connected.
Confirm the Wazuh manager is running.
Ensure Filebeat is forwarding alerts.
Verify the Wazuh Indexer is healthy.
Confirm indices are being created.
Review manager and Filebeat logs for errors.
Check dashboard connectivity.

Remember that a healthy agent does not necessarily mean logs are being collected successfully.

Agent Is Connected but Sending No Logs

A connected agent that produces no events usually indicates a configuration issue rather than a connectivity problem.

Common causes include:

Incorrect ossec.conf configuration
Disabled log collection modules
Invalid log file paths
Permission issues
XML syntax errors
Unsupported log formats

Generate a known event (such as a failed login) and verify whether it reaches the manager.

Related Guides:

Missing Windows Events

If Windows logs are incomplete or entirely absent:

Verify Windows Event Log service is running.
Confirm the correct event channels are configured.
Check agent permissions.
Generate test security events.
Review agent logs for parsing errors.

Security, PowerShell, Defender, and Sysmon logs should all be validated independently.

Missing Cloud Logs

Missing cloud events often result from configuration or permission problems.

Review:

AWS IAM permissions
CloudTrail configuration
API credentials
Network connectivity
Collection intervals
Integration configuration

Ensure CloudTrail itself is generating the events you expect before troubleshooting Wazuh.

See the following guide: How to Monitor AWS CloudTrail Logs Using Wazuh

Missing Firewall Events

If firewall logs never appear:

Verify syslog forwarding.
Confirm the correct destination IP and port.
Check firewall logging policies.
Validate Wazuh syslog configuration.
Test network connectivity between devices.

Firewall logs are frequently blocked by incorrect network routing or disabled logging policies rather than Wazuh itself.

Related Guides:

Excessive False Positives

Too many alerts reduce analyst productivity and increase alert fatigue.

Common remediation steps include:

Tune noisy rules.
Adjust alert thresholds.
Exclude trusted administrative activity.
Create allowlists where appropriate.
Build environment-specific custom rules.
Review recurring alerts monthly.

Aim to reduce noise without sacrificing detection coverage.

High Resource Usage

Monitoring can become resource-intensive if agents collect unnecessary data or perform excessive scanning.

Investigate:

CPU utilization
Memory usage
File Integrity Monitoring scope
Log collection frequency
Large monitored directories
Indexing performance

Gradually optimize configurations while ensuring important security events remain visible.

Related Guide:

Dashboard Not Updating

If alerts stop appearing in the Dashboard while agents continue sending logs:

Check:

Indexer health
Filebeat status
Dashboard service
Index creation
Cluster status
Available disk space

Many dashboard issues originate in the indexing layer rather than the user interface itself.

Related Guides:

Wazuh Monitoring Workflow

Successful monitoring is an ongoing process rather than a one-time deployment.

The following workflow provides a structured approach for implementing, maintaining, and continuously improving a Wazuh monitoring environment.

Identify Assets

Begin by identifying the systems that require monitoring.

Prioritize assets such as:

Domain controllers
Production servers
Cloud infrastructure
Kubernetes clusters
Firewalls
Business-critical applications
Administrative workstations

Classifying assets by business importance allows monitoring resources to be allocated effectively.

Deploy Agents

Install and register Wazuh agents on supported systems.

Verify that:

Agents connect successfully
Communication is encrypted
Agent versions are current
Host information appears correctly in the Dashboard

Automated deployment tools can simplify large-scale rollouts.

Configure Log Sources

Enable collection for the logs most relevant to your security objectives.

Typical sources include:

Windows Event Logs
Linux authentication logs
Apache logs
Firewall logs
CloudTrail
Kubernetes audit logs
Application logs

Avoid enabling unnecessary log sources that generate little security value.

Validate Data Collection

After deployment, verify that events successfully flow through every stage of the monitoring pipeline.

Validation should include:

Agent connectivity
Test events
Alert generation
Dashboard visibility
Index creation
Timestamp accuracy

Routine validation helps identify problems before they become operational issues.

Tune Detection Rules

No monitoring environment is perfect immediately after deployment.

Continuously refine:

Alert thresholds
Rule severity
Custom rules
Whitelists
Event exclusions

Rule tuning reduces noise while improving detection quality.

Monitor Dashboards

Dashboards provide ongoing visibility into security posture.

Review them regularly for:

High-severity alerts
Authentication failures
Malware detections
Cloud activity
Compliance violations
Agent health

Scheduled dashboard reviews help identify trends that individual alerts may not reveal.

Investigate Alerts

Respond to alerts according to organizational procedures.

During investigations:

Review related events
Examine affected hosts
Validate indicators
Determine attack scope
Document findings
Initiate containment if necessary

Consistent investigation procedures improve response quality and reduce incident resolution times.

Continuously Improve Detection

Threat landscapes evolve continuously, so monitoring should evolve as well.

Establish a regular review cycle to:

Update Wazuh
Add new detection rules
Remove obsolete rules
Test monitoring coverage
Review false positives
Incorporate lessons learned from incidents

Organizations that continually refine detection capabilities are better positioned to identify emerging threats before they cause significant damage.

Wazuh Monitoring Checklist

Use the following checklist before considering your Wazuh monitoring deployment production-ready.

☐ Monitoring objectives defined
☐ Critical assets identified
☐ Agents deployed
☐ Log collection verified
☐ Windows events monitored
☐ Cloud logs collected
☐ Kubernetes monitored
☐ Apache logs ingested
☐ Firewall logs centralized
☐ SSH monitoring enabled
☐ Ransomware detection tested
☐ Alert thresholds tuned
☐ Dashboards configured
☐ False positives minimized
☐ Monitoring documentation updated

Completing this checklist helps ensure your deployment provides comprehensive visibility across endpoints, servers, cloud infrastructure, containers, applications, and network devices while maintaining high detection accuracy and operational efficiency.

Related Resources:

Frequently Asked Questions (FAQ)

This section addresses common questions about Wazuh monitoring, its capabilities, and how it fits into modern security architectures.

Question: What is Wazuh monitoring?

Wazuh monitoring is the continuous collection, analysis, and correlation of security events across endpoints, servers, cloud environments, applications, and network infrastructure using the Wazuh platform.

It transforms raw logs into actionable security insights by applying detection rules, behavioral analysis, and threat intelligence to identify suspicious or malicious activity in real time.

Question: What can Wazuh monitor?

Wazuh can monitor a wide range of systems and data sources, including:

Operating systems (Windows, Linux, macOS)
Cloud platforms (AWS, Azure, GCP)
Containers and Kubernetes clusters
Web servers and applications
Firewalls and network devices
Authentication systems
Security configurations
File integrity changes
Vulnerability exposure

This broad coverage allows organizations to centralize security visibility across hybrid and multi-cloud environments.

Question: Can Wazuh monitor Windows, Linux, and macOS?

Yes. Wazuh agents support all major operating systems:

Windows: Event Logs, PowerShell, Defender, RDP activity
Linux: syslog, SSH authentication, sudo activity, system logs
macOS: system logs, authentication events, process activity, file changes

This cross-platform support is one of the primary reasons Wazuh is widely used in heterogeneous environments.

Question: Does Wazuh support cloud monitoring?

Yes. Wazuh supports cloud monitoring through integration with cloud-native logging and audit services such as:

AWS CloudTrail
Azure activity logs
Google Cloud audit logs

These integrations enable monitoring of API calls, identity changes, infrastructure modifications, and administrative activity across cloud environments.

Question: Can Wazuh monitor Kubernetes clusters?

Yes. Wazuh can monitor Kubernetes environments by collecting:

API server logs
Audit logs
Container runtime events
Pod activity
Cluster configuration changes

This provides visibility into cluster security, workload behavior, and administrative actions.

Question: How does Wazuh detect ransomware?

Wazuh detects ransomware by identifying behavioral indicators rather than relying on a single signature.

Common detection signals include:

Rapid file modifications across directories
Suspicious process execution
Privilege escalation attempts
Shadow copy deletion
Mass encryption or renaming activity

By correlating these behaviors, Wazuh can identify ransomware activity early in the attack lifecycle.

Question: How does Wazuh collect firewall logs?

Wazuh collects firewall logs primarily through syslog forwarding or agent-based log collection.

Supported sources include:

pfSense
Fortinet
Cisco devices
Palo Alto firewalls
Sophos
Linux-based firewalls (iptables, nftables, UFW)

Logs are parsed, normalized, and analyzed using detection rules to identify suspicious network activity.

Related Guide: How to Collect Firewall Logs in Wazuh

Can Wazuh monitor application logs?

Yes. Wazuh can monitor application logs from web servers, databases, and custom applications.

Common use cases include:

Web attack detection (SQL injection, brute force attempts)
Application error monitoring
Authentication tracking
API activity monitoring
Custom business logic events

For example, Apache logs are commonly monitored to detect web-based attacks and reconnaissance activity.

See our How to Monitor Apache Logs with Wazuh guide.

How do I reduce false positive alerts?

False positives can be reduced through careful tuning of detection rules and log sources.

Key strategies include:

Adjusting rule thresholds
Suppressing known benign activity
Creating custom rules for your environment
Excluding trusted processes or users
Reviewing recurring alerts regularly
Avoiding over-collection of unnecessary logs

Proper tuning improves analyst efficiency while preserving detection accuracy.

Related Guide: How to Reduce False Positives in Wazuh

Is Wazuh suitable for enterprise security monitoring?

Yes. Wazuh is widely used in enterprise environments due to its scalability, flexibility, and extensive monitoring capabilities.

It supports:

Distributed and clustered deployments
Large-scale agent management
Centralized log aggregation
Compliance reporting
Integration with SIEM and SOAR platforms

When properly architected, Wazuh can support enterprise-grade Security Operations Centers (SOCs) across hybrid and multi-cloud infrastructures.

Conclusion

Wazuh monitoring provides a comprehensive foundation for detecting, analyzing, and responding to security events across modern IT environments.

By centralizing logs and applying real-time detection rules, organizations gain visibility into threats that would otherwise remain hidden across fragmented systems.

Key Takeaways

Wazuh enables centralized monitoring across endpoints, cloud, containers, and network infrastructure.
Effective monitoring depends on proper log collection, rule tuning, and alert management.
Behavioral detection is essential for identifying advanced threats like ransomware.
Performance and scalability must be considered in larger environments.
Continuous improvement is required to maintain detection accuracy over time.

A well-designed Wazuh deployment evolves alongside your infrastructure and threat landscape, ensuring long-term visibility and security effectiveness.

When to Expand Your Monitoring Coverage

You should expand your monitoring scope when:

New infrastructure is deployed (cloud, containers, applications)
Traffic volume or user base increases significantly
Compliance requirements expand
New threat vectors emerge
Existing monitoring gaps are identified during investigations

Expansion should be incremental, prioritizing high-value assets first to maintain operational stability.

Related Monitoring Guides

For step-by-step implementation details, refer to the following cluster guides:

These guides provide practical configuration steps to implement the monitoring strategies described in this pillar page.

Related Guides:

The Complete Wazuh Monitoring Guide

What You’ll Learn in This Guide

Understanding Wazuh Monitoring

How Wazuh Monitoring Works

Log Collection

Event Normalization

Rule-Based Detection

Alert Generation

Dashboard Visualization

Core Components Involved in Monitoring

Wazuh Agents

Wazuh Manager

Wazuh Indexer

Wazuh Dashboard

Filebeat and Data Flow

Types of Monitoring Wazuh Supports

Endpoint Monitoring

Log Monitoring

Cloud Monitoring

Container Monitoring

Network Device Monitoring

File Integrity Monitoring

Security Configuration Assessment

Vulnerability Detection

Planning Your Wazuh Monitoring Deployment

Define Monitoring Objectives

Compliance

Threat Detection

Incident Response

Operational Visibility

Identify Critical Assets

Servers

Workstations

Cloud Resources

Containers

Firewalls

Applications

Determine Log Sources

Windows Event Logs

Linux System Logs

Application Logs

Cloud Logs

Firewall Logs

Authentication Logs

Design Your Monitoring Architecture

Single Server Deployment

Distributed Deployment

Clustered Environment

Configuring Wazuh Monitoring

Installing and Registering Agents

Configuring Log Collection

Enabling Real-Time Monitoring

Creating Custom Monitoring Rules

Configuring Alert Levels

Verifying Data Collection

Common Monitoring Use Cases

Monitoring Windows Event Logs

What Events Should You Monitor?

Security Events

System Events

PowerShell Logs

Defender Events

RDP Activity

Monitoring AWS CloudTrail Logs

Key Cloud Events

IAM Changes

Root Account Usage

Security Group Changes

Console Logins

API Calls

Monitoring Kubernetes Clusters

Kubernetes Monitoring Areas

API Server Events

Audit Logs

Container Runtime Logs

Pod Activity

Cluster Security

Monitoring Apache Web Server Logs

Detecting Web Threats

Brute Force Attempts