Best Practices for Configuring a Web Policy
Web Gateway offers many ways to configure rules. However, to achieve an efficient filtering process, some guidelines should be observed.
- Use rules and rule sets in appropriate filtering cycles — Some filtering activities are better handled in the request cycle, while others can be left to processing in the response cycle. For example, a rule that blocks requests based on the categories of the submitted URLs should be processed in the request cycle.
- Use "expensive" properties toward the end of the filtering process — Some properties require more time and bandwidth to retrieve values for them during the filtering process.
For example, the Antimalware.Infected property is expensive in this sense, so a rule that contains this property should be placed after a rule with, for example, the less expensive URL.Categories property. If a request is blocked by the first rule, the effort of processing the second rule is avoided. - If possible, do not use more than two properties in the rule criteria — This guideline does not save processing resources but makes it easier to understand how rules work.
- Use "expensive" properties toward the end of the filtering process — Some properties require more time and bandwidth to retrieve values for them during the filtering process.
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.
General guideline for using the request cycle
Let any information that is available in a request be filtered in the request cycle to get any blocked matter out of the way as soon as possible. To understand this guideline, consider cases like the following:
- If filtering based on URL categories is performed in the response cycle, rather than in the request cycle, the requested data might be received from the web server, only to find out that it cannot be passed on to the client because their category is not allowed.
- If filtering based on client IP addresses is performed in the request cycle and a request is blocked, no response cycle is performed, so it is useless to have a rule for filtering this data in the response cycle. If a request is allowed, it is not necessary to filter the data a second time in the response cycle.
Processing cycles and recommended filtering activities
The following table shows the filtering activities that should be performed in the different cycles.
Request cycle | Response cycle | Embedded objects cycle |
---|---|---|
Filtering based on whitelists | Filtering based on whitelists | Inspecting the body of a request or response |
Filtering based on blocking lists | Filtering based on server-sent headers, such as Content-Length and others |
Media type filtering |
Filtering based on client-sent headers, such as User-Agent and others |
Media type filtering | Anti-malware scanning for embedded objects |
User authentication | Anti-malware scanning for downloads |
|
URL filtering | ||
Anti-malware scanning |
As this overview also shows, there are some activities that are only recommended for one cycle, while others, for example, whitelisting or anti-malware scanning, are recommended for two or more cycles.
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.
Expensiveness of properties
The following table shows the "expensiveness" of some properties that are often used in rules.
Properties marked by an * (asterisk) rely also on external components, for example, on an authentication server, which additionally impacts performance. The table also shows expensiveness for two rule elements that are not properties, but events.
Less expensive | Medium | More expensive |
---|---|---|
URL | URL.Destination.IP* | Antimalware.Infected |
URL.Host | Media.EnsuredTypes | Properties used in DLP (Data Loss Prevention) filtering |
URL.Categories* | Properties* used for authenticating users |
Using the HTML Opener (enabled by an event) |
Client.IP | Using the Composite Opener (enabled by an event) |
|
Proxy.IP | ||
Proxy.Port | ||
System.Hostname | ||
Properties used to check HTTP header information |
Expensiveness of properties considered for individual rules
The guideline for using properties according to their expensiveness applies not only to a suitable placement of rules and rule sets within the rule set system as a whole, but also to the use of properties in individual rules.
The following rule blocks a request for access to a web server with a particular host name if this request was sent by a client with a particular IP address.
Name/Criteria | Action |
---|---|
Block host abcd.com for client with IP address 1.2.3.4 Client.IP equals 1.2.3.4 AND URL.Host matches *abcd.com |
Block<Default>Continue |
When the rule is processed, the value for Client.IP is retrieved first to see where the request comes from. If it does not equal the configured operand, the rule does not apply and processing continues with the next rule. Only if the value for Client IP is actually 1.2.3.4, will the value for URL.Host be retrieved as well, to see if the criteria matches completely.
Client.IP is placed first in the criteria because comparing two client IP addresses is less expensive than verifying that a host name matches a wildcard expression.
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
|
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.