# Suricata IDS/IPS in pfSense - Intrusion Detection

> Installing and configuring Suricata IDS/IPS in pfSense - rule sources, blocking modes, EVE JSON logging, pass lists, and Wazuh SIEM integration

Source: https://opennix.org/en/docs/pfsense/packages/pfsense-suricata/


Suricata is a high-performance intrusion detection and prevention engine (IDS/IPS) that processes network traffic in real time. In pfSense, Suricata is installed as a package and provides deep packet inspection (DPI), signature-based threat detection, protocol analysis, and EVE JSON logging. Unlike the firewall, which operates at the IP address and port level, Suricata analyzes traffic content - detecting exploitation attempts, port scanning, malicious code transfer, and protocol anomalies.

Suricata supports two operating modes: IDS (Intrusion Detection System) for detection and logging only, and IPS (Intrusion Prevention System) for active blocking of malicious traffic. The choice depends on security requirements and acceptable impact on network traffic.

## Installing Suricata

Installation is performed through the package manager:

1. Navigate to **System > Package Manager > Available Packages**
2. Search for **suricata** in the search field
3. Click **Install** and confirm the installation
4. Wait for the installation to complete

After installation, Suricata configuration is accessible at **Services > Suricata**.

### System Requirements

Suricata demands significant resources, particularly when processing high traffic volumes:

| Parameter | Minimum | Recommended |
|---|---|---|
| **RAM** | 2 GB | 4 GB or more |
| **CPU** | 2 cores | 4 cores or more |
| **Disk** | 10 GB free space | 20 GB (for log storage) |

Memory consumption depends on the number of loaded rules and the volume of analyzed traffic. Enabling all rule categories may push RAM usage beyond 4 GB.

## Global Settings

Initial configuration begins on the **Global Settings** tab (**Services > Suricata > Global Settings**), where rule sources and general parameters are defined.

### Rule Sources

Suricata uses signature sets (rules) to detect known threats. Each source contains thousands of rules organized into categories.

| Source | Description | Registration Required |
|---|---|---|
| **ET Open** | Emerging Threats Open - free signature set by Proofpoint | No |
| **ET Pro** | Extended commercial Emerging Threats set | Yes (Oink Code) |
| **Snort VRT** | Cisco Talos rule set (Snort Subscriber Rules) | Yes (Oink Code) |
| **Snort Community** | Free Snort rule set with delayed updates | No |
| **Feodo Tracker** | Rules for detecting banking trojan C2 servers | No |
| **ETPRO Telemetry** | Telemetry data for improving ET Pro | No |

To use paid sources, obtain an Oink Code from the provider's website and enter it in the corresponding field on the **Global Settings** tab.

### Rule Update Interval

The **Update Interval** parameter controls automatic rule download frequency. Recommended values:

| Interval | Scenario |
|---|---|
| **6 Hours** | Environments with elevated security requirements |
| **12 Hours** | Standard deployments |
| **1 Day** | Environments with limited bandwidth |

The initial rule download must be performed manually through the **Updates** tab after configuring sources.

## Interface Configuration

Suricata binds to pfSense network interfaces and analyzes traffic on each independently. Interface configuration is performed through **Services > Suricata > Interfaces**.

### Adding an Interface

1. Navigate to **Services > Suricata > Interfaces**
2. Click **Add** to add a new interface
3. Select the network interface from the list (WAN, LAN, OPT1, etc.)
4. Check **Enable** to activate
5. Configure parameters and click **Save**

### Selecting Interfaces for Monitoring

| Interface | Recommendations |
|---|---|
| **WAN** | Essential - analyzes inbound internet traffic, detects external attacks |
| **LAN** | Recommended - detects internal threats, lateral movement, C2 communications |
| **DMZ** | Recommended - protects servers in the demilitarized zone |
| **VPN** | As needed - analyzes VPN tunnel traffic |

> **Warning**:
>
> Each additional monitored interface increases resource consumption. On resource-constrained systems, start with the WAN interface and add others as required.

### Core Interface Parameters

| Parameter | Description |
|---|---|
| **Enable** | Activate Suricata on this interface |
| **Send Alerts to System Log** | Duplicate alerts to the pfSense system log |
| **Block Offenders** | Enable IPS mode - block sources of malicious traffic |
| **IPS Mode** | Blocking mode: Legacy Mode or Inline Mode |
| **Kill States** | Terminate active sessions when blocking an IP address |
| **Which IP to Block** | Which address to block: SRC, DST, or BOTH |

## Blocking Modes

Suricata in pfSense supports two intrusion prevention modes that differ in their blocking mechanism.

### Legacy Mode

In Legacy Mode, Suricata operates as a classic IDS with blocking capability. When a rule triggers, the offending IP address is added to the pf blocking table (snort2c). All subsequent packets from that address are dropped by the firewall until the blocking timeout expires.

Legacy Mode characteristics:

- The first malicious packet passes through (blocking occurs after detection)
- All traffic from the offending IP is blocked, including legitimate traffic
- False blocks are possible when rules trigger on legitimate traffic
- Lower resource consumption compared to Inline Mode

### Inline Mode

In Inline Mode, Suricata inserts itself directly into the packet path through the firewall using netmap. Every packet passes through the Suricata engine before a pass or drop decision is made.

Inline Mode characteristics:

- Malicious packets are dropped before reaching their destination
- Only malicious packets are blocked, not all traffic from the IP address
- More precise threat prevention
- Higher resource consumption and potential latency increase
- Requires rules with `drop` action instead of `alert`

To activate Inline Mode:

1. On the interface configuration tab, set **IPS Mode** to **Inline Mode**
2. Ensure rules with `drop` action are enabled
3. Restart Suricata on the interface

> **Warning**:
>
> Inline Mode adds latency to every packet processed. On systems with insufficient performance, this may slow network connections. Test under load before enabling Inline Mode in production environments.

## Rule Management

### Rule Categories

Rules are organized into categories by the type of threat detected. Category management is performed on the **Categories** tab for each interface.

Key ET Open categories:

| Category | Description |
|---|---|
| **emerging-attack_response** | Responses indicating a successful attack |
| **emerging-botcc** | Communications with known botnet servers |
| **emerging-ciarmy** | IP addresses from the CI Army list |
| **emerging-compromised** | Known compromised hosts |
| **emerging-current_events** | Current threats (updated frequently) |
| **emerging-dns** | Anomalous DNS queries and DNS tunneling |
| **emerging-dos** | DoS/DDoS attack detection |
| **emerging-exploit** | Exploitation of known vulnerabilities |
| **emerging-malware** | Malware and related traffic |
| **emerging-policy** | Corporate policy violations (torrents, anonymizers) |
| **emerging-scan** | Port scanning and network reconnaissance |
| **emerging-trojan** | Trojans and backdoors |
| **emerging-web_client** | Attacks targeting web browsers and client software |
| **emerging-web_server** | Web server attacks (SQL injection, XSS, RCE) |

### Enabling and Disabling Categories

The **Categories** tab displays the complete list of available categories with checkboxes. For standard deployments, enabling the following is recommended:

- All `emerging-malware`, `emerging-trojan`, `emerging-exploit` categories
- The `emerging-botcc` and `emerging-compromised` categories
- The `emerging-scan` category for reconnaissance detection
- The `emerging-web_server` category when web servers are present on the network

The `emerging-policy` and `emerging-games` categories should only be enabled when network usage policy enforcement is required.

### SID Management

SID Management allows controlling individual rules by their unique identifier (SID) without disabling entire categories.

Configuration is performed through **Services > Suricata > SID Mgmt**.

| Action | File | Format |
|---|---|---|
| **Disable rules** | disablesid.conf | `SID` or `SID1, SID2, SID3` |
| **Enable rules** | enablesid.conf | `SID` or `SID1, SID2, SID3` |
| **Change action to drop** | dropsid.conf | `SID` or `SID1, SID2, SID3` |
| **Change action to reject** | rejectsid.conf | `SID` or `SID1, SID2, SID3` |

SID Management files are applied after each rule update, preserving custom modifications across automatic rule set updates.

### Custom Rules

Custom rules are created on the **Rules** tab within the interface settings. Rules follow the Suricata format:

```text
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Custom - Suspicious User-Agent"; http.user_agent; content:"sqlmap"; nocase; classtype:web-application-attack; sid:9000001; rev:1;)
```

Core rule elements:

| Element | Description |
|---|---|
| **action** | Action: `alert`, `drop`, `reject`, `pass` |
| **protocol** | Protocol: `tcp`, `udp`, `http`, `dns`, `tls`, etc. |
| **src/dst** | Source and destination addresses (variables `$HOME_NET`, `$EXTERNAL_NET`) |
| **msg** | Alert description message |
| **content** | Pattern to match within packet content |
| **sid** | Unique rule identifier (use SID > 9000000 for custom rules) |
| **classtype** | Threat classification type |

## Pass Lists

Pass lists define IP addresses whose traffic is exempt from IPS blocking when rules trigger. Addresses on the pass list continue to be analyzed by Suricata and alerts are generated, but automatic blocking is not applied.

### Configuring Pass Lists

Configuration is performed on the **Pass Lists** tab (**Services > Suricata > Pass Lists**).

1. Click **Add** to create a new pass list
2. Specify the name and description
3. Add IP addresses or subnets in the appropriate fields
4. Save and assign the pass list to an interface

### Preset Entries

A pass list can automatically include:

| Parameter | Description |
|---|---|
| **Add Firewall Aliases** | Import aliases from firewall rules |
| **Add Virtual IP Addresses** | Include virtual IP addresses (CARP, IP Alias) |
| **Add VPN Addresses** | VPN client and server addresses |
| **Add Locally Assigned Addresses** | pfSense interface IP addresses |

### Usage Recommendations

The pass list should include:

- IP addresses of critical servers where blocking is unacceptable
- Addresses of internal monitoring systems performing scans
- ISP gateways and DNS servers
- Addresses of partner organizations with intensive traffic

> **Warning**:
>
> A pass list does not disable detection - alerts continue to be generated. It only prevents automatic blocking. This allows traffic analysis without risking disruption to critical services.

## EVE JSON Logging

EVE (Extensible Event Format) is Suricata's primary logging format, writing events in structured JSON format. Each log line contains the full event context, simplifying parsing and integration with SIEM systems.

### Enabling EVE JSON

On the interface configuration tab under **Logging Settings**:

1. Set **EVE JSON Log** to **Enabled**
2. Select event types for logging
3. Configure file rotation

### EVE Event Types

| Type | Description | File |
|---|---|---|
| **Alerts** | Detection rule triggers | eve.json |
| **HTTP** | HTTP request metadata (URL, User-Agent, status) | eve.json |
| **DNS** | DNS queries and responses | eve.json |
| **TLS** | TLS connection metadata (SNI, certificates) | eve.json |
| **Files** | Information about transferred files | eve.json |
| **Drop** | Dropped packets (in Inline Mode) | eve.json |
| **Flow** | Network connection metadata | eve.json |
| **Stats** | Engine performance statistics | eve.json |

### EVE JSON Log Example

```json
{
  "timestamp": "2024-03-15T10:23:45.123456+0000",
  "flow_id": 1234567890,
  "event_type": "alert",
  "src_ip": "192.168.1.100",
  "src_port": 52341,
  "dest_ip": "203.0.113.50",
  "dest_port": 443,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 2024897,
    "rev": 3,
    "signature": "ET TROJAN Observed Malicious SSL Certificate",
    "category": "A Network Trojan was detected",
    "severity": 1
  }
}
```

### Log Location

Suricata logs are stored in the `/var/log/suricata/suricata_<interface>` directory. A separate subdirectory is created for each interface.

## Viewing Alerts

Suricata alerts are displayed in several locations:

### Alerts Tab

**Services > Suricata > Alerts** is the primary alert viewing page with filtering by interface, priority, and time. Each alert displays:

- Trigger time
- Priority (1 - critical, 4 - informational)
- Protocol, source and destination IP addresses and ports
- Rule description (message)
- Rule SID

The alerts interface supports the following actions:

- Add the IP address to a pass list
- Disable the rule by SID
- View rule details

### Blocked IP Addresses

**Services > Suricata > Blocks** displays the list of IP addresses blocked in IPS mode. Each blocked address shows:

- IP address
- Block time
- SID of the triggering rule
- Rule description

Blocked addresses can be manually unblocked from this page or allowed to expire automatically based on the block timeout.

### Dashboard Widget

Suricata adds a widget to the pfSense **Dashboard** showing the current service status on each interface and alert counts.

## Suricata Variables

Variables define address ranges used in rules to identify internal and external networks.

| Variable | Description | Default Value |
|---|---|---|
| **$HOME_NET** | Internal networks (protected) | Subnets of all pfSense interfaces |
| **$EXTERNAL_NET** | External networks | `!$HOME_NET` (everything except internal) |
| **$HTTP_SERVERS** | Web servers on the internal network | `$HOME_NET` |
| **$DNS_SERVERS** | DNS servers | `$HOME_NET` |
| **$SMTP_SERVERS** | Mail servers | `$HOME_NET` |
| **$SQL_SERVERS** | Database servers | `$HOME_NET` |

Variable configuration is performed on the interface configuration tab under **Variables**. For improved detection accuracy, specifying actual server IP addresses rather than using default values is recommended.

## Performance Tuning

### Multi-Threading

Suricata supports multi-threaded traffic processing. Thread configuration is performed on the interface tab under **Detection Engine Settings**.

| Parameter | Description | Recommendation |
|---|---|---|
| **Detect-Engine Profile** | Memory usage profile | **Medium** for most deployments |
| **Pattern Matcher Algorithm** | Pattern matching algorithm | **AC** (Aho-Corasick) for maximum performance |
| **Stream Memory Cap** | Memory limit for stream reassembly | 64 MB (increase for high traffic) |

### Hardware Offloading

For Suricata to operate in Inline Mode, hardware packet processing acceleration must be disabled on network interfaces:

1. Navigate to **System > Advanced > Networking**
2. Check **Disable Hardware Checksum Offload**, **Disable Hardware TCP Segmentation Offload**, **Disable Hardware Large Receive Offload**
3. Click **Save** and reboot pfSense

> **Warning**:
>
> Disabling hardware offloading reduces network interface throughput but is necessary for correct Suricata operation in deep packet inspection mode. Without disabling these features, Suricata may miss fragmented packets or receive incorrect checksums.

### Optimization Recommendations

- Enable only necessary rule categories - each category consumes memory
- Use SID Management to disable rules generating false positives
- Configure log rotation to prevent disk space exhaustion
- On systems with limited RAM, select the **Low** profile for Detect-Engine
- Monitor resource consumption through **Status > System Activity**

## Wazuh Integration

Suricata generates logs in EVE JSON format, which Wazuh supports for decoding and analysis. Integration provides centralized IDS/IPS alert monitoring, correlation with other security events, and extended alerting.

### Log Forwarding Configuration

To send Suricata alerts to Wazuh, configure syslog forwarding or install the Wazuh Agent on pfSense:

1. Configure EVE JSON logging with the **Alerts** type enabled
2. Set up log forwarding via syslog (**Status > System Logs > Settings**) or through the Wazuh Agent
3. Ensure the Wazuh Agent configuration specifies the EVE JSON file path: `/var/log/suricata/suricata_<interface>/eve.json`

Detailed integration instructions are available in [pfSense Wazuh Integration](/docs/pfsense/pfsense-wazuh-integration/).

### Wazuh Rules for Suricata

Wazuh includes a built-in rule set for decoding and classifying Suricata alerts (rule group `suricata`). Alerts are automatically enriched with MITRE ATT&CK information and classified by severity levels.

## Troubleshooting

### Suricata Fails to Start

1. Check system logs: **Status > System Logs > System**
2. Verify that rules are downloaded: **Services > Suricata > Updates**
3. Check available memory: **Status > System Activity**
4. If encountering `PCRE-based rules not loading`, increase the memory limit in interface settings

### High False Positive Rate

1. Start with IDS mode (no blocking) to study traffic patterns
2. Add legitimate servers and services to the pass list
3. Use SID Management to disable rules with frequent false positives
4. Configure `$HOME_NET` and server variables as precisely as possible
5. Review the `emerging-policy` and `emerging-games` categories - they frequently generate false alerts in corporate networks

### Rules Not Triggering

1. Verify that the rule category is enabled on the **Categories** tab
2. Check that the rule is not disabled in SID Management
3. Confirm that traffic passes through the interface where Suricata is running
4. Verify `$HOME_NET` and `$EXTERNAL_NET` variables - the traffic direction in the rule must match reality
5. When using HTTPS, confirm that the rule supports TLS metadata analysis (SNI, JA3)

### Network Performance Degradation

1. Check CPU load through **Status > System Activity**
2. Reduce the number of enabled rule categories
3. In Legacy Mode, increase the blocking timeout to reduce the blocking table load
4. Consider switching from Inline Mode to Legacy Mode when resources are insufficient
5. Disable logging for event types not used for analysis (Flow, Stats)

### Legitimate Traffic Blocked

1. Check the blocked address list: **Services > Suricata > Blocks**
2. Manually unblock the address
3. Identify the SID of the triggering rule
4. Add the address to the pass list or disable the rule through SID Management
5. Consider using `alert` action instead of `drop` for the rule in question

## Suricata vs. Snort Comparison

pfSense offers two IDS/IPS packages: Suricata and Snort. When choosing between them, consider these key differences:

| Parameter | Suricata | Snort |
|---|---|---|
| **Multi-threading** | Built-in support | Limited |
| **Inline IPS** | Supported via netmap | Supported |
| **Protocols** | Extended analysis (HTTP2, TLS, SMB, NFS) | Classic set |
| **Log Format** | EVE JSON (structured) | Unified2, text |
| **Rule Compatibility** | Snort-compatible format + extensions | Native format |
| **Resource Usage** | Higher with multi-threading | Lower at small scale |

Suricata is recommended for new deployments due to its multi-threading capability, extended protocol analysis, and structured logging format.

## Related Sections

- [Package Management](/docs/pfsense/packages/pfsense-package-management/) - installing and updating pfSense packages
- [Firewall Rules](/docs/pfsense/firewall/pfsense-firewall-rules/) - interaction between firewall rules and Suricata blocks
- [pfSense Wazuh Integration](/docs/pfsense/pfsense-wazuh-integration/) - forwarding Suricata alerts to SIEM
- [Firewall Aliases](/docs/pfsense/firewall/pfsense-firewall-aliases/) - using aliases in pass lists
- [Suricata IDS/IPS on VyOS](/docs/vyos/services/vyos-suricata/) - intrusion detection and prevention on the VyOS platform
- [Security Recipes](/docs/pfsense/recipes/pfsense-security-recipes/) - hardening, IDS/IPS, PCI DSS and CIS