The arp_spoof inspector does not provide default configuration parameter values in the FMC web interface.

Enable the arp_spoof inspector rules to generate events and, in an inline deployment, drop offending packets.

The arp_spoof inspector does not have any intrusion rule options.

binder[]

A binder includes an array of rules defined as a pair of when and use objects.

Type: array

Example:

{
    binder: {
        rules: [
            {
                "when": {
                    ...
                },
                "use": {
                    ...
                 }
            },
            {
                "when": {
                    ...
                },
                "use": {
                    ...
                }
            }
        ]
    }
}

binder[].use.type

Specifies the inspector to bind to the data flow when the criteria in the when parameter matches. For example, to inspect CIP traffic, add use.type with a value of cip.

Type: string

Valid values: The name of any Snort 3 inspector described in this document.

Default value: The binder inspector includes a use.type parameter for each supported inspector.

binder[].when.proto

Specifies the protocol that the traffic must match to bind the data flow to the inspector specified in use.type. For example, if the network analysis policy is configured to inspect TCP traffic, the binder inspector must have this parameter set to tcp.

Type: enum

Valid values: any, ip, icmp, tcp, udp, user, file

Default value: The binder inspector includes a when.proto parameter for each protocol.

binder[].when.ports

Specifies the ports that the traffic must match to bind the data flow to the inspector specified in use.type. For example, to inspect traffic on TCP port 80, set when.proto to tcp and when.ports to 80.

Specify a list of one or more ports represented as decimal or hex integers. Separate multiple ports with a space and enclose the list with double quotes.

Type: string

Valid range: 1 - 65535

Default value: 65535 (This value may vary depending upon the value of when.proto.)

binder[].when.role

Specifies the roles that the traffic must match to bind the flow to the inspector specified in use.type.

Type: enum

Valid values: client, server, any

Default value: any

Specifies the service that the traffic must match to bind the flow to the inspector specified in use.type.

Type: string

Valid values: A name of a service that may encapsulate incoming data, for example: netbios-ssn or dcerpc.

Default value: None

The binder inspector does not have any associated rules.

The binder inspector does not have any intrusion rule options.

CIP TCP port configuration

The binder inspector defines the CIP TCP port configuration. For more information, see the Binder Inspector.

[
    {
        "when": {
                    "role": "server",
                    "proto": "tcp",
                    "ports": "44818"
        },
        "use": {
                    "type": "cip"
        }
    }
]

embedded_cip_path

Determines whether the inspector checks the embedded CIP connection path.

Type: string

Valid values:

• "false"

• CIP path enclosed in double quotation marks, for example, "0x2 0x36".

Default value: "false"

unconnected_timeout

Sets the default unconnected timeout in seconds. When a CIP request message does not contain a protocol-specific timeout value and the maximum number of concurrent unconnected requests per TCP connection is reached, the system times the message for the number of seconds specified by this parameter. When the timer expires, the message is removed to make room for future requests.

When you specify 0, all traffic that does not have a protocol-specific timeout configured times out first.

Type: integer

Valid range: 0 - 360

Default value: 300

max_unconnected_messages

Sets the maximum number of concurrent unconnected CIP messages per TCP connection. If the system reaches the maximum number of concurrent requests that can go unanswered, the system closes the connection.

Type: integer

Valid range: 1 - 10000

Default value: 100

max_cip_connections

Sets the maximum number of simultaneous CIP connections allowed by the system per TCP connection.

Type: integer

Valid range: 1 - 10000

Default value: 100

Enable the cip inspector rules to generate events and, in an inline deployment, drop offending packets.

cip_attribute

Detection parameter to match the CIP attribute.

Type: interval

Syntax: cip_attribute: <range_operator><positive integer>; or cip_attribute: <positive integer><range_operator><positive integer>;

Valid values: A set of one or more integers between 0 and 65535, and a range_operator as specified in the Range Formats table.

Examples: cip_attribute: <100;

cip_class

Detection parameter to match the CIP class.

Type: interval

Syntax: cip_class: <range_operator><positive integer>; or cip_class: <positive integer><range_operator><positive integer>;

Valid values: A set of one or more integers between 0 and 65535, and a range_operator as specified in the Range Formats table.

Examples: cip_class: <25;

cip_conn_path_class

Detection parameter to match the CIP connection path class.

Type: interval

Syntax: cip_conn_path_class: <range_operator><positive integer>; or cip_conn_path_class: <positive integer><range_operator><positive integer>;

Valid values: A set of one or more integers between 0 and 65535, and a range_operator as specified in the Range Formats table.

Examples: cip_conn_path_class: <85;

cip_instance

Detection parameter to match the CIP instance.

Type: interval

Syntax: cip_instance: <range_operator><positive integer>; or cip_instance: <positive integer><range_operator><positive integer>;

Valid values: A set of one or more integers between 0 and 65535, and a range_operator as specified in the Range Formats table.

Examples: cip_instance: <15;

cip_req

Detection parameter to match the CIP request.

Syntax: cip_req;

Examples: cip_req;

cip_rsp

Detection parameter to match the CIP response.

Syntax: cip_rsp;

Examples: cip_rsp;

cip_service

Detection parameter to match the CIP service.

Type: interval

Syntax: cip_service: <range_operator><positive integer>; or cip_service: <positive integer><range_operator><positive integer>;

Valid values: A set of one or more integers between 0 and 127, and a range_operator as specified in the Range Formats table.

Examples: cip_service: <50;

cip_status

Detection parameter to match the CIP response status.

Type: interval

Syntax: cip_status: <range_operator><positive integer>; or cip_status: <positive integer><range_operator><positive integer>;

Valid values: A set of one or more integers between 0 and 255, and a range_operator as specified in the Range Formats table.

Examples: cip_status: <250;

DCE SMB port configuration

The binder inspector defines the DCE SMB port configuration. For more information, see the Binder Inspector.

[
   {
       "when": {
           "role":"any",
           "service":"netbios-ssn",
           "ports": ""
       },
        "use": {
            "type":"dce_smb"
       }
   }
]

max_frag_len

Specifies the maximum fragment length in bytes allowed for defragmentation. For processing larger fragments the inspector considers packet content to this size before defragmenting.

Note	The value specified in this parameter must be greater than or equal to the depth to which the rules need to examine the data to ensure detection. To ensure that all data goes through detection, use the default value.

Type: integer

Valid range: 1514 - 65535

Default value: 65535

smb_max_compound

Specifies the maximum number of commands to process in one SMB request.

Type: integer

Valid range: 0 - 255

Default value: 3

smb_max_chain

Specifies the maximum number of chained SMB AndX commands allowed. Typically, more than a few chained AndX commands represent anomalous behavior and could indicate an evasion attempt. Specify 1 to permit no chained commands or 0 to disable detecting the number of chained commands.

The inspector first counts the number of chained commands and generates an event if accompanying SMB inspector rules are enabled and the number of chained commands equals or exceeds the configured value. It then continues processing.

You can enable rule 133:20 to generate events and, in an inline deployment, drop offending packets for this parameter.

Type: integer

Valid range: 0 - 255

Default value: 3

disable_defrag

Specifies whether to defragment fragmented DCE/RPC traffic. When enabled, the dce_smb inspector detects anomalies and sends DCE/RPC data to the rules engine, but at the risk of missing exploits in fragmented DCE/RPC data.

Although disable_defrag provides the flexibility of not defragmenting traffic and can speed processing, most DCE/RPC exploits attempt to take advantage of fragmentation to hide the exploit. Enabling this parameter would bypass most known exploits, resulting in a large number of false negatives.

Type: boolean

Valid values: true, false

Default value: false

limit_alerts

Specifies whether to limit the DCE alerts to at most one per signature per flow.

Type: boolean

Valid values: true, false

Default value: true

reassemble_threshold

Specifies the minimum number of bytes in the DCE/RPC desegmentation and defragmentation buffers to queue before sending a reassembled packet to the rules engine. This parameter is useful in inline mode so as to potentially catch an exploit early before full defragmentation is done.

Note that a low value increases the likelihood of early detection but could have a negative impact on performance. You should test for performance impact if you enable this parameter.

A value of 0 disables reassembly.

Type: integer

Valid range: 0 - 65535

Default value: 0

policy

Specifies the Windows or Samba DCE/RPC implementation used by the targeted host or hosts on your monitored network segment.

Type: enum

Valid values: Win2000, WinXP, WinVista, Win2003, Win2008, Win7, Samba, Samba-3.0.37, Samba-3.0.22, Samba-3.0.20

Default value: "WinXP"

smb_max_credit

Specifies the maximum number of outstanding requests.

Type: integer

Valid range: 1 - 65536

Default value: 8192

smb_file_depth

Specifies the number of bytes inspected when a file is detected in SMB traffic, beginning at the location specified by the file_data IPS rule option (described in Snort 3 open source documentation, available at https://www.snort.org/snort3).

Specify -1 to disable file inspection.

Specify 0 to indicate unlimited file inspection.

Type: integer

Valid range: -1 - 32767

Default value: 16384

When a file is detected in SMB traffic, the smb_file_depth parameter indicates the number of file data bytes the inspector will examine beginning at the pointer set in the file_data IPS rule option. To inspect the file type and signature, dce_smb uses the enable_type, type_depth, enable_signature, and signature_depth parameters set in the file_id inspector. For more information on the file_id inspector, see the Snort open source documentation, available at https://www.snort.org/snort3.

memcap

Specifies the maximum memory limit in bytes allocated to the inspector. When the maximum memory cap is reached or exceeded, the dce_smb inspector deletes the least recently used data to create more space.

Type: integer

Valid range: 512 - 9,007,199,254,740,992 (maxSZ)

Default value: 8,388,608

smb_fingerprint_policy

Causes the inspector to detect the Windows or Samba version that is identified in SMB Session Setup AndX requests and responses. When the detected version is different from the Windows or Samba version configured for the policy inspector parameter, the detected version overrides the configured version for that session only.

For example, if you set policy to Windows XP and the inspector detects Windows Vista, the inspector uses a Windows Vista policy for that session. Other settings remain in effect.

Type: enum

Valid values: none, client, server, or both

• Use client to inspect server-to-client traffic for the policy type.

• Use server to inspect client-to-server traffic for the policy type.

• Use both to inspect server-to-client and client-to-server traffic for the policy type.

• Use none to disable Windows or Samba version inspection.

Default value: none

smb_legacy_mode

When smb_legacy_mode is true, the system applies SMB intrusion rules only to SMB Version 1 traffic, and applies DCE/RPC intrusion rules to DCE/RPC traffic using SMB Version 1 as a transport.

When smb_legacy_mode is false, the system applies SMB intrusion rules to traffic using SMB Versions 1, and 2, and:

• For Versions 7.0 and 7.0.x the system applies DCE/RPC intrusion rules to DCE/RPC traffic using SMB as a transport only for SMB Version 1.

• For Versions 7.1+ the system applies DCE/RPC intrusion rules to DCE/RPC traffic using SMB as a transport for SMB Versions 1 and 2.

Type: boolean

Valid values: true, false

Default value: false

valid_smb_versions

Specifies which SMB versions to inspect. Separate multiple SMB versions with a space character.

Type: string

Valid values: v1, v2, all

Default value: all

Enable the dce_smb inspector rules to generate events and, in an inline deployment, drop offending packets.

dce_iface

Specifies the following comma-separated elements:

• The UUID for a service interface.

• The interface version (optional). The default setting matches any version.

• An indicator of whether a rule should match on any fragment in a request (optional). The default setting matches only the first fragment.

In the DCE/RPC protocol, a client must bind to a service before making a call to it. When a client sends a bind request to the server, it can specify one or more service interfaces to bind to. Each interface is represented by a UUID, and each interface UUID is paired with a unique index (or context ID) that future requests can use to reference the service that the client is calling. The server responds with the interface UUIDs it accepts as valid and allows the client to make requests to those services. When a client makes a request, it will specify the context ID so the server knows to what service the client is making a request.

Using the dce_iface rule option, a rule can ask the inspector whether the client has bound to a specific interface UUID and whether this client request is making a request to that interface. This can eliminate false positives where more than one service is bound to successfully since the inspector can correlate the bind UUID to the context id used in the request.

The dce_iface option requires tracking client Bind and Alter Context requests as well as server Bind Ack and Alter Context responses for connection-oriented DCE/RPC in the inspector. For each Bind and Alter Context request, the client specifies a list of interface UUIDs along with a handle (or context id) for each interface UUID that will be used during the DCE/RPC session to reference the interface. The server response indicates which interfaces it allows the client to make requests to—it either accepts or rejects the client’s wish to bind to a certain interface. This tracking is required so that when a request is processed, the context id used in the request can be correlated with the interface UUID for which it is a handle.

The dce_iface rule option matches if:

• the specified interface UUID matches the interface UUID (as referred to by the context ID) of the DCE/RPC request

and

• the version argument is not supplied, or the version argument is supplied and matches the interface UUID of the DCE/RPC request

and

• the any_frag argument is supplied, or the any_frag argument is absent and the dce_iface option matches the UUID and version criteria on the initial request fragment

Examples:

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188;

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, <2;

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188,any_frag;

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, =1, any_frag;

dce_iface.uuid

A DCE/RPC request can specify whether UUID numbers are represented as big endian or little endian. The representation of the interface UUID in a request is different depending on the endianness specified in the request. The dce_rpc inspector normalizes the UUID. This means that the UUID specification in the dce_iface rule option must be written the same way regardless of the endianness of the request.

For example, a little endian Bind request would represent a UUID as follows:

|f8 91 7b 5a 00 ff d0 11 a9 b2 00 c0 4f b6 e6 fc|

and a big-endian Bind request would represent the same UUID as follows:

|5a 7b 91 f8 ff 00 11 d0 a9 b2 00 c0 4f b6 e6 fc|

In Snort 3 rules using the dce_iface option, the UUID must be represented in a string using big endian order regardless of the endian-ness of the request:

5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc

Type: string

Syntax: dce_iface: <UUID>;

Valid values: Where: UUID is 32 hexadecimal digits, displayed in five groups separated by hyphens, in the form: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Examples: dce_iface: 5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc;

dce_iface.version

A service interface has a version associated with it. Some versions of an interface may not be vulnerable to certain exploits. For this reason you can specify one or more version numbers in the dce_iface option, to determine whether it is necessary to check for a particular exploit.

Type: interval

Syntax: dce_iface: <range_operator><positive integer>; or dce_iface: <positive integer><range_operator><positive integer>;

Valid values: A set of one or more positive version numbers and a range_operator as specified in the Range Formats table.

Examples: dce_iface: =6;

dce_iface.any_frag

A DCE/RPC request can be broken up into 1 or more fragments. Flags are set in the DCE/RPC header to indicate whether the current fragment is the first, a middle, or the last fragment of the request. Many checks for data in the DCE/RPC request are relevant only if the DCE/RPC request is a first fragment (or full request), since subsequent fragments will contain data deeper into the DCE/RPC request. For example, a rule that looks for data 5 bytes into the request (for example, a length field), will looking at the wrong data on a fragment other than the first, since the beginning of subsequent fragments are already offset some length from the beginning of the request. This can be a source of false positives in fragmented DCE/RPC traffic.

For this reason, by default the DCE_RPC inspector matches only the initial fragment in a request. To force the inspector to examine all fragments in a request for a match, add any_frag to the dce_iface rule option. Note that a defragmented DCE/RPC request is considered a full request.

Syntax: dec_iface: any_frag;

Examples: dce_iface: any_frag;

dce_opnum

Match a DCE RPC operation number, range of operation number, or list of operation number. This option represents one or more a specific function calls that can be made to an interface. After a client has bound to a specific service interface and makes a request to it, rules need to determine what function call the client is making to the service, to check for exploits that may lie within the function call. The functions call(s) are specified as a double-quote-enclosed list of operation numbers (opnums)

Type: string

Syntax: dce_opnum: <opnum_list>;

Where opnum_list is one of the following:

• A single integer.

• A comma-separated list of integers.

• A range of integers specified with a hyphen separating the lowest and highest numbers in the range.

• A combination of the above.

Valid values: A list of DCE/RPC request opnums.

Examples:

dce_opnum: "15";

dce_opnum: "15-18";

dce_opnum: "15, 18-20";

dce_opnum: "15, 17, 20-22";

dce_stub_data

This option places the detection cursor (used to traverse the packet payload in rules processing) at the beginning of the DCE/RPC stub data, regardless of preceding rule options. This option matches if there is DCE/RPC stub data present.

Syntax: dce_stub_data;

Examples: dce_stub_data;

DCE TCP port configuration

The binder inspector defines the DCE TCP port configuration. For more information, see the Binder Inspector.

[
   {
        "when": {
            "role": "any",
            "proto": "tcp",
            "service": "dcerpc",
            "ports": ""
        },
        "use": {
            "type": "dce_tcp"
        }
    }
]

max_frag_len

Specifies the maximum fragment length in bytes allowed for defragmentation. For processing larger fragments the inspector considers packet content to the specified size before defragmenting.

Note	The value specified in this parameter must be greater than or equal to the depth to which the rules need to examine the data to ensure detection. To ensure that all data goes through detection, use the default value.

Type: integer

Valid range: 1514 - 65535

Default value: 65535

disable_defrag

Specifies whether to defragment fragmented DCE/RPC traffic. When this parameter is true, the inspector still detects anomalies and sends DCE/RPC data to the rules engine, but at the risk of missing exploits in fragmented DCE/RPC data.

Although this parameter provides the flexibility of not defragmenting traffic and can speed processing, most DCE/RPC exploits attempt to take advantage of fragmentation to hide the exploit. Enabling this parameter would bypass most known exploits, resulting in a large number of false negatives.

Type: boolean

Valid values: true, false

Default value: false

limit_alerts

Specifies whether to limit DCE alerts to at most one per signature per flow.

Type: boolean

Valid values: true, false

Default value: true

reassemble_threshold

Specifies the minimum number of bytes in the DCE/RPC desegmentation and defragmentation buffers to queue before sending a reassembled packet to the rules engine. This parameter is useful in inline mode so as to potentially catch an exploit early before full defragmentation is done.

A low value increases the likelihood of early detection but could have a negative impact on performance. You should test for performance impact if you enable this parameter.

A value of 0 disables reassembly.

Type: integer

Valid range: 0 - 65535

Default value: 0

policy

Specifies the Windows or Samba DCE/RPC implementation used by the targeted host or hosts on your monitored network segment.

Type: enum

Valid values: A double-quote enclosed string selected from the following list: Win2000, WinXP, WinVista, Win2003, Win2008, Win7, Samba, Samba-3.0.37, Samba-3.0.22, Samba-3.0.20

Default value: "WinXP".

Enable the dce_tcp inspector rules to generate events and, in an inline deployment, drop offending packets.

dce_iface

Specifies the following comma-separated elements:

• The UUID for a service interface.

• The interface version (optional). The default setting matches any version.

• An indicator of whether a rule should match on any fragment in a request (optional). The default setting matches only the first fragment.

In the DCE/RPC protocol, a client must bind to a service before making a call to it. When a client sends a bind request to the server, it can specify one or more service interfaces to bind to. Each interface is represented by a UUID, and each interface UUID is paired with a unique index (or context ID) that future requests can use to reference the service that the client is calling. The server responds with the interface UUIDs it accepts as valid and allows the client to make requests to those services. When a client makes a request, it will specify the context ID so the server knows to what service the client is making a request.

Using the dce_iface rule option, a rule can ask the inspector whether the client has bound to a specific interface UUID and whether this client request is making a request to that interface. This can eliminate false positives where more than one service is bound to successfully since the inspector can correlate the bind UUID to the context id used in the request.

The dce_iface option requires tracking client Bind and Alter Context requests as well as server Bind Ack and Alter Context responses for connection-oriented DCE/RPC in the inspector. For each Bind and Alter Context request, the client specifies a list of interface UUIDs along with a handle (or context id) for each interface UUID that will be used during the DCE/RPC session to reference the interface. The server response indicates which interfaces it allows the client to make requests to—it either accepts or rejects the client’s wish to bind to a certain interface. This tracking is required so that when a request is processed, the context id used in the request can be correlated with the interface UUID for which it is a handle.

The dce_iface rule option matches if:

• the specified interface UUID matches the interface UUID (as referred to by the context ID) of the DCE/RPC request

and

• the version argument is not supplied, or the version argument is supplied and matches the interface UUID of the DCE/RPC request

and

• the any_frag argument is supplied, or the any_frag argument is absent and the dce_iface option matches the UUID and version criteria on the initial request fragment

Examples:

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188;

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, <2;

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188,any_frag;

dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, =1, any_frag;

dce_iface.uuid

A DCE/RPC request can specify whether UUID numbers are represented as big endian or little endian. The representation of the interface UUID in a request is different depending on the endianness specified in the request. The dce_rpc inspector normalizes the UUID. This means that the UUID specification in the dce_iface rule option must be written the same way regardless of the endianness of the request.

For example, a little endian Bind request would represent a UUID as follows:

|f8 91 7b 5a 00 ff d0 11 a9 b2 00 c0 4f b6 e6 fc|

and a big-endian Bind request would represent the same UUID as follows:

|5a 7b 91 f8 ff 00 11 d0 a9 b2 00 c0 4f b6 e6 fc|

In Snort 3 rules using the dce_iface option, the UUID must be represented in a string using big endian order regardless of the endian-ness of the request:

5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc

Type: string

Syntax: dce_iface: <UUID>;

Valid values: Where: UUID is 32 hexadecimal digits, displayed in five groups separated by hyphens, in the form: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Examples: dce_iface: 5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc;

dce_iface.version

A service interface has a version associated with it. Some versions of an interface may not be vulnerable to certain exploits. For this reason you can specify one or more version numbers in the dce_iface option, to determine whether it is necessary to check for a particular exploit.

Type: interval

Syntax: dce_iface: <range_operator><positive integer>; or dce_iface: <positive integer><range_operator><positive integer>;

Valid values: A set of one or more positive version numbers and a range_operator as specified in the Range Formats table.

Examples: dce_iface: =6;

dce_iface.any_frag

A DCE/RPC request can be broken up into 1 or more fragments. Flags are set in the DCE/RPC header to indicate whether the current fragment is the first, a middle, or the last fragment of the request. Many checks for data in the DCE/RPC request are relevant only if the DCE/RPC request is a first fragment (or full request), since subsequent fragments will contain data deeper into the DCE/RPC request. For example, a rule that looks for data 5 bytes into the request (for example, a length field), will looking at the wrong data on a fragment other than the first, since the beginning of subsequent fragments are already offset some length from the beginning of the request. This can be a source of false positives in fragmented DCE/RPC traffic.

For this reason, by default the DCE_RPC inspector matches only the initial fragment in a request. To force the inspector to examine all fragments in a request for a match, add any_frag to the dce_iface rule option. Note that a defragmented DCE/RPC request is considered a full request.

Syntax: dec_iface: any_frag;

Examples: dce_iface: any_frag;

dce_opnum

Match a DCE RPC operation number, range of operation number, or list of operation number. This option represents one or more a specific function calls that can be made to an interface. After a client has bound to a specific service interface and makes a request to it, rules need to determine what function call the client is making to the service, to check for exploits that may lie within the function call. The functions call(s) are specified as a double-quote-enclosed list of operation numbers (opnums)

Type: string

Syntax: dce_opnum: <opnum_list>;

Where opnum_list is one of the following:

• A single integer.

• A comma-separated list of integers.

• A range of integers specified with a hyphen separating the lowest and highest numbers in the range.

• A combination of the above.

Valid values: A list of DCE/RPC request opnums.

Examples:

dce_opnum: "15";

dce_opnum: "15-18";

dce_opnum: "15, 18-20";

dce_opnum: "15, 17, 20-22";

dce_stub_data

This option places the detection cursor (used to traverse the packet payload in rules processing) at the beginning of the DCE/RPC stub data, regardless of preceding rule options. This option matches if there is DCE/RPC stub data present.

Syntax: dce_stub_data;

Examples: dce_stub_data;

DNP3 TCP port configuration

The binder inspector defines the DNP3 TCP port configuration. For more information, see the Binder Inspector.

[
   {
       "when": {
           "role": "any",
           "service": "dnp3"
	   },
       "use": {
           "type": "dnp3"
       }
    }
]

check_crc

Specifies whether to validate the checksums contained in DNP3 Link-Layer Frames. The dnp3 inspector ignores frames with invalid checksums. If intrusion rule 145:1 is enabled, Snort generates alerts for invalid checksums.

Type: boolean

Valid values: true, false

Default value: false

Enable the dnp3 inspector rules to generate events and, in an inline deployment, drop offending packets.

dnp3_data

The dnp3_data keyword positions the detection cursor to the beginning of the DNP3 data in an application layer fragment, regardless of preceding rule options. With this option you can write rules based on the data within fragments without splitting up the data and adding CRCs every 16 bytes.

Syntax: dnp3_data;

Examples: dnp3_data;

dnp3_func

This option matches against the function code inside a DNP3 Application Layer request/response header. The code may be a decimal number or a string from the list below.

Type: string

Syntax: dnp3_func: <DNP3_function>;

Valid values: DNP3_function is one of the following:

• An integer from 0 to 255

• confirm (Corresponds to function code 0.)

• read (Corresponds to function code 1.)

• write (Corresponds to function code 2.)

• select (Corresponds to function code 3.)

• operate (Corresponds to function code 4.)

• direct_operate (Corresponds to function code 5.)

• direct_operat_nr (Corresponds to function code 6.)

• immed_freeze (Corresponds to function code 7.)

• immed_freeze_nr (Corresponds to function code 8.)

• freeze_clear (Corresponds to function code 9.)

• freeze_clear_nr (Corresponds to function code 10.)

• freeze_at_time (Corresponds to function code 11.)

• freeze_at_time_nr (Corresponds to function code 12.)

• cold_restart (Corresponds to function code 13.)

• warm_restart (Corresponds to function code 14.)

• initialize_data (Corresponds to function code 15.)

• initialize_appl (Corresponds to function code 16.)

• start_appl (Corresponds to function code 17.)

• stop_appl (Corresponds to function code 18.)

• save_config (Corresponds to function code 19.)

• enable_unsolicited (Corresponds to function code 20.)

• disable_unsolicited (Corresponds to function code 21.)

• assign_class (Corresponds to function code 22.)

• delay_measure (Corresponds to function code 23.)

• record_current_time (Corresponds to function code 24.)

• open_file (Corresponds to function code 25.)

• close_file (Corresponds to function code 26.)

• delete_file (Corresponds to function code 27.)

• get_file_info (Corresponds to function code 28.)

• authenticate_file (Corresponds to function code 29.)

• abort_file (Corresponds to function code 30.)

• activate_config (Corresponds to function code 31.)

• authenticate_req (Corresponds to function code 32.)

• authenticate_err (Corresponds to function code 33.)

• response (Corresponds to function code 129.)

• unsolicited_response (Corresponds to function code 130.)

• authenticate_resp (Corresponds to function code 131.)

Examples:

dnp3_func: 1;

dnp3_func: delete_file;

dnp3_ind

Provide a list of Internal Indicator flags to match against the Internal Indicator flags in a DNP3 application layer response header. If you provide multiple flags in one option, the rule fires if any one of the flags is set. To alert on multiple flags, use multiple rule options.

Type: string

Syntax: dnp3_ind: "<flag> <flag>";

Valid values: One or more DNP3 Internal Indicator flags where flag is one of the following:

• all_stations

• class_1_events

• class_2_events

• class_3_events

• need_time

• local_control

• device_trouble

• device_restart

• no_func_code_support

• object_unknown

• parameter_error

• event_buffer_overflow

• already_executing

• config_corrupt

• reserved_2

• reserved_1

Examples:

Alert on device restart OR on initiation of time synchronization:

dnp3_ind:"device_restart need_time";

Alert on class_1 AND class_2 AND class_3 events:

dnp3_ind:class_1_events; dnp3_ind:class_2_events; dnp3_ind:class_3_events;
            

dnp3_obj

Matches on DNP3 object header groups and variations.

Type: integer

Syntax: dnp3_obj:<groupnum>,<varnum>;

Valid values: DNP3 object group identifiers and variation identifiers, where:

• groupnum is an integer from 0 to 255 specifying a DNP3 object group.

• varnum is an integer from 0 to 255 specifying a variation within the object group.

Examples:

Alert on DNP3 Date and Time object:

dnp3_obj:50,1;

bounce

Specifies whether to check for FTP bounces by examining the host information in ftp port commands issued by the client. When bounce is true, if the host information in an ftp port command does not match the configured client IP address or host information , and rule 125:8 is enabled, the system generates an alert, and in an inline deployment drops offending packets. This can be used to prevent FTP bounce attacks and permit FTP connections where the FTP data channel destination is different from the client.

Type: boolean

Valid values: true, false

Default value: false

ignore_telnet_erase_cmds

Specifies whether to ignore the telnet escape sequences for the erase character (TNC EAC) and the erase line character (TNC EAL) when normalizing the FTP command channel. You should set this parameter to match how the FTP client handles telnet erase commands. Newer FTP clients typically ignore these telnet escape sequences, while legacy clients typically process them. When the ignore_telnet_erase_cmds parameter is false, the inspector uses rule 125:1 to generate alerts, and in an inline deployment, drop offending packets.

Type: boolean

Valid values: true, false

Default value: false

max_resp_len

Specifies the maximum length for all response messages accepted by the client in bytes. If the message for an FTP response (everything after the 3 digit return code) exceeds that length, and rule 125:6 is enabled, the system generates an alert, and, in an inline deployments, drop offending packets. This is used to check for buffer overflow exploits within FTP clients.

Type: integer

Valid range: 0 - 4,294,967,295 (max32)

Default value: 4,294,967,295

telnet_cmds

Specifies whether to check for telnet commands on the FTP command channel. The presence of such commands could indicate an evasion attempt on the FTP command channel.

You can enable rule 125:1 to generate events for this parameter, and in an inline deployment, drop offending packets.

Type: boolean

Valid values: true, false

Default value: false

Enable the ftp_client inspector rules to generate events and, in an inline deployment, drop offending packets.

The ftp_client inspector does not have any intrusion rule options.

FTP Server port configuration

The binder inspector defines the FTP Server configuration. For more information, see the Binder Inspector.

[
    {
        "when": {
            "role":"any",
            "service":"ftp",
            "ports": ""
        },
        "use": {
            "type":"ftp_server"
        }
    }
]

chk_str_fmt

Specifies a list of FTP commands to check for string format attacks. You can enable rule 125:5 to generate an alert, and in an inline deployment, drop offending packets when the inspector detects this condition. Separate multiple commands with a space character.

Type: string

Valid values: A list of valid FTP commands.

Default value: None

data_chan_cmds

Specifies a list of FTP commands to check for correct formatting. Separate multiple commands with a space character.

Type: string

Valid values: A list of one or more of the following commands: PORT PASV LPRT LPSV EPRT EPSV.

Default value: None

data_xfer_cmds

Specifies a list of data transfer commands. Check for correct formatting of the commands. Separate multiple commands with a space character.

Type: string

Valid values: A list of one or more of the following commands: RETR STOR STOU APPE LIST NLST.

Default value: None

file_put_cmds

Specifies a list of PUT commands. Check for correct formatting of the commands. Separate multiple commands with a space character.

Type: string

Valid values: A list of one or more of the following commands: STOR STOU APPE.

Default value: None

Caution

Do not change the file_put_cmds parameter unless directed to do so by Support.

file_get_cmds

Specifies a list of GET commands. Check for correct formatting of the commands. Separate multiple commands with a space character.

Type: string

Valid values: A list of GET command, such as RETR.

Default value: None

Caution

Do not change the file_get_cmds parameter unless directed to do so by Support.

encr_cmds

Specifies a list of commands related to secure connections. Check for correct formatting of the commands. Separate multiple commands with a space character.

Type: string

Valid values: A list of commands related to secure connections, for example: AUTH.

Default value: None

login_cmds

Specifies a list of commands related to the login process. Check for correct formatting of the commands. Separate multiple commands with a space character.

Type: string

Valid values: Specify a list of one or more commands: USER, PASS.

Default value: None

check_encrypted

Specifies whether to check an encrypted session for a command to end encryption. Use with the encrypted_traffic parameter.

You can enable rule 125:7 to generate events and, in an inline deployment, drop offending packets for this parameter.

Type: boolean

Valid values: true, false

Default value: false

cmd_validity[]

An array of FTP commands and the criteria the inspector uses to validate them. These validity checks override the default checks performed by the ftp_server inspector (RFC 959).

You can enable rules 125:2 and 125:4 to generate events, and, in an line deployment, drop offending packets for this parameter.

Type: array (object)

{
   "cmd_validity": [
       {
           "command": "CWD",
           "format": "abc",
           "length": 250
       }
   ]
}

cmd_validity[].command

Specifies the name of an FTP command to validate.

Type: string

Valid values: A valid FTP command enclosed in double quotation marks.

Default value: None

cmd_validity[].format

Describes the valid format for cmd_validity[].command

Type: string

Valid values: "fmt" where fmt uses the following conventions:

• int – The parameter must be an integer

• number – The parameter much be an integer between 1 and 255

• char chars – The parameter must be a single character from chars, a list of one or more characters with no separators between them.

• date datefmt – The parameter follows the format specified, where datefmt is constructed using the following elements:

  • # = Number

  • C = Char

  • [] = Optional format enclosed

  • | = OR

  • {} = Choice of formats enclosed

  • .+- literal characters

• string – The parameter is an unlimited string.

• host_port – The parameter must be a host port specifier, per RFC 959.

• long_host_port – The parameter must be a long host port specifier per RFC 1639.

• extended_host_port – The parameter must be an extended host port specifier per RFC 2428.

• {},| – The parameter must be one of the choices enclosed within the braces, separated by |.

• {}, [] – The parameter must be one of the choices enclosed within the braces. Optional values are enclosed within the brackets.

Default value: None

cmd_validity[].length

Specifies the maximum length in bytes for the cmd_validity[].command parameter, overriding the default value defined in def_max_param_len. If the parameter for the FTP command exceeds the cmd_validity[].length, and rule 125:3 is enabled, Snort generates an alert. Use cmd_validity[].length to restrict specific commands to small parameter values.

Specify 0 to indicate unlimited length.

Type: integer

Valid range: 0 - 4,294,967,295 (max32)

Default value: 0

def_max_param_len

Specifies the default maximum length in bytes that the inspector permits for all FTP commands handled by the server. Use def_max_param_len for basic buffer overflow detection. (This can be overridden for individual commands using cmd_validity[].length.) You can enable rule 125:3 to generate events and, in an inline deployment, drop offending packets for this parameter.

Specify 0 to indicate unlimited length.

Type: integer

Valid range: 0 - 4,294,967,295 (max32)

Default value: 100

encrypted_traffic

Specifies whether to check for encrypted FTP traffic. Use with the check_encrypted parameter. You can enable rule 125:7 to generate events and, in an inline deployment, drop offending packets for this parameter.

Type: boolean

Valid values: true, false

Default value: false

ftp_cmds

A list of FTP commands the server supports beyond those described in RFC 959. (If your installation uses the "X" commands specified in RFC 775, for instance, you can add them to the inspector using this parameter.)

Type: string

Valid values: Space-separated list of valid FTP commands, enclosed in double quotation marks.

Default value: None

ignore_data_chan

Specifies whether to ignore the FTP data channels.

Type: boolean

Valid values: true, false

Default value: false

ignore_telnet_erase_cmds

Specifies whether to ignore the telnet escape sequences for the erase character (TNC EAC) and the erase line character (TNC EAL) when normalizing the FTP command channel. Set ignore_telnet_erase_cmds to match how your FTP server handles telnet erase commands. Newer FTP clients typically ignore these telnet escape sequences, while legacy clients typically process them.

If telnet erase commands are not ignored, and rule 125:1 is enabled, Snort generates an event, and, in an inline deployment, drops offending packets.

Type: boolean

Valid values: true, false

Default value: false

print_cmds

Specifies whether to print the configuration for each FTP command for this server on initialization.

Type: boolean

Valid values: true, false

Default value: false

telnet_cmds

Specifies whether to check for telnet commands on the FTP command channel. The presence of such commands could indicate an evasion attempt on the FTP command channel.

Type: boolean

Valid values: true, false

Default value: false

Enable the ftp_server inspector rules to generate events and, in an inline deployment, drop offending packets.

The ftp_server inspector does not have any intrusion rule options.

GTP Inspect service configuration

The binder inspector defines the GTP Inspect service configuration. For more information, see the Binder Inspector.

[
   {
       "when": {
           "service": "gtp_inspect",
           "role": any
       },
       "use": {
           "type": "gtp_inspect"
       }
   },
   {
       "when": {
           "proto": "tcp",
           "role": "server",
           "ports": "2123 2152 3386"
       },
       "use": {
           "type": "gtp_inspect"
       }
   }
]

version

Specifies a legal GTP version.

Type: integer

Valid values: 0, 1, 2

Default value: 2

messages[]

Specifies an array of information about valid GTP messages.

Type: array (object)

{
    messages: [
        {
            "type": 0,
            "name": ""
        }
    ]
}

messages[].type

Specifies a valid GTP message type. See Table 1.

Type: integer

Valid range: 0 - 255

Default value: None

messages[].name

Specifies a valid GTP message name. See Table 1.

Type: string

Valid values: A valid GTP message name

Default value: None

infos[]

Specifies an array of GTP information elements.

Type: array (object)

{
    infos: [
        {
            "type": 0,
            "name": "echo_request",
            "length": 0
        }
    ]
}

infos[].type

Specifies a valid GTP element type code. See Table 2.

Type: integer

Valid range: 0 - 255

Default value: 0

infos[].name

Specifies a valid GTP element name.

Type: string

Valid values: Valid GTP information element names enclosed in double quotation marks. See Table 2.

infos[].length

Specifies the length of a valid GTP information element.

Type: integer

Valid range: 0 - 255

Default value: 0

Enable the gtp_inspect inspector rules to generate events and, in an inline deployment, drop offending packets.

The gtp_inspect inspector intrusion rule options allow you to inspect the GTP command channel for the GTP version, message type, and information elements.

You cannot use GTP options in combination with content or byte_jump. You must use gtp_version in each rule that uses gtp_info or gtp_type.

gtp_version

Check the specified GTP version against the version of the GTP control messages.

Type: integer

Syntax: gtp_info: <version>;

Valid values: 0, 1, 2

Examples: gtp_version: 1;

gtp_type

Each GTP message is identified by a message type, which is comprised of both a numeric value and a string. Check the specified GTP types against the type of the GTP messages.

You can specify a defined decimal value for a message type, a defined string, or a comma-separated list of either or both in any combination, as seen in the following example:

Type: string

Syntax: gtp_type: <message_type>;

Valid values: Listed in the GTP Message Types table.

Examples: gtp_type: "10, 11, echo_request";

The system uses an OR operation to match each value or string that you list. The order in which you list values and strings does not matter. Any single value or string in the list matches the keyword. The system generates an error if you attempt to save a rule that includes an unrecognized string or an out-of-range value.

Note that different GTP versions sometimes use different values for the same message type. For example, the sgsn_context_request message type has a value of 50 in GTPv0 and GTPv1, but a value of 130 in GTPv2.

The gtp_type option matches different values depending on the version number in the packet. For instance the sgsn_context_request message matches the value 50 in a GTPv0 or GTPv1 packet and the value 130 in a GTPv2 packet. The option does not match a packet when the message type value in the packet is not a known value for the version specified in the packet.

If you specify an integer for the message type, the option matches if the message type matches the value in the GTP packet, regardless of the version specified in the packet.

gtp_message_type is a numeric value or keyword from the GTP Message Types table.

The following table lists the defined values and strings for each GTP message type.

gtp_info

A GTP message can include multiple information elements, each of which is identified by both a defined numeric value and a defined string. You can use the gtp_info option to start inspection at the beginning of a specified information element, and restrict inspection to that information element.

You can specify either the defined decimal value or the defined string for an information element. You can specify a single value or string, and you can use multiple gtp_info options in a rule to inspect multiple information elements.

When a message includes multiple information elements of the same type, all are inspected for a match. When information elements occur in an invalid order, only the last instance is inspected.

Depending on the version, a GTP message can use different values for the same information element. For example, the cause information element has a value of 1 in GTPv0 and GTPv1, but a value of 2 in GTPv2.

The gtp_info option matches different values depending on the version number in the packet. In the example above, the keyword matches the information element value 1 in a GTPv0 or GTPv1 packet and the value 2 in a GTPv2 packet. The option does not match a packet when the information element value in the packet is not a known value for the version specified in the packet.

If you specify an integer for the information element, the option matches if the message type matches the value in the GTP packet, regardless of the version specified in the packet.

Type: string

Syntax: gtp_info: <identifier>;

Valid values: Listed in the GTP Information Elements table.

Examples: gtp_info: "qos";

The following table lists the information element identifiers for each GTP version.

Consider the following best practices when configuring the http_inspect inspector:

• Set the request_depth and response_depth parameters if your HTTP traffic includes large video files.

• Use the default settings for the HTTP URI inspection parameters:

  "utf8": "true"

  "plus_to_space": "true"

  "percent_u": "true"

  "utf8_bare_byte": "true"

  "iis_unicode": "true"

  "iis_double_decode": "true"

HTTP service configuration

The binder inspector defines the HTTP service configuration. For more information, see the Binder Inspector.

[
    {
        "when": {
             "service": "http",
             "role": any
        },
        "use": {
            "type": "http_inspect"
        }            
    }
]

request_depth

Specifies the number of bytes to read from the HTTP message request body.

Specify -1 to place no limit on the number of bytes to inspect. We recommend that you specify the request_depth and response_depth parameters to limit the amount of HTTP body data to analyze.

To inspect only the HTTP headers, set request_depth to 0.

Type: integer

Valid range: -1 - 9,007,199,254,740,992 (max53)

Default Value: -1

response_depth

Specifies the number of bytes to read from the HTTP message response body.

Specify -1 to place no limit on the number of bytes to inspect. We recommend that you specify the request_depth and response_depth parameters to limit the amount of HTTP body data to analyze.

To inspect only the HTTP headers, set response_depth to 0.

Type: integer

Valid range: -1 - 9,007,199,254,740,992 (max53)

Default Value: -1

unzip

Specifies whether to decompress gzip files and deflate message bodies before inspecting them. When you turn off decompression, the HTTP inspector is unable to process all parts of the HTTP message body. The http_inspect inspector can process the HTTP headers.

Type: boolean

Valid values: true, false

Default value: true

maximum_host_length

Specifies the maximum number of bytes allowed in the Host HTTP header value.

Specify -1 to place no limit on the header value length.

Type: integer

Valid range: -1 - 9,007,199,254,740,992 (max53)

Default value: -1

maximum_chunk_length

Specifies the maximum number of bytes allowed in an HTTP message body chunk.

Specify -1 to place no limit on the number of bytes in an HTTP chunk.

Type: integer

Valid range: -1 - 9,007,199,254,740,992 (max53)

Default value: -1

normalize_utf

Specifies whether to normalize UTF encodings (UTF-8, UTF-7, UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE) found in the HTTP response body. The http_inspect inspector determines the UTF character encoding from the HTTP Content-Type header.

Type: boolean

Valid values: true, false

Default value: true

decompress_pdf

Specifies whether to decompress the deflate-compatible compressed portions of the application/pdf (PDF) files found in the HTTP response body. The http_inspect inspector decompresses PDF files with the /FlateDecode stream filter.

Type: boolean

Valid values: true, false

Default value: false

decompress_swf

Specifies whether to decompress application/vnd.adobe.flash-movie (SWF) files found in the HTTP response body.

Note	You can only decompress the compressed portions of files found in the HTTP GET responses.

Type: boolean

Valid values: true, false

Default value: false

decompress_vba

Specifies whether to decompress Microsoft Office Visual Basic for Applications macro files found in the HTTP response body.

Type: boolean

Valid values: true, false

Default value: false

decompress_zip

Specifies whether to decompress application/zip (ZIP) files found in the HTTP response body.

Type: boolean

Valid values: true, false

Default value: false

script_detection

Specifies whether to inspect the JavaScript content after detecting the script end element (<\script>). When http_inspect detects the end of a script, it immediately forwards the partially read message body for early detection. Script detection enables Snort to quickly block response messages that may contain malicious JavaScript.

Type: boolean

Valid values: true, false

Default value: false

normalize_javascript

Specifies whether to use the legacy mechanism to normalize JavaScript in the HTTP response body. The http_inspect inspector normalizes obfuscated JavaScript data including the unescape and decodeURI functions, and the String.fromCharCode method. The HTTP inspector normalizes encodings within the unescape, decodeURI, and decodeURIComponent functions: %XX, %uXXXX, XX, and uXXXXi.

The http_inspect inspector detects consecutive white spaces and normalizes them into a single space. When normalize_javascript is enabled, you can set max_javascript_whitespaces to limit the number of consecutive white spaces in the obfuscated JavaScript.

Type: boolean

Valid values: true, false

Default value: false

js_norm_bytes_depth

Specifies the number of input JavaScript bytes to normalize.

Specify -1 to place no limit on the number of JavaScript bytes.

Type: integer

Valid range: -1 - 9,007,199,254,740,992 (max53)

Default value: -1

js_norm_identifier_depth

Specifies the maximum number of unique JavaScript identifiers to normalize.

Type: integer

Valid range: 0 - 65535

Default value: 65535

js_norm_max_bracket_depth

Specifies the maximum depth of JavaScript bracket nesting to normalize.

Type: integer

Valid range: 1 - 65535

Default value: 256

js_norm_max_scope_depth

Specifies the maximum depth of JavaScript scope nesting to normalize.

Type: integer

Valid range: 1 - 65535

Default value: 256

js_norm_max_tmpl_nest

Specifies the maximum depth of JavaScript template literal nesting to normalize.

Type: integer

Valid range: 0 - 255

Default value: 32

max_javascript_whitespaces

Specifies the maximum consecutive whitespaces allowed within the JavaScript obfuscated data.

Type: integer

Valid range: 1 - 65535

Default value: 200

percent_u

Specifies whether to normalize the %uNNNN and %UNNNN encodings. The four N characters represent a hex-encoded value that correlates to a Microsoft internet information services (IIS) Unicode code point. As legitimate clients rarely use %u encodings, we recommend that you normalize the HTTP traffic encoded with %u encodings.

Type: boolean

Valid values: true, false

Default value: false

utf8

Specifies whether to normalize the standard UTF-8 Unicode sequences in the URI. The http_inspect inspector can normalize two or three byte UTF-8 characters into a single byte.

Type: boolean

Valid values: true, false

Default value: true

utf8_bare_byte

Specifies whether to normalize UTF-8 characters which include bytes that are not URL or percent encoded. We recommend that you enable the utf8_bare_byte parameter.

Type: boolean

Valid values: true, false

Default value: false

iis_unicode

Specifies whether to normalize the characters in the HTTP message with the Unicode code point.

Note	We recommend that you enable the iis_unicode parameter. Unicode is commonly seen in attacks and evasion attempts.

Type: boolean

Valid values: true, false

Default value: false

iis_unicode_code_page

Specifies whether to use the code page from the IIS Unicode map file.

Type: integer

Valid range: 1 - 65535

Default value: 1252

iis_double_decode

Specifies whether to normalize characters by performing double decoding of URL encoded characters. Decodes IIS double encoded traffic by making two passes through the request URI. We recommend that you enable the iis_double_decode parameter. Double encoding is typically found only in attack scenarios.

Type: boolean

Valid values: true, false

Default value: true

oversize_dir_length

Specifies the maximum number of bytes allowed for the URL directory.

Type: integer

Valid range: 1 - 65535

Default value: 300

backslash_to_slash

Specifies whether to replace the backslash (\) with forward slash (/) in the URIs.

Type: boolean

Valid values: true, false

Default value: true

plus_to_space

Specifies whether to replace the plus sign (+) with <sp> in the URIs.

Type: boolean

Valid values: true, false

Default value: true

simplify_path

Specifies whether to reduce the URI directory path to the simplest form. A URI directory path that includes extra traversals may include: ., .., and /.

Type: boolean

Valid values: true, false

Default value: true

xff_headers

Specifies the types of X-Forwarded-For HTTP header to examine. In the xff_headers parameter, list the X-Forwarded-For headers from highest to lowest preference.

You can define custom X-Forwarded-For type headers. The HTTP header, which carries the original client IP address, can have a vendor-specific header name. In this scenario, the xff_headers parameter provides a way to introduce custom headers to the HTTP inspector.

The xff_headers default value is x-forwarded-for true-client-ip, two commonly known headers. If both default headers are present in the stream, x-forwarded-for is preferred over true-client-ip. When specifying multiple X-Forwarded-For HTTP headers, delimit the header names with a space.

Type: string

Valid values: "x-forwarded-for", "true-client-ip"

Default value: "x-forwarded-for true-client-ip"

Enable the http_inspect inspector rules to generate events and, in an inline deployment, drop offending packets.