Skip to main content
Inspectors are the Snort 3 equivalent of Snort 2 preprocessors. They normalize traffic, track state, and publish inspection events so that other components — including the detection engine — can consume data only when needed. Unlike the flat preprocessor list in Snort 2, Snort 3 organizes inspectors into typed roles. Each type runs at a specific point in the packet-processing pipeline.

​
Inspector types

Snort 3 uses a typed inspector model instead of a generalized list. Each type runs at a defined point in the processing flow.
TypeWhen it runsExamples
IT_PACKETRaw packets only, before any stream processingnormalizer
IT_NETWORKPackets on flows without a detected servicearp_spoof, back_orifice
IT_STREAMFlow tracking, IP defragmentation, TCP reassemblystream, stream_tcp, stream_ip
IT_FIRSTFirst packet of a new flowInitial classification steps
IT_WIZARDDetermines which service inspector handles the flowwizard
IT_SERVICEAnalyzing application-layer PDUshttp_inspect, ftp_server, smtp, dce_smb
IT_CONTROLAll packets, before detectionFirewall-style checks
IT_PASSIVEConfiguration-only / inspection events, no packet modificationbinder, data_log
IT_PROBEAfter detection completesperf_monitor, port_scan
The basic processing flow illustrates where inspectors fit: 
(pkt) -> [decode] -> [stream] -> [service] -> [detect] -> [log] -> (verdict)
                 ----------------------------------------
                      [appid]   [firewall]   [other]

​
Event-driven pub/sub architecture

Snort 3 replaces Snort 2’s callback approach with a publish/subscribe (observer) pattern for inspection events. Instead of one inspector calling another directly, an inspector publishes access to its data. Any subscriber can then read the raw or normalized version of that data on demand.
Normalization is done only on first access. Subsequent accesses reuse the already-normalized result. This is called just-in-time (JIT) processing — Snort works smarter by never normalizing data that nothing will read.
This decoupling means:
  • A new feature can subscribe to existing HTTP or SSL events without modifying those inspectors.
  • AppID subscribes to HTTP, SSL, SIP, and DCE/RPC inspection events to identify applications.
  • There is no wasted normalization work when downstream consumers don’t need the data.

​
JIT buffer stuffers

Buffers such as http_uri, http_header, and file_data are not materialized until a rule actually needs to evaluate them. These lazy evaluations are called JIT buffer stuffers. A rule that doesn’t include http_uri will never trigger URI normalization for that packet.

​
Example: data_log passive inspector

data_log is a passive inspector (IT_PASSIVE) that demonstrates the pub/sub model. It subscribes to an inspection event and logs the value whenever the event fires. No packet modification occurs. To enable a simple URI logger, add this to snort.lua: 
data_log = { key = 'http_raw_uri' }
When http_inspect processes an HTTP request, it publishes access to http_raw_uri. data_log receives that event and logs the raw URI without any other side effects.

​
Configuring inspectors

All inspectors are configured as Lua tables with the same name as the module. The minimum configuration is an empty table to accept all defaults: 
http_inspect = { }
smtp = { }
appid = { }
The binder inspector (passive type) maps traffic to specific inspectors based on protocol, port, or detected service: 
binder =
{
    {
        when = { proto = 'tcp', ports = '80 8080 8000' },
        use  = { type = 'http_inspect' },
    },
    {
        when = { proto = 'tcp', ports = '25 465 587' },
        use  = { type = 'smtp' },
    },
    { use = { type = 'wizard' } },
}
The wizard inspector (IT_WIZARD) provides port-independent service identification by peeking at the first bytes of a new flow and matching them against text spells, binary hexes, or C++ state-machine curses.

​
Available service inspectors

HTTP / HTTP2

Full HTTP/1.x and HTTP/2 inspection with PDU-based normalization, URI analysis, header parsing, and JavaScript normalization.

FTP / Telnet

FTP command and response parsing, data channel tracking, buffer overflow detection, and Telnet command normalization.

SMTP

SMTP command inspection, MIME attachment extraction, sender/recipient logging, and TLS-encrypted traffic handling.

IMAP / POP

IMAP4 and POP3 command inspection with MIME decoding (Base64, QP, UU) for email attachment analysis.

DCE/RPC

SMB desegmentation and DCE/RPC defragmentation across SMB, TCP, and UDP transports with interface and opnum tracking.

DNS

DNS query and response inspection.

SSL / TLS

TLS handshake parsing for certificate and version inspection; feeds AppID with SNI and certificate data.

SSH

SSH protocol inspection and anomaly detection.

SIP

VoIP SIP message inspection for call setup and control traffic.

NetFlow

NetFlow v5/v9 and IPFIX flow record processing.

Modbus

SCADA Modbus TCP inspection on port 502 with function code and unit ID rule options.

DNP3

DNP3 inspection over TCP/UDP with function, indication, and object rule options.

IEC 60870-5-104

IEC 104 telecontrol protocol inspection on port 2404.

S7CommPlus

Siemens S7comm-Plus protocol inspection for Simatic S7 PLCs.

OPC UA

OPC Unified Architecture message inspection for industrial automation.

MMS

Manufacturing Message Specification (IEC 61850) inspection on port 102.

SOCKS

SOCKS4/4a and SOCKS5 proxy protocol inspection with tunnel metadata extraction.

AppID

Application identification by subscribing to events from HTTP, SSL, SIP, and DCE/RPC inspectors.

Port Scan

Reconnaissance detection for TCP, UDP, IP, and ICMP scans and sweeps.

Back Orifice

Detects the Back Orifice remote access trojan on UDP traffic.

​
Learning more about a module

You can inspect any module’s parameters, peg counts, and built-in rules from the command line: 
snort --help-module http_inspect
snort --help-module stream_tcp
snort --list-builtin

Build docs developers (and LLMs) love

Get started for freeTalk to us