4 Replies Latest reply on Oct 24, 2014 9:37 AM by asabban

    Making Bypasses for SSL Scanner using Maintained Lists

      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;

      Rule Location.jpg

      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;

      Teamviewer Rule.jpg

       

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

       

      1. Pick the correct property;

      Teamviewer Rule Part 1.jpg

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

      Teamviewer Rule Part 2.jpg

      3. Select the correct operator:

      Match in list.jpg

      4. Select the button to add the new list.

      Add List of Wildcard.jpg

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

      Teamviewer User Agents.jpg

      (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;

      Teamviewer List info.jpg

      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.

      Stop Cycle.jpg

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

      Auth User.jpg

      [Finished Rule]

      Teamviewer Rule.jpg

       

       

       

       

       

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

      Citrix IP Range Bypass List.jpg

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

      Citrix.jpg

       

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

      Common Other Apps Bypass.jpg

       

      I would put these under the following location;

      Other Apps Bypass.jpg

       

       

       

      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;

      Event 1.jpg

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

      Event 2.jpg

       

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

      Microsoft Bypasses.jpg

       

      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;

       

      Microsoft Bypasses.png

       

      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.

        • 1. Re: Making Bypasses for SSL Scanner using Maintained Lists
          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

          • 2. Re: Making Bypasses for SSL Scanner using Maintained Lists
            M Bagheryan M

            I am agree with saban.

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

            • 3. Re: Making Bypasses for SSL Scanner using Maintained Lists

              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.

               

              Information for limiting based on IP.jpg

               

              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,

              • 4. Re: Making Bypasses for SSL Scanner using Maintained Lists
                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