Intrusion Detection With Suricata: An Overview

What Suricata Does

Suricata is a network threat detection engine. It sits on your network, inspects traffic as it flows past, and compares what it sees against a database of known attack patterns. When it finds a match, it generates an alert. Optionally, it can block the traffic before it reaches its destination.

Think of it as a customs inspector reading every package that crosses the border. Each package is opened (deep packet inspection), its contents are compared against a list of prohibited items (rule sets), and matching packages are flagged or confiscated. The inspector does not care about the sender or recipient - only whether the contents match a known threat.

Suricata handles multiple protocols natively: HTTP, TLS, DNS, SMB, SSH, FTP, and more. For each protocol, it understands the structure well enough to extract specific fields - HTTP headers, DNS query names, TLS certificate details - and match rules against those fields. This protocol awareness makes it far more effective than simple pattern matching on raw bytes.

IDS vs IPS Mode

Suricata operates in two modes that determine what happens when a threat is detected.

IDS (Intrusion Detection System) mode is passive. Suricata receives a copy of network traffic (via a span port, tap, or packet capture), analyzes it, and generates alerts. The original traffic is unaffected. A detected attack still reaches its target - but you know about it and can respond. IDS mode carries zero risk of breaking legitimate traffic.

IPS (Intrusion Prevention System) mode is inline. Traffic flows through Suricata before reaching its destination. When a rule matches, Suricata can drop the packet, preventing the attack from completing. The upside is automatic blocking. The downside is that false positives - legitimate traffic that triggers a rule incorrectly - get blocked too, potentially breaking applications.

For home networks, start with IDS mode. Run it for several weeks, review the alerts, tune out false positives, and build confidence in the rule set. Switch to IPS mode only after you understand what your rules are flagging and have eliminated noisy false positives.

graph TD
    subgraph "IDS Mode - Passive"
        TRAFFIC_IDS[Network Traffic] --> COPY[Copy of Traffic]
        TRAFFIC_IDS --> DEST_IDS[Destination Device]
        COPY --> SURICATA_IDS[Suricata Engine]
        SURICATA_IDS --> RULES_IDS[Rule Matching]
        RULES_IDS --> ALERT_IDS[Alert Generated]
        ALERT_IDS --> LOG_IDS[Log/Dashboard]
    end
    subgraph "IPS Mode - Inline"
        TRAFFIC_IPS[Network Traffic] --> SURICATA_IPS[Suricata Engine]
        SURICATA_IPS --> RULES_IPS[Rule Matching]
        RULES_IPS -->|No Match| PASS[Pass to Destination]
        RULES_IPS -->|Match - Drop Action| DROP[Packet Dropped]
        RULES_IPS -->|Match - Alert Action| ALERT_IPS[Alert and Pass]
    end

IDS passively monitors a copy of traffic, IPS sits inline and can block threats before they reach the target

Rule Sets and How They Work

Suricata's effectiveness depends entirely on its rules. Rules are text-based patterns that describe network traffic associated with known threats. Without rules, Suricata is an expensive traffic copier.

The primary free rule set is Emerging Threats (ET Open), maintained by Proofpoint. It contains tens of thousands of rules covering malware signatures, exploit attempts, command-and-control communications, policy violations, and more. It is updated multiple times per week.

ET Pro is the commercial version with additional rules and faster updates. For home use, ET Open is comprehensive enough. The Suricata project also maintains its own rule set that complements ET Open.

Rules are organized into categories: malware, exploit, policy, trojan, info-leak, and others. You can enable or disable entire categories. Running all rules generates more alerts (including more false positives) but catches more threats. Disabling noisy categories reduces alert fatigue but creates blind spots.

Anatomy of a Suricata Rule

Understanding rule structure helps you interpret alerts and write custom rules when needed. A Suricata rule has two parts: the header and the options.

The header specifies the action (alert, drop, pass, reject), protocol (tcp, udp, http, dns), source and destination addresses, and ports. The options contain the actual detection logic: content matches, regular expressions, protocol-specific field checks, and metadata.

For example, a simplified rule detecting a DNS query to a known malicious domain might look like: action is alert, protocol is dns, source is any internal address, destination is any, and the option checks whether the DNS query name contains "malware-domain.example." When Suricata sees a DNS query matching that pattern, it generates an alert with the rule's message and severity.

You do not need to write rules for most threats - the community rule sets handle that. But understanding the structure helps when a rule fires and you need to determine whether it is a true positive (actual threat) or false positive (legitimate traffic that looks suspicious).

Deployment Options

Getting traffic to Suricata requires one of three approaches.

Span/mirror port on a managed switch. You configure the switch to copy all traffic from one or more ports to a dedicated monitoring port where your Suricata sensor is connected. This is the cleanest IDS deployment - no changes to the traffic path, no risk of breaking connectivity.

Inline deployment places the Suricata sensor between your router and your network. All traffic flows through it. This is required for IPS mode (blocking) but adds a point of failure - if the Suricata sensor crashes, the network goes down unless you configure a bypass.

Integration with pfSense is the most common home deployment. The Suricata package for pfSense runs directly on the firewall. It inspects traffic on whichever interfaces you configure (usually WAN for inbound threats, LAN for outbound threats). No additional hardware needed. The tradeoff is that Suricata shares CPU and memory with your firewall.

graph TD
    subgraph "Option 1 - Span Port"
        SW1[Managed Switch] -->|Mirrored Traffic| SENSOR1[Suricata Sensor]
        SW1 -->|Normal Traffic| DEVICES1[Network Devices]
    end
    subgraph "Option 2 - Inline"
        ROUTER2[Router] --> SENSOR2[Suricata Sensor]
        SENSOR2 --> SW2[Switch]
        SW2 --> DEVICES2[Network Devices]
    end
    subgraph "Option 3 - pfSense Integration"
        WAN3[WAN Interface] --> PF3[pfSense with Suricata Package]
        PF3 --> LAN3[LAN Interface]
        LAN3 --> DEVICES3[Network Devices]
    end

Three Suricata deployment options - span port for passive monitoring, inline for active blocking, or integrated with pfSense

Performance Considerations

Suricata is computationally expensive. It disassembles every packet, reassembles TCP streams, parses application-layer protocols, and matches against thousands of rules. This takes CPU power.

For a 100 Mbps connection, a modern dual-core CPU handles Suricata comfortably. At 500 Mbps, a quad-core is recommended. At gigabit speeds with full rule sets, you want a modern quad-core with enough single-thread performance (Suricata parallelizes across flows, but each flow is single-threaded).

Memory matters too. Suricata loads all rules into memory and maintains state for every tracked flow. Budget 4 GB minimum, 8 GB if running on pfSense alongside other services. Running out of memory causes Suricata to drop flows - creating blind spots in your monitoring.

If your hardware cannot handle full inspection at line rate, Suricata drops packets rather than slowing the connection (in IDS mode). You lose visibility but not connectivity. In IPS mode, dropped packets mean dropped connections - another reason to start with IDS.

What Suricata Catches

Suricata excels at detecting known threats with established signatures. This includes exploit attempts against known vulnerabilities (buffer overflows, SQL injection, path traversal), malware command-and-control communications using known protocols and patterns, network scanning and reconnaissance activity, policy violations like cleartext password transmission, and data exfiltration indicators like large outbound transfers to unusual destinations.

The ET Open rule set is particularly strong on malware C2 detection. When a compromised device on your network tries to contact its command server, the traffic pattern often matches a known signature. Suricata catches this and alerts you, potentially revealing a compromise that would otherwise go unnoticed for months.

What Suricata Misses

Suricata has real blind spots that are important to understand.

Encrypted traffic is opaque to Suricata. With most web traffic using HTTPS, Suricata can see that a connection was made to a specific server (via SNI in the TLS handshake) but cannot inspect the content. Malware using HTTPS for C2 communication is largely invisible unless the domain or IP is in a threat intelligence feed.

Zero-day attacks have no signatures yet. Suricata detects known patterns. A novel attack using a previously unknown technique will pass through undetected until someone writes a rule for it.

Low-and-slow attacks that stay below detection thresholds can evade rate-based rules. An attacker probing one port per hour across days will not trigger scanning detection rules tuned for faster scans.

Wireless-layer attacks are completely invisible to Suricata. Deauthentication, evil twin APs, and WPA attacks happen on the 802.11 medium before traffic ever reaches the network layer. This is where complementary tools become essential.

Suricata on pfSense

Installing Suricata on pfSense takes about five minutes. Navigate to System, Package Manager, Available Packages, find Suricata, and install. After installation, go to Services, Suricata, and configure your first interface.

Key configuration steps: select the WAN interface for monitoring inbound threats, enable the ET Open rule set, choose IDS mode (Legacy Mode in pfSense), and set the home network variable ($HOME_NET) to your LAN subnets. Start the interface and let it run.

The Alerts tab shows detected threats in real time. Expect noise initially - legitimate traffic triggering overly broad rules. Use the suppress list to silence specific rules on specific IP addresses (not globally, as the rule might be valid for other hosts). Over a week or two of tuning, the alert stream becomes manageable and meaningful.

Complementing Suricata With Wireless Monitoring

Suricata watches the wired network. The BLEShark Nano watches the wireless environment. Together, they cover both domains where threats operate.

When Suricata alerts on suspicious traffic from a specific internal IP, the Nano can help you identify what physical device is at that address by scanning the WiFi environment and correlating MAC addresses. When the Nano detects a rogue access point or deauthentication attack, Suricata's logs can show whether any traffic anomalies correlate with the wireless event.

Neither tool alone provides complete visibility. The combination of network-layer intrusion detection and wireless-layer monitoring creates the kind of layered defense that catches threats at multiple stages of an attack.