context

context

Use the context keyword to specify which protocol field the engine should search for a pattern in. If it is not present, the IPS engine searches for the pattern in the whole packet.

Syntax:

--<context <field>;

<field>	Description
`PACKET`	Searches for the pattern in the whole packet This is the default setting.
`PACKET_ORIGIN`	Searches the original packet without protocol decoding
`URI`	This is only used to match content in the URI field of an HTTP request. Since there are various encoding standards that can be used in a URI, a character can be expressed in several ways. For example, %2f, %u002f, and %c0%af all represent "/". In order to cope with evasion attempts based on this, the content to be searched for in a URI must be decoded. The HTTP dissector decodes and normalizes the original URI field, placing the results in three buffers. The following three URI buffers search for the specified pattern. Original URI: /scripts/. .%c0%af../winnt/system32/cmd.exe?/c+ver Decoded URI: /scripts/. ./../winnt/system32/cmd.exe?/c+ver ("\" is also converted to "/" in this phase.) Extracted Directory Traversal URI: winnt/system32/cmd.exe?/c+ver
`HEADER`	The search range is the entire header of scanned HTTP, IMAP, SMTP, POP3 or SSH traffic.
`BODY`	The search range is the entire body of scanned HTTP, IMAP, SMTP, or POP3 traffic. The decoder has no separate buffer for the body section of above-mentioned traffic. Because of this, body data in different packets is not reassembled. The decoder just locates the beginning and end of the body in a packet payload and tries to match inside of it. If a signature has two patterns in a body section that are to be matched, but the patterns span across two separate packets, the second pattern will not be matched.
`BANNER`	The search range is the entire banner of scanned HTTP, IMAP, SMTP, POP3 or SSH traffic.
`HOST`	For an HTTP session, the search range is the "`Host:`" field of an HTTP header. For an HTTPS session, the search ranges is the server name field of Server Name Indication (SNI) in the client Hello packet and the Common Name (CN) field in the server certificate packet.
`FILE`	The search range for the file context can be one of: decoded attachments for email protocols. data sessions for FTP. the body for HTTP.

Examples:

--context URI;

--context PACKET_ORIGIN;

Notes

The IPS engine supports "packet-based" inspection, which means it inspects packets even if there are no sessions associated with them Many keywords, for example those for matching TCP/IP header fields, are enabled in packet-based inspection. If a pattern has the context value PACKET, PACKET_ORIGIN, or no context, it will be inspected using packet-based inspection.
The BANNER and BODY are in the packet buffer.
There is no body context in FTP, so file context should be used instead.
For HTTP, the body context and the file context are the same. You can use either --context file or --context body to indicate where to match the pattern.
MIME parsing is supported for the email protocols SMTP, IMAP, POP3, and NNTP. We decode most of the encoding methods, including base64, uuencode, 7/8bit. quota, binary, and quoted-printable.
If the file itself is zipped or archived, the engine currently does NOT decompress it.
The content, uri, header, and body keywords are deprecated. They are still supported in IPS Engine 3.0 (and above) in order to maintain backward compatibility, but don't use them when creating new signatures.
The U, H, and B modifiers have been removed from PCRE. Use context to specify these conditions for PCRE matching:

PCRE

Description

Context

U

Match the decoded URI buffers

uri

H

Match normalized HTTP header

header

B

Don't use the decoded buffers

packet_origin
MIME parsing is supported for the email protocols SMTP, IMAP, POP3 and NNTP. Currently, all attachments fall under --context file. Most of the encoding methods are decoded, including base64, uuencode, 7/8bit, quota, binary, and quoted-printable.
For email protocols, some signatures used to use --context body for base64 encoded strings in attachments. They will not work anymore, because base64 is now decoded and the strings are located in the file context.
For email protocols, use --context body to inspect content located in the body and is not an attachment.
There is no body context in FTP, so the file context should be used. For example, a signature like this should be able to match the eicar file in all of these protocols as it does not specify a service context and it uses file context:
```
F-SBID( --protocol tcp; --pattern "X5O!P"; --context FILE; )
```
If the file is zipped or archived, the engine currently does NOT decompress it.

PCRE	Description	Context
U	Match the decoded URI buffers	uri
H	Match normalized HTTP header	header
B	Don't use the decoded buffers	packet_origin

context

Use the context keyword to specify which protocol field the engine should search for a pattern in. If it is not present, the IPS engine searches for the pattern in the whole packet.

Syntax:

--<context <field>;

<field>	Description
`PACKET`	Searches for the pattern in the whole packet This is the default setting.
`PACKET_ORIGIN`	Searches the original packet without protocol decoding
`URI`	This is only used to match content in the URI field of an HTTP request. Since there are various encoding standards that can be used in a URI, a character can be expressed in several ways. For example, %2f, %u002f, and %c0%af all represent "/". In order to cope with evasion attempts based on this, the content to be searched for in a URI must be decoded. The HTTP dissector decodes and normalizes the original URI field, placing the results in three buffers. The following three URI buffers search for the specified pattern. Original URI: /scripts/. .%c0%af../winnt/system32/cmd.exe?/c+ver Decoded URI: /scripts/. ./../winnt/system32/cmd.exe?/c+ver ("\" is also converted to "/" in this phase.) Extracted Directory Traversal URI: winnt/system32/cmd.exe?/c+ver
`HEADER`	The search range is the entire header of scanned HTTP, IMAP, SMTP, POP3 or SSH traffic.
`BODY`	The search range is the entire body of scanned HTTP, IMAP, SMTP, or POP3 traffic. The decoder has no separate buffer for the body section of above-mentioned traffic. Because of this, body data in different packets is not reassembled. The decoder just locates the beginning and end of the body in a packet payload and tries to match inside of it. If a signature has two patterns in a body section that are to be matched, but the patterns span across two separate packets, the second pattern will not be matched.
`BANNER`	The search range is the entire banner of scanned HTTP, IMAP, SMTP, POP3 or SSH traffic.
`HOST`	For an HTTP session, the search range is the "`Host:`" field of an HTTP header. For an HTTPS session, the search ranges is the server name field of Server Name Indication (SNI) in the client Hello packet and the Common Name (CN) field in the server certificate packet.
`FILE`	The search range for the file context can be one of: decoded attachments for email protocols. data sessions for FTP. the body for HTTP.

Examples:

--context URI;

--context PACKET_ORIGIN;

Notes

The IPS engine supports "packet-based" inspection, which means it inspects packets even if there are no sessions associated with them Many keywords, for example those for matching TCP/IP header fields, are enabled in packet-based inspection. If a pattern has the context value PACKET, PACKET_ORIGIN, or no context, it will be inspected using packet-based inspection.
The BANNER and BODY are in the packet buffer.
There is no body context in FTP, so file context should be used instead.
For HTTP, the body context and the file context are the same. You can use either --context file or --context body to indicate where to match the pattern.
MIME parsing is supported for the email protocols SMTP, IMAP, POP3, and NNTP. We decode most of the encoding methods, including base64, uuencode, 7/8bit. quota, binary, and quoted-printable.
If the file itself is zipped or archived, the engine currently does NOT decompress it.
The content, uri, header, and body keywords are deprecated. They are still supported in IPS Engine 3.0 (and above) in order to maintain backward compatibility, but don't use them when creating new signatures.
The U, H, and B modifiers have been removed from PCRE. Use context to specify these conditions for PCRE matching:

PCRE

Description

Context

U

Match the decoded URI buffers

uri

H

Match normalized HTTP header

header

B

Don't use the decoded buffers

packet_origin
MIME parsing is supported for the email protocols SMTP, IMAP, POP3 and NNTP. Currently, all attachments fall under --context file. Most of the encoding methods are decoded, including base64, uuencode, 7/8bit, quota, binary, and quoted-printable.
For email protocols, some signatures used to use --context body for base64 encoded strings in attachments. They will not work anymore, because base64 is now decoded and the strings are located in the file context.
For email protocols, use --context body to inspect content located in the body and is not an attachment.
There is no body context in FTP, so the file context should be used. For example, a signature like this should be able to match the eicar file in all of these protocols as it does not specify a service context and it uses file context:
```
F-SBID( --protocol tcp; --pattern "X5O!P"; --context FILE; )
```
If the file is zipped or archived, the engine currently does NOT decompress it.

Secure Networking

Hybrid Mesh Firewall

NOC Management

LAN

WAN

Unified SASE

Single Vendor SASE

Cloud Network Security

Secure Endpoint Connectivity

Web Application / API Protection

Security Operations

Security Operations Automation

Identity

Early Detection & Prevention

Secure Networking

Hybrid Mesh Firewall

NOC Management

LAN

WAN

Communication & Surveillance

Unified SASE

Single Vendor SASE

Secure Endpoint Connectivity

Cloud Network Security

Cloud-Native Security

Web Application / API Protection

Security Operations

Security Operations Automation

Endpoint

Data Protection

Identity

Email

Early Detection & Prevention

Expert Services

Edge Firewall

Orchestration & management

SD Branch

Application Delivery

Single Vendor SASE

Secure Endpoint Connectivity

Secure Private Access

Thin Edge

Identity

Application Gateway

Enterprise Asset Management

Endpoint Agent

Agentless Security Posture

Identity

Wireless

Switching

Identity

Privilege Acccess Management

Next Generation Firewall

Orchestration & management

Expert Services

All

All

Account Management

SAAS Management

SAAS Application Security

Managed Services

Platform as a service (PAAS)

Other SAAS Services

4D Pillars

Cloud

Popular Solutions

Custom IPS and Application Control Signature Syntax Guide

context

Syntax:

Examples:

Notes

context

context

Syntax:

Examples:

Notes