AnsweredAssumed Answered

Monitoring proxied web traffic with SA

Question asked by RSA Admin Employee on Apr 1, 2014
Latest reply on Apr 16, 2014 by RSA Admin

Hi, wondered if anyone had any views on this issue?


We have deployed SA South of our web proxies, therefore capturing all web traffic between the clients and the proxies. This presents some advantages, but also some problems.


The biggest problem is TCP session re-use. If an employee browses to an external website, SA captures and records that TCP session. If the user then goes on to browse to other sites, the TCP session to the proxy is re-used, as their computer considers all external websites to be on a single IP (the proxy).... the same TCP session is used for all browsing within a single browser instance, unless the idle timer expires.


Why is this a problem? A single SA session could contain a large number of entries, representing all websites visited and content downloaded within that TCP session. If one of those domains matches a risky domain defined within in a Live feed, it is not always obvious which domain is responsible. Similarly alerts will display the first value observed in the session, rather than the one that triggered the alert. The same goes for other metatypes, where SA reports something suspicious (e.g. obfuscated iframe), but it is not obvious which website/content triggered the event.


We could move our SA monitoring to Northside of the web proxies. This would then ensure that a new session is created for each website a user visits. Downsides of this:

Primarily, we would not be able to detemine the employees IP address (all sessions would originate from the web proxy)

We would not record any activity that bounces off the proxy to an internal website

We would not record any activity that is blocked by the web proxy (although this would be recorded in proxy logs)


Can anyone comment on this, has anyone else had a similar problem? Are there any solutions, other than moving the monitoring to North of the proxies? I've considered whether the TCP idle time could be reduced in order to reduce the likelihood of session re-use.