Modern cyberattacks rarely leave evidence in a single location.

Network-based threats may be visible in traffic patterns, while endpoint compromise indicators often appear in host logs.

Organizations that rely on only one source of security telemetry risk missing critical indicators of compromise.

By integrating Wazuh with Suricata, security teams can combine endpoint visibility with network-level threat detection to create a more comprehensive security monitoring solution.

Suricata identifies suspicious network activity in real time, while Wazuh centralizes, correlates, and analyzes those alerts alongside operating system, application, and compliance logs.

This integration helps security teams detect threats faster, reduce alert fatigue, and gain deeper visibility across their environments.

What is Wazuh?

Wazuh is an open-source security platform that combines Security Information and Event Management (SIEM) and Extended Detection and Response (XDR) capabilities.

It enables organizations to collect, analyze, and correlate security events from endpoints, servers, cloud platforms, containers, and network devices.

Wazuh provides:

• Log collection and analysis
• File Integrity Monitoring (FIM)
• Vulnerability detection
• Threat hunting
• Compliance monitoring
• Active response automation

If you’re new to Wazuh detection engineering, check out our How to Create Custom Detection Rules in Wazuh (With Examples) guide.

What is Suricata?

Suricata is a high-performance open-source Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring (NSM) platform developed by the Open Information Security Foundation (OISF).

Suricata inspects network traffic in real time and detects malicious activity using:

• Signature-based detection
• Protocol analysis
• File extraction
• TLS inspection
• Network behavior analysis

It can monitor traffic across multiple protocols and generate detailed alerts when suspicious activity is identified.

Why Combine Wazuh and Suricata?

While Suricata excels at detecting network threats, it does not provide broad endpoint visibility or centralized security analytics by itself.

Wazuh fills this gap by ingesting Suricata alerts and correlating them with:

• Endpoint events
• Authentication logs
• System changes
• Cloud activity
• Compliance data

For example, Suricata may detect a command-and-control (C2) connection attempt from a workstation. Wazuh can correlate that alert with endpoint logs showing suspicious process execution on the same device, providing a more complete incident timeline.

This layered approach significantly improves threat detection accuracy.

Benefits of Integrating a SIEM/XDR Platform with a Network Intrusion Detection System

Integrating Wazuh and Suricata offers several advantages:

Improved Threat Detection

Network-based and endpoint-based indicators can be correlated to uncover attacks that might otherwise go unnoticed.

Centralized Security Monitoring

Security analysts can investigate alerts from a single dashboard rather than switching between multiple tools.

Faster Incident Response

Correlated alerts provide additional context, helping analysts quickly determine the scope and severity of incidents.

Enhanced Visibility

Organizations gain visibility into:

• Network traffic
• Endpoint behavior
• Authentication events
• System modifications
• Compliance violations

Better Threat Hunting

Analysts can search across both network and endpoint telemetry to identify advanced threats.

According to the MITRE ATT&CK Framework, effective threat detection often requires visibility across multiple stages of the attack lifecycle, making telemetry correlation a critical component of modern security operations.

What You’ll Learn in This Guide

In this tutorial, you’ll learn:

• How Wazuh and Suricata work together
• The architecture behind the integration
• How to configure Suricata logging
• How to collect Suricata alerts with Wazuh
• How to create custom detection rules
• How to validate and test the integration
• Best practices for ongoing monitoring and maintenance

By the end of this guide, you’ll have a fully integrated security monitoring solution capable of detecting threats across both network and endpoint layers.

Understanding Wazuh and Suricata Integration

Before configuring the integration, it’s important to understand the role each platform plays and how they work together to improve security visibility.

What Is Wazuh?

Wazuh is an open-source SIEM and XDR platform designed to collect, analyze, and correlate security events from diverse data sources.

It provides centralized visibility across endpoints, cloud environments, applications, and network infrastructure.

Overview of Wazuh Capabilities

Log Analysis

Wazuh collects logs from operating systems, applications, cloud services, and security tools.

The platform normalizes and analyzes these logs to identify suspicious activity and generate security alerts.

Organizations commonly use Wazuh to monitor:

• Linux logs
• Windows Event Logs
• Syslog data
• Cloud audit logs
• Application logs

For cloud monitoring use cases, see How to Monitor AWS CloudTrail Logs Using Wazuh.

Threat Detection

Wazuh uses built-in rules, decoders, and threat intelligence integrations to identify:

• Malware activity
• Privilege escalation
• Unauthorized access attempts
• Policy violations
• Known indicators of compromise

Compliance Monitoring

Wazuh includes frameworks and controls for standards such as:

• PCI DSS
• HIPAA
• GDPR
• NIST
• CIS Benchmarks

This allows organizations to continuously assess compliance posture while monitoring security events.

Active Response

Wazuh can automatically respond to threats by:

• Blocking malicious IP addresses
• Disabling compromised accounts
• Terminating suspicious processes
• Executing custom response scripts

This capability helps reduce response times and limit attacker movement.

What Is Suricata?

Suricata is an open-source network threat detection engine capable of functioning as:

• Intrusion Detection System (IDS)
• Intrusion Prevention System (IPS)
• Network Security Monitoring (NSM) platform

It continuously analyzes network traffic and generates alerts when malicious activity is detected.

Overview of Suricata IDS/IPS

Suricata inspects network packets in real time and supports multi-threaded processing, allowing it to handle high-volume environments efficiently.

The platform can detect:

• Malware communications
• Exploit attempts
• Port scanning
• Command-and-control traffic
• Data exfiltration activity

Signature-Based Detection

Suricata primarily uses detection signatures to identify known attack patterns.

Many organizations use the Emerging Threats Ruleset to continuously update Suricata with the latest threat intelligence indicators.

These signatures allow Suricata to detect:

• Known malware families
• Exploit kits
• Botnet traffic
• Malicious domains
• Vulnerability exploitation attempts

Protocol Analysis

Suricata understands numerous application-layer protocols, including:

• HTTP
• HTTPS
• DNS
• SMTP
• FTP
• SSH
• TLS

This protocol awareness enables deeper inspection than traditional packet filtering tools.

Network Traffic Inspection

Suricata performs deep packet inspection (DPI) to analyze network communications and identify suspicious behaviors.

Examples include:

• DNS tunneling
• Suspicious TLS certificates
• Unauthorized outbound connections
• Exploit payload delivery
• Lateral movement activity

How the Integration Works

The Wazuh-Suricata integration creates a unified workflow where network alerts become part of a centralized security monitoring platform.

Suricata Generates Network Security Alerts

When Suricata detects suspicious network activity, it records alerts in its EVE JSON log file.

Typical alerts include:

• Port scanning attempts
• Malware communications
• Exploit activity
• Command-and-control traffic
• Brute-force attacks

Each alert contains valuable context such as:

• Source IP address
• Destination IP address
• Timestamp
• Protocol information
• Threat classification
• Signature details

Wazuh Collects and Analyzes Suricata Logs

Wazuh agents monitor Suricata log files and forward events to the Wazuh Manager.

Once received, Wazuh:

• Parses Suricata events
• Applies detection rules
• Enriches alert metadata
• Assigns severity levels
• Generates dashboard alerts

Organizations can further customize alert handling using techniques covered in How to Create Custom Detection Rules in Wazuh (With Examples).

Alert Correlation and Centralized Visibility

One of the most powerful benefits of the integration is event correlation.

Wazuh can combine Suricata alerts with:

• Windows Event Logs
• Linux audit logs
• Authentication events
• File Integrity Monitoring alerts
• Vulnerability detection results

This provides analysts with a complete picture of an attack rather than isolated events.

Security Monitoring Workflow

A typical monitoring workflow looks like this:

1. Network traffic passes through Suricata.
2. Suricata detects suspicious activity.
3. Suricata writes an alert to EVE JSON logs.
4. Wazuh collects the alert.
5. Wazuh applies rules and correlates events.
6. Security alerts appear in the Wazuh dashboard.
7. Analysts investigate or trigger automated response actions.

This workflow enables organizations to combine network-based detection with endpoint and log-based monitoring, creating a stronger and more comprehensive security operations capability.

Benefits of Integrating Wazuh with Suricata

Integrating Wazuh with Suricata creates a powerful security monitoring solution that combines network-based threat detection with endpoint visibility, log analysis, and automated response capabilities.

Rather than treating network alerts as isolated events, organizations can correlate Suricata detections with system activity, authentication logs, file changes, and cloud events to gain deeper security insights.

Improved Threat Detection Accuracy

Many attacks generate indicators across multiple systems and layers of infrastructure.

For example:

• Suricata may detect malicious outbound traffic.
• Wazuh may simultaneously detect suspicious process execution.
• Authentication logs may show abnormal login behavior.

By correlating these events, security teams can distinguish genuine threats from isolated anomalies.

According to the MITRE ATT&CK Framework, attackers frequently move through multiple phases of the attack lifecycle, making visibility across both network and endpoint telemetry essential for effective detection.

Examples of threats that become easier to detect include:

• Command-and-control communications
• Malware infections
• Data exfiltration attempts
• Lateral movement activity
• Credential compromise

Centralized Security Monitoring

Without integration, analysts often need to review alerts across multiple consoles.

The Wazuh-Suricata integration centralizes security data into a single platform where teams can:

• View network alerts
• Monitor endpoint activity
• Analyze authentication events
• Review compliance violations
• Investigate vulnerabilities

This centralized approach simplifies investigations and improves operational efficiency.

Organizations already using Wazuh for endpoint monitoring can extend visibility without introducing another SIEM platform.

Enhanced Incident Investigation

Incident response becomes significantly easier when all relevant security events are available in one place.

Consider a scenario where Suricata detects communication with a known malicious IP address.

Using Wazuh, analysts can immediately investigate:

• Which endpoint initiated the connection
• What process generated the traffic
• Whether suspicious files were created
• Which user account was active
• Whether additional systems were affected

This context reduces investigation time and helps responders make informed decisions faster.

Real-Time Network Visibility

Suricata continuously analyzes network traffic and generates alerts as suspicious activity occurs.

This provides visibility into:

• Port scans
• Malware communications
• Exploit attempts
• DNS abuse
• Command-and-control traffic
• Unauthorized outbound connections

When these alerts are forwarded into Wazuh, security teams gain real-time awareness of network threats alongside host-based telemetry.

Reduced Alert Fatigue Through Correlation

One of the biggest challenges facing security teams is alert overload.

Independent security tools often generate large numbers of alerts that lack context, forcing analysts to manually determine which events require investigation.

Wazuh helps reduce alert fatigue by:

• Correlating related events
• Enriching alerts with additional metadata
• Prioritizing higher-risk activity
• Providing context around detections

For example, a single Suricata alert may be low priority on its own.

However, if Wazuh identifies concurrent privilege escalation activity on the affected host, the event can be elevated for immediate review.

Open-Source and Cost-Effective Security Stack

Many commercial SIEM and Network Detection and Response (NDR) solutions require substantial licensing investments.

Wazuh and Suricata provide enterprise-grade security monitoring capabilities without per-endpoint or per-ingest licensing fees.

Benefits include:

• No proprietary vendor lock-in
• Large open-source communities
• Extensive customization options
• Transparent detection logic
• Lower operational costs

Organizations can build a robust security monitoring environment while maintaining budget flexibility.

For a deeper comparison between Wazuh and other security monitoring platforms, see Wazuh vs Splunk and Wazuh vs OSSIM.

Prerequisites

Before configuring the integration, ensure your environment meets the necessary hardware, software, and access requirements.

System Requirements

Wazuh Manager Installed

You must have a functioning Wazuh Manager deployment available to receive and process Suricata alerts.

The Wazuh Manager should be:

• Installed and operational
• Accessible from the Suricata host
• Running the Wazuh API and indexing services
• Properly configured to receive agent data

Wazuh Agent Installed on the Suricata Server

The Wazuh Agent is responsible for collecting Suricata logs and forwarding them to the manager.

Install the agent on the system where Suricata is running.

The agent will:

• Monitor Suricata log files
• Collect generated alerts
• Send events to the Wazuh Manager
• Enable centralized analysis

If you need assistance deploying agents, see How to Install a Wazuh Agent on Windows Server for an overview of the Wazuh agent architecture and deployment process.

Linux Server Requirements

The integration is commonly deployed on Linux systems running Suricata.

Recommended minimum resources:

Production deployments monitoring high network volumes may require significantly more resources.

The Suricata Documentation recommends sizing systems according to expected network throughput and inspection requirements.

Network Access Considerations

Verify the following before proceeding:

• The Wazuh Agent can communicate with the Wazuh Manager.
• Firewall rules allow required Wazuh traffic.
• DNS resolution is functioning properly.
• Time synchronization is configured using NTP.

Accurate timestamps are particularly important for event correlation and incident investigations.

Software Requirements

Wazuh 4.x or Later

This guide assumes you’re running:

• Wazuh 4.x
• Wazuh Indexer
• Wazuh Dashboard

Newer Wazuh releases provide improved Suricata integration support and enhanced event processing capabilities.

Suricata 6.x or Later

Use Suricata version 6.x or newer whenever possible.

Benefits include:

• Improved EVE JSON logging
• Enhanced protocol detection
• Better performance
• Expanded rule support
• Additional threat detection capabilities

While older versions may function, the latest stable release is generally recommended.

Required Permissions

Root or sudo Access

Administrative privileges are required to:

• Install packages
• Manage services
• Edit configuration files
• Modify logging settings
• Restart system services

Most commands in this guide assume either:

sudo command

or a root shell.

Ability to Modify Wazuh and Suricata Configuration Files

You will need access to modify:

Suricata configuration

/etc/suricata/suricata.yaml

Suricata log directory

/var/log/suricata/

Wazuh Agent configuration

/var/ossec/etc/ossec.conf

After configuration changes are made, both services will need to be restarted.

Installing Suricata

If Suricata is not already installed, follow the appropriate instructions for your Linux distribution.

Installing Suricata on Ubuntu/Debian

Update package repositories:

sudo apt update

Install Suricata:

sudo apt install suricata -y

Verify the package was installed successfully:

suricata --build-info

For the latest releases, consider using the official packages provided by the Open Information Security Foundation (OISF).

Installing Suricata on CentOS/RHEL

Install the EPEL repository:

sudo dnf install epel-release -y

Install Suricata:

sudo dnf install suricata -y

For older systems using YUM:

sudo yum install suricata -y

Verify the installation:

suricata --build-info

The command should display detailed build information and enabled features.

Verifying the Installation

Confirm that Suricata is installed correctly.

Check the version:

suricata --version

Example output:

This is Suricata version 7.x.x

Validate the configuration:

sudo suricata -T -c /etc/suricata/suricata.yaml

Expected output:

Configuration provided was successfully loaded.

Resolving configuration errors now will prevent problems later when integrating with Wazuh.

Starting and Enabling the Suricata Service

Start Suricata:

sudo systemctl start suricata

Enable Suricata to start automatically at boot:

sudo systemctl enable suricata

Verify service status:

sudo systemctl status suricata

You should see output indicating that the service is active and running:

Active: active (running)

To confirm Suricata is generating logs, check the log directory:

ls -lah /var/log/suricata/

Typical files include:

eve.json
fast.log
stats.log
suricata.log

The eve.json file is particularly important because it contains the structured security events that Wazuh will collect and analyze in the next step.

Configuring Suricata for Wazuh Integration

Once Suricata is installed and running, the next step is configuring it to generate structured security events that Wazuh can ingest and analyze.

The recommended approach is to use EVE JSON logging, which provides detailed machine-readable event data that integrates seamlessly with Wazuh.

Enable EVE JSON Logging

Suricata supports several output formats, but EVE JSON is the preferred option for SIEM integrations because it provides rich metadata and structured event fields.

EVE JSON can record:

• Security alerts
• DNS activity
• HTTP transactions
• TLS events
• File transfers
• Network flow information
• Protocol-specific metadata

Wazuh parses these JSON events and converts them into searchable security alerts.

Modify the Suricata Configuration File

Open the Suricata configuration file:

sudo nano /etc/suricata/suricata.yaml

Locate the outputs section.

You should find an EVE JSON configuration block similar to the following:

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      community-id: true
      types:
        - alert
        - dns
        - http
        - tls
        - flow

If EVE logging is disabled, update the configuration so that:

enabled: yes

is set.

Why EVE JSON Matters

Unlike traditional IDS log formats, EVE JSON preserves detailed contextual information that security teams can use during investigations.

For example, a Suricata alert can include:

• Source and destination IP addresses
• Port information
• Protocol details
• Alert severity
• Signature identifiers
• Threat classifications

This data becomes extremely valuable once correlated with endpoint events inside Wazuh.

Configure Alert Logging

For most deployments, the most important event type is:

types:
  - alert

Alert events contain Suricata detections generated by IDS rules.

You can also enable additional telemetry sources:

types:
  - alert
  - dns
  - http
  - tls
  - flow
  - ssh

Collecting additional network metadata improves visibility and threat-hunting capabilities but will increase storage consumption.

The Suricata EVE JSON Documentation provides a complete list of supported event types and configuration options.

Restart Suricata

After saving the configuration file, restart the service to apply the changes.

sudo systemctl restart suricata

Verify that the service started successfully:

sudo systemctl status suricata

Expected output should show:

Active: active (running)

If the service fails to start, review:

sudo journalctl -u suricata

for configuration errors.

Verify EVE JSON Log Generation

Confirm that Suricata is generating EVE JSON events.

Check whether the log file exists:

ls -lah /var/log/suricata/eve.json

Monitor the file in real time:

sudo tail -f /var/log/suricata/eve.json

You should see JSON-formatted events similar to:

{
  "timestamp":"2025-01-01T12:00:00.000000+0000",
  "event_type":"alert",
  "src_ip":"192.168.1.10",
  "dest_ip":"8.8.8.8",
  "alert":{
    "signature":"ET SCAN Potential SSH Scan",
    "severity":2
  }
}

Example Log Location

Most Linux installations store the EVE JSON log at:

/var/log/suricata/eve.json

This is the file that Wazuh will monitor and ingest in the next step.

Configuring the Wazuh Agent to Collect Suricata Logs

With Suricata generating structured security events, the Wazuh Agent must be configured to monitor the EVE JSON file and forward events to the Wazuh Manager.

Locate the Wazuh Agent Configuration File

On Linux systems, the Wazuh Agent configuration file is located at:

/var/ossec/etc/ossec.conf

Open the file:

sudo nano /var/ossec/etc/ossec.conf

This file controls:

• Log collection
• Agent behavior
• Monitoring settings
• File integrity monitoring
• Event forwarding

Add Suricata Log Collection Settings

Inside the <ossec_config> section, add the following configuration:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

Configuration Explanation

This configuration instructs the Wazuh Agent to continuously monitor the Suricata log file and forward newly generated events to the Wazuh Manager.

If you’re unfamiliar with Wazuh log collection mechanisms, our How to Create Custom Detection Rules in Wazuh (With Examples) guide provides additional details on how Wazuh processes incoming events.

Save and Apply the Configuration

After adding the configuration block:

1. Save the file.
2. Exit the editor.
3. Validate the XML formatting if desired.

A malformed configuration file may prevent the Wazuh Agent from starting correctly.

Restart the Wazuh Agent

Restart the Wazuh Agent service:

sudo systemctl restart wazuh-agent

Verify the service status:

sudo systemctl status wazuh-agent

Expected output:

Active: active (running)

If issues occur, review the agent log:

sudo tail -f /var/ossec/logs/ossec.log

Verify Log Collection

You can confirm that the Wazuh Agent is reading the Suricata log file by monitoring:

sudo tail -f /var/ossec/logs/ossec.log

Look for messages indicating that events are being processed and forwarded to the manager.

You can also verify communication from the manager:

sudo /var/ossec/bin/agent_control -l

The Suricata host should appear as an active Wazuh Agent.

If the agent cannot communicate with the manager, review our troubleshooting guide:

[INTERNAL LINK: Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work]

Validating the Integration

After configuring both platforms, it’s important to verify that Suricata alerts are successfully reaching Wazuh and appearing within the dashboard.

Generate Test Network Traffic

The easiest way to test the integration is to generate traffic that triggers a Suricata rule.

Several approaches can be used:

Option 1: Test Rule Trigger

Add a temporary test rule to Suricata:

alert icmp any any -> any any (msg:"ICMP Test Alert"; sid:1000001; rev:1;)

Then generate ICMP traffic:

ping 8.8.8.8

Option 2: Nmap Scan

Perform a basic port scan against a test host:

nmap -sS target-ip

Many Suricata rule sets generate alerts for reconnaissance activity.

Option 3: Emerging Threats Test Rules

The Emerging Threats Ruleset includes signatures specifically designed for validation and testing purposes.

Trigger a Suricata Alert

After generating traffic, inspect the EVE JSON log:

sudo tail -f /var/log/suricata/eve.json

Look for entries where:

"event_type":"alert"

Example:

{
  "event_type":"alert",
  "src_ip":"192.168.1.50",
  "dest_ip":"10.0.0.20",
  "alert":{
    "signature":"ICMP Test Alert",
    "severity":3
  }
}

This confirms that Suricata is detecting activity correctly.

Confirm Events Appear in Wazuh

Log into the Wazuh Dashboard.

Navigate to:

Security Events → Events

Search for:

suricata

or the rule signature name.

You should see alerts generated from the test activity.

If no events appear:

1. Verify Suricata is writing to eve.json.
2. Confirm the Wazuh Agent is monitoring the correct file.
3. Check Wazuh Agent logs for collection errors.
4. Confirm the agent is connected to the manager.

Verify Alert Details and Metadata

Open an alert and review the available metadata.

Typical fields include:

• Source IP
• Destination IP
• Source port
• Destination port
• Protocol
• Signature name
• Severity level
• Timestamp
• Suricata rule ID

This information helps analysts understand what occurred and determine whether additional investigation is necessary.

Review Correlated Security Events

The real value of the integration becomes apparent when Suricata alerts are correlated with other Wazuh telemetry.

For example, an investigation may reveal:

This broader context helps security teams identify the full scope of an incident rather than investigating isolated alerts.

Organizations using How to Configure File Integrity Monitoring (FIM) in Wazuh can gain even greater visibility by correlating network detections with unauthorized file changes occurring on the same host.

At this stage, the Wazuh-Suricata integration should be fully operational, providing centralized visibility into network threats and endpoint activity from a single security platform.

Understanding Suricata Alerts in Wazuh

After integrating Suricata with Wazuh, security alerts generated by network traffic analysis become searchable, correlated events within the Wazuh platform.

Understanding how these alerts are categorized and what information they contain will help you investigate incidents more effectively and create more accurate detection rules.

Alert Severity Levels

Suricata assigns severity values to alerts based on the associated detection rule.

While severity levels vary by ruleset, they are commonly interpreted as follows:

Examples of high-severity alerts include:

• Known malware communications
• Exploit attempts
• Command-and-control traffic
• Active attacks against services

Examples of lower-severity alerts include:

• Network reconnaissance
• Suspicious protocol usage
• Policy violations
• Informational detections

Organizations often create custom Wazuh rules to prioritize severity 1 and 2 events for immediate review.

Common Suricata Event Types

Suricata generates a variety of event types depending on the traffic it analyzes.

Understanding these categories helps analysts quickly determine the nature of a security incident.

Intrusion Attempts

Intrusion-related alerts indicate attempts to exploit vulnerabilities or gain unauthorized access to systems.

Examples include:

• Remote code execution attempts
• Exploit kit activity
• SQL injection attacks
• Vulnerability scanning
• Brute-force attacks

These alerts often warrant immediate investigation because they indicate active attack behavior.

Malware Communication

Suricata can detect network traffic associated with known malware families.

Common examples include:

• Command-and-control traffic
• Botnet communications
• Malware downloads
• Beaconing behavior
• Known malicious domains

According to the CISA Known Exploited Vulnerabilities Catalog, attackers frequently leverage known vulnerabilities combined with malware delivery infrastructure, making these alerts especially valuable for early detection.

Port Scanning Activity

Port scans are often one of the first steps attackers perform when targeting an environment.

Suricata can detect:

• SYN scans
• TCP connect scans
• UDP scans
• Service enumeration attempts
• Network reconnaissance activity

While not always malicious, repeated scanning activity can indicate an attacker mapping the environment before launching additional attacks.

DNS Threats

DNS traffic often contains indicators of compromise.

Suricata can identify:

• DNS tunneling
• Connections to malicious domains
• Domain Generation Algorithms (DGA)
• Suspicious DNS requests
• DNS-based data exfiltration

These detections can reveal malware activity even when other network traffic appears normal.

Web Application Attacks

Web-facing applications are frequent attack targets.

Suricata signatures can identify:

• SQL injection attempts
• Cross-site scripting (XSS)
• Directory traversal attacks
• Remote file inclusion
• Exploitation of vulnerable applications

Organizations hosting public web services should closely monitor these alerts.

Suspicious Network Connections

Not all threats match known malware signatures.

Suricata can also detect anomalous network behavior such as:

• Unexpected outbound traffic
• Connections to high-risk countries
• Unusual protocol usage
• Traffic on uncommon ports
• Potential lateral movement

These alerts often provide early indicators of compromise before malware signatures are triggered.

Key Fields Found in Suricata Events

When Suricata alerts are ingested into Wazuh, they typically contain several important fields.

Common fields include:

Example event:

{
  "event_type": "alert",
  "src_ip": "10.10.1.15",
  "dest_ip": "203.0.113.20",
  "proto": "TCP",
  "alert": {
    "signature": "ET MALWARE Known C2 Traffic",
    "severity": 1
  }
}

These fields become particularly useful when building custom dashboards and detection rules.

Creating Custom Detection Rules

The default Wazuh and Suricata rule sets provide strong coverage for many attack scenarios.

However, every environment has unique requirements that may require additional detections.

Custom rules allow security teams to prioritize important alerts, reduce noise, and improve threat visibility.

For a comprehensive guide to Wazuh rule development, see How to Create Custom Detection Rules in Wazuh (With Examples).

Why Create Custom Rules?

Default detection rules are designed to work across many environments.

However, organizations often need custom logic to:

• Highlight critical assets
• Prioritize high-value systems
• Escalate specific Suricata signatures
• Reduce false positives
• Detect organization-specific threats
• Support compliance requirements

For example, a financial institution may want all outbound traffic to known command-and-control servers immediately escalated to critical severity.

Adding Custom Wazuh Rules for Suricata Alerts

Custom Wazuh rules are typically added to:

/var/ossec/etc/rules/local_rules.xml

Open the file:

sudo nano /var/ossec/etc/rules/local_rules.xml

Custom rules can be created to match fields contained within Suricata events.

After making changes, restart the Wazuh Manager:

sudo systemctl restart wazuh-manager

Example Rule for High-Severity Threats

The following example elevates high-severity Suricata alerts.

<group name="suricata_custom">

  <rule id="100500" level="12">
    <if_group>suricata</if_group>
    <field name="alert.severity">1</field>
    <description>Critical Suricata Threat Detected</description>
  </rule>

</group>

This rule:

• Matches Suricata events
• Looks for severity level 1 alerts
• Raises the Wazuh alert level
• Improves analyst visibility

Organizations often use similar rules to prioritize malware and exploitation activity.

Creating Rules Based on Specific Signatures

You can also target individual Suricata signatures.

Example:

<group name="suricata_custom">

  <rule id="100501" level="15">
    <if_group>suricata</if_group>
    <field name="alert.signature">.*C2 Traffic.*</field>
    <description>Potential Command-and-Control Communication</description>
  </rule>

</group>

This rule specifically matches signatures containing:

C2 Traffic

Additional use cases include:

• Malware families
• Ransomware indicators
• DNS tunneling detections
• Vulnerability exploitation attempts
• Threat intelligence matches

The Wazuh Rules Syntax Documentation provides detailed guidance on available rule conditions and matching options.

Testing Custom Rules

After creating a rule, validate it before deploying to production.

Wazuh includes a useful testing utility:

sudo /var/ossec/bin/wazuh-logtest

Paste a sample Suricata event into the tool.

Example:

{
  "event_type":"alert",
  "alert":{
    "signature":"Known C2 Traffic",
    "severity":1
  }
}

Verify that:

• The rule matches successfully
• The expected alert level is assigned
• No syntax errors are present

Testing helps prevent rule misconfigurations that could result in missed detections or excessive alert noise.

Using Wazuh Dashboards to Monitor Suricata Events

One of the biggest advantages of integrating Suricata with Wazuh is the ability to visualize network security events through centralized dashboards.

Dashboards help analysts identify threats, monitor trends, and investigate incidents more efficiently.

Accessing Security Events

Log in to the Wazuh Dashboard and navigate to:

Security Events → Events

Here you can search for:

suricata

or filter based on specific fields such as:

• Source IP
• Destination IP
• Signature name
• Severity level
• Event type

This provides a centralized view of all Suricata detections being collected by Wazuh.

Building Custom Dashboards

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

Popular dashboard widgets include:

• Total Suricata alerts
• Top attack sources
• Most frequent signatures
• Alert severity distribution
• Geographic threat activity
• Attack trends over time

The OpenSearch Dashboards Documentation offers additional guidance on creating advanced visualizations within the Wazuh ecosystem.

Organizations comparing monitoring platforms may also find our Wazuh vs OpenSearch article useful.

Filtering by Severity

Severity filtering helps analysts focus on the highest-risk events first.

Common filters include:

Many SOC teams create dedicated dashboards that display only critical and high-severity alerts.

This reduces distractions and improves response efficiency.

Tracking Attack Trends

Historical analysis can reveal patterns that may not be obvious from individual alerts.

Useful trend metrics include:

• Daily alert volume
• Weekly attack frequency
• Monthly threat trends
• Malware activity spikes
• Reconnaissance attempts over time

Trend analysis helps identify:

• Persistent attackers
• Seasonal attack patterns
• Changes in threat activity
• Emerging risks

Monitoring Top Threat Sources

Tracking the most active attack sources can help prioritize defensive efforts.

Common metrics include:

• Top source IPs
• Top destination systems
• Most active countries
• Most common malware signatures
• Most frequently targeted services

This information assists security teams in:

• Threat hunting
• Firewall tuning
• Blocklist management
• Incident prioritization

Creating Visualizations and Reports

Wazuh dashboards support a variety of visualizations, including:

• Bar charts
• Pie charts
• Heat maps
• Data tables
• Time-series graphs
• Geographic maps

Useful reports often include:

• Executive security summaries
• Weekly threat activity reports
• Incident response metrics
• Compliance reporting
• Threat intelligence findings

By combining Suricata detections with endpoint, authentication, and file integrity monitoring data, organizations gain a comprehensive view of their security posture from a single platform.

For even greater visibility into endpoint activity, consider implementing How to Configure File Integrity Monitoring (FIM) in Wazuh alongside your Suricata integration.

Automating Incident Response

Detecting threats is only part of an effective security strategy.

The ability to respond quickly can significantly reduce the impact of an attack.

One of the major advantages of integrating Wazuh with Suricata is the ability to automate responses when high-confidence threats are detected.

Rather than relying solely on manual investigation, organizations can use Wazuh’s Active Response framework to contain threats immediately.

Using Wazuh Active Response

Wazuh Active Response enables automated actions to be executed when specific alert conditions are met.

Common response actions include:

• Blocking malicious IP addresses
• Disabling compromised accounts
• Terminating suspicious processes
• Triggering custom scripts
• Sending notifications
• Integrating with external security tools

When combined with Suricata alerts, Active Response can help stop attacks before they escalate.

For example, if Suricata detects communication with a known command-and-control server, Wazuh can automatically block the source or destination IP address.

The Wazuh Active Response Documentation provides detailed guidance on available response mechanisms.

Blocking Malicious IP Addresses Automatically

One of the most common Active Response use cases is automatically blocking malicious IP addresses.

Example workflow:

1. Suricata detects malicious traffic.
2. Wazuh receives the alert.
3. A custom rule identifies the event as high risk.
4. Active Response executes a firewall block action.
5. Future communication is prevented.

This approach is particularly effective against:

• Port scanners
• Brute-force attackers
• Known malware hosts
• Command-and-control servers
• Threat intelligence matches

Organizations should carefully test automated blocking policies to avoid disrupting legitimate traffic.

Triggering Firewall Rules

Wazuh can integrate with operating system firewalls and security controls to enforce automated network restrictions.

Common firewall integrations include:

• iptables
• nftables
• firewalld
• Windows Defender Firewall
• Cloud security groups

Example use cases:

• Block repeated intrusion attempts
• Prevent outbound malware communications
• Restrict access from malicious IP ranges
• Isolate compromised systems

This allows organizations to move from passive detection to active threat containment.

Sending Notifications to Security Teams

Not every alert should trigger automated blocking.

In many environments, notification-based responses are more appropriate.

Wazuh can notify security teams through:

• Email alerts
• Slack channels
• Microsoft Teams
• Webhooks
• Ticketing systems
• SOC workflows

Notifications can include:

• Alert severity
• Source and destination IPs
• Suricata signature details
• Affected systems
• Recommended response actions

According to the SANS Institute, timely alerting and escalation procedures remain critical components of effective incident response programs.

Integrating with External Security Tools

Many organizations operate a broader security ecosystem that extends beyond Wazuh and Suricata.

Common integrations include:

• Threat intelligence platforms
• SOAR solutions
• Case management systems
• Ticketing platforms
• Vulnerability scanners
• Endpoint security tools

Examples:

• Create an incident ticket automatically.
• Enrich alerts with threat intelligence.
• Trigger orchestration playbooks.
• Notify incident response teams.
• Launch forensic investigations.

Organizations already using threat intelligence can also enhance detections through How to Integrate Wazuh with VirusTotal for Threat Intelligence.

Best Practices for Wazuh and Suricata Integration

A successful integration requires more than simply forwarding logs. Proper tuning and maintenance ensure the platform remains effective as threats evolve.

The following best practices can help maximize detection quality while minimizing operational overhead.

Keep Suricata Rules Updated

Threats change constantly, and outdated signatures can leave detection gaps.

Regularly update your Suricata rulesets to ensure coverage for:

• New malware families
• Emerging vulnerabilities
• Recent attack techniques
• Updated threat intelligence indicators

Most organizations use the Emerging Threats Ruleset to keep detections current.

Automated rule updates should be incorporated into routine maintenance procedures.

Monitor High-Severity Alerts First

Security teams often receive more alerts than they can immediately investigate.

Prioritize:

• Severity 1 alerts
• Severity 2 alerts
• Malware detections
• Exploitation attempts
• Command-and-control activity

Focusing on the highest-risk events improves response efficiency and reduces the likelihood of overlooking critical threats.

Tune Detection Rules to Reduce False Positives

Excessive alert noise can overwhelm analysts and hide genuine threats.

Common tuning techniques include:

• Disabling noisy signatures
• Creating exceptions for trusted systems
• Adjusting alert thresholds
• Refining custom Wazuh rules
• Filtering benign traffic patterns

The goal is to improve signal-to-noise ratio without reducing meaningful visibility.

Enable Log Retention for Investigations

Security investigations often require access to historical data.

Organizations should retain:

• Suricata alerts
• Endpoint events
• Authentication logs
• File integrity events
• Threat intelligence matches

Log retention helps support:

• Incident response
• Threat hunting
• Compliance audits
• Forensic investigations

Retention requirements will vary depending on regulatory and business needs.

Create Custom Correlation Rules

Correlating network and endpoint telemetry is one of the biggest advantages of the integration.

Examples include:

• Suricata malware alert + suspicious process execution
• Port scan + failed login attempts
• Exploit attempt + file modification event
• DNS tunneling + unusual outbound traffic

These correlation rules provide richer context and help analysts identify complex attacks more quickly.

Review Alert Trends Regularly

Individual alerts provide tactical insights, but trends reveal strategic risks.

Review metrics such as:

• Alert volume over time
• Most active attack sources
• Most common signatures
• Frequently targeted assets
• Repeated attack campaigns

Trend analysis helps identify emerging threats and prioritize security improvements.

Test Detection Capabilities Periodically

Detection rules should be validated regularly.

Organizations should perform:

• Controlled attack simulations
• Red team exercises
• Purple team assessments
• Rule validation testing
• Alert verification exercises

The MITRE ATT&CK Evaluations demonstrate the importance of continuously validating security controls against realistic attack techniques.

Periodic testing ensures that alerts continue functioning as expected after updates or configuration changes.

Troubleshooting Common Issues

Even well-configured integrations can encounter issues.

The following troubleshooting steps address the most common problems encountered when integrating Wazuh and Suricata.

Wazuh Is Not Receiving Suricata Logs

If no Suricata events appear in Wazuh:

Verify the EVE JSON file exists:

ls -lah /var/log/suricata/eve.json

Confirm the Wazuh Agent is monitoring the correct file:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

Check agent status:

sudo systemctl status wazuh-agent

Review logs:

sudo tail -f /var/ossec/logs/ossec.log

Suricata Alerts Are Missing from Wazuh

Sometimes Wazuh receives logs but no alerts are generated.

Possible causes include:

• Suricata is not generating alert events.
• Relevant signatures are disabled.
• Traffic is not matching rules.
• Alert rules are improperly configured.

Verify Suricata is producing alerts:

grep alert /var/log/suricata/eve.json

Generate test traffic and confirm alerts appear locally before troubleshooting Wazuh.

JSON Parsing Errors

Malformed JSON can prevent Wazuh from processing events correctly.

Common causes include:

• Corrupted log files
• Improper log rotation
• Invalid custom output configurations
• Truncated JSON records

Validate JSON structure:

jq . /var/log/suricata/eve.json

Review Wazuh logs for parser-related errors.

Permission Denied Errors

Permission problems are common when the Wazuh Agent cannot access Suricata logs.

Check permissions:

ls -lah /var/log/suricata/

Verify the Wazuh user can read:

/var/log/suricata/eve.json

Adjust ownership or permissions if necessary:

sudo chmod 644 /var/log/suricata/eve.json

Use the principle of least privilege when modifying permissions.

High Resource Usage

Both Wazuh and Suricata can consume significant resources in high-volume environments.

Common optimization strategies include:

• Reduce unnecessary Suricata event types.
• Disable unused signatures.
• Increase hardware resources.
• Tune packet capture settings.
• Archive older logs.

Monitor:

top

or:

htop

to identify bottlenecks.

The Suricata Performance Documentation provides additional tuning recommendations.

Excessive False Positives

False positives can reduce analyst effectiveness and increase alert fatigue.

To reduce noise:

• Disable problematic signatures.
• Create alert exceptions.
• Tune custom Wazuh rules.
• Adjust severity levels.
• Whitelist trusted systems.

Regular review of alert quality should be part of ongoing security operations.

Custom Rules Not Triggering

If custom rules fail to generate alerts:

Verify the rule syntax:

sudo /var/ossec/bin/wazuh-logtest

Check:

• Rule IDs are unique.
• Field names match actual Suricata events.
• XML formatting is valid.
• The Wazuh Manager was restarted after changes.

Example:

sudo systemctl restart wazuh-manager

If troubleshooting reveals issues with rule development, revisit How to Create Custom Detection Rules in Wazuh (With Examples) for detailed guidance on building and testing custom detections.

By following these troubleshooting practices, most Wazuh-Suricata integration issues can be identified and resolved quickly, ensuring consistent visibility into network-based threats and security events.

Wazuh vs Suricata: Understanding Their Roles

A common misconception is that Wazuh and Suricata compete with one another.

In reality, they solve different security problems and are often deployed together as part of a layered defense strategy.

Understanding the distinct role of each platform helps security teams design more effective monitoring and detection architectures.

How Wazuh and Suricata Complement Each Other

Suricata specializes in monitoring network traffic, while Wazuh focuses on collecting, correlating, and analyzing security events from across an organization’s infrastructure.

Think of Suricata as the sensor that detects suspicious network activity and Wazuh as the platform that centralizes, enriches, and investigates those findings.

A typical workflow looks like this:

1. Suricata inspects network traffic.
2. Suricata detects suspicious activity.
3. Suricata generates an alert.
4. Wazuh ingests the alert.
5. Wazuh correlates it with endpoint and log data.
6. Analysts investigate the event through a centralized dashboard.

This layered approach provides significantly greater visibility than either tool can offer independently.

For organizations comparing the two platforms directly, see Suricata vs Wazuh.

IDS vs SIEM/XDR Functionality

The biggest difference between Wazuh and Suricata is their primary function.

Suricata excels at:

• Deep packet inspection
• Network threat detection
• Protocol analysis
• Intrusion detection
• Intrusion prevention

Wazuh excels at:

• Security event management
• Threat correlation
• Endpoint visibility
• Compliance monitoring
• Incident response automation

According to the NIST Cybersecurity Framework, effective security monitoring relies on multiple detection layers rather than a single technology, making IDS and SIEM/XDR platforms highly complementary.

Why Organizations Deploy Both Together

Modern attacks often leave evidence across multiple systems.

For example:

Using both platforms together enables organizations to:

• Detect attacks earlier
• Improve incident investigations
• Correlate network and endpoint activity
• Reduce blind spots
• Accelerate incident response

Security teams that combine network telemetry and endpoint monitoring generally achieve better threat detection outcomes than teams relying on either data source alone.

Frequently Asked Questions

Question: Does Wazuh include Suricata by default?

No.

Wazuh and Suricata are separate open-source projects.

A standard Wazuh installation does not automatically deploy Suricata.

To use the integration, you must:

1. Install Suricata separately.
2. Configure EVE JSON logging.
3. Configure the Wazuh Agent to collect Suricata events.
4. Validate that alerts are reaching the Wazuh Manager.

Once configured, Wazuh can analyze and correlate Suricata alerts alongside other security telemetry.

Question: Can Wazuh automatically respond to Suricata alerts?

Yes.

Using Wazuh Active Response, organizations can automate actions based on Suricata detections.

Examples include:

• Blocking malicious IP addresses
• Triggering firewall rules
• Sending notifications
• Executing custom scripts
• Launching security workflows

These automated responses can significantly reduce containment times during active incidents.

Question: Does this integration work with Suricata IPS mode?

Yes.

The integration works whether Suricata is deployed as:

• IDS (Intrusion Detection System)
• IPS (Intrusion Prevention System)
• Network Security Monitoring (NSM) platform

In IPS mode, Suricata can actively block malicious traffic while simultaneously forwarding alert data to Wazuh for analysis and investigation.

This combination provides both prevention and visibility.

Question: Can I monitor multiple Suricata sensors with one Wazuh Manager?

Yes.

Many enterprise deployments use a centralized Wazuh Manager to collect events from multiple Suricata sensors.

Common architectures include:

• Multiple branch offices
• Distributed data centers
• Hybrid cloud environments
• Segmented network zones

Each sensor can run its own Wazuh Agent and forward alerts to a central Wazuh deployment.

This architecture allows security teams to monitor large environments from a single dashboard.

Question: What log format does Wazuh require from Suricata?

The recommended format is:

EVE JSON

EVE JSON provides structured event data that Wazuh can easily parse and analyze.

Typical configuration:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

While Suricata supports additional logging formats, EVE JSON is considered the standard for SIEM integrations.

The Suricata Documentation recommends EVE JSON for advanced logging and integration use cases.

Question: Is the integration suitable for enterprise environments?

Absolutely.

Many enterprises use Wazuh and Suricata together because they provide:

• Scalable architecture
• Centralized monitoring
• Network visibility
• Endpoint visibility
• Automated response capabilities
• Compliance reporting
• Cost-effective deployment

Because both platforms are open source, organizations can build enterprise-grade detection and response capabilities without the licensing costs associated with many commercial SIEM and NDR solutions.

Large deployments often incorporate:

• Multiple Wazuh Managers
• Load-balanced indexing clusters
• Multiple Suricata sensors
• Threat intelligence integrations
• Security orchestration workflows

Conclusion

Integrating Wazuh with Suricata creates a powerful security monitoring solution that combines network intrusion detection with centralized security analytics and incident response capabilities.

Throughout this guide, we covered how to:

• Install Suricata
• Configure EVE JSON logging
• Collect Suricata alerts with Wazuh
• Validate the integration
• Create custom detection rules
• Build monitoring dashboards
• Automate incident response
• Troubleshoot common issues

By combining these technologies, organizations gain several important security advantages:

• Enhanced threat detection accuracy
• Centralized security monitoring
• Improved network visibility
• Faster incident investigations
• Automated response capabilities
• Reduced alert fatigue through event correlation

Security monitoring is not a one-time deployment. Threat landscapes continuously evolve, which means detection content, correlation rules, and response procedures must evolve as well.

Security teams should regularly:

• Update Suricata signatures
• Review alert trends
• Tune noisy detections
• Validate custom rules
• Test incident response workflows
• Conduct threat-hunting exercises

For organizations looking to further strengthen their Wazuh deployment, useful next steps include implementing How to Configure File Integrity Monitoring (FIM) in Wazuh, integrating How to Integrate Wazuh with VirusTotal for Threat Intelligence, and learning How to Create Custom Detection Rules in Wazuh (With Examples) to build more advanced threat detection capabilities.

When properly configured and maintained, the Wazuh-Suricata integration provides a highly effective, cost-efficient foundation for modern threat detection, security monitoring, and incident response operations.