Understanding the Error Handler

Last updated
Save as PDF

What is the Error Handler?

The Error Handler has two main functions:

Error Handling
Incident Handling

The focus of this article will be on the primary function which is handling errors. These errors occur whenever the Secure Web Gateway encounters a situation where it cannot process a request/response correctly. Secure Web Gateway then falls into the error handler with an "Error.ID"(Property) number. Common Error.ID numbers are included in the section below.
Incident Handling (for monitoring your appliance) is covered in a separate article found here:

Examples of Error.IDs

AV engine errors (overloads, failure to updated, 14xxx error codes)

14000 - Cannot Load Anti-Malware Engine - This is an error for when the Anti-Malware engine has failed to load.
14001 - Anti-Malware Engine Overloaded - This is an error that can occur if the AV engine is overloaded and cannot process more requests at this time.
14002 - Internal Anti-Malware Engine Error - This is for various internal AV errors. When the AV engine is unable to scan a file for some reason.

URL filtering errors (failure to load or update, timeouts, 15xxx error codes)

15000, 15002, 15004, 15005 - Cannot Load URL Filter - These are various URL filter errors which can happen for different reasons.

External ICAP (DLP) errors (16xxx error codes)

16000 - Rule Engine Error - This error occurs when an ICAP server is unavailable.
16002 - Rule Engine Error - This error occurs when we receive an invalid response from an ICAP server.

A full list of error codes can be found in the current product guide or the online help.

Error Handler Diagram

Fail Open vs. Fail Closed - A Policy Decision

So, what can we do with the error handler? The Error Handler can take different actions depending on what you want to do:

It can "fail closed", meaning the end users request would not be allowed to proceed and a block message would be shown instead.
- By default, the SWG is configured to "fail closed".
It can "fail open", meaning the error handler will NOT block the request and the end user can proceed. At the same time, additional logging/notifications can be triggered.
- "Fail open" scenarios are most commonly found in enterprise environments.

What kind of benefi ts are there to failing open in my environment?

Prevent business interruptions. Web access is one of the most critical parts of many jobs today.
Avoid unnecessary calls to internal help desks. It is enough if the SWG admins are aware and can fi x the problem. No need to alert end users
Layered security that can compensate for a failed component as long as immediate alerts are sent and action is taken

The flexibility of the error handler allows you to create whatever rules are needed for your policy. Here are a few examples:

Strict fail closed on all errors
Broad fail open to prevent any end user impact (ever)
Notifications to swg admins independent of fail open/fail closed setups
Exceptions for specific clients/users. For example, executives or other business critical parts of the organization can fail open while others fail closed
Selective blocking of specific requests. For example monitoring servers (known by their IP) can fail closed for additional alerting, while others fail open

Examples

Here we will cover three examples to get you a starting point when working with the error handler:

General fail open
Fail open with notifications
Fail open for specific groups/criteria

General Fail Open

Creating a general fail open policy is quite simple. The screenshot below shows an example of how every ruleset in the Error Handler should look. Follow the instructions below

Select "Policy" then "Error Handler"
Select a rule then "Edit"
Select "Action" and choose "Continue" from the dropdown.
Repeat 1-3 for every rule in the Error Handler.

How to Fail Open with Notifications

Follow along with the screenshots. These instructions are for doing fail-open with notifications on Anti-Malware overloads (situations where there are too many fi les in the AV engine being scanned).

Go to Policy>Rule Sets>Error Handler>Block on Anti-Malware Engine Errors
Edit "Block If Antimalware-Engine is Overloaded"
Select "Action" and from the Action dropdown choose "Stop Ruleset"
Select Events>Add>Event>Choose Email.Send.
Select "Edit", the values you enter in on these fields will be unique to your environment. Select "OK" when finished filling them out.
Select "Parameters" then select "Recipients", enter in the email address which is to receive the notification
Select "Subject", enter in what you want as the subject line in the notification emails,for this example we will enter in "Antimalware Engine is Overloaded"
Select "Body", enter in what you want the body to be, for this example we will enter in "The Antimalware Engine is Overloaded, please examine the swg-antimalware-errors.log fi le for more information"
Select Ok>Ok>Finish>Save Changes to finish creating the rule.

Note: For this to work you must either disable the "Block on All Errors" rule. OR you can just copy the rule that was modified, and paste it into the "Block on All Errors" ruleset,making sure you place it above the block rule.

Fail Open for Specific Groups

We can also add criteria to the rule to cause the bypass to only work for certain users.Follow the instructions and screenshot below to see how to modify the rule above to work only for users in the "Executive" group. Understand that authentication must have taken place before we are able to take any actions based upon it, this means that you must have become authenticated before hitting the rule which caused the error for this to work.

Edit the rule that we made prior.
Select "Rule Criteria">Add "User/Group criteria"
Choose "Authentication.UserGroups" on the left, at least on in list from the center,then select "Add List of string" from the right.
Name it "Groups to bypass from Antimalware overloads" then choose the radio button for "Groups" and select OK
Select "Edit List" then select the green "Add String" symbol.
Enter in "Executive" without quotes. Select OK three times.
From the AND/OR column choose AND from the dropdown.
Select Finish then Save Changes

Conclusion

The Error Handler is a powerful way of controlling what happens when an error occurs.Hopefully, after reading this document it will help you make the decision to fail open or fail closed in your environment. With the many options available for deciding who/what fails open or closed, you should now be able to configure the Error Handler to suit the needs of your environment and policies.