Add an HTTP Inspection Filter

There are two ways to add HTTP Inspection filters:

Basic view—Common component of a filter are provided, offering options for the filtering type (HTTP request or response), URL host, URL path, URL query, and request or response header.
Advanced view—Allows you to enter patterns
Note: New filters can also be added by clicking on the name of an existing filter, then modifying it as needed and saving it under a different name.

Adding a Filter in the Basic View

The filter configured in the Basic View defines the following:

Filter name and description—Name and description assigned to the new filter by the user.
HTTP request or response—Denotes the traffic direction
Filter scope—Includes the HTTP method (HTTP request only), scope, path, query, and/or header
Keyword matching—For HOST, PATH, QUERY and METHOD options, matching means the value contains the input keywords (using simple string comparison). For the HEADER option, matching supports both string value matching and integer value comparison.
Note: Determine your filter parameters by running a packet capture on the HTTP request or response.

To add a new HTTP Inspection filter in the basic view:

Go to HTTP > HTTP Inspection > Filters.
Click Add.
Enter a filter name and description.
Select the Basic view radio button.
Select the filtering type, either HTTP Request or HTTP Response Method, depending on the direction for which you want to create a filter.
HTTP Request—Creates a filter used when clients send a request to the Web server to retrieve an HTML page. Request filters include the following scope: request method, URL host, URL path, URL query, and HTTP header.
HTTP Response—Creates a filter used when the Web server returns a response message to the client. Response filters include the following scope: URL host*, URL path*, URL query*, and HTTP response header.

Note: Information for the items above with an asterisk (*) are obtained from the HTTP request. The response does not contain this information.

Enter values to define the filter by configuring one or more of the following options:
(HTTP Request Filtering type only) Check the Request Method check box. To limit the scope of the filter, provide the HTTP request method. The value can be those shown below or any other extension method value.

Method	Description
DELETE	Deletes the specified resource.
GET	Requests the specified resource.
HEAD	Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.
OPTIONS	Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.
POST	Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.
PUT	Uploads a representation of the specified resource.
TRACE	Echoes back the received request, so that a client can see what (if any) changes or additions have been made by intermediate servers.

Note: Users can define multiple keywords with an OR relation, separated by the ‘|’ character or on a new line for the URL Query, URL Path, Header, or HTTP Method options.
Check the URL Host check box. Type the host name or IPv4/IPv6 address (including port number, if any) as part of the URL.
Check the URL Path check box. Type the path part of the URL (if any) after, but not including, the final "/" of the host part, and up to, but not including, the "?" of the query, if any.
Check the URL Query check box. Type the query part of the URL (if any), after, but not including, the "?" and up to the end of the URL string in the field below the translation wizard.

If you need to translate a UTF-8 string, check the Need a translator check box.
Note: Keyword queries only are only supported in UTF-8 encoding. Use URL-encoded hex code to match multiple-byte characters with other character sets.
Type the UTF-8 string to translate.
Select the appropriate Character set:

Chinese Simplified (GB2312)
Chinese Traditional (Big5)
Japanese (EUC)
Japanese (Shift-JIS)

Click Translate and the translated value appears in the Translated string field.

Check the Header check box. To enter the Name and Value of the header being used, click the "+" sign in the last column. This supports both string-value matching and integer-value comparison:

Contains|Not Contain—Means the value contains or does not contain the input keywords using a simple string comparison
Add multiple keywords with an OR relation, separated by the "|" character.
=, ≠, ≤, ≥—Means integer-value comparison
Exist/Not exist—Means the header includes or does not include the defined header
The web traffic is matched by one filter only if all the defined scopes are matched, which means there is an AND relation in METHOD, HOST, PATH, QUERY, and multiple HEADERs.
Type the values to be used and select the appropriate operation (Contains, Not Contain, equals, does not equal, greater than or equal to, or less than or equal to) from the drop-down list.

Click Save.

Your new filter name now appears in the list of filters at the HTTP > HTTP Inspection > Filters.

Adding a Filter in the Advanced View

You can edit filter definitions in text mode with defined syntax. (HTTP BODY is not supported.) Regular expressions are supported in the defined syntax. All regular expressions are applied (refer http://www.pcre.org/pcre.txt) with only the following PCRE flags active:

Regular expression	Description
PCRE_DOTALL	The ‘.’ (period) character matches any byte, including the EOL characters CR (‘\r’) and LF (‘\n’).
PCRE_DOLLAR_ENDONLY	The ‘$’ (dollar sign) character matches only the absolute “end of source” (the end of the data), and does not match EOL.
PCRE_EXTENDED	The main effect of this is that the following characters (as literals) are ignored in regular expression definitions: ‘ ’ (space), tab, carriage return, line feed, form feed, ‘#’ However, the escaped forms of these characters are obeyed: ‘\ ’, ‘\t’, ‘\r’, ‘\n’, ‘\f’, ‘\#’. This allows regular expression definitions to be formatted in a more readable manner (with white space emphasizing structure and branches), and it allows them to be easily split across line boundaries.

Note: PCRE_DOTALL and PCRE_EXTENDED may be turned off by including ‘(?-s)’ and ‘(?-x)’, respectively, in an expression.

Other rules include:
-The PCRE runtime flag PCRE_UTF8 (“UTF-8 mode”) is never used. This means that the ‘.’ character will always match only one byte.
- In signature definitions, EOL may be escaped by using ‘\’ (backslash) at the end of the line (in the Unix shell manner). Note that this is not part of the PCRE regular expression language and, to be safe, the line continuation backslash should be preceded by at least one space. When assembling a multi-line regular expression for use, the line-end backslashes are stripped, and then all leading and trailing white space is stripped from each line before the lines are concatenated.

To add a new HTTP Inspection filter in the advanced view:

Go to HTTP > HTTP Inspection > Filters.
Click Add.
Enter a filter name and description.
Select the Advanced view radio button.
Enter a pattern in the Patterns field using the following syntax:
Note: The [Filter Type] must be replaced with REQ (for request mode) or RESP (for response mode.)

[ScanSetName] [Filter Type] {

[TAG]:RegularEx

[HDR-TAG]:[HDR-NAME]:[HDR-OP]:RegularEx

[TAG]

METHOD, HOST, PATH, QUERY

[HDR-TAG]

REQ-HDR, RESP-HDR}

[HEADER_OP]:

-----------------------------------

EQ : =

NE : !=

GE : >=

LE : <=

M : Contain

NM : Not Contain

X : Exist

NX : Not exist

Sample pattern for Request mode:

# _SCAN_SET_1_ REQ {

# METHOD: POST

# HOST: ^www\.samplesite\.com:2345(?!\d)

# PATH: test

# QUERY: test

# REQ-HDR:Content-Type:M:multipart/form-data

# REQ-HDR:Content-Length:GE:1048576

# }

Sample pattern for Response mode

# _SCAN_SET_2_ RESP {