Re: Recording slow scans

[Darren Reed <darrenr () reed wattle id au>]

In some email I received from Crispin Cowan, sie wrote:
> Darren Reed wrote:
>
> > (2) significant kernel bloat and subsequent requirements for machines;
>
> True ... so make the IDS enhancement modular, so it can be left out.

Have a look at what RealSecure (ISS's offering) requires on NT4.0:
200MHz Pentium, 128MB+ RAM, etc.  From observing it run, it doesn't
appear to be "because it's NT".  I assume it is from it keeping a
large amount of data about connections past and present "in core".
In a worst case scenario, you need 1MB of memory for each second of
raw data you want to keep "in core" for a system attached to ethernet.
Do you need it all ?  Maybe.  Are most systems likely to be running at
ethernet speed ?  Depends on your IDS placement.  If it's outside
your firewall but not between your DMZ and internal network, then someone
may compromise your DMZ using a "new" attack method and launch a full
scale attack on internal systems at ethernet or fast ethernet or ATM, etc,
and go un noticed.  Now if you want to detect those attacks too, your
requirements for the IDS system suddently become something like (if not
worse than) the above.

The point I was making with (2) is that it isn't (yet) suitable to make
IDS part of what goes on every desktop.

> > (3) all IDS solutions are part-kernel, part-user programs;
>
> Counter-example:  Tripwire.  Slow IDS, no kernel mods required.

Last time I checked Tripwire didn't examine IP packets, but it's
been a while since I looked.  IDS products as have been refered to
in this thread has not, I presume, been about this class of product.

Then again, since tripwire needs to be on a host which is compromised
before it works it is not beyond probability to defeat tripwire (however,
this is somewhat dependant on the system configuration).

Darren