Best Practices for Configuring a Web Policy

Using rules and rule sets in appropriate cycles

Rule processing on Web Gateway is performed in different cycles. Perform filtering activities in the cycles that are best suited for them.

The following cycles are available:

• Request cycle — For processing requests from clients of Web Gateway.
  This cycle works with any data that is available in a request, such as client IP address, URL, user name (if authentication is performed), or browser-related header information.
  If a request is blocked in this cycle, no response cycle is performed, as the request is not forwarded to a web server and therefore no response is received.
• Response cycle — For processing responses by web servers, responding to the requests that Web Gateway forwarded to them
  This cycle works with any data that is available in a response, such as the requested data or server-related header information.
• Embedded objects cycle — For processing web objects that are embedded in requests or responses
  This cycle is performed when an opener is called in the request or response cycle to allow the filtering modules to look into a web object more deeply. The following two openers are available:
  • Composite Opener — The "normal" opener for inspecting files with formats such as .zip, .exe, and others
  • HTML Opener — Used very rarely in some advanced configurations

The embedded objects cycle is performed after the request or response cycle if embedded objects need to be inspected. If there are no embedded objects, the cycle is not performed.

After the request, response, and embedded object cycles are completed, rule sets with logging rules are processed on Web Gateway to let data be written into log files. Processing these rule sets is sometimes also referred to as performing the logging cycle.

Using expensive properties at the end of the filtering process

"Expensive" properties require a huge processing effort. Rules with these properties should be placed at the end of the rule set system.

When rules are processed, the modules (or engines) on Web Gateway are called to retrieve values for their properties. Some of these modules usually consume more time and bandwidth than others. For example, running the engines for anti-malware scanning usually consumes more resources than letting the URL Filter module retrieve URL category information.

To improve performance, place rule sets containing rules with expensive properties at the end of the rule set system, so that rules with less expensive properties are processed first. If one of these rules already blocks a request or response, the rules with the more expensive properties need not be processed.

Using not more than two properties in the criteria of a rule

Using not more than two properties in the criteria of a rule (where possible) makes the rule easier to understand for others and for you when you get back to it after some time.

The following sample rule allows access to destinations within a particular domain and for administrators, but only if they use a particular port for access. There are four different properties in the criteria of this rule for checking the following parameters:

• Host name of a URL — Is access requested to the configured domain?
• User group — Did authentication show that the user who sent the request is in the user group for administrators?
• Client IP address range — Was the request sent from a client with an IP address within the address range that is reserved for administrators?
• Proxy port — Is access to the domain requested over the configured port?

The rule looks as follows:

Name/Criteria	Action
Allow only administrators using port 9090 access to test domain URL.Host matches "testdomain.com" AND (Authentication.UserGroups does not contain "Administrator" OR Client.IP is not in range 192.168.42.0/24 OR Proxy.Port does not equal 9090)	Block <Default>

For a match that lets the rule apply, the first part of the rule criteria requires that a request for access to the test domain is actually submitted.

All other criteria parts are phrased negatively. If the user is not an administrator or the client IP address is not within the configured range or the proxy port is not 9090, then the request is blocked.

In other words, only if a request for access to the test domain is sent by an administrator from a client with an IP address that is within the configured range, using proxy port 9090, does this rule allow access.

The last three criteria parts are included in parentheses, so a combined truth value can be found for them and then checked together with the value for the first criteria part.

The same filtering behavior can be achieved by splitting this rule up into the following three rules.

Name/Criteria	Action
Check whether request is for accessing test domain URL.Host does not match *testdomain.com	Stop Rule Set
Block access if not over proxy port 9090 Proxy.Port does not equal 9090	Block <Default>
Block users who are not administrators based on user name and client IP address Authentication.UserGroups does not contain "Administrator" OR Client.IP is not in range 192.168.42.0/24	Block <Default>

The first of the three rules checks whether a request for access to the test domain is actually submitted. If this is not the case, processing the rules that follow this rule within the same rule set is stopped.

This means the two blocking rules that follow the first rule would not be processed. It is not necessary to process them, however, as there is no attempt made to access the test domain in the first place.

When the two blocking rules are processed, they check the parameters that are involved in deciding whether a request to access the test domain is allowed. The checking is performed in the same way as in the preceding single rule with four properties in its criteria.

The parameters that concern the administrator status of a user are combined within one rule with two properties.