context

Copy Link

Copy Doc ID f21167b4-200c-11e9-b6f6-f8bc1258b856:846037

Download PDF

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.

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.

Custom IPS and Application Control Signature Syntax Guide

context

context

Syntax:

Examples:

Notes

context

Syntax:

Examples:

Notes