Filtering Rules

Content Gateway supports the ability to create rules that inspect requests for certain parameters and, when matched, apply a specified action. Rules can be created to:

Deny or allow URL requests

Insert custom headers

Allow specified applications, or requests to specified websites to bypass user authentication

Keep or strip header information from client requests

Prevent specified applications from transiting the proxy


	Note To create rules for IWA, NTLM, and LDAP user authentication, see Rule-Based Authentication. To get started with Content Gateway user authentication options, see Content Gateway user authentication.

Filtering rules are created and modified on the Configure > Security > Access Control > Filtering tab. Rules are stored in the filter.config file.

Rules are applied in the order listed, top to bottom. Only the first match is applied. If no rule matches, the request proceeds.

Secondary specifiers are optional. More than one secondary specifier can be used in a rule. However, you cannot repeat a secondary specifier.

Three filtering rules are configured by default. The first denies traffic on port 25 to all destinations. The second and third bypass user authentication for connections to 2 Websense file sandbox destinations.

After adding, deleting, or modifying a rule, restart Content Gateway.

See filter.config for information about the structure of stored rules.

Creating filtering rules

Go to the Configure > Security > Access Control > Filtering tab and click Edit File to open filter.config in the file editor.

Select a Rule Type from the drop down list. The Rule Type specifies the action the rule will apply. The supported options are:

allow — allows particular URL requests to bypass authentication; the proxy caches and serves the requested content.

deny — denies requests for objects from specific destinations. When a request is denied, the client receives an access denied message.

keep_hdr — specifies which client request header information to keep.

strip_hdr — specifies which client request header information to strip.

add_hdr — causes a custom header-value pair to be inserted. Requires that Custom Header and Header Value are specified. Provides support for destination hosts that require a specific header-value pair. For an example, see Creating an add_hdr rule to allow Google enterprise gmail, below.


	Note The "radius" rule type is not supported.

Select a Primary Destination Type and then enter a corresponding value in the Primary Destination Value field. Primary Destination Types include:

dest_domain — a requested domain name. The value is a domain name.

dest_host — a requested hostname. The value is a hostname.

dest_ip — a requested IP address. The value is an IP address.

url_regex — a regular expression to be found in a URL. The value is a regular expression.

If the Primary Destination Type is keep_hdr or strip_hdr, select the type of information to keep or strip from the Header Type drop down list. Options include:

date

host

client_ip

If the rule applies to only inbound traffic on a specific port, enter a value for Proxy Port.

If the rule type is add_hdr, specify the Custom Header and Header Value. The Custom Header and Header Value must be values that the destination host expects. See the example for Google Business Gmail below.

Provide values for any required or desired Secondary Specifiers. They include:

Time — Specifies a time range, such as 08:00-14:00.

Prefix — Specifies a prefix in the path part of a URL.

Suffix — Specifies a file suffix in the URL.

Source IP address — Specifies a single client IP address, or an IP address range of clients.

Port — Specifies the port in a requested URL.

Method — Specifies a request URL method:

Scheme — Specifies the protocol of a requested URL. Options are:

HTTP

HTTPS

FTP (for FTP over HTTP only)

User-Agent — Specifies a request header User-Agent value. This is a regular expression (regex).

You can use the User-Agent field to create application filtering rules that:

Allow applications that don't properly handle authentication challenges to bypass authentication

Block particular client-based applications from accessing the Internet

See the Websense knowledge base article titled "When authentication prevents devices, browsers, and custom applications from working with the proxy" for more information and several examples.

When you have finished defining the rule, click Add to add the rule and then Apply to save the rule.

When you are done adding rules, click Apply to save all the changes and then click Close to close the edit window.

Editing a rule

Go to Configure > Security > Access Control > Filtering and click Edit File to open filter.config in the file editor.

In the list, select the rule to be modified and change the values as desired.

Click Set to update the rule and click Apply to save the rule.

Click Close to close the edit window.

Creating an add_hdr rule to allow Google enterprise gmail

Google provides a mechanism in the form of a custom header in the request, that allows Google to recognize and allow or block access to enterprise gmail and other Google Apps for Business.

To make Google's solution work for enterprise gmail:

In the Web module of the TRITON Manager allow the category Internet Communication > General Email.

In the Content Gateway manager enable HTTPS (SSL decryption). If your site does not already use SSL support, acquaint yourself with the feature before enabling it.

In the Content Gateway manager, on the Configure > Security > Access Control page, open filter.config and create an add_hdr rule.


	Note The add_hdr rule type can be used with any site that uses a custom header-value pair to accomplish special handling.

Select add_hdr.

For Primary Destination Type select dest_domain.

For Primary Destination Value specify "mail.google.com".

In the Custom Header field, specify "X-GoogApps-Allowed-Domains".

In the Header Value field, specify your domain, or a list of domains separated by commas. For example: www.example1.com,www.example2.com

Optionally, in the Source IP field specify the source IP address or range of source IP addresses to which this rule will be applied. For example: 10.10.20.30 or 10.10.1.1-10.30.40.50

Click Add to add the rule.

Click Apply to save all the changes, and then click Close to close the edit window.

When a user attempts to access Google services from an unauthorized account, Google displays a block page similar to this:

For Google's description of the filtering solution, see the article Block access to consumer accounts and services while allowing access to Google Apps for your organization.