cancel
Showing results for 
Search instead for 
Did you mean: 
malware-alerts
Level 10

High volume (bytes from client) from MWG to http://mwg_ip:port/crossdomain.xml

Jump to solution

We currently use MWG in a transparent router setup with version 7.4.2.2

The appliance has 3 interfaces enabled:

1 external (ETH0)

1 internal that intercepts http/https/ftp traffic (ETH1)

1 dedicated for accessing the GUI and for central management.(ETH3)

When reporting on Web Usage in CSR (Sum of Bytes from client / per site) the top site (87% of 'all bytes from client' transferred) is always the MWG appliance itself, on eth3.

When looking at the report details, all hits for this site are for the URL: http://MWG_ETH3_IPSmiley Tongueroxy_port/crossdomain.xml

I don't have the username since the appliances are currently in transparent router mode and don't authenticate.

Looking at the browser information of each hit, it's always the same (Chrome on 64-bits windows) and I'm deducting that it's MY browser "causing" these hits since our standard browser is IE, only a subset of people actively use Chrome and only a subset of people using Chrome have 64-bits Windows and the users' browser traffic travels from ETH1 to ETH0.

The CSR report I'm looking at is for the last 24hours and my browser was opened on the management GUI of MWG (ETH3) pretty much all day.

I can see the same 'pattern' in the MWG dashboards: the top 2 "Source IPs by bytes transferred" are #1 the external interface IP (ETH0) and #2 the management interface IP (ETH3)

Looking at the number of "bytes from client" transferred for each 'GET' request in the detailed CSR report, it varies from 2MB to over 341MB (no particular order or pattern)

Here is the typical details page from the CSR report  (Edited to remove IP and hostname)

Action taken:Allow
Agent name:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
Application name:-
Application protocol:http
Browse time:36 seconds
Browser name:Chrome
Browser name and version:Chrome 37.0
Bytes:82.91 MB
Bytes from client:82.83 MB
Bytes from server:81.47 kB
Cache result:Miss
Cache result detailed:MissSmiley Surprisedther/Unknown
Cache status:-
Category name:-
Content type:-
Date and time:9/23/14 1:19:41 AM
File extension:-
HTTP status:502
IP address:MWG_ETH3_IP
Log source name:mwg_hostname
Log source type:McAfee Web Gateway (Webwasher)
Malware name:-
Method:GET
Protection area:-
Reputation:Unverified
Site:MWG_ETH3_IP
URL:http://MWG_ETH3_IPSmiley Tongueroxyport/crossdomain.xml

Anyone has any idea what this is all about?

0 Kudos
1 Solution

Accepted Solutions
abenjami
Level 8

Re: High volume (bytes from client) from MWG to http://mwg_ip:port/crossdomain.xml

Jump to solution

Hello,

I just sent an e-mail over to you on this issue.  It seems that the Web Gateway has the VIA header removed from both of the systems.  This can cause issues with requests going into a looping state on the proxy through the proxy port.  Based on the log entry, this is going back into the Web Gateway on one of the Proxy ports that you have configured for one of the proxy listeners.  Please try to configure the following on the Web Gateway based on our best practices;

This should help the issue from occurring on the Web Gateway.  I have sent an e-mail through the service request detailing more information on this.

Thanks,

0 Kudos
4 Replies
malware-alerts
Level 10

Re: High volume (bytes from client) from MWG to http://mwg_ip:port/crossdomain.xml

Jump to solution

Been investigating a bit further directly in the MWG access.log.

I can see the following pattern:

First There is a 'get' request to http://mwg_eth3_ipSmiley Tongueroxyport/crossdomain.xml from my workstation:

[24/Sep/2014:12:11:07 -0400] "" my_wks_ip_addr 502 "GET http://mwg_eth3_ipSmiley Tongueroxyport/crossdomain.xml HTTP/1.1" "" "Unverified" "" 3805 591 "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; .NET CLR 1.1.4322)" "" "0" ""[

The I get a bunch of those requests every 4 to 6 seconds:

[24/Sep/2014:12:11:14 -0400] "" mwg_eth3_ip 502 "GET http://mwg_eth3_ipSmiley Tongueroxyport/crossdomain.xml HTTP/1.1" "" "Unverified" "" 3801 649 "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; .NET CLR 1.1.4322)" "" "0" ""

Though this could be only happening when my browser was opened on the MWG GUI, so I closed the browser for 2 minutes and then re-opened to look at the logs, and these requests kept on coming even while my browser was closed, so no relation there. Also, yesterday's logs suggested Chrome as the User-Agent and today it's IE...

0 Kudos
malware-alerts
Level 10

Re: High volume (bytes from client) from MWG to http://mwg_ip:port/crossdomain.xml

Jump to solution

Ran a tcpdump on the affetced appliance just to see if I could pinpoint the source and surprise! These entries in the access.log are not generated from live connections... something is "looping" in the logging process and it keeps on logging phantom requests

0 Kudos
abenjami
Level 8

Re: High volume (bytes from client) from MWG to http://mwg_ip:port/crossdomain.xml

Jump to solution

Hello,

I just sent an e-mail over to you on this issue.  It seems that the Web Gateway has the VIA header removed from both of the systems.  This can cause issues with requests going into a looping state on the proxy through the proxy port.  Based on the log entry, this is going back into the Web Gateway on one of the Proxy ports that you have configured for one of the proxy listeners.  Please try to configure the following on the Web Gateway based on our best practices;

This should help the issue from occurring on the Web Gateway.  I have sent an e-mail through the service request detailing more information on this.

Thanks,

0 Kudos
malware-alerts
Level 10

Re: High volume (bytes from client) from MWG to http://mwg_ip:port/crossdomain.xml

Jump to solution

Thanks Andrew, this was actually the problem.

I was under the impression the VIA headers were only necessary in the case of upstream proxies setup? I guess not.

0 Kudos