8.53. Rule Types and Categorization
Once parsed, Suricata rules are categorized for performance and further processing (as different rule types will be handled by specific engine modules). The signature types are defined in src/detect.h:
enum SignatureType {
SIG_TYPE_NOT_SET = 0,
SIG_TYPE_IPONLY, // rule is handled by IPONLY engine
SIG_TYPE_LIKE_IPONLY, // rule is handled by pkt engine, has action effect like ip-only
/** Proto detect only signature.
* Inspected once per direction when protocol detection is done. */
SIG_TYPE_PDONLY, // rule is handled by PDONLY engine
SIG_TYPE_DEONLY,
SIG_TYPE_PKT,
SIG_TYPE_PKT_STREAM,
SIG_TYPE_STREAM,
SIG_TYPE_APPLAYER, // app-layer but not tx, e.g. appproto
SIG_TYPE_APP_TX, // rule is handled by TX engine
SIG_TYPE_MAX,
};
In more human readable terms:
Rule Type |
Code Symbol |
Engine-Analysis Representation |
---|---|---|
Decoder Events Only |
|
|
Packet |
|
|
IP Only |
|
|
IP Only (contains negated address(es)) |
|
|
Protocol Detection Only |
|
|
Packet-Stream |
|
|
Stream |
|
|
Application Layer Protocol |
|
|
Application Layer Protocol Transactions |
|
|
The rule type will impact:
To what does the signature action apply, in case of a match (Action Scope)
When is the rule matched against traffic (Inspection Hook)
Against what the rule matches (Data Exposed)
This categorization is done taking into consideration the presence or absence of certain rule elements, as well as the type of keywords used. The categorization currently takes place in src/detect-engine-build.c:void SignatureSetType().
The SignatureSetType()
overall flow is described below:

Flowcharts expanding uncovered functions or portions of the overall algorithm above are shown in the Detailed Flowcharts section.
The following table lists all Suricata signature types, and how they impact the aspects aforementioned.
Type |
Action Scope |
Inspection Hook |
Data Exposed |
Keyword Examples (non-exhaustive) |
---|---|---|---|---|
( |
Packet |
Per-broken/ invalid packet |
Decoding events |
|
( |
Packet |
Per-packet basis |
Packet-level info (e.g.: header info) |
|
( |
Flow (if existing). Packets (if not part of a flow) |
Once per direction |
IP addresses on the flow |
Source/ Destination field of a rule |
IP Only (contains negated address) 2 ( |
Flow |
All packets |
IP addresses on the flow |
Source/ Destination field of a rule containing negated address |
( |
Flow |
Once per direction, when protocol detection is done |
Protocol detected for the flow |
|
( |
Flow, if stateful 1 |
Per stream chunk, if stateful, per-packet if not (stream payload AND packet payload) |
The reassembled stream and/or payload data |
|
( |
Flow, if stateful 1 |
Stream chunks, if stateful, just packets if not |
Stream reassembled payload or packet payload data |
|
( |
Flow |
Per-packet basis |
'protocol' field in a rule |
Protocol field of a rule |
Application Layer Protocol Transactions ( |
Flow |
Per transaction update |
Buffer keywords |
Application layer protocol-related, e.g. |
Note
Action Scope: Flow, if stateful
(1) Apply to the flow. If a segment isn't accepted into a stream for any reason (such as packet anomalies, errors, memcap reached etc), the rule will be applied on a packet level.
Warning
Although both are related to matching on application layer protocols, as the
table suggests, since Suricata 7 a Protocol Detection rule (that uses the
app-layer-protocol
keyword) is not internally classified the same as a
rule simply matching on the application layer protocol on the protocol
field.
8.53.1. Signature Properties
The Action Scope mentioned above relates to the Signature Properties, as seen in src/detect-engine.c:
const struct SignatureProperties signature_properties[SIG_TYPE_MAX] = {
/* SIG_TYPE_NOT_SET */ { SIG_PROP_FLOW_ACTION_PACKET, },
/* SIG_TYPE_IPONLY */ { SIG_PROP_FLOW_ACTION_FLOW, },
/* SIG_TYPE_LIKE_IPONLY */ { SIG_PROP_FLOW_ACTION_FLOW, },
/* SIG_TYPE_PDONLY */ { SIG_PROP_FLOW_ACTION_FLOW, },
/* SIG_TYPE_DEONLY */ { SIG_PROP_FLOW_ACTION_PACKET, },
/* SIG_TYPE_PKT */ { SIG_PROP_FLOW_ACTION_PACKET, },
/* SIG_TYPE_PKT_STREAM */ { SIG_PROP_FLOW_ACTION_FLOW_IF_STATEFUL, },
/* SIG_TYPE_STREAM */ { SIG_PROP_FLOW_ACTION_FLOW_IF_STATEFUL, },
/* SIG_TYPE_APPLAYER */ { SIG_PROP_FLOW_ACTION_FLOW, },
/* SIG_TYPE_APP_TX */ { SIG_PROP_FLOW_ACTION_FLOW, },
};
8.53.1.1. Signature: Require Real Packet
Aside from the scope of action of a signature, certain rule conditions will
require that it matches against a real packet (as opposed to a pseudo packet).
These rules are flagged with SIG_MASK_REQUIRE_REAL_PKT
by the engine, and
will have real_pkt
listed as one of the rule's requirements
. (See
engine-analysis
example output for the Packet rule type.)
A pseudo packet is an internal resource used by the engine when a flow is over but there is still data to be processed, such as when there is a flow timeout. A fake packet is then injected in the flow to finish up processing before ending it.
Those two types will be more documented soon (tracking #7424).
8.53.2. Signature Types and Variable-like Keywords
Keywords such as flow variables (flowint
, flowbits
), datasets
,
and similar ones can alter the rule type, if present in a signature.
That happens because the variable condition can change per packet. Thus, the Signature is categorized as a packet rule.
This affects rule types:
Application Layer (
app_layer
)Protocol Detection Only (
pd_only
)Decoder Events Only (
de_only
)IP Only (
ip_only
) 3Like IP Only (
like_ip_only
) 3
The rule examples provided further cover some such cases, but the table below lists those keywords with more details:
Keyword |
Keyword Option |
Rule Type change? |
---|---|---|
|
|
no type changes 3 |
|
|
to packet |
|
|
to packet |
|
|
no type change |
|
|
to packet |
|
defining the variable; unseting; |
no type change |
|
|
to packet |
Note
IP Only and Like IP Only
(3) Unlike the other affected types, signatures that would otherwise be
classified as ip_only
or like_ip_only
become Packet rules if the
flow
keyword is used, regardless of option.
Note
dataset
, while may look similar to the keywords above, doesn't pertain
to this list as it can only be used with sticky buffer keywords, thus being
only available to Application Layer Transaction rules (app_tx), which are
not affected by this.
8.53.2.1. Flowbits: isset
If a non-stateful rule (e.g. a pkt
rule) checks if a flowbit is set (like in
flowbits:fb6,isset) and the rule that sets that variable is a stateful one,
such as an app_tx
rule, the engine will set a flag to indicate that that
rule is also stateful - without altering its signature type. This flag is
currently SIG_FLAG_INIT_STATE_MATCH
(cf. ticket #7483).
There is a work-in-progress to add information about this to the engine-analysis
report (ticket #7456).
8.53.3. Signatures per Type
This section offers brief descriptions for each rule type, and illustrates what signatures of each type may look like. It is possible to learn the type of a signature, as well as other important information, by running Suricata in engine analysis mode.
For each rule type, there is also a sample of the Engine Analysis report for one or more of rule(s) shown.
8.53.3.1. Decoder Events Only
Signatures the inspect broken or invalid packets. They expose Suricata decoding events.
For more examples check https://github.com/OISF/suricata/blob/master/rules/decoder-events.rules.
8.53.3.1.1. Example
alert pkthdr any any -> any any (msg:"SURICATA IPv6 duplicated Hop-By-Hop Options extension header"; decode-event:ipv6.exthdr_dupl_hh; classtype:protocol-command-decode; sid:1101;)
drop pkthdr any any -> any any (msg:"SURICATA IPv4 invalid option length"; :example-rule-emphasis:`decode-event:ipv4.opt_invalid_len; classtype:protocol-command-decode; sid:2200005; rev:2;)
8.53.3.1.2. Engine-Analysis Report
{
"raw": "alert pkthdr any any -> any any (msg:\"SURICATA IPv6 duplicated Hop-By-Hop Options extension header\"; decode-event:ipv6.exthdr_dupl_hh; classtype:protocol-command-decode; sid:1101;)",
"id": 1101,
"gid": 1,
"rev": 0,
"msg": "SURICATA IPv6 duplicated Hop-By-Hop Options extension header",
"app_proto": "unknown",
"requirements": [
"engine_event"
],
"type": "de_only",
"flags": [
"src_any",
"dst_any",
"sp_any",
"dp_any",
"toserver",
"toclient"
],
"pkt_engines": [
{
"name": "packet",
"is_mpm": false
}
],
"frame_engines": [],
"lists": {
"packet": {
"matches": [
{
"name": "decode-event"
}
]
}
}
}
8.53.3.2. Packet
Rules that expose/ inspect information on a packet-level (for instance, the
header). Certain flow keywords may also turn a rule into a pkt
rule, if
they require per-packet inspection (cf. Signature Types and Variable-like Keywords).
8.53.3.2.1. Examples
alert tcp-pkt any any -> any any (msg:"tcp-pkt, anchored content"; content:"abc"; startswith; sid:203;)
alert tcp any any -> any any (msg:"ttl"; ttl:123; sid:701;)
alert udp any any -> any any (msg:"UDP with flow direction"; flow:to_server; sid:1001;)
alert tcp any any -> any 443 (flow: to_server; flowbits:set,tls_error; sid:1604; msg:"Allow TLS error handling (outgoing packet) - non-stateful rule";)
alert tcp-pkt any any -> any any (msg:"Flowbit isset"; flowbits:isset,fb6; flowbits:isset,fb7; sid:1919;)
8.53.3.2.2. Engine-Analysis Report
{
"raw": "alert tcp-pkt any any -> any any (msg:\"tcp-pkt, anchored content\"; content:\"abc\"; startswith; sid:203;)",
"id": 203,
"gid": 1,
"rev": 0,
"msg": "tcp-pkt, anchored content",
"app_proto": "unknown",
"requirements": [
"payload",
"real_pkt"
],
"type": "pkt",
"flags": [
"src_any",
"dst_any",
"sp_any",
"dp_any",
"need_packet",
"toserver",
"toclient",
"prefilter"
],
"pkt_engines": [
{
"name": "payload",
"is_mpm": true
}
],
"frame_engines": [],
"lists": {
"payload": {
"matches": [
{
"name": "content",
"content": {
"pattern": "abc",
"length": 3,
"nocase": false,
"negated": false,
"starts_with": true,
"ends_with": false,
"is_mpm": true,
"no_double_inspect": false,
"depth": 3,
"fast_pattern": false,
"relative_next": false
}
}
]
}
},
"mpm": {
"buffer": "payload",
"pattern": "abc",
"length": 3,
"nocase": false,
"negated": false,
"starts_with": true,
"ends_with": false,
"is_mpm": true,
"no_double_inspect": false,
"depth": 3,
"fast_pattern": false,
"relative_next": false
}
}
8.53.3.3. IP Only
The IP ONLY rule type is used when rules match only on source and destination IP addresses, and not on any other flow or content modifier.
8.53.3.3.1. Examples
alert tcp-stream any any -> any any (msg:"tcp-stream, no content"; sid:101;)
alert tcp-pkt [192.168.0.0/16,10.0.0.0/8,172.16.0.0/12] any -> any any (msg:"tcp-pkt, no content"; sid:201;)
alert ip any any -> any any (hostbits:set,myflow2; sid:1505;)
alert udp any any -> any any (msg:"UDP with flow direction"; sid:1601;)
8.53.3.3.2. Engine-Analysis Report
{
"raw": "alert ip any any -> any any (hostbits:set,myflow2; sid:1505;)",
"id": 1505,
"gid": 1,
"rev": 0,
"app_proto": "unknown",
"requirements": [],
"type": "ip_only",
"flags": [
"src_any",
"dst_any",
"sp_any",
"dp_any",
"toserver",
"toclient"
],
"pkt_engines": [],
"frame_engines": [],
"lists": {
"postmatch": {
"matches": [
{
"name": "hostbits"
}
]
}
}
}
8.53.3.4. IP Only (contains negated address)
A rule that inspects IP only properties, but contains negated IP addresses.
IP Only signatures with negated addresses are like IP-only signatures, but currently handled differently due to limitations of the algorithm processing IP Only rules. Impactful differences from a user-perspective are listed on the Signature Types table.
8.53.3.4.1. Examples
alert tcp 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12 any -> ![192.168.0.0/16,10.0.0.0/8,172.16.0.0/12] any (msg:"tcp, has negated IP address"; sid:304;)
alert tcp [10.0.0.0/8,!10.10.10.10] any -> [10.0.0.0/8,!10.10.10.10] any (msg:"tcp, has negated IP address"; sid:305;)
8.53.3.4.2. Engine-Analysis Report
{
"raw": "alert tcp [10.0.0.0/8,!10.10.10.10] any -> [10.0.0.0/8,!10.10.10.10] any (msg:\"tcp, has negated IP address\"; sid:305;)",
"id": 305,
"gid": 1,
"rev": 0,
"msg": "tcp, has negated IP address",
"app_proto": "unknown",
"requirements": [],
"type": "like_ip_only",
"flags": [
"sp_any",
"dp_any",
"toserver",
"toclient"
],
"pkt_engines": [],
"frame_engines": [],
"lists": {}
}
8.53.3.5. Protocol Detection Only
When a signature checks for the application layer protocol but there is no need
for a per-packet inspection, protocol detection can be done with the
app-layer-protocol
keyword. Check the keyword documentation
full for usage.
See Protocol Detection Only for a flowchart representing how the type is defined.
See Application Layer Protocol for a packet-based inspection.
Warning
Since Suricata 7, a Protocol Detection rule (that uses the
app-layer-protocol
keyword) is not internally classified the same as a
rule simply matching on the application layer protocol on the protocol
field.
8.53.3.5.1. Examples
alert tcp any any -> any any (msg:"tcp, pd negated"; app-layer-protocol:!http; sid:401;)
alert tcp any any -> any any (msg:"tcp, pd positive"; app-layer-protocol:http; sid:402;)
alert tcp any any -> any any (msg:"tcp, pd positive dns"; app-layer-protocol:dns; sid:403;)
alert tcp any any -> any any (msg:"tcp, pd positive, dns, flow:to_server"; app-layer-protocol:dns; flow:to_server; sid:405;)
8.53.3.5.2. Engine-Analysis Report
{
"raw": "alert tcp any any -> any any (msg:\"tcp, pd positive dns\"; app-layer-protocol:dns; sid:403;)",
"id": 403,
"gid": 1,
"rev": 0,
"msg": "tcp, pd positive dns",
"app_proto": "unknown",
"requirements": [],
"type": "pd_only",
"flags": [
"src_any",
"dst_any",
"sp_any",
"dp_any",
"toserver",
"toclient"
],
"pkt_engines": [
{
"name": "packet",
"is_mpm": false
}
],
"frame_engines": [],
"lists": {
"packet": {
"matches": [
{
"name": "app-layer-protocol"
}
]
}
}
}
8.53.3.6. Packet-Stream
A rule is categorized as such when it inspects on traffic in specific portions
of the packet payload, using content
buffer with the startswith
or
depth
keywords.
8.53.3.6.1. Examples
alert tcp any any -> any any (msg:"tcp, anchored content"; content:"abc"; startswith; sid:303;)
alert http any any -> any any (msg:"http, anchored content"; content:"abc"; depth:30; sid:603;)
8.53.3.6.2. Engine-Analysis Report
{
"raw": "alert http any any -> any any (msg:\"http, anchored content\"; content:\"abc\"; depth:30; sid:603;)",
"id": 603,
"gid": 1,
"rev": 0,
"msg": "http, anchored content",
"app_proto": "http_any",
"requirements": [
"payload",
"flow"
],
"type": "pkt_stream",
"flags": [
"src_any",
"dst_any",
"sp_any",
"dp_any",
"applayer",
"need_packet",
"need_stream",
"toserver",
"toclient",
"prefilter"
],
"pkt_engines": [
{
"name": "payload",
"is_mpm": true
}
],
"frame_engines": [],
"lists": {
"payload": {
"matches": [
{
"name": "content",
"content": {
"pattern": "abc",
"length": 3,
"nocase": false,
"negated": false,
"starts_with": false,
"ends_with": false,
"is_mpm": true,
"no_double_inspect": false,
"depth": 30,
"fast_pattern": false,
"relative_next": false
}
}
]
}
},
"mpm": {
"buffer": "payload",
"pattern": "abc",
"length": 3,
"nocase": false,
"negated": false,
"starts_with": false,
"ends_with": false,
"is_mpm": true,
"no_double_inspect": false,
"depth": 30,
"fast_pattern": false,
"relative_next": false
}
}
8.53.3.7. Stream
A rule that matches payload traffic without regards to its position, that is,
on an unanchored content
buffer, uses byte extraction or matches on
tcp-stream
is classified a stream rule.
8.53.3.7.1. Examples
alert tcp-stream any any -> any any (msg:"tcp-stream, simple content"; content:"abc"; sid:102;)
alert http any any -> any any (msg:"http, simple content"; content:"abc"; sid:602;)
alert tcp any any -> any 443 (flow: to_server; content:"abc"; flowbits:set,tls_error; sid:1605; msg:"Allow TLS error handling (outgoing packet) with simple content - Stream rule";)
alert tcp any any -> any 443 (flow: to_server; content:"abc"; sid:160401; msg:"Allow TLS error handling (outgoing packet) - stream rule";)
alert tcp any any -> any 443 (content:"abc"; sid:160402; msg:"Allow TLS error handling (outgoing packet) - stream rule";)
alert tcp any any -> any any (msg:"byte_extract with dce"; byte_extract:4,0,var,dce; byte_test:4,>,var,4,little; sid:901;)
8.53.3.7.2. Engine-Analysis Report
{
"raw": "alert tcp any any -> any any (msg:\"byte_extract with dce\"; byte_extract:4,0,var,dce; byte_test:4,>,var,4,little; sid:901;)",
"id": 901,
"gid": 1,
"rev": 0,
"msg": "byte_extract with dce",
"app_proto": "dcerpc",
"requirements": [
"payload",
"flow"
],
"type": "stream",
"flags": [
"src_any",
"dst_any",
"sp_any",
"dp_any",
"applayer",
"need_stream",
"toserver",
"toclient"
],
"pkt_engines": [
{
"name": "payload",
"is_mpm": false
}
],
"frame_engines": [],
"lists": {
"payload": {
"matches": [
{
"name": "byte_extract"
},
{
"name": "byte_test",
"byte_test": {
"nbytes": 4,
"offset": 4,
"base": "unset",
"flags": [
"little_endian"
]
}
}
]
}
}
}
8.53.3.8. Application Layer Protocol
For a packet-based inspection of the application layer protocol, a rule should use the protocol field for the matches.
Warning
Since Suricata 7, a simple rule matching traffic on the protocol
field
is not internally classified the same as a rule using the app-layer-protocol
keyword).
Warning
As per Suricata 7, if flow:established
or flow:not_established
is added
to a base Application Layer Protocol rule, that signature will become a
Packet rule.
8.53.3.8.1. Examples
alert dns any any -> any any (msg:"app-layer, dns"; sid:404;)
alert http any any -> any any (msg:"http, no content"; sid:601;)
alert tls any any -> any any (msg:"tls, pkt or app-layer?"; flowint:tls_error_int,=,0; sid:613;)
8.53.3.8.2. Engine-Analysis Report
{
"raw": "alert dns any any -> any any (msg:\"app-layer, dns\"; sid:404;)",
"id": 404,
"gid": 1,
"rev": 0,
"msg": "app-layer, dns",
"app_proto": "dns",
"requirements": [
"flow"
],
"type": "app_layer",
"flags": [
"src_any",
"dst_any",
"sp_any",
"dp_any",
"applayer",
"toserver",
"toclient"
],
"pkt_engines": [],
"frame_engines": [],
"lists": {}
}
8.53.3.9. Application Layer Protocol Transactions
Rules inspecting traffic using keywords related to application layer protocols are classified with this signature type. This also includes frame keywords.
8.53.3.9.1. Examples
alert tcp any any -> any any (msg:"http, pos event"; app-layer-event:http.file_name_too_long; sid:501;)
alert http any any -> any any (msg:"Test"; flow:established,to_server; http.method; content:"GET"; http.uri; content:".exe"; endswith; http.host; content:!".google.com"; endswith; sid:1102;)
alert udp any any -> any any (msg:"DNS UDP Frame"; flow:to_server; frame:dns.pdu; content:"|01 20 00 01|"; offset:2; content:"suricata"; offset:13; sid:1402; rev:1;)
alert tcp any any -> any any (msg:"byte_extract with dce"; dcerpc.stub_data; content:"abc"; byte_extract:4,0,var,relative; byte_test:4,>,var,4,little; sid:902;)
8.53.3.9.2. Engine-Analysis Report
{
"raw": "alert tcp any any -> any any (msg:\"byte_extract with dce\"; dcerpc.stub_data; content:\"abc\"; byte_extract:4,0,var,relative; byte_test:4,>,var,4,little; sid:902;)",
"id": 902,
"gid": 1,
"rev": 0,
"msg": "byte_extract with dce",
"app_proto": "dcerpc",
"requirements": [
"flow"
],
"type": "app_tx",
"flags": [
"src_any",
"dst_any",
"sp_any",
"dp_any",
"applayer",
"toserver",
"toclient",
"prefilter"
],
"pkt_engines": [],
"frame_engines": [],
"engines": [
{
"name": "dce_stub_data",
"direction": "toclient",
"is_mpm": true,
"app_proto": "dcerpc",
"progress": 0,
"matches": [
{
"name": "content",
"content": {
"pattern": "abc",
"length": 3,
"nocase": false,
"negated": false,
"starts_with": false,
"ends_with": false,
"is_mpm": true,
"no_double_inspect": false,
"fast_pattern": false,
"relative_next": true
}
},
{
"name": "byte_extract"
},
{
"name": "byte_test",
"byte_test": {
"nbytes": 4,
"offset": 4,
"base": "unset",
"flags": [
"little_endian"
]
}
}
]
},
{
"name": "dce_stub_data",
"direction": "toserver",
"is_mpm": true,
"app_proto": "dcerpc",
"progress": 0,
"matches": [
{
"name": "content",
"content": {
"pattern": "abc",
"length": 3,
"nocase": false,
"negated": false,
"starts_with": false,
"ends_with": false,
"is_mpm": true,
"no_double_inspect": false,
"fast_pattern": false,
"relative_next": true
}
},
{
"name": "byte_extract"
},
{
"name": "byte_test",
"byte_test": {
"nbytes": 4,
"offset": 4,
"base": "unset",
"flags": [
"little_endian"
]
}
}
]
},
{
"name": "dce_stub_data",
"direction": "toclient",
"is_mpm": true,
"app_proto": "smb",
"progress": 0,
"matches": [
{
"name": "content",
"content": {
"pattern": "abc",
"length": 3,
"nocase": false,
"negated": false,
"starts_with": false,
"ends_with": false,
"is_mpm": true,
"no_double_inspect": false,
"fast_pattern": false,
"relative_next": true
}
},
{
"name": "byte_extract"
},
{
"name": "byte_test",
"byte_test": {
"nbytes": 4,
"offset": 4,
"base": "unset",
"flags": [
"little_endian"
]
}
}
]
},
{
"name": "dce_stub_data",
"direction": "toserver",
"is_mpm": true,
"app_proto": "smb",
"progress": 0,
"matches": [
{
"name": "content",
"content": {
"pattern": "abc",
"length": 3,
"nocase": false,
"negated": false,
"starts_with": false,
"ends_with": false,
"is_mpm": true,
"no_double_inspect": false,
"fast_pattern": false,
"relative_next": true
}
},
{
"name": "byte_extract"
},
{
"name": "byte_test",
"byte_test": {
"nbytes": 4,
"offset": 4,
"base": "unset",
"flags": [
"little_endian"
]
}
}
]
}
],
"lists": {},
"mpm": {
"buffer": "dce_stub_data",
"pattern": "abc",
"length": 3,
"nocase": false,
"negated": false,
"starts_with": false,
"ends_with": false,
"is_mpm": true,
"no_double_inspect": false,
"fast_pattern": false,
"relative_next": true
}
}
8.53.4. Detailed Flowcharts
A look into the illustrated overall representation of functions or paths that determine signature types.
8.53.4.1. IP Only and IP Only with negated addresses
ip_only
and like_ip_only
flows.

8.53.4.2. Protocol Detection Only
pd_only
flow.

8.53.4.3. Application Layer Protocol, Transaction, Packet, Stream and Stream-Packet rules
app_layer
, app_tx
, pkt
, stream
and stream-pkt
flows.
REQUIRE_PACKET_
and REQUIRE_STREAM
can be seen as flags need_packet
and need_stream
in the engine-analysis
output.
