5 Replies Latest reply on Jul 24, 2017 11:21 AM by Jon Scholten

    McAfee Web Gateway action on ICAP server response

    metalhead

      Hi experts,

       

      we are currently testing a McAfee WebGateway connected to a non- McAfee Sandbox via ICAP.

      We used the default "ICAP client" ruleset (only RESPMOD) and all works well.

       

      Now we are trying to understand how MWG reacts on the different ICAP server resonses and how it evaluates the ICAP server´s response.

       

      What we seemed to found out so far:

       

      - ICAP client rule is true at least if ICAP server´s "modified HTTP reply header" includes "403" -> this result is the action within this rule; default is "Stop Cycle"

           * Question 1: Why is the default action not "Block" to get a proper block page on a "this file is malicious" response from the ICAP server ?

       

      - MWG seems to "know" when to set "true" or "false" in the rule above

           * Question 2: How does it evaluate the response ?

           * Question 3: Can I "manually" evaluate the ICAP server´s response by setting the ICAP client rule to "Continue" and create a next rule which evaluates "ICAP.RespMod.ResponseHeader.Get("X-Response-Header")<RespMod> matches "403" ?

       

      Thanks for any help.


      Regards Tom

        • 1. Re: McAfee Web Gateway action on ICAP server response
          Jon Scholten

          Hi Tom!

           

          On question 1, it's set to stop cycle because by default we'll show whatever content the ICAP server responded with instead of our own. The ICAP server (in most cases a DLP server) might include information thats useful to the user. You are free to set this to block.

           

          #2, It's basically looking at the response codes to see if it received on that indicates the request/response body has changed in anyway. If it has changed, the properties are set to true.

           

          #3, You can indeed! Thats exactly what would be required.

           

          Curious, have you noticed that when you send the object over to the Sandbox things get slowed down?

           

          I had written a ruleset which can enable "Offline" scanning for ICAP requests. This is useful when you dont want to interrupt the user transactions.

           

          Re: Don´t wait for ICAP Server response  ... it looks like you started that post...

           

          Best Regards,

          Jon

          1 of 1 people found this helpful
          • 2. Re: McAfee Web Gateway action on ICAP server response
            metalhead

            Hi Jon,

             

            many thanks for your response.

             

             

            #2, It's basically looking at the response codes to see if it received on that indicates the request/response body has changed in anyway. If it has changed, the properties are set to true.

             

             

            Is there a more specific explanation on this ?

            We try to achieve a more specific behavior on the different ICAP response codes in regards to the information shown to the user:

            RFC 3507 - Jeremy Elson and Alberto Cerpa, Editors

            E.g. I want to display a different block page in case of a scanning failure in opposite to the block page when the file is found to be malicious.

             

             

            #3, You can indeed! Thats exactly what would be required.

             

             

            Sadly that did not work. The rule tracing showed that this property was empty.

             

             

            Curious, have you noticed that when you send the object over to the Sandbox things get slowed down?

             

             

            What exactly do you mean by "things get slowed down" ? We did not notice any general "slowish" behavior but downloads are extended because the comfort pages also waits for the sandbox to complete its scanning.

             

            Regards Thomas

            • 3. Re: McAfee Web Gateway action on ICAP server response
              Jon Scholten

              Hi Thomas,

               

              From working with ICAP for the last 10 years, we're looking at the ICAP response codes, like 200 or 204. 200 means something changed, whereas 204 means to use what you (the ICAP client) have. If there is an error 40x or 50x, we'll fall to the error handler -- for that you'll need to setup the proper block pages in the error handler. There is multiple error situations that can occur, each with their own ID. If the rules arent there already, you might need to create a rule for each error ID to have customized blockpages for each (see: Web Gateway: Understanding the Error Handler )

               

              Error.IDError NameDescription
              16000NoICAPServerAvailableNo ICAP server available from service
              16001NoRespModPropInReqModThe property $propName$ cannot be calculated in the request cycle
              16002ICAPBadResponseICAP client filter error: ICAP server send bad response.
              16003ICAPMaxConnectionLimitICAP client filter error: Maximum connection limit reached.
              16004ICAPCannotConnectToServerICAP client filter error: Cannot connect to ICAP server.
              16005ICAPCommunicationFailureICAP client filter error: Communication failure with ICAP server.

               

               

              When you used the property "ICAP.RespMod.ResponseHeader.Get("X-Response-Header")<RespMod>", is "RespMod" the settings container you used when you called the ICAP server? Example below, "GSD-MWG1 - GAM" is my settings container for when I called the ICAP server, so when I fetch an ICAP server from the response, I must use "GSD-MWG1-GAM". The ICAP header "X-Test" must also exist. Connection tracing or packet captures are good for understanding if the header is actually sent.

               

               

              As far as the "slow down" question, typically with sandboxing, there is two methodologies. Inline (user waits for sandbox to complete), or offline (user gets file without waiting on the sandbox) -- it sounds like you have "Inline". Just asking in case you were not aware the other option was available. The other thread I referenced was demonstrating how to modify an Offline scanning ruleset (originally meant for our Sandbox -- ATD) to be used with an ICAP server.

               

              You should also be aware that MWG 7.7.x has encrypted tap options. This allows for SSL traffic to be sent to a span port for a sandbox to scan the traffic passively (without user interruption).

               

              Not trying to sell you on offline scanning or encrypted tap, just making sure you're aware that they exist.

               

               

              Best Regards,

              Jon

              1 of 1 people found this helpful
              • 4. Re: McAfee Web Gateway action on ICAP server response
                metalhead

                Hi Jon,

                 

                wow that´s the infos I needed.

                I am just getting into ICAP so I really appreciate all infos from one that "really knows" :-)

                 

                In ICAP.RespMod.ResponseHeader.Get we did not properly use our ICAP server setting container so this is most likely the problem - we will test it the next days ...

                 

                We are using the solution "inline" so we are aware of the added time delay which in this case is only 1-4 minutes.

                 

                Regarding "You should also be aware that MWG 7.7.x has encrypted tap options. This allows for SSL traffic to be sent to a span port for a sandbox to scan the traffic passively (without user interruption)" is this an additional harware tap ?

                 

                Thanks again and regards

                Tom

                • 5. Re: McAfee Web Gateway action on ICAP server response
                  Jon Scholten

                  Hi Tom,

                   

                  For the encrypted tap, there's no extra hardware needed. The MWG has a new event called "Enable SSL Tap", and in the appliance configuration you define a network interface thats connected to a SPAN port. When the event is used, MWG will replay any SSL traffic to that span port -- where there is likely a sandbox or DLP.

                   

                  Here's a guide which walks you through how to use it -- not for this specific use case, but similar.

                  Web Gateway: Configuring SSL Tap with Network Data Loss Prevention (NDLP) Monitor

                   

                  Best Regards,

                  Jon