Sensor placement with presence of web proxies

Zeek
1

Our org is looking at using web proxies without changing settings on
the client. This can involve using Cisco's WCCP or policy-based
routing to marshal traffic that would normally go to the Internet to a
proxy. As I understand it, the proxy makes the request, returns the
response to the router, and the router returns the response to the
client. My question is if anyone has run into problems with a tap or
span on the side of the router closest to the client. That is, does
the proxy change the traffic enough to interfere? It seems
nonsensical to put the sensor at the edge of the network since the
requests will have the source IP of the proxy, not the actual client,
but that means that the traffic the IDS inspects will be inauthentic
versus what the remote host on the Internet actually sent.
Theoretically, it should be the same traffic, but I'm wondering if
anyone can confirm that. I'm especially concerned with appliances
that reorder or normalize HTTP headers, etc.

Thanks,

Martin

2

one thing I do with some of the snort stuff is to pull the packet contents and look for a 'X-FORWRDED-FOR' header.

Several of my automated scripts do this so this enables me to trace connections back through squid proxies with out problems.

If the proxies add such headers than you may be able to get a bro script to automatically pull the real IP and report that.

R

3

Right, but then you lose the power of reporting on srcip, as well as
any chance at correlation. A very frequent task my analysts do is to
follow-up on any newly-identified hostile dstip's by doing a query
which shows all unique srcip's to hit it. My httpry_logger.pl script
sets the srcip via X-Forwarded-For if available, but a lot of other
tools don't.

All of that aside, I shouldn't need to worry about XFF if I sniff the
client-side of the connection, right? If that's true, then my main
concern is whether server response headers are getting altered by the
proxy.