The new docs.trellix.com features a modernized UI and AI-powered conversational search. Content is currently available in English, with additional languages launching in early November 2026. We hope you enjoy the updated experience.

Press CTRL+K to open search

Payload rule options

  • Published on Oct 5, 2026
  • 14 minute(s) read
Prev Next

This section describes the options and conditions that you can apply to the payload in TCP, UDP, ICMP, IP, HTTP, FTP, TLS, SMB, or DNS traffic. Note that some of the options work differently in Trellix IPS when compared to Snort. Also, some options are not supported.

The payload rule options discussed in this section include content modifier and preprocessor rule options. You use content modifiers to change the way content option works. These are specifications that the Sensor should apply on the content data before it looks for a match.

Content

This enables you to specify the content that a Sensor should look for in the packet payload. If the Sensor finds traffic matching what you specify in the content, then it raises an alert and also takes the defined response action such as packet log or packet drop.

The option data for the content keyword can contain text, binary (hex values), or mixed text and binary data. The binary data must be enclosed within the pipe (|) character and represented as bytecode.

Note

  • The following characters must be escaped inside a content rule:

    • : (colon)

    • ; (semi colon)

    • \ (backward slash)

    • " (double quotes)

  • Though you can specify even a single-byte token, the longer the content value, the accurate the detection will be. The maximum length of a content or uricontent for NS-series Sensors is 256 bytes.

  • Make sure the content option does not contain any generic values identified by Trellix IPS (some examples are listed below). Such rules can severely impact Sensor performance.

    • GET

    • POST

    • Host:

    • User-Agent

Syntax: content:"<content string>";

Example rules:

  • alert tcp any any -> 10.1.1.1 80 (msg:"command dot exe attempt"; content:"cmd.exe"; flow:to_server; sid:2001; priority: 1;)

  • alert tcp any any -> 10.1.1.1 80 (msg:"command dot exe attempt"; content:"|63 6D 64 2E 65 78 65|"; flow:to_server; sid:2001; priority: 1;)

  • alert tcp any any -> 10.1.1.1 80 (msg:"command dot exe attempt"; content:"|63| m |64 2E 65 78 65|"; flow:to_server; sid:2001; priority: 1;)

This section explains the content modifiers, which you can use to change the way content option works. The content modifiers are specifications that the Sensor should apply on the content data before it looks for a match.

nocase

Use this if you want the Sensor to look for the content data regardless of the case.

Syntax: nocase;

Example rule:

alert tcp any any -> 10.1.1.1 80 (msg: "command dot exe attempt"; content: "cMd.eXe"; nocase; flow:to_server; sid:2002; priority: 1;)

rawbytes

Use this if you want the Sensor to consider the content data as raw data. Then Sensor matches the content data against the non-normalized traffic.

Syntax: rawbytes;

For example, http://www.example.com/big%20cars/blue%20colored%20cars/pictures.htm

will normalize to http://www.example.com/big cars/blue colored cars/pictures.htm.

If you want the Sensor to find "blue%20color" in the traffic before normalization (that is, as seen in the "wire"), then your rule could be as shown below:

alert tcp any any -> 10.1.1.1 80 (msg: "example rule for rawbytes"; content:"blue%20color"; rawbytes; flow:to_server; sid:2003;priority:1;)

If you do not specify rawbytes for the same rule, the Sensor will look for "blue%20color" in the normalized traffic, which it would never find.

http_client_body

Use this modifier if you want the Sensor to look into only the normalized http client body.

Note the following:

  • Content should precede http_client_body, and it applies only to the immediately preceding Content.

  • If you use http_client_body with offset or depth, then these options are calculated from the beginning of the http payload. Consider the example rule below:

    alert tcp any any -> any any (msg: "example rule for http_client_body"; content:"red"; http_client_body; depth:30; sid:2007;priority:1;)

    The Sensor looks for "red" within 30 bytes from the beginning of the http payload and not from the beginning of the http client body.

  • Because this modifier works only for the normalized data, you cannot use it with rawbytes for the same content.

Example rule:

alert tcp any any -> any any (msg: "example rule for http_client_body"; content:"red"; content:"blue"; http_client_body;sid:2007;priority:1;)

For this rule, the Sensor looks for "red" in the entire payload and for "blue" only in the normalized HTTP request.

http_cookie

The http_cookie modifier is supported in Trellix IPS.

http_header

In this case, the Sensor checks for the content only in the normalized HTTP request.

Note the following:

  • Content should precede http_header, and it applies only to the immediately preceding Content.

  • If you use http_header with offset or depth, then these options are calculated from the beginning of the payload. Consider that you created a rule as shown below:

    alert tcp any any -> 10.1.1.1 80 (msg: "example rule for http_header"; content:"user"; http_header; depth:100; sid:2008;priority:1;)

    The Sensor looks for "user" within 100 bytes from the beginning of the http payload.

  • You cannot apply the http_header and rawbytes on the same content.

Syntax: http_header;

Example rule:

alert tcp any any -> any any (msg:"example for http_header"; content:"red"; content:"user";http_header;sid:2008;priority:1;)

In this rule, the Sensor looks for "red" in the entire payload and for "blue" just in the normalized HTTP header part of the payload.

http_method

In this case, the Sensor checks for the content only in the normalized HTTP method section within a HTTP request.

Note the following:

  • Content should precede http_method, and it applies only to the immediately preceding content.

  • If you use http_method with offset or depth, then these options are calculated from the beginning of the http payload and not within a specific http field. Consider that you created a rule as shown below:

    alert tcp any any -> any any (msg: "example rule for http_method"; content:"post"; http_method; depth:5; sid:2009;priority:1;)

    The Sensor looks for "post" within 5 bytes from the beginning of the http payload.

  • You cannot apply the http_method and rawbytes to the same content.

Syntax: http_method;

Example rule:

alert tcp any any -> any any (msg:"example for http_method"; content:"red"; content:"PUT";http_method;sid:2009;priority:1;)

For this rule, the Sensor looks for "red" in the entire payload and whether the HTTP method is PUT.

http_uri

In this case, the Sensor checks for the content only in the normalized request URI section.

Note the following:

  • Content should precede http_uri, and it applies only to the immediately preceding Content.

  • Functionally, using http_uri is same as using the uricontent option explained later in this section.

  • If you use http_uri with offset or depth, these options are calculated from the beginning of the http payload. Consider that you created a rule as shown below:

    alert tcp any any -> any any (msg: "example rule for http_uri"; content:"red"; http_uri; depth:50; sid:2009;priority:1;)

    The Sensor looks for "red" within 50 bytes from the beginning of the http payload.

  • You cannot apply http_uri and rawbytes on the same content.

Syntax: http_uri;

Example rule:

alert tcp any any -> any any (msg:"example for http_uri"; content:"red"; content:"blue"; http_uri; sid:2009; priority:1;)

In this rule, the Sensor looks for "red" in the entire payload; "blue" just in the normalized request URI.

http_raw_cookie

This searches the extracted unnormalized cookie header field of a HTTP request or a HTTP response. Since this is a content modifier to the previous content, there must be a content in the rule preceding the http_raw_cookie rule option.

Note

In a Snort custom attack, you cannot use http_raw_cookie modifier with rawbytes or http_cookie modifiers for the same content.

Syntax: http_raw_cookie;

Example rule:

alert tcp any any -> any 80 (msg: "example rule for http_raw_cookie"; content:"red"; content:"blue"; http_raw_cookie;sid:2099;priority:1;)

This rule searches only for blue in the extracted unnormalized cookie header field of a HTTP request.

http_raw_header

This searches the extracted unnormalized header fields of a HTTP request or a HTTP response. Since this is a content modifier to the previous content, there must be a content in the rule preceding the http_raw_header rule option.

Note

In a Snort custom attack, you cannot use http_raw_header modifier with rawbytes or http_cookie modifiers for the same content.

Syntax: http_raw_header;

Example rule:

alert tcp any any -> any 80 (msg: "example rule for http_raw_header"; content:"red"; content:"blue"; http_raw_header;sid:2199;priority:1;)

This rule searches only for blue in the extracted unnormalized header fields of a HTTP request or HTTP response.

http_raw_uri

This searches the unnormalized request URI field. Since this is a content modifier to the previous content, there must be a content in the rule preceding the http_raw_uri rule option.

Note

In a Snort custom attack, you cannot use http_raw_uri modifier with rawbytes or http_cookie modifiers for the same content.

Syntax: http_raw_uri;

Example rule:

alert tcp any any -> any 80 (msg: "example rule for http_raw_uri"; content:"red"; content:"blue"; http_raw_uri;sid:2499;priority:1;)

This rule searches only for blue in the unnormalized URI.

http_stat_code

This searches the extracted status code field from a HTTP response. Since this is a content modifier to the previous content, there must be a content in the rule preceding the http_stat_code rule option.

Note

In a Snort custom attack, you cannot use http_stat_code modifier with rawbytes modifier for the same content.

Syntax: http_stat_code;

Example rule:

alert tcp any any -> any 80 (msg: "example rule for http_stat_code"; content:"red"; content:"200"; http_stat_code;sid:7199;priority:1;)

This rule searches for status 200 in the extracted status code field of a HTTP response.

uricontent

Use this keyword to search in the normalized request URI field. Note that if the uricontent value has anything that is normalized, then the rule will return negative. For example, if the value contains %20, then the Sensor does not raise an alert because it will check for %20 in the normalized uricontent, which it will never find. To check for non-normalized content, consider using the content option with rawbytes.

Note the following:

  • This is same as using content with http_uri.

  • If you use uricontent with offset or depth, these options are calculated from the beginning of the http payload. Consider that you created a rule as shown below:

    alert tcp any any -> any any (msg: "example rule for uricontent"; uricontent:red; depth:50; sid:2009;priority:1;)

    The Sensor looks for "red" within 50 bytes from the beginning of the http payload.

  • You cannot use rawbytes with uricontent.

Syntax: uricontent:[!]<content string>;

Example rule:

alert tcp any any -> any any (msg:"example for uricontent"; content:"red"; uricontent:"hello+world"; sid:2033; priority:1;)

In this rule, the Sensor looks for "red" in the entire payload; "hello+world" just in the normalized request URI.

urilen

This is a condition that enables you to specify the exact, minimum, or maximum lengths, or range of URI lengths to match.

Syntax:

urilen: int<>int;

urilen: [<,>] <int>;

Examples:

urilen:5

Matches URIs that are 5 bytes in length.

Example rule:

alert tcp any any -> any any (msg:"example for urilen"; content:"red"; content:"blue"; urilen:5; sid:2009; priority:1;)

For this rule, the Sensor checks for the strings "red" and "blue" in the entire payload and also sees if the request URI is exactly 5 bytes in length.

urilen: < 5

Matches URIs that are less shorter than 5 bytes.

urilen: 5<>10

Matches URIs that are >= 5 bytes and <= 10 bytes.

PCRE

You can use Perl Compatible Regular Expressions (PCRE) with the related modifiers in the Snort rules. If you use PCRE in a rule, then it should be preceded by a Content. The Content is the triggering token for PCRE options following it. That is, the Sensor checks for the PCRE part of the rule only when the traffic is positive for the preceding Content. Do not use negation operator on the triggering token.

Important

PCRE options are resource-intensive on the Sensor. Trellix recommends that you check if there are other options to achieve the same result.

Syntax: pcre:[!]"(/<regex>/)[ismxAEGUPHMCOIDKYS]";

  • / is the only supported delimiter.

  • For the PCRE options, by default, the Sensor considers only the first 256 bytes from the beginning of the triggering token.

  • When you import or validate the Snort rules in the Manager, you can know the unsupported PCRE options due to which the rules failed to convert successfully.

The following table explains the PCRE-related options supported in Trellix IPS.

Modifier

Description

i

The Sensor ignores the case of the corresponding string.

s

Use this to consider new lines in the dot meta-character.

m

This is used with the anchors (^ and $).

Use m with ^ if you want the Sensor to check for the string immediately after a new line as well as at the beginning of the buffer.

Use m with $ if you want the Sensor to check for the string immediately before a new line as well as at the end of the buffer.

x

Use this if you want the Sensor to ignore any empty space characters in the buffer unless it is escaped or inside a character class.

A

The Sensor checks if the string is at the beginning of the buffer. This is the same as ^.

E

This is used with $. Without E, $ also matches immediately before the final character if it is a new line but not before any other new lines.

G

This inverts the "greediness" of the quantifiers so that they become greedy only when followed by a question mark.

I

Matches the unnormalized HTTP request URI buffer. This is similar to http_raw_uri in function. Snort does not allow using this modifier along with the HTTP request uri buffer modifier for the same content.

C

Matches normalized HTTP request or HTTP response cookie. This is similar to http_cookie in function. This is not allowed with the unnormalized HTTP request or HTTP response cookie modifier for the same content.

H

Matches normalized HTTP request or HTTP response header. This is similar to http_header. This modifier is not allowed with the unnormalized HTTP request or HTTP response header modifier for the same content. For SIP message, matches SIP header for request or response, similar to how sip_header functions.

P

Matches unnormalized HTTP request body. This is similar to how http_client_body functions. For SIP message, matches SIP body for request or response, similar to how sip_body works.

D

Matches unnormalized HTTP request or HTTP response header, similar to http_raw _header. This modifier is not allowed with the normalized HTTP request or HTTP response header modifier for the same content.

M

Matches normalized HTTP request method, similar to http_method

K

Matches unnormalized HTTP request or HTTP response cookie, similar to http_raw_cookie. This modifier is not allowed with the normalized HTTP request or HTTP response cookie modifier for the same content.

S

Matches HTTP response status code, similar to http_stat_code

Y

Matches HTTP response status message, similar to http_stat_msg

Note

\X, \P, \K, \U, \R, and \C escape sequences and back references are not supported.

Example rule:

alert tcp any any -> any any (msg: "command dot exe attempt"; content: "user"; pcre:"/cMd.eXe/i"; sid:2030; priority: 1;)

This rule first checks for the string, "user". Here, "user" is the triggering token. If "user" is found, the Sensor then checks for the PCRE "cmd.exe" in the first 256 bytes from the beginning of the buffer.

sip_method

This rule option enables you to check for Session Initiation Protocol (SIP) request methods. In the same option, you can specify multiple SIP request methods separated by commas. In this case, it is considered as an OR condition. That is, the rule triggers if there is a match for any of the mentioned request methods.

Syntax:

sip_method:<method>|<method-list>

The following request methods are supported:

  • invite

  • cancel

  • ack

  • bye

  • register

  • options

  • refer

  • subscribe

  • update

  • join

  • info

  • message

  • notify

  • prack

The ! operator is supported. However, if you use !, you can specify only one method in one sip_method option.

Examples:

  • sip_method:invite — This checks for the invite request method.

  • sip_method:!invite — The condition is true if the method is anything other than invite.

  • sip_method:invite,cancel,bye — The condition is true if the method is invite, cancel, or bye.

  • sip_method:!invite; sip_method:!cancel — The condition is true if the method is anything other than invite and cancel.

Example rule:

alert udp any any -> 10.1.1.1 5060 (msg:"Example rule"; flow:to_server; sip_method:invite; content:"SIP/2.0"; nocase; priority:1; sid:20189;rev:1;)

sip_stat_code

This rule option enables you to check for SIP response status codes. The condition matches if any of the specified status code is present in the SIP response.

Syntax:

sip_stat_code:<code>|<code>,<code>

The following request methods are supported:

Examples:

  • sip_stat_code:400 — This checks for the status code 400.

  • sip_stat_code:180,182 — The condition matches of the status code is 180 or 182.

  • sip_stat_code:4 — This condition looks for 4xx. That is it is true if the method is anything from 400 to 599. The numbers 1 to 6 are expressed as 1xx, 2xx, 3xx, and so on where, for example, 1xx corresponds to the range 100 - 199.

Example rule:

alert udp any any -> 10.1.1.1 5060 (msg:"Example rule"; flow:to_server; sip_stat_code:401; content:"SIP/2.0"; nocase; priority:1; sid:20289;rev:1;)

sip_header

This rule option searches only the extracted header fields of a SIP request or response.

Syntax: sip_header;

Example rule:

alert udp any any -> 10.1.1.1 5060 (msg:"Example rule"; flow:to_server; sip_header; content:"SIP/2.0"; nocase; priority:1; sid:20290;rev:1;)

sip_body

This rule option points the Sensor to the beginning of the body fields of a SIP message.

Syntax: sip_body;

Example rule:

alert udp any any -> 10.1.1.1 5060 (msg:"Example rule"; flow:to_server; sip_body; content:"SIP/2.0"; nocase; priority:1; sid:20491;rev:1;)

ssl_version

This rule option can check for the SSL version numbers exchanged between the server and the client during the handshake. In the same option, you can check for multiple SSL versions separated by commas. In this case, it is considered as an OR condition. That is, the rule triggers if there is a match for any of the versions. To check for an AND condition involving two or more versions, use separate ssl_version rule options.

Syntax:

ssl_version:<version-list>

The ! operator is supported. However, if you use !, you can specify only one method in one sip_method option.

Examples:

  • ssl_version:sslv2 — This checks for SSL version 2.

  • ssl_version:!sslv3 — The condition is true for any version other than SSL version 3.

  • ssl_version:tls1.0,tls1.1,tls1.2 — The condition is true if the SSL version is TLS 1.0, TLS 1.1, or TLS 1.2.

  • ssl_version:!tls1.0; ssl_version:!tls1.1 — The condition is true if the SSL version is anything other than TLS 1.0 and TLS 1.1.

Example rule:

alert tcp any any -> 10.1.1.2 443 (msg:"Example rule"; flow:to_server; ssl_version:sslv2; content:"|0B|"; priority:1; sid:20389;rev:1;)

ssl_state

This option is not relevant for a Snort rule in Trellix IPS, and is not supported. If a rule that you imported contained this option, it is displayed in the Conversion Notes section of the rule. The Sensor ignores this option when it checks the traffic against this rule.

modbus_func

This rule option checks for the specified function code in the in a Modbus header. You can specify either the code number in the decimal format or the equivalent string.

Syntax: modbus_func:<code>

The following are the supported values for code:

  • A number ranging from 0 to 255

  • read_coils

  • read_discrete_inputs

  • read_holding_registers

  • read_input_registers

  • write_single_coil

  • write_single_register

  • read_exception_status

  • diagnostics

  • get_comm_event_counter

  • get_comm_event_log

  • write_multiple_coils

  • write_multiple_registers

  • report_slave_id

  • read_file_record

  • write_file_record

  • mask_write_register

  • read_write_multiple_registers

  • read_fifo_queue

  • encapsulated_interface_transport

Examples:

  • modbus_func:1

  • modbus_func:read_discrete_inputs

Example rule:

alert tcp any any -> 10.1.1.5 502 (msg:"Example rule"; flow:to_server; modbus_func:write_multiple_coils; byte_test:2,>,1968,10; reference:url,www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf; classtype:protocol-command-decode; priority:1; sid:20589;rev:1;)

modbus_data

This rule option points the Sensor to the beginning of the data field in a Modbus request or response.

Syntax: modbus_data;

Example rule:

alert tcp any any -> 10.1.1.7 502 (msg:"Example rule"; flow:to_server; modbus_data; content:"example content"; nocase; priority:1; sid:20481;rev:1;)

dnp3_func

This rule option checks against the function code of a DNP3 request or response header. You can specify either the code number in the decimal format or the equivalent string.

Syntax:

dnp3_func:<code>

The following are the supported values for code:

  • A number ranging from 0 to 255

  • confirm

  • read

  • write

  • select

  • operate

  • direct_operate

  • direct_operate_nr

  • immed_freeze

  • immed_freeze_nr

  • freeze_clear

  • freeze_clear_nr

  • freeze_at_time

  • freeze_at_time_nr

  • cold_restart

  • warm_restart

  • initialize_data

  • initialize_appl

  • start_appl

  • stop_appl

  • save_config

  • enable_unsolicited

  • disable_unsolicited

  • assign_class

  • delay_measure

  • record_current_time

  • open_file

  • close_file

  • delete_file

  • get_file_info

  • authenticate_file

  • abort_file

  • activate_config

  • authenticate_req

  • authenticate_err

  • response

  • unsolicited_response

  • authenticate_resp

Examples:

  • dnp3_func:2;

  • dnp3_func:get_file_info;

dnp3_data

This rule option points the Sensor to the beginning of the application-layer fragment so that the Sensor can execute the other rule options.

Syntax:

dnp3_data;

Example:

dnp3_data; content:"example content";

Copyright © 2026 Musarubra US LLC | Privacy | Legal | AI Disclaimer