Suricata IDS Guide: Rules, EVE JSON and Deployment

Most organisations cannot see what crosses their own network, so command and control, lateral movement and data theft go unnoticed until something else breaks. Suricata is a free, open source engine that inspects traffic and produces alerts plus rich protocol metadata, and it can sit inline to block. This guide explains what Suricata does, how its rules and outputs work, how to deploy it in IDS or IPS mode safely, how to tune it for throughput and false positives, and where it fits beside other tools. It is written for detection engineers, SOC analysts and network security teams, and it stays on the defender side: everything here comes from the project's official documentation.

Key takeaways

Suricata is three tools in one: a signature IDS, an inline IPS and a network security monitoring (NSM) logger that writes protocol records for HTTP, DNS, TLS, SMB, SSH and many more.
Start passive, then go inline: run from a TAP or SPAN port in IDS mode first, measure drops and noise, and only then move selected segments to NFQUEUE or AF_PACKET IPS mode.
EVE JSON is the product: the alert is only one event type; flow, DNS, TLS and anomaly records are what make hunting and incident response possible in your SIEM.
Rules are content you must manage: use suricata-update with a controlled set of sources, keep local changes in enable.conf, disable.conf and threshold.config, and check each source's licence terms.
Dropped packets are silent failures: NIC offloading, small ring buffers and the wrong runmode cause loss that hides attacks, so monitor capture statistics as a first class KPI.

What the tool does

Suricata is a high performance engine for network intrusion detection, intrusion prevention and network security monitoring. It is developed by the Open Information Security Foundation (OISF), a non profit that owns the project on behalf of its community. The source code is licensed under the GNU General Public License version 2 (GPLv2), and the documentation under Creative Commons Attribution NonCommercial 4.0. GPLv2 lets you run, study and modify Suricata freely; obligations arise mainly if you distribute modified binaries, which matters for teams embedding it in an appliance.

The engine decodes packets, reassembles TCP streams, identifies application protocols regardless of port, matches signatures, and logs. Because protocol detection is port independent, a rule written for http still fires when HTTP runs on a non standard port, which is directly useful against MITRE ATT&CK T1571 Non-Standard Port.

Rule format in general terms

Every rule has three parts: an action, a header (protocol, source and destination addresses and ports, direction) and options in parentheses separated by semicolons. The documentation's own teaching example, which flags a benign HTTP GET whose URI contains the word "rule", shows the shape:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP GET Request Containing Rule in URI"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"rule"; fast_pattern; classtype:bad-unknown; sid:123; rev:1;)

Rule element	Values (from the docs)	Practical note
Action	alert, pass, drop, reject, rejectsrc, rejectdst, rejectboth	drop and reject only block in IPS mode; in IDS mode they still alert
Protocol	ip, tcp, udp, icmp, plus app layer keywords such as http, http2, tls, quic, dns, smb, ssh, krb5, ldap, rdp, smtp	List what your build supports with `suricata --list-rule-protos`; modbus, dnp3 and enip are off by default
Addresses and ports	Variables such as $HOME_NET and $EXTERNAL_NET	A wrong HOME_NET is the most common cause of missed or noisy alerts
Sticky buffers	http.method, http.uri, tls.sni, ja3.hash, ja4.hash and others	Following `content` matches apply only to that buffer, which is faster and more precise
Metadata	msg, classtype, sid, rev	Reserve a local SID range so custom rules never collide with vendor rules

EVE JSON output

EVE writes one JSON object per event. Core types are alert, anomaly, flow, stats and drop; protocol records include http, http2, dns, tls, smb, ssh, quic, krb5, dhcp, rdp, ftp, sip and others. Some (frame, arp, netflow, ntp, pgsql) are off by default. Output can go to a regular file, syslog, a Unix socket (unix_dgram, unix_stream) or Redis. Set community-id: true and use the same community-id-seed on every tool so a Suricata alert can be joined to the matching Zeek connection record or firewall log by a single flow hash.

TLS, JA3 and JA4 metadata

Most traffic is encrypted, so Suricata's value on TLS and QUIC comes from metadata: server name (SNI), certificate fields, versions and client fingerprints. The ja3.hash, ja3s.hash, ja3.string and ja4.hash keywords match fingerprints, enabled with app-layer.protocols.tls.ja3-fingerprints and ja4-fingerprints. JA3 is an MD5 of ClientHello fields and is easy for modern clients to vary, so treat fingerprints as a hunting pivot rather than a blocking key. Rules can declare requires: feature ja4; so they are skipped on builds without support instead of failing to load. This is the main lever against T1573 Encrypted Channel.

Defender use cases

Use case	What Suricata provides	ATT&CK technique it helps detect
Command and control over the web	Signatures on http and tls buffers, SNI and fingerprint matches	T1071.001 Web Protocols, T1573 Encrypted Channel
DNS tunnelling and suspicious lookups	dns EVE records, rules on dns.query	T1071.004 DNS
Internal scanning	flow records and threshold based rules	T1046 Network Service Discovery
Services on odd ports	Port independent protocol detection	T1571 Non-Standard Port
Exfiltration over existing channels	flow byte counts, fileinfo and protocol logs	T1041 Exfiltration Over C2 Channel
Incident scoping	Historic EVE metadata searched in a SIEM, optional PCAP	Supports response across techniques

Perimeter and egress monitoring: sensors on internet links catch known malware families and policy violations. See the IDS and IPS Guide.
East west visibility: sensors between user, server and OT zones see lateral movement that perimeter controls never inspect. In the Salt Typhoon telecom intrusions, attackers logged in to network devices with stolen credentials, copied configurations out over TFTP and FTP and ran SSH on high ports; tftp, ftp and ssh records from internal sensors are exactly the evidence that exposes that pattern.
NSM for hunting: protocol logs let analysts ask "which hosts talked to this domain in the last 30 days" without full packet capture. See the Threat Hunting Guide.
Feeding a SIEM or NDR stack: EVE JSON is easy to ship and parse. See the SIEM Guide and the NDR Guide.

Deployment and safe use

IDS versus IPS mode

Mode	How traffic reaches Suricata	Failure behaviour	Choose when
IDS (passive)	TAP or SPAN into AF_PACKET, PF_RING, NETMAP or PCAP capture	Sensor failure loses visibility, not connectivity	Default for most organisations and every new deployment
IPS with NFQUEUE	iptables or nftables send packets to a queue, Suricata started with `-q`	Without the `bypass` option, no listener means dropped traffic; with it, traffic passes uninspected	Host or gateway protection where firewall rules already exist
IPS with AF_PACKET	Suricata bridges two interfaces using `copy-mode: ips` and `copy-iface`	Sensor outage breaks the link unless external bypass hardware is used	Dedicated inline segment with tested rules
AF_PACKET tap copy mode	`copy-mode: tap` bridges but never drops	Behaves like an inline IDS	Rehearsal before switching a bridge to ips

Phased rollout

Define scope and data handling: decide which links are monitored, who can read EVE logs (they contain URLs, hostnames and possibly credentials in clear text protocols) and the retention period. Record this in your monitoring policy and privacy notice.
Build the sensor: a dedicated host with a management interface and a sniffing interface that has no IP address. Disable GRO, LRO and TSO offloading on capture interfaces, since the docs warn these create oversized frames and drops.
Configure variables: set HOME_NET to every internal range, including cloud VPCs and VPN pools.
Load rules with suricata-update: it fetches ET Open by default into /var/lib/suricata/rules/suricata.rules. Add sources with update-sources, list-sources and enable-source; subscription sources such as et/pro need an access code. Rule sets carry their own licence terms: confirm them with each provider before use or redistribution.
Run in IDS mode for at least two weeks: measure alert volume, top SIDs and capture drops before anyone relies on the output.
Tune: disable irrelevant rules in /etc/suricata/disable.conf (by SID, group: file or re: regex), enable extras in enable.conf, and adjust with modify.conf and drop.conf. Re-run suricata-update and reload after changes.
Pilot IPS on one segment: promote only high confidence SIDs to drop (drop.conf), keep everything else as alert, and test failure behaviour by stopping the service in a change window.
Roll back cleanly: keep the previous rules file and configuration under version control; reverting is restoring the file and reloading. For NFQUEUE, the bypass option keeps the link up when Suricata stops, at the cost of no enforcement.

Performance tuning

Capture method: AF_PACKET with cluster_flow (the default) keeps both directions of a flow on the same thread; use cluster_qm only with symmetric RSS. Use tpacket-v3 for IDS and v2 for IPS.
Pattern matcher: set mpm-algo: hs (Hyperscan) where supported; otherwise ac-ks beats the default ac on commodity hardware.
Buffers: raise ring-size when drop counters climb, and max-pending-packets towards 10000 or more, without going so high that performance degrades.
Detection grouping: detect.profile: high is usually enough; custom with larger toclient and toserver groups trades a little memory for speed.
Elephant flows: stream.bypass stops inspecting a flow once reassembly depth is reached, which protects CPU on backups and video.

False positive management

Use threshold.config rather than editing vendor rules. suppress gen_id 1, sig_id <sid>, track by_src, ip 192.0.2.10 silences one rule for a known vulnerability scanner while keeping it for every other host. threshold with type limit, threshold or both caps alert rates per source, destination, rule or flow. rate_filter changes the action, for example to drop, only when a rule fires above a set rate. Record every suppression with an owner and review date, because yesterday's benign scanner can become tomorrow's compromised host.

Detection and hardening value

What to monitor

Capture health: stats events and stats.log counters for kernel packets and kernel drops per interface; alert when the drop ratio exceeds your threshold.
Rule health: load errors at start up, rules skipped by requires, and the date of the last successful suricata-update.
Coverage: share of internet egress and critical internal segments with a sensor, and whether HOME_NET matches the current IP plan.
Sensor integrity: the sensor is a high value target holding sensitive metadata; restrict management access, patch it and forward its own system logs.

Metrics that show it is working

KPI	Target to aim for
Capture drop rate per sensor	Below 1 percent at peak, investigated daily
Rule update age	Under 24 hours for active sources
Alert to true positive ratio for the top 20 SIDs	Rising quarter on quarter as tuning matures
Monitored egress points	100 percent of internet links
Suppressions past review date	Zero
Mean time from alert to triage	Within the SOC service level for its severity

Framework mapping

Framework	Reference	How Suricata contributes
NIST CSF 2.0	DE.CM-01, DE.AE-02	Monitors networks and supplies events for analysis
NIST SP 800-53 Rev. 5	SI-4, SI-4(4), SC-7, AU-6	System monitoring, inbound and outbound traffic monitoring, boundary protection, log review
CIS Controls v8.1	Control 13 Network Monitoring and Defense	Network intrusion detection and, inline, intrusion prevention
ISO/IEC 27001:2022	Annex A 8.16 Monitoring activities, 8.20 Networks security	Evidence of network monitoring and anomaly detection
MITRE D3FEND	D3-NTSA Network Traffic Signature Analysis, D3-NTA Network Traffic Analysis	Signature and metadata based traffic analysis

Common failure patterns

Silent packet loss: offloading left on or an undersized ring, so the sensor sees half the traffic and nobody checks.
Stale or partial HOME_NET: cloud and VPN ranges missing, so outbound rules never match.
Every rule enabled, nobody triaging: thousands of policy alerts bury the few that matter; tune before go live.
Inline without a failure plan: an IPS crash takes a link down, and the business demands the sensor is removed for good.
Alerts without metadata: only the alert type is shipped, so responders cannot scope an incident from flow, DNS and TLS records.
Unreviewed rule source terms: a subscription rule set redistributed or shared beyond what its licence allows.

Alternatives

Option	Approach	When it fits better
Zeek	Scriptable NSM producing detailed protocol logs, little signature matching	Hunting and metadata depth; often run alongside Suricata. See the Zeek Network Monitoring Guide.
Snort	Long established signature IDS and IPS with a similar rule language	Teams with existing Snort content or appliances built on it
Security Onion	Platform that bundles Suricata with Zeek, packet capture and Elastic based search	Teams wanting an integrated stack rather than a single engine. See the Security Onion Guide.
Commercial NDR	Sensors plus behavioural analytics, managed content and support	Limited engineering capacity or strict support requirements. See the NDR Buyer's Guide.
Firewall or UTM IPS features	IPS signatures inside the perimeter firewall	Small sites wanting one box, accepting less metadata and east west visibility

For small organisations, one IDS mode sensor on the internet link feeding a SIEM gives most of the value. Large organisations need sensors per zone, central rule management, community ID correlation with Zeek and endpoint data, and detection content written as code. Host side detection complements this: see the Wazuh Guide and, for portable SIEM rules, the Sigma Rules Guide.

Practitioner checklist

Map every internet egress and critical internal segment, and place a sensor or document why not.
Disable GRO, LRO and TSO on capture interfaces and confirm drop counters stay low at peak.
Set HOME_NET from the current IP plan, including cloud and VPN ranges, and review it quarterly.
Manage rules only through suricata-update with enable.conf, disable.conf, modify.conf and drop.conf under version control.
Confirm the licence terms of every rule source and reserve a local SID range for custom rules.
Enable EVE alert, flow, dns, tls, http and anomaly records with community ID, and ship them to the SIEM.
Run IDS mode before any IPS pilot, and test failure behaviour with NFQUEUE bypass or bypass hardware.
Record every suppression and threshold with an owner and expiry date.
Harden and patch sensors, restrict management access and restrict who can read EVE data.

Standards and references

Related NHI Mgmt Group resources: IDS and IPS Guide · NDR Guide · SIEM Guide · Threat Hunting Guide · Zeek Network Monitoring Guide

Suricata IDS Guide: Network Intrusion Detection, Rules and Deployment