Re: The old question...

From: bhooper3@csc.com
Date: 09/28/01 

Date: Fri, 28 Sep 2001 14:04:48 +0100
From: bhooper3@csc.com
Subject: Re: The old question...
To: Matt Collins <matt@clues.com>
Message-id: <OF16F57C3E.612F2DBF-ON80256AD5.00465B28@com>

Interesting points Matt. As a result of the WTC events, my work colleges in
NY are having to work from home and we are currently using Instant
messenger as our means of communication. This means allowing IM out through
the firewall although only on port 80. We are very cautious not to give
away any information that could come back and bite us. e.g. passwords ,IP
addresses, etc.

However it would be great to be able to find some information somewhere
about any nasties that could be injected into the HTTP tunnel and
compromise our security, after all we have no idea what is actually
happening in the application itself.

Brian

Matt Collins <matt@clues.com> on 28/09/2001 07:07:32

To: Donovan_Denis@emc.com
cc: Cedric.Royer@getronics.com, focus-ids@securityfocus.com
Subject: Re: The old question...

On Fri, Sep 28, 2001 at 05:01:21AM -0400, Donovan_Denis@emc.com wrote:
> i don't claim to be an expert in ids but i did look into this
> (albeit in a swithced environment) and this is what i came up with
> Note that we were looking at commercial ids systems, been using
> realsecure for a while now.
>
> cheers,
> denis
>

Yeah, I've got a few replies like this. I'm pretty cogniscant of IDS
deployment
and operation from a vanilla "Buy a probe, put it in, tune to your traffic,
sit back, enjoy" point of view, but what I'm talking about here is a much
more specific issue.

to clarify, as a hypothetical:

We have data; firewall logs, proxy usage logs, IDS logs.

We know that use is made of that infrastructure for legitimate web
browsing,
stock tickers, news sites and the like.

We *also* know that folks are using that infrastructure for application
data
streams tunnelled inside of legitimate HTTP requests; Stuff like the Java
RMI
tunnelling via HTTP POST, ICQ proxies, HTTPtunnel servers giving desktop
Socks servers, and so forth, that pretty much make a mockery of our risk
control
and assessment proceedures; the firewalls, if they permit HTTP and SSL to
arbitary
external hosts on arbitary ports, permit any semiskilled computer user
access
to any external resource; and potentially any external resource access to
the
internal LANs.

The trick is ,as I see it, first to identify those misusing the
infrastructure; my
initial thoughts on that are by building a statistical profile of "normal"
http
traffic. I expect this to be short snappy connections - retrieval of an
HTML page or
GIF image, for example, with a small amount of outbound traffic for URL
requests,
CGI submissions, cookie responses, etc.

I would expect "tunnelled" traffic to be of a different nature; much more
evenly
balanced inbound/outbound connections, those using CONNECT methods to be
established
for far longer than usual, for interactive sessions the data to be much
lower
throughput and more "spikey" in terms of transfer, and so on.

I guess I'm talking about a statistical analysis of traffic flow,
throughput and
duration patterns to try and identify people tunnelling applications via
HTTP
and SSL, with an eye to expanding that to other such more sophisticated and
covert channels at a later date (Sending data as FTP transfer feeds,
bundling data
into "packets" for POST requests, etc)

Once we've found a way to identify such connections semi-reliably we can
look at
enforcing more rigourous controls on them.

What I'm asking is if anyone has methodically addressed these issues
already, knows
of a forumn where such methods are being discussed, knows of a commercial
product
that attempts to address and identify/control such protocol usurpation (is
that
a word? ;-) ) or has any initial ideas on how to proceed.

Anything woul dbe helpful; I've looked at the W3C's http traffic
analysis's, which are
a good start, but further statistical data on traffic usage, methodologies
for gathering
such data from an arbitary environment and identifying tunnelled traffic,
etc, would
all be appreciated ;)

Uhm. Any ideas? Anyone interested? Or is life still "We have pattern
matches for
known exploits, anything else configure the traffi cyou expect and alert on
exceptions"?

Thats not really a viable approach for an open internet border; we need to
do analysis
on traffic patterns, I think, as its not possible to define each and every
web site on
the internet that folks might want to visit, and deny everything else, and
then effectively
ensure such a policy remains up to date.

Bleuggh.

Matt