Re: Important Comments re: INtrusion Detection

[Rick Morrow <rmorrow () delfax net>]

On Sat, 14 Feb 1998 tqbf () secnet com wrote:

> > I would disagree, as this conclusion would not take into account the need 
> > for a secondary source of information regarding the hosts which are 
> > possible targets.  There is a strong need for context to be able to 
>
> Believe it or not, the proxy solution actually solves quite a number of
> problems. I spent about 40 minutes yesterday trying to explain to Kurt
[...]
> A proxy gateway has the distinct advantage of being a connection endpoint.
> In the terminology I've been using lately, I'd say that a proxy-sniffer is
> an ACTIVE (not passive) monitor. Say we have hosts A (the attacker), B
[...]

        Forgive me if, by unlurking and adding to the thread, I am
stepping in well over my head. :) I've noted some interesting trends in
this thread, and see some relationships to other topics that have appeared
recently. 

        First of all, if we make the IDS an active endpoint for the
connection can we, using the classic definition of an IDS, still call it
an IDS anymore? Wouldn't it at that point become a firewall with IDS
capabilities?

        Mind you, I'm not saying this is a bad thing, and I certainly
wouldn't be so presumptuous as to say that this looks like a step forward
in firewall technology. But it does (IMHO) :-). 

        And it would also seem that for the most part some of the list
members see it as that as well, although I wouldn't be so presumptuous as
to speak for anyone else...

        One comment was made in a recent message in this thread about the
need to preserve a sense of a remote context. Perhaps this _can_ be done
with this kind of proxying scheme. One of the things that I usually do on
installations, at least in the proofing stage, is to run packet monitors
on both the outside and inside of the firewall. With a bit of data
reduction and analysis I am able to get a sense of the behaviour of the
firewall. What if we used something like this, and extended it slightly to
provide our sense of context? 

        We could monitor the packet stream at three points; 

1. At the outside of the firewall (the results of which would look much
like what a contemporary IDS would obtain), giving us a sense of the raw
data reaching the firewall.

2. Somewhere within the TCP/IP stack, at a point during the processing
that the packets have completed any modifications in order to pass them up
the stack, but before any firewall rules have been applied.

3. On the inside of the firewall, giving us a representation of the
resultant packet stream after the rules have been applied.

        The thing about this is that you get a picture of the data stream
at all stages. You can see the early warning signs of an attack from stage
1, get a picture of the data stream after reassembly at stage 2, and
finally be able to see what is making it through the firewall in stage 3.

        Individually each of these monitor points might be of limited
value, but if their datum were analyzed in context with each other would
that not be able to give us a fairly accurate picture of what is really
happening? If a reactive stance is desired then the conclusions from the 3
point analysis could be applied back to the rule-set, in either a positive
or negative feedback mode, depending on the preference.

        I realize that I am talking about adding a lot into what a
firewall is expected to do, but if the firewall were designed in a modular
sense then it should be relatively easy to add to any firewall the modules
neccesary to do the monitoring at the three stages. Designing the analysis
module would probably be more difficult, but certainly not impossible. I
think that the most difficult module to get right in a scheme like this
would be the feedback module. Considering its ability to directly affect
the operation of the firewall there would be tremendous potential for
catastrophic error. 

        Potential bottle-necking would be another possible problem, but
considering the kinds of processing power that can be had cheaply these
days a proper design should be able to avoid being a bottleneck.

        Anyways, this has been my two cents on this topic. Hopefully it
has brought up some useful points into the discussion. If not, then back
to full lurk mode I go. :-)     



-----------------------------------------------------------------
Rick Morrow, North Bay, Ontario, Canada
rmorrow () delfax net, rmorrow () onlink net
PGP Public Key: http://www.delfax.net/~rmorrow/pgp_pub.key