Working with the Error Handler

Version 3

     

     

    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 MWG encounters a situation where it cannot process a request/response correctly. MWG 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: https://community.mcafee.com/docs/DOC-4837

     

    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

     

    MBOdiagram3.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 MWG 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 benefits 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 MWG admins are aware and can fix 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 mwg 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.

    1.png

     

     

    How to Fail Open with Notifications

     

    Follow along with the screenshots. These instructions are for doing fail-open with notifications on Antimalware overloads (situations where there are too many files 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 mwg-antimalware-errors.log file 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.

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

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