Re: flow_depth and WMF exploit

[Jason <security () brvenik com>]

Frank Knobbe wrote:
> > The comment is not dismissive at all. IMHO it is factual and
> > representative of the misconception people have of the appropriate use
> > of technology.
>
>
> So, to summarize, are you of the opinion that IDSes shouldn't need to
> inspect web server responses because that task of alerting of hostile
> traffic is better left to other tools? (like an alerting web proxy --
> websense without the blocking if you will)?
>
> The point that web *requests* are important, because these allow us to
> detect actual intrusions and compromises of machines, is valid. But what
> about the scenarios where you have been compromised, but you can not
> tell by the requests traffic alone, only by the responses?
>
> There are botnet like programs that use benign web requests to connect
> to the handlers. Only the response traffic is a giveaway of the
> intrusion. This scenario does not fit the "protect internal PCs from
> hostile websites" profile that everyone is coming back to.
>
> What I'm after is the detection of intrusion through analysis of web
> response traffic.

It is my opinion that if this is concern and that the goal is inspection
and detection of this activity then access to the Internet should be
forced through a proxy that is well suited for this purpose. You should
also require authentication and enforce content encodings and acceptable
use.

> And yes, it can be encoded/encrypted and we lost in that case. In my
> opinion, gzip doesn't fit that bill. If we were capable of decompressing
> it, we could inspect the response traffic. Again, this is not to screen
> for incoming malicious files (although it would certainly help there).
> That task, as we discovered several times now, are better left to other
> proxies. But we could use it to uncover compromised machines.
>
> SSL running on off ports, DNS tunnels and such can be detected. My point
> is that the gzipped content can not be easily detected as bad since it
> is ambiguous. We need to decompress it first before we can tell good
> from bad.

You need to use a proxy that can actually enforce this behavior, cache
the results, and speed up the handling while providing content filtering.

> heh, I just realized that I'm falling back to the gzip thing. I
> apologize for that.
>
> Focusing on flow_depth and the analysis of response traffic, there are
> cases where analysis of response traffic is required since it contains a
> reflection of compromised hosts... bad analogy.... there are cases where
> we can only identify compromised hosts by analysis of response traffic.

I disagree with this in principle. A compromised host will make itself
known in many ways and if the only thing it does is contact a web page
and receive content that does not cause another detectable action to
occur then where is the compromise?

> I'm really not after filtering good from bad web content, but I admit
> that I slipped towards that. But at the same time we can't dismiss
> incoming web traffic either since it can tell us a lot of the state of
> internal machines.

There are far better approaches to this problem that are out of scope
for this thread. In all cases I have seen presented the proxy is far
better suited to handle the problem.

> Anyway, I'm dropping this thread since I tend to confuse with gzip. I
> will continue to argue the need for that on the devel list. ;)

See you there... ;-)

> Cheers,
> Frank
>
>
>
>
>  


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users