I am new here in the McAfee community and I would just like to start off by saying hello to everyone and I look forward to a good discussion, and hopefully one that ends up not only helping my situation but others that run into the same issue, if that is even possible. Also my knowledge of McAfee Web Gateway, version 18.104.22.168, is very novice so please go easy on me, I know there are a great deal of knowledgeable individuals in this community I'm just not one of them yet.
Okay, down to business. I have a McAfee Web Gateway appliance that I just upgraded to version 22.214.171.124 from 6.8.6. Now in our case we ONLY use the Web Gateway, and we can get into a utilization discussion later, appliance as an ICAP server, nothing else. The device serves as a, well the best way I can describe it, "Man in the middle" where we have an IBM XS-40 DataPower device sending Base 64 RespMods to the McAfee Web Gateway to scan items that are uploaded to our system via users. Now here is the issue that we have run into with this new OS is that we need to find a way for the appliance to decode the Base 64 requests prior to them being sent to the ICAP server for scanning. Also some other configuration information, so that we can keep the discussion well focused on finding a way to decode Base 64 requests within the Web Gateway, is that; one the DataPower appliance is using a custom style sheet to send the requests to the Web Gateway and that cannot be shared nor modified because the style sheet is how we are communicating to the Web Gateway that the data being sent to it is Base 64 encoded. Two we made certain that the ICAP Server was enabled in the Configuration>Proxies (HTTP(S), FTP, ICAP, and IM) section as well as making certain that our URIs were set the same way we had them in version 6.8.6. We also made sure that our timeouts and other settings, that we could find in version 7.0, were set similar to the settings in version 6.8.6. We generated packet captures of the transfer and we can see that the appliance is opening the request, however, for what ever reason, the Web Gateway suddenly resets the connection.
So bottom line... We need to know how, if possible, to teach the McAfee Web Gateway, via some sort of rule set, how to decode Base 64 encoded requests before sending the requests on to the ICAP server for scanning. Does anyone know how that might be accomplished? Also, just because this is driving me crazy, but is there anyone else simply using the McAfee Web Gateway appliance as an ICAP server only? I appreciate all the help that I can get. Thank you.
Does the DataPower strip the surrounding XML away from the base64 already before it sends it to ICAP? That is, are you only sending the InnerText in base64 format? Or are you sending the OuterXML also?
The first thing that comes to mind is to somehow use the property:
But I'm not sure how it would be applied specifically.
One thing that would help is to see traces (off-list) from the current DataPower to the Webwasher in order to see exactly what is getting sent.
I'd want to see an example of one with a normal document, and one with eicar that gets blocked. (Either ICAP traces or tcpdumps)
I know what you are trying to do and have done it for others in a similar fashion. Isn't there a way for the transform to re-encode it back to binary before getting sent to ICAP? Or is that a constraint of the your application?
You were close in your response. From what I was able to find out the Web Gateway needed to be taught how to decode Base64 data through various parameters, and yours was not too far off. I created a new rule set in the Policy portion of the GUI. I named that new Rule Set Decode Base64 Data set the "Applies To:" property to "Requests (and IM)" ONLY. I then set the "Apply this rule set:" property to Always and set the Permissions to Super Administrator for Read and write permissions. Once I had completed that I created a new rule within the Rule Set called "Decode B64". In the Rule Criteria for the property "Apply this rule:" I set that to Always. In the Action section I set the "Action:" to Continue, and finally in the Events section I did the following, and please forgive me for the number of steps:
The issue we had was that the MWG was not even recognizing the traffic that we were sending to it. Once we sent the data to the MWG it would just drop the traffic because it did not know how to handle it. Also I disabled all other Rule Sets besides the one I had created and the virus detection rule sets. We made a few tests and everything seemed to work alright, however, one of our tests where we had a file that was sent it with all of the Base64 data on one line, longer than the 76 usual limit, the MWG responded to the DataPower as clean even if an EICAR was sent to it. So I am not sure if we need to make another rule which defines the length of the string to decode or if there is a preset way by which the MWG can detect that a file contains Base64 data that is all on one line and I just have not enabled it? Any ideas would be greatly appreciated. Thank you.
My apologies to the thread. It seems my way of thinking was backwards on this issue. It wasn't that we were unable to read base64 data that was on one line, but base64 data that was on multiple lines. It was explained to me that the processing of base64 data had changed from version 6.x.x to 7.x.x, in that in 6.x.x base64 data could only be read if it were on multiple lines; whereas now in version 7.x.x it can only read base64 data that sits on one line. In either matter we were able to modify our custom stylesheet, for the IBM appliance, to allow the McAfee Web Gateway to interpret the data correctly. At this point the only other customization that was done was to add the virus name into the ICAP response header doing the following:
There you have it. I hope this question will be useful to others. I'm sorry that I was the one that answered my own question, but I certainly do appreciate all the help I received from the community. Thanks to all.