# Sensor placement with presence of web proxies

**URL:** https://community.zeek.org/t/sensor-placement-with-presence-of-web-proxies/2201
**Category:** Zeek
**Created:** [January 26, 2012, 9:54pm UTC](https://community.zeek.org/t/sensor-placement-with-presence-of-web-proxies/2201 "2012-01-26T21:54:35Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![Martin\_Holste](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@Martin\_Holste](https://community.zeek.org/u/Martin_Holste)
#### Post date: [January 26, 2012, 9:54pm UTC](https://community.zeek.org/t/sensor-placement-with-presence-of-web-proxies/2201/1 "2012-01-26T21:54:35Z")

</div>

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

---

<div class="post-metadata">

### Author: ![Russell\_Fulton](https://avatars.discourse-cdn.com/v4/letter/r/85f322/32.png) [@Russell\_Fulton](https://community.zeek.org/u/Russell_Fulton)
#### Post date: [January 27, 2012, 2:01am UTC](https://community.zeek.org/t/sensor-placement-with-presence-of-web-proxies/2201/2 "2012-01-27T02:01:34Z")

</div>

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

---

<div class="post-metadata">

### Author: ![Martin\_Holste](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@Martin\_Holste](https://community.zeek.org/u/Martin_Holste)
#### Post date: [January 27, 2012, 2:57am UTC](https://community.zeek.org/t/sensor-placement-with-presence-of-web-proxies/2201/3 "2012-01-27T02:57:27Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)
#### Post date: [May 6, 2022, 3:40pm UTC](https://community.zeek.org/t/sensor-placement-with-presence-of-web-proxies/2201/4 "2022-05-06T15:40:08Z")

</div>


