Skip to main content

Check out Interactive Visual Stories to gain hands-on experience with the SSE product features. Click here.

Skyhigh Security

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.

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


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.

 

  • Was this article helpful?