Skip to main content

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

Skyhigh Security

Documentation of Rule Set

Documentation of Rule Set 

To get started please import the associated XML file into your existing Secure Web Gateway (On-Prem) policy. To do this, please access the Web Interface, log on with a user that is permitted to make changes to the policy, and go to "Policy" -> "Rule Sets". Here please click "Add" -> "Top Level Rule Set...":


In the dialog, please choose “Import rule set from Rule Set Library”. In the new window, please click “Import from file...” in the lower left corner. Please pick the associated XML file to import the rules. If you encounter conflicts during the import, please refer to the troubleshooting section of this document.

Where to Put the Rule Set?

You should place this rule set close to the beginning of the policy. If there is an SSL Scanner rule set in place, the SSL Scanner rule set should be on top of the welcome page rule set. Additionally, you may want to consider exceptions from the welcome page, such as global white- or black lists.

Authentication needs to be considered when placing the rule set. In case you want to bind the welcome page to a username rather than a client IP address, authentication should be performed before the welcome page rule set is entered.

Welcome Page

The rule set only contains one rule as it is relatively simple.


The rule sets criteria ensure that the rule set is not triggered during the SSL handshake when the SSL scanner is used. The rule set is only valid for the request cycle since all information required for redirecting the user is already available.

Redirect to External Site

The criteria of this rule ensure that the request is (most likely) coming from a browser. The User-Agent header is used by major browsers to identify themselves as remote hosts. Most common browsers contain the string “Mozilla”. By this check, the redirect is not performed if the request is coming from a script or other applications utilizing HTTP, since these will usually not contain “Mozilla” in their headers.

The second criterion checks for the URL path. This check is used to determine if a user has accessed a web site manually. The URL path is usually “/” if a user accesses a website by entering its URL into the address bar of his browser, such as or The Redirect action is only called for such requests to
prevent an object which is embedded into a website and not directly visible for the user gets redirected. For example, the Firefox browser generates some HTTP requests to check for updates when it is started. Without these criteria, already the check for the update would trigger the welcome page, and the user may never see it.

The last criteria checks for the PDStorage value of a key called “WelcomePage”. If there is no PDStorage value set for this user and key, the Redirect action is performed and the value is set. By doing so, the next request by this user will have the “WelcomePage” key set to true, and the user is allowed without being redirected again.

Timeout Settings

By default, the “WelcomePage” key expires after 8 hours. You can configure the time out in the associated settings for PDStorage:


The default setting of 8 hours defines that the Welcome Page is displayed again if a user has not made any requests for 8 hours. After 8 hours, the “WelcomePage” key is removed from PDStorage, which causes the next request to be redirected to the configured URL.

Redirect Target

With the default settings, the Redirect action will redirect a client to the McAfee homepage. To replace the destination URL, please have a look at the associated action setting:


The Redirect URL specifies the target for the Redirect action. You will need to put in the URL to which your users should be redirected.

  • Was this article helpful?