Re: flow_depth and WMF exploit

[Frank Knobbe <frank () knobbe us>]

On Thu, 2006-01-05 at 12:59 -0500, Jason wrote:
> I didn't intend to put words in your mouth at all. I am stating the it
> is unfortunate that AV is failing to respond effectively. I think that
> as a result of this people are searching for other things that can help
> them out.

I see. Yeah, traditional AV surely got spanked on the WMF issue. I'm
surprised one vendor even made public the rate of infection within their
client base :

> > Not quite. IPSes that claim to inspect traffic at wire speed (that
> > includes server responses), are less capable of performing the
> > inspection tasks at higher speeds when the workload is increased by also
> > having to decode the data first from various encoding formats. (Proxies
> > are better suited for that since they were designed from day one as a
> > accept-and-forward type device.)
>
> This is rather obvious isn't it?
>
> Your statement also further highlights that there is a complete lack of
> understanding in the market. That any vendor claims to be able to
> perform this at wire speed, handling all or even the most common
> potential encodings and formats, and actually markets the technology
> that way is a disservice.

I agree. But again, I was never talking about it the IPS angle.

> That you echo these thoughts is good. That you seemingly buy into the
> methodology and think it is a tool that is appropriate is not good.

No, I don't. Again, I wasn't referring to the IPS.

> 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.

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.


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'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.

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. ;)

Cheers,
Frank




 
-- 
It is said that the Internet is a public utility. As such, it is best
compared to a sewer. A big, fat pipe with a bunch of crap sloshing
against your ports.

Attachment: signature.asc
Description: This is a digitally signed message part