[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-ids
Subject:    Re: x-forwarded-for an IDS capability
From:       bartlettNSF <bartlettNSF () comcast ! net>
Date:       2009-05-10 5:40:31
Message-ID: 4A0668CF.2090400 () comcast ! net
[Download RAW message or body]

James wrote:
> 2009/5/7 Jason Haar <Jason.Haar@trimble.co.nz>:
> 
> > On 04/30/2009 10:04 AM, Hellman, Matthew wrote:
> > 
> > > I believe that the original poster is trying to deal with the problem of not \
> > > having the true source IP address for a given IDS alarm specifically because of \
> > > a forwarding proxy or NAT device on his own network. 
> > > 
> > As I was the original chap back in 2004 who asked this question, I'd
> > like to have my 2c worth too :-)
> > 
> > Indeed the issue was that our (snort) IDS was picking up
> > spyware-infected PCs phoning home through our proxies - and so the IDS
> > could only tell you the src IP was the proxy - no use at all in itself.
> > 
> 
> That is the same problem I have.
> 
> 
> > FYI our proxies lie inside our network - not on the edge (where the IDS
> > are).
> > 
> 
> Same again
> 
> 
> > Well now it's 2009 and we found a different way around it. We installed
> > snort onto all our proxies :-) Now snort can see the clients.
> > 
> > As far as the X-Forwarded-For comments go - I think that track is a very
> > bad idea. Everyone running proxies should be taking the opportunity to
> > 
> 
> Ok maybe I should help out with a flow diagram so you can understand
> where I am coming from
> 
> 
> user_pc
> -> transparent proxy (x-f-f stamped here)
> -> internet_gateway_proxy (headers stripped)
> -> internet
> 
> The IDS is capturing on the internal leg of the internet_gateway_proxy
> hence all http/https IDS alerts have a source ip of the transparent
> proxy which means correlation is virtually impossible unless the IDS
> can extract the x-f-f and substitute this for the source ip in the
> alerts.
> 
> 
> 
Hello list,
In my opinion would it not be easier to simply place and IDS (simple pc 
blackbox) on each segment and have it send the logs to a parent IDS 
system on a secured segment of the network? I'm considering this at my 
current place of employment to simply allow me to see our VPN sites as 
well. Although I understand that the newest version of Snort IDS, 
ver.3.8.4, is different in its installation method I would still 
consider using it. I plan on testing it soon here at home in a virtual 
state.
I do realize using multiple IDS sensors would add cost, bandwidth, and a 
POF to the network.Although the point of failure (POF) would not be 
considered an essential asset or classified as a critical system. Being 
that it is not a critical system it's hard for me to provide ROI on the 
added sensors that would allow coverage of any addition network segments 
they need to be installed on.

I want to make one thing clear. I, nor my employer, use any IDS system 
to view our employee traffic. We use it to provide a security service to 
them by giving us the ability to see an attack, what ever the traffic 
may be classified as, from an external source. This statement must be 
made on my behalf to ensure that our department keeps within our 
standing guidelines and policies. (legal crap)

-- 
Stephen Bartlett, B.S.
INFOSEC, CSSM, CSA, ISSO, CISO, CSC, CRA 
Assistant Systems Administrator


[prev in list] [next in list] [prev in thread] [next in thread]