Skip to main content

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

Skyhigh Security

Understanding the Error Handler

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)
  1. 14000 - Cannot Load Anti-Malware Engine - This is an error for when the Anti-Malware engine has failed to load.
  2. 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.
  3. 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)
  1. 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)
  1. 16000 - Rule Engine Error - This error occurs when an ICAP server is unavailable.
  2. 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

clipboard_eaa89f4e11f086708a37b390a1dde3697.png

 

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

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

clipboard_e53d218d116322564eb918cd5293c5e32.png

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). 

  1. Go to Policy>Rule Sets>Error Handler>Block on Anti-Malware Engine Errors
  2. Edit "Block If Antimalware-Engine is Overloaded"
  3. Select "Action" and from the Action dropdown choose "Stop Ruleset"
  4. Select Events>Add>Event>Choose Email.Send.
  5. Select "Edit", the values you enter in on these fields will be unique to your environment. Select "OK" when finished filling them out.
  6. Select "Parameters" then select "Recipients", enter in the email address which is to receive the notification
  7. 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"
  8. 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"
  9. 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. 

clipboard_ec5640c77149f6ce37e2a902504467a4b.png

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.

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

clipboard_e28fec7af5da8652fc42207838fadca08.png

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.

  • Was this article helpful?