Making Bypasses for SSL Scanner using Maintained Lists

[abenjami]

I have noticed that there have been some questions or encounters with Web Gateway administrators trying to make bypasses for their SSL Scanner on the Web Gateway.

(This is based on the concept that the authentication rules are occurring after the SSL Scanner!)

I hope to make this process a little easier here;

First lets make our bypass top level rule-sets like the following;

Then in our new rule-set which is enabled for (Request(and IM)/Responses/Embedded Objects)

We are going to make a more complex rule for bypassing Teamviewer from the SSL Scanner using the programs User Agent.

Here is what the rule is going to look like in it's completed form;

To make this rule, you will need to do the following;

1. Pick the correct property;

2. Put in the parameters for the header that you are looking for.

3. Select the correct operator:

4. Select the button to add the new list.

5. Give the list a name like the following and hit OK.

(If the name of the rule matches the list, it will turn blue and you can access the rule through the list name!)

6. Add in the entries that we are looking for;

7. After saving the list, you will then need to choose the following option to "Stop Cycle" which will stop the filtering for this traffic.

8. If the authentication is occurring after the SSL Scanner, you can do the following to add a username to match the bypass.

[Finished Rule]

For other bypasses with the maintained list configuration, you will want to make the list using the following option unlike how we made the list in (Step 5).

Then select the correct Maintained List that you are looking for;

Here are some of our more common configurations which customer's use;

I would put these under the following location;

If you are planning on adding in the Microsoft Bypasses you might need to add in Timeout Configurations for some of the traffic like Microsoft Lync.

To add in the extended timeout, select the rule you would like to do this on (Microsoft Lync or Office 365)

Then in the events, select the following;

Then for the new event, you will want to give it a name and also adjust the timeout value for the rule;

If you want to make bypasses for Microsoft Office, I would put them in the following location;

Here are some of the common rules to bypass Microsoft Applications.  The list names match the names of the Maintained lists in the rules for reference;

Please keep in mind that the Maintained Lists are "maintained" by McAfee with content provided by their software vendors.  Their content is subject to change at anytime so these lists are provided to reduce administrative overhead.  If you noticed that list content has changed or the information in the list is no longer correct with the software vendor please contact the McAfee Web Gateway support team.

[asabban]

One more note may be important. If you use "URL.Destination.IP" properties this means that MWG *must* have access to DNS. I have seen MWG in "DNS-less" environments where all traffic is handed to a next-hop proxy, in this case MWG will never see the IP address and will not be able to resolve the IP address, so those rules will fail and eventually cause delays.

Best,

Andre

[mbagheryan]

I am agree with saban.

I had this experience before in my customer's network environment (Bank).

[abenjami]

In hindsight, it might be better to ensure that the Web Gateway is enforcing that the connection is an IP before using the URL.DestinationIP property.

Based on some of our internal testing, if we insure the following, "URL.HostIsIP" "Equals" "True" while using the "AND" with Boolean logic to cause the check to first see if the connection is an IP to the destination before the URL.Destination.IP property, it seems that this will ensure that we only execute the property under the idea that it is an IP thus mitigating the need for the DNS look-up.  Per our testing by having this in place, the Web Gateway did not execute the DNS part of this property when used in this manner.

Andre, can you confirm that this would be a better action to take in regards to working around the DNS look-up part of the property?

Thanks,

[asabban]

Hey Andrew,

I am not exactly sure that this will work as expected.

Assume we have a maintained list which only has IP address ranges in it. I think we do have an IP range list for Webex IP ranges, for example.

Usually I don't expect that the client makes a

CONNECT a.b.c.d HTTP/1.0

but it will rather make a

CONNECT somehost.webex.com HTTP/1.0

URL:Destination.IP will resolve "somehost.webex.com" into "a.b.c.d" and "a.b.c.d" is listed in the maintained list. So the Stop Cycle action applied, access is granted.

Assuming we don't have DNS and/or we apply the change you indicated in the screenshot the Stop Cycle action will only be applied when the client talked to the IP address directly. Any request to a host (which is more likely to happen) will not cause the Stop Cycle to be executed, so access is not possible.

For some cases it will work, but I think for most cases you need to have MWG talk to DNS in order to make this working properly as expected.

For sure the above rule set will work if the list of hosts contains all the possible host names. However for some services we only have IP address ranges.

Hope it makes some sense 🙂

Best,

Andre