Modern security environments generate thousands, or even millions, of log events every day. Without an effective alerting system, security teams can easily miss indicators of compromise, policy violations, or operational failures buried within that data. This is where Wazuh alerts become essential.
Rather than requiring administrators to manually review every log entry, Wazuh automatically analyzes incoming events, applies detection rules, and generates actionable alerts whenever suspicious or noteworthy activity is detected.
Whether you’re monitoring authentication failures, malware activity, file integrity changes, privilege escalation attempts, cloud infrastructure, or endpoint security events, properly configured Wazuh alerts enable security teams to respond faster and reduce the time attackers remain undetected.
Wazuh’s rule engine is highly customizable, allowing organizations to tune alert severity, eliminate false positives, and integrate alerts with external notification and incident response platforms.
In this guide, you’ll learn how Wazuh alerts work, how they’re generated, how to configure them effectively, and the best practices for optimizing alert quality while minimizing alert fatigue.
You’ll also learn how alerts flow through the entire Wazuh architecture, from log collection to dashboard visualization and external integrations.
Expert insight: The SANS Institute consistently emphasizes that effective security monitoring depends not on collecting more data, but on generating high-fidelity alerts that analysts can investigate quickly. Excessive low-value alerts contribute directly to alert fatigue and missed incidents.
What Are Wazuh Alerts?
Wazuh alerts are structured security events produced after the Wazuh Manager analyzes incoming logs against its decoders and detection rules.
Rather than simply storing raw logs, Wazuh transforms them into meaningful security findings that describe what occurred, where it happened, how severe it is, and why administrators should care.
Alerts form the foundation of Wazuh’s detection capabilities.
Every dashboard visualization, security report, active response action, and external notification begins with a generated alert.
Definition of Wazuh Alerts
A Wazuh alert is a processed event that matches one or more detection rules within the Wazuh Manager.
Each alert contains rich metadata that helps analysts understand the event, including:
- Rule ID
- Severity level
- Rule description
- Timestamp
- Agent information
- Source IP address
- Username
- File paths
- Process names
- MITRE ATT&CK mappings (when available)
- Compliance mappings (PCI DSS, HIPAA, NIST, GDPR, etc.)
Unlike raw log entries, alerts are normalized into a consistent format that makes searching, filtering, correlation, and automated response much easier.
How Alerts Are Generated Within the Wazuh Architecture
Every alert follows a processing pipeline before appearing in the dashboard.
- A monitored endpoint generates a log.
- The Wazuh Agent (or another log source) forwards the event to the Wazuh Manager.
- The manager selects the appropriate decoder.
- The decoder extracts useful fields from the raw log.
- Detection rules evaluate the parsed data.
- Matching rules generate an alert.
- The alert is indexed into the Wazuh Indexer.
- The Wazuh Dashboard displays the alert for analysts.
Because this pipeline separates log parsing from rule evaluation, administrators can support virtually any log format while building highly customized detections.
Relationship Between Agents, Manager, Rules, Decoders, and Alerts
Several Wazuh components work together before an alert is generated.
- Wazuh Agent collects logs, system information, file integrity events, vulnerability data, and security telemetry.
- Wazuh Manager receives and processes incoming events.
- Decoders identify log formats and extract structured fields.
- Rules analyze decoded fields to determine whether security conditions are met.
- Alerts are produced whenever a rule matches the event.
Understanding this relationship is essential because alert quality depends heavily on properly written decoders and well-designed detection rules.
For deeper coverage of rule creation, see How to Create Custom Detection Rules in Wazuh.
For decoder customization, see Wazuh Decoder Guide.
Types of Security Events That Generate Alerts
Almost any security-related event can generate a Wazuh alert, including:
- Failed SSH logins
- Windows authentication failures
- Privilege escalation attempts
- Malware detections
- File Integrity Monitoring (FIM) changes
- Unauthorized configuration modifications
- Brute force attacks
- Suspicious PowerShell execution
- Cloud infrastructure events
- Docker and Kubernetes activity
- Vulnerability detections
- Compliance violations
- Firewall events
- IDS/IPS detections from Suricata
- Threat intelligence matches from VirusTotal
Because Wazuh supports hundreds of built-in rulesets and custom rule development, organizations can tailor alerting to their own security requirements.
Relevant guides include:
- How to Monitor Failed SSH Login Attempts Using Wazuh
- How to Configure File Integrity Monitoring (FIM) in Wazuh
- How to Integrate Wazuh with Suricata for Better Threat Detection
- How to Integrate Wazuh with VirusTotal for Threat Intelligence
Benefits of Properly Configured Alerts
Well-designed alerts provide significantly more value than simply generating large volumes of notifications.
Benefits include:
- Faster incident detection
- Reduced attacker dwell time
- Improved SOC efficiency
- Lower false positive rates
- Better compliance reporting
- Automated incident response
- Improved visibility across endpoints and cloud environments
- Easier forensic investigations
According to IBM’s Cost of a Data Breach Report, organizations that identify and contain incidents more quickly experience substantially lower breach costs, highlighting the importance of effective alerting and rapid detection.
How Wazuh Alerting Works
Understanding the alert lifecycle makes troubleshooting and customization much easier.
Every alert passes through several processing stages before reaching analysts.
Event Collection from Monitored Endpoints
Everything begins with data collection.
The Wazuh Agent continuously monitors configured data sources such as:
- Operating system logs
- Windows Event Logs
- Linux syslog
- File Integrity Monitoring
- Auditd
- Sysmon
- Containers
- Kubernetes
- Cloud platforms
- Network devices
- Third-party applications
External systems can also forward logs through Syslog, Filebeat, Fluent Bit, Logstash, and other supported collectors.
If you’re configuring centralized log collection, see How to Configure Wazuh as a Centralized Syslog Server.
Log Decoding Process
Raw logs arrive in many different formats.
Before rules can analyze them, Wazuh decoders convert unstructured log messages into structured fields.
A decoder extracts information such as:
- Username
- IP address
- Hostname
- Process
- Event ID
- File path
- Command executed
- HTTP status code
- Application name
This normalization allows a single ruleset to analyze events consistently across multiple platforms.
Custom decoders can also be written for proprietary applications and internal software.
For more information, see Wazuh Decoder Guide.
Rule Evaluation and Matching
After decoding, the event passes through Wazuh’s hierarchical rule engine.
Rules examine extracted fields and evaluate conditions such as:
- Regular expressions
- Frequency thresholds
- Time windows
- Field values
- Parent-child relationships
- Previous event correlation
- Geographic conditions
- Threat intelligence matches
Multiple rules may evaluate a single event before the final alert is generated.
Organizations commonly customize rules to:
- suppress noisy events
- increase alert severity
- create organization-specific detections
- reduce false positives
For advanced rule creation, see The Complete Custom Wazuh Rules and Decoders Guide.
Alert Creation and Indexing
Once a rule matches, Wazuh creates a structured JSON alert.
The alert contains:
- Rule metadata
- Agent details
- Severity level
- Event data
- Decoder information
- Compliance mappings
- MITRE ATT&CK techniques
- Timestamp
- Source information
The alert is then forwarded to the Wazuh Indexer, where it becomes searchable and available for dashboards, reporting, and analytics.
Alert Visualization in the Wazuh Dashboard
After indexing, alerts appear almost immediately in the Wazuh Dashboard.
Analysts can:
- Search alerts
- Filter by severity
- Investigate affected agents
- Review timelines
- Pivot into related events
- Build dashboards
- Create saved searches
- Monitor attack trends
Dashboard visualizations make it significantly easier to identify ongoing attacks than reviewing raw log files manually.
Alert Forwarding to External Systems
Many organizations extend Wazuh by forwarding alerts to external platforms.
Common destinations include:
- Email notifications
- Slack
- PagerDuty
- SIEM platforms
- SOAR platforms
- Webhooks
- Ticketing systems
- Security orchestration workflows
Forwarding enables automated incident response and ensures critical alerts reach the appropriate teams immediately.
Relevant integration guides include:
- Wazuh Email Alerts Not Working? Complete Fix Guide
- Fix Wazuh Slack Webhook Errors: Curl 52 Empty Reply
- Resolving PagerDuty Integration Failures and Routing Key Errors in Wazuh
Expert insight: The MITRE ATT&CK framework encourages organizations to enrich detections with adversary techniques and tactics, allowing analysts to prioritize alerts based on attacker behavior rather than isolated events. Wazuh supports MITRE ATT&CK mappings in many built-in rules.
Prerequisites
Before configuring Wazuh alerts, verify that the core components of your deployment are functioning correctly.
Alerting depends on several services working together, and problems with any of them can prevent alerts from being generated or displayed.
Working Wazuh Deployment
Ensure your Wazuh environment is fully operational before making alert configuration changes.
Agents should already be enrolled, logs should be arriving at the manager, and events should appear in the dashboard.
If you’re deploying a new environment, consult The Complete Wazuh Cluster Architecture Guide or The Ultimate Wazuh Agent Deployment Guide.
Wazuh Manager Installed
The Wazuh Manager performs all decoding, rule evaluation, and alert generation.
Confirm that the manager service is running and processing incoming events without errors.
Verify:
- Manager service is active
- Rules are loading successfully
- Decoders initialize correctly
- No configuration errors appear in the manager logs
Wazuh Dashboard Access
You’ll need administrative access to the Wazuh Dashboard to:
- View generated alerts
- Search indexed events
- Validate rule matches
- Investigate alert details
- Test configuration changes
If the dashboard isn’t accessible, see Wazuh Dashboard Not Loading? Complete Troubleshooting Guide.
Wazuh Indexer Operational
The Wazuh Indexer stores generated alerts.
Even if the manager successfully creates alerts, they won’t appear in the dashboard if indexing fails.
Check that:
- Indexer cluster health is green or acceptable
- Alert indices exist
- Disk usage is sufficient
- Index templates are healthy
- No shard allocation issues are present
Related resources:
- The Ultimate Wazuh Indexer Guide
- How to Fix a Yellow Cluster Status in Wazuh Indexer
- How to Fix Wazuh All Shards Failed Error
Administrative Privileges
Most alert configuration tasks require administrative or root-level access to edit configuration files, restart Wazuh services, manage rules, and verify system logs.
Ensure you have the necessary permissions before making changes to production systems.
Sample Log Source for Testing
Finally, prepare a reliable log source to validate your alert configuration.
This could be:
- A Linux system generating authentication events
- A Windows endpoint producing Event Logs
- A firewall forwarding Syslog messages
- A web server such as Apache or NGINX
- A test application with custom log entries
Using predictable test events allows you to confirm that logs are collected, decoded, matched against rules, indexed, and displayed correctly throughout the entire alerting pipeline.
Understanding the Wazuh Alert Pipeline
Before customizing alerts, it’s important to understand how Wazuh processes security events.
Every alert follows a structured pipeline that transforms raw logs into actionable security intelligence.
Knowing how each stage works makes it much easier to troubleshoot missing alerts, tune detection accuracy, and create custom rules.
Log Collection
Everything begins with log collection.
Wazuh gathers security events from a wide variety of data sources, including:
- Windows Event Logs
- Linux Syslog
- Auditd
- Sysmon
- Apache and NGINX logs
- Firewall logs
- Kubernetes
- Docker
- Cloud platforms such as AWS, Azure, and GCP
- Network devices
- Databases
- Third-party security tools
Depending on your deployment, logs may be collected directly by Wazuh Agents or forwarded from external systems using Syslog, Filebeat, Logstash, Fluent Bit, or other supported collectors.
Common examples include:
| Source | Example Event |
|---|---|
| Windows | Failed login |
| Linux | SSH authentication failure |
| Apache | HTTP 404 or 500 errors |
| Firewall | Blocked connection |
| Sysmon | PowerShell execution |
| Kubernetes | Pod creation |
| CloudTrail | IAM policy modification |
Proper log collection is the foundation of effective alerting. If logs never reach the manager, alerts cannot be generated.
Related Guide:
Decoders
Once logs arrive at the Wazuh Manager, they pass through decoders.
A decoder identifies the log format and extracts structured fields from otherwise unstructured text.
For example, this raw log:
Failed password for root from 192.168.1.15 port 52144 ssh2May be decoded into:
- Username: root
- Source IP: 192.168.1.15
- Port: 52144
- Service: SSH
- Event type: Failed authentication
This structured information allows the rule engine to make intelligent decisions rather than searching raw text.
Wazuh includes hundreds of built-in decoders covering common operating systems, applications, cloud services, and security products.
Administrators can also create custom decoders for proprietary applications.
Related Guide: Wazuh Decoder Guide
Rules
After decoding, the extracted fields are evaluated by Wazuh’s rule engine.
Rules define the conditions that determine whether an event represents normal activity, a policy violation, or a potential security incident.
Rules can evaluate:
- Event IDs
- Regular expressions
- Source IP addresses
- Usernames
- File paths
- Process names
- Frequency thresholds
- Time windows
- Previous matching events
- Parent-child rule relationships
Thousands of predefined rules are included with Wazuh, covering everything from malware detection to cloud security monitoring.
Administrators frequently create custom rules to detect organization-specific activity or reduce unnecessary alerts.
Related Guide: How to Create Custom Detection Rules in Wazuh (With Examples)
Rule Matching
As each event passes through the ruleset, Wazuh evaluates every applicable rule until a match occurs.
Multiple rules may apply to the same event.
For example:
- A decoder identifies a failed SSH login.
- A generic authentication rule matches.
- A Linux-specific authentication rule matches.
- A brute force correlation rule detects repeated failures.
- A high-severity alert is generated.
This layered evaluation enables increasingly sophisticated detections while minimizing duplicate processing.
Rule matching also supports:
- Event correlation
- Frequency analysis
- Stateful detection
- Parent-child relationships
- Dynamic field evaluation
- Threat intelligence enrichment
Alert Generation
When a rule successfully matches, Wazuh generates a structured JSON alert.
A typical alert contains:
- Rule ID
- Rule description
- Alert level
- Agent name
- Timestamp
- Source IP
- Username
- Decoder used
- Rule groups
- Compliance mappings
- MITRE ATT&CK techniques
- Full event data
The alert represents the final result of Wazuh’s detection engine and becomes available for searching, reporting, dashboards, and automated responses.
Alert Storage
Generated alerts are forwarded to the Wazuh Indexer.
The Indexer stores alerts inside OpenSearch indices where they become searchable in near real time.
Indexed alerts can be:
- Queried
- Filtered
- Correlated
- Aggregated
- Visualized
- Archived
- Exported
Retention policies determine how long alerts remain searchable before being deleted or archived.
Related Guide:
Dashboard Visualization
The Wazuh Dashboard provides analysts with a centralized interface for investigating alerts.
Common dashboard capabilities include:
- Alert timelines
- Severity breakdowns
- MITRE ATT&CK visualizations
- Agent health
- Search and filtering
- Geographic maps
- Trend analysis
- Compliance dashboards
Analysts can drill down from a summary dashboard into the full JSON alert to investigate every field generated by the detection engine.
Notification Integrations
Many organizations require alerts to trigger notifications outside the Wazuh Dashboard.
Wazuh supports forwarding alerts to systems including:
- Slack
- PagerDuty
- Webhooks
- SOAR platforms
- SIEM solutions
- Ticketing systems
Notifications can be filtered based on:
- Alert level
- Rule ID
- Rule group
- Agent
- Event type
- Compliance category
This ensures only high-value alerts reach incident responders while lower-priority events remain searchable without creating unnecessary noise.
Expert insight: The National Institute of Standards and Technology (NIST) recommends implementing centralized security event monitoring with automated alerting and prioritization to improve incident detection and response effectiveness.
Understanding Wazuh Alert Levels
Every Wazuh alert is assigned a severity level ranging from 0 to 16.
These levels help security teams prioritize investigations by indicating how serious an event is.
Instead of treating every event equally, analysts can focus on high-risk detections while filtering out routine informational activity.
Alert levels can be customized for individual rules, allowing organizations to tailor severity ratings to their own risk tolerance and operational requirements.
Severity Levels (0–16)
Wazuh assigns an integer value between 0 and 16 to every generated alert.
Generally speaking:
| Alert Level | Meaning |
|---|---|
| 0 | Ignored or informational processing |
| 1–3 | Informational activity |
| 4–6 | Low-risk events |
| 7–9 | Medium-risk security events |
| 10–12 | High-priority threats |
| 13–16 | Critical incidents requiring immediate attention |
Higher numbers indicate greater urgency, although administrators may customize individual rule severities to better reflect their environment.
Informational Alerts
Informational alerts record routine system activity without indicating malicious behavior.
Examples include:
- Service startup
- Successful logins
- Configuration changes
- Scheduled tasks
- Normal system operations
These alerts provide valuable context during investigations but rarely require immediate action.
Low-Priority Events
Low-severity alerts often indicate events that deserve monitoring but are not necessarily security incidents.
Examples include:
- Single failed login attempts
- Minor configuration warnings
- Expected application errors
- User account changes
- Temporary connectivity issues
Security teams often retain these alerts for auditing and trend analysis while suppressing notifications to reduce alert fatigue.
Medium-Severity Alerts
Medium-priority alerts typically indicate suspicious behavior that warrants investigation.
Examples include:
- Repeated authentication failures
- Suspicious process execution
- Unexpected administrative activity
- Privilege changes
- Firewall policy modifications
Analysts should review these alerts promptly to determine whether additional escalation is necessary.
High-Severity Threats
High-severity alerts generally represent events with a strong likelihood of malicious activity.
Examples include:
- Malware detections
- Privilege escalation
- Persistence mechanisms
- Lateral movement
- Exploit attempts
- Multiple failed login correlations
- File Integrity Monitoring changes on sensitive files
Many organizations configure automated notifications or active response actions for alerts in this range.
Related Guide: How to Configure Wazuh Active Response
Critical Security Incidents
Critical alerts represent confirmed or highly probable attacks that require immediate attention.
Examples include:
- Ransomware indicators
- Remote code execution
- Known command-and-control communication
- Root compromise
- Credential theft
- Security policy bypasses
- Confirmed malware execution
Organizations often integrate these alerts with incident response workflows, ticketing systems, and on-call notification platforms.
Recommended Response Priorities
Although every environment has different requirements, a common prioritization strategy is:
| Alert Level | Recommended Response |
|---|---|
| 0–3 | Record for auditing |
| 4–6 | Monitor trends |
| 7–9 | Analyst review |
| 10–12 | Investigate immediately |
| 13–16 | Initiate incident response |
Rather than relying solely on severity, mature security operations centers also consider asset criticality, threat intelligence, user context, and historical activity before determining the overall priority of an alert.
Expert insight: Google’s Mandiant incident response teams emphasize prioritizing alerts based on both severity and business impact to reduce analyst overload and improve response times.
Understanding Default Wazuh Alert Rules
One of Wazuh’s biggest strengths is its extensive library of built-in detection rules.
These rules allow organizations to begin identifying common attacks immediately after deployment without writing custom detections from scratch.
The default rulesets cover operating systems, network devices, cloud services, applications, malware indicators, authentication events, compliance frameworks, and adversary techniques.
Built-in Rulesets
Wazuh includes thousands of predefined rules organized into logical categories.
These rules monitor events such as:
- Authentication
- File Integrity Monitoring
- Vulnerability detection
- Sysmon activity
- CloudTrail
- Windows Event Logs
- Linux audit logs
- Apache
- NGINX
- Docker
- Kubernetes
- Suricata
- VirusTotal
- Firewall events
Because these rules are maintained by the Wazuh project, administrators receive updated detections when upgrading to newer releases.
Rule IDs
Every Wazuh rule has a unique numeric identifier.
For example, an alert includes a field similar to:
"rule": {
"id": "5710",
"level": 5,
"description": "sshd: authentication failed."
}Rule IDs allow administrators to:
- Identify specific detections
- Create exceptions
- Override default behavior
- Adjust severity
- Build custom correlation rules
- Search historical alerts
Rule Groups
Rules are organized into groups that classify similar detections.
Common rule groups include:
- authentication
- ssh
- windows
- malware
- sysmon
- firewall
- web
- cloud
- compliance
- audit
- policy
Groups make it easier to search alerts, create dashboards, and apply notification filters.
Rule Inheritance
Wazuh supports hierarchical rule inheritance.
A child rule can inherit behavior from a parent rule while adding additional detection logic.
For example:
- Parent rule identifies SSH authentication.
- Child rule detects repeated failures.
- Another child rule identifies brute force attacks.
- A further child rule increases severity when root accounts are targeted.
This layered approach reduces duplication and keeps rules easier to maintain.
Compliance Mappings
Many default rules include mappings to widely adopted regulatory and security frameworks.
These mappings simplify compliance reporting by automatically associating alerts with relevant controls.
Supported mappings include:
- PCI DSS
- HIPAA
- GDPR
- NIST 800-53
- CIS Controls
Compliance dashboards can then filter alerts based on the applicable framework, helping auditors and compliance teams demonstrate control effectiveness.
MITRE ATT&CK Mappings
Many Wazuh rules also map directly to the MITRE ATT&CK framework.
For example, an alert may identify techniques related to:
- Initial Access
- Persistence
- Privilege Escalation
- Defense Evasion
- Credential Access
- Discovery
- Lateral Movement
- Command and Control
- Exfiltration
These mappings help analysts understand attacker behavior rather than viewing events in isolation.
Organizations can also build dashboards that visualize ATT&CK techniques observed across their environments.
PCI DSS, HIPAA, GDPR Mappings
In addition to MITRE ATT&CK, many default rules include references to regulatory frameworks such as PCI DSS, HIPAA, and GDPR.
This allows organizations to:
- Generate compliance reports
- Demonstrate monitoring controls
- Track security events affecting regulated systems
- Simplify audit preparation
- Correlate alerts with specific compliance requirements
Combined with customizable dashboards and alert searches, these mappings make Wazuh a valuable tool for both security operations and regulatory compliance.
For organizations with unique compliance requirements, custom rules can extend these mappings while preserving compatibility with the built-in ruleset.
Related Guide: The Complete Custom Wazuh Rules and Decoders Guide
Configuring Alert Generation
Wazuh provides extensive control over how alerts are generated, stored, and displayed.
Most alert-related settings are configured in the ossec.conf file on the Wazuh Manager.
By adjusting these options, you can control which events generate alerts, how alerts are stored, and which formats are available for dashboards and integrations.
Before making any changes, it’s recommended to back up your existing configuration and validate syntax after every modification.
Editing ossec.conf
The primary Wazuh configuration file is located at:
/var/ossec/etc/ossec.confOpen the file using your preferred text editor:
sudo nano /var/ossec/etc/ossec.confAlert generation settings are primarily located within the <alerts>, <logging>, and related configuration sections.
When editing the file:
- Preserve XML formatting.
- Ensure every opening tag has a matching closing tag.
- Avoid duplicate configuration blocks.
- Validate changes before restarting services.
Configuration syntax errors can prevent the Wazuh Manager from starting.
Related Guide: How to Fix ossec.conf Syntax Errors in Wazuh Agents
Configuring Global Alert Settings
Global alert settings determine the minimum severity required before an event becomes an alert.
A typical configuration looks like:
<alerts>
<log_alert_level>3</log_alert_level>
<email_alert_level>12</email_alert_level>
</alerts>Key options include:
| Setting | Purpose |
|---|---|
log_alert_level | Minimum severity written to alert logs |
email_alert_level | Minimum severity for email notifications |
| Global rules | Controls baseline alert generation behavior |
For example:
- Setting
log_alert_levelto 1 records nearly every event. - Setting it to 7 records only medium and high-severity alerts.
- Higher thresholds reduce storage usage and alert volume but may hide useful forensic information.
Choose thresholds that balance visibility with operational efficiency.
Enabling JSON Alerts
Modern Wazuh deployments typically use JSON-formatted alerts because they integrate seamlessly with the Wazuh Indexer, OpenSearch, APIs, and external automation platforms.
JSON alerts include structured fields such as:
- Rule ID
- Alert level
- Agent name
- Timestamp
- Source IP
- User
- Decoder
- Compliance mappings
- MITRE ATT&CK techniques
Structured JSON is significantly easier to parse than plain text and is recommended for production environments.
If you’re integrating Wazuh with external SIEMs, SOAR platforms, or custom scripts, JSON alerts should almost always be enabled.
Configuring Log Alerts
Alert logging determines which generated alerts are written to disk.
Depending on the configured alert level, Wazuh stores alert information under:
/var/ossec/logs/alerts/Common alert files include:
alerts.jsonalerts.log
Administrators often configure logging based on:
- Storage capacity
- Compliance requirements
- Incident response needs
- Retention policies
- External log forwarding
Lower thresholds capture more events but increase storage consumption.
Configuring Archive Logs
Archive logs differ from alerts.
While alerts contain only events that matched detection rules, archive logs preserve the original processed events regardless of whether they generated alerts.
Archive logging is valuable for:
- Forensic investigations
- Rule development
- Decoder testing
- Historical analysis
- Compliance audits
However, archive logs can consume significant disk space in busy environments.
Organizations commonly retain archives for shorter periods while keeping alerts available for longer-term investigations.
Related Guide:
Restarting Wazuh Services
After modifying ossec.conf, restart the Wazuh Manager so the new configuration takes effect.
Example:
sudo systemctl restart wazuh-managerVerify the service starts successfully:
sudo systemctl status wazuh-managerIf the service fails to restart:
- Review manager logs.
- Check XML syntax.
- Verify recently modified configuration sections.
- Validate custom rules if they were edited simultaneously.
Avoid making multiple configuration changes at once, as this makes troubleshooting more difficult.
Verifying Configuration
Once the manager is running again, confirm that alerts are being generated correctly.
Recommended verification steps include:
- Generate a known security event (such as a failed SSH login).
- Confirm the event appears in
alerts.json. - Verify the alert is indexed in the Wazuh Indexer.
- Search for the alert in the Wazuh Dashboard.
- Confirm any configured notifications (email, Slack, PagerDuty, etc.) are delivered.
- Review the assigned rule ID and alert level to ensure they match expectations.
Testing after every configuration change helps identify issues early before deploying updates to production environments.
Creating Custom Alert Rules
Although Wazuh ships with thousands of built-in detection rules, every organization has unique security requirements.
Custom rules allow you to detect organization-specific activity, tune alert severity, reduce false positives, and monitor proprietary applications without modifying the default ruleset.
Best practice is to place all custom rules in local_rules.xml, ensuring they remain intact during Wazuh upgrades.
Creating local_rules.xml
Custom rules are typically stored in:
/var/ossec/etc/rules/local_rules.xmlIf the file doesn’t already exist, create it and define your custom rules within the root <group> element.
Keeping custom rules separate from the built-in rulesets simplifies maintenance and prevents your changes from being overwritten when updating Wazuh.
Related Guide: The Complete Custom Wazuh Rules and Decoders Guide
Assigning Rule IDs
Each custom rule requires a unique rule ID.
General recommendations include:
- Use IDs outside the ranges reserved for built-in Wazuh rules.
- Keep IDs organized by application or detection category.
- Document assigned IDs for future maintenance.
- Avoid reusing existing IDs to prevent unexpected behavior.
A consistent numbering strategy makes large rule libraries easier to manage over time.
Setting Alert Levels
Every rule should include an appropriate severity level between 0 and 16.
Consider factors such as:
- Likelihood of malicious activity
- Potential business impact
- Confidence in the detection
- Frequency of occurrence
For example:
- Informational events may use levels 1–3.
- Suspicious activity may use levels 7–9.
- Confirmed attacks may use levels 12–16.
Accurate severity assignments help analysts prioritize investigations and reduce alert fatigue.
Matching Specific Events
Rules can target highly specific activity by matching fields extracted during the decoding process.
Common matching criteria include:
- Event IDs
- Usernames
- Source or destination IP addresses
- Process names
- File paths
- Registry keys
- HTTP methods
- URLs
- Cloud service actions
- Authentication events
The more precise your matching logic, the fewer false positives your rules are likely to generate.
Using Regular Expressions
Regular expressions (regex) allow rules to detect patterns rather than exact values.
Examples include matching:
- Multiple usernames
- IP address ranges
- Command-line arguments
- File extensions
- URL paths
- Suspicious PowerShell commands
- Malware naming conventions
While regex provides flexibility, overly broad expressions can increase processing overhead and generate unintended matches.
Test expressions carefully before deploying them in production.
Correlating Multiple Events
One of Wazuh’s most powerful capabilities is event correlation.
Rather than generating alerts for isolated events, rules can detect suspicious behavior occurring over time.
Examples include:
- Multiple failed logins within five minutes.
- Repeated privilege escalation attempts.
- Numerous file modifications in sensitive directories.
- Brute-force attacks against administrative accounts.
- Sequential execution of known attack techniques.
Correlation significantly improves detection fidelity by identifying patterns that individual events cannot reveal.
Related Guide:
Testing New Rules
Always validate custom rules before deploying them into production.
A recommended testing process includes:
- Generate sample log events.
- Use
wazuh-logtestto verify decoding and rule matching. - Confirm the expected rule ID is triggered.
- Check the assigned alert level.
- Verify the alert appears in the Wazuh Dashboard.
- Confirm integrations and notifications work as expected.
Thorough testing helps identify syntax errors, incorrect matching logic, and unexpected rule interactions before they affect production monitoring.
Related Guide:
Reducing Alert Noise
One of the biggest challenges in any Security Operations Center (SOC) is alert fatigue.
Excessive low-value alerts can overwhelm analysts, delay investigations, and increase the likelihood of overlooking genuine threats.
An effective Wazuh deployment focuses on producing high-fidelity alerts by suppressing unnecessary events while preserving valuable security data.
Expert insight: The Center for Internet Security (CIS) recommends continuously tuning detection rules and reducing false positives as part of an effective continuous monitoring program, helping analysts focus on actionable events.
Rule Suppression
Rule suppression prevents specific alerts from being generated under defined conditions.
Common suppression scenarios include:
- Known maintenance activities
- Approved administrative actions
- Routine system scans
- Expected software updates
- Internal monitoring tools
Suppress only well-understood events to avoid hiding legitimate attacks.
Ignore Rules
In some cases, entire categories of low-value events can be ignored.
Examples include:
- Repetitive health checks
- Successful routine authentications
- Expected application warnings
- Scheduled automation jobs
- Benign service restarts
Ignoring unnecessary events reduces storage requirements and improves dashboard usability without affecting critical detections.
Frequency Thresholds
Some security events become meaningful only when they occur repeatedly.
Frequency-based rules trigger alerts only after predefined thresholds are reached.
Examples include:
- Five failed logins within two minutes.
- Ten blocked firewall connections from the same IP.
- Multiple malware detections on one endpoint.
- Repeated execution of suspicious commands.
Thresholds significantly reduce noise from isolated events while highlighting coordinated attacks.
Time-Based Suppression
Time-based suppression limits how often identical alerts are generated within a specified period.
For example, instead of generating hundreds of identical alerts during a brute-force attack, Wazuh can consolidate repeated events into a smaller number of meaningful alerts.
Benefits include:
- Reduced alert storms
- Lower storage usage
- Easier analyst review
- Improved notification quality
This approach is particularly useful for noisy infrastructure components and internet-facing services.
Duplicate Event Handling
Duplicate events frequently occur when multiple systems report the same activity.
Examples include:
- Endpoint agents
- Firewalls
- IDS/IPS platforms
- Cloud logging services
- Syslog relays
Proper rule tuning and event correlation help eliminate redundant alerts while preserving the underlying security context.
Whitelisting Trusted Activity
Trusted systems, service accounts, and known administrative actions often generate predictable events.
Common whitelist candidates include:
- Vulnerability scanners
- Backup servers
- Domain controllers
- Configuration management tools
- Approved automation platforms
- Internal monitoring services
Whitelisting reduces unnecessary alerts while allowing security teams to concentrate on unexpected or unauthorized activity.
Whitelists should be reviewed regularly to ensure they remain accurate and do not inadvertently exclude malicious activity originating from compromised trusted systems.
Filtering Unnecessary Events
The final step in reducing alert noise is filtering events that provide little security value.
Organizations commonly filter:
- Debug logs
- Informational application messages
- Temporary network failures
- Routine scheduled jobs
- Duplicate monitoring events
- Non-security operational logs
Rather than aggressively filtering everything, start conservatively and refine your configuration over time based on real-world alert volumes, analyst feedback, and incident response outcomes.
Related Guide:
Be First to Comment