OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: IDS: kernel implementations
From: drellisus.ibm.com
Date: Fri Jul 21 2000 - 08:24:15 CDT

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owneruow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
-----------------------------------------------------------------------------

     What kind of bandwidth can you successfully monitor? Most sniffers
start failing between 20 and 30 Mpbs.

     I also am somewhat wary of the idea of passing pointers around from
the NIC memory to user space. I only see that working if this IDS is a
network-based IDS running on a dedicated system.

     Although most IDSs started off as host-based and then migrated to
network-based, I now think that there is going to have to be a greater
focus on host-based IDSs. The reasons for that were put forth effectively
by Ptacek and Newsham in:
http://members.home.net/razvan.peteanu
A host-based IDS can effectively avoid all of these problems because the
IDS sees exactly what the kernel sees, and is therefore not duped by the
same classes of attack. Since it is a host-based system that needs to see
exactly what the kernel sees, and we are worried about performance, why not
put the host-based IDS right into the kernel? The reason: questions of how
much the internal IDS will impact performance on that host. (Obviously a
host-basd system that monitors only itself and is unable to run anything
besides the kernel is a waste.)

John S Flowers <jflowershiverworld.com> on 07/21/2000 12:54:00 AM

To: Daniel R Ellis/Austin/IBMIBMUS
cc: idsuow.edu.au
Subject: Re: IDS: kernel implementations

At Hiverworld, we're actively working with the OpenBSD team and have
added in kernel support for a Bpf function (called HwBpf) that does
packet filtering in the OpenBSD kernel.

We're also doing some neat tricks to expose the in kernel memory map to
the userland process, which basically means we're sending packet
information (in the form of pointers to structures) directly from the
NIC to a memory segment mapped to userland.

This has proven to be quite useful and is allowing us to achieve
considerable speed beyond the normal libpcap style of performing bpf
calls.

I'm not sure if we're going to release this code back to the OpenBSD
kernel sources, as there's a huge dependency on our own foundation
classes, but we're tossing the idea around and may end up making our
OpenBSD changes publicly available.

In the meantime, you'll have to wait for our IDS solution to be
available before you see a product that uses this technology.

Alternately, I believe there's a Linux based IDS solution called LIDS
that does some of this, but they aren't achieving anywhere near the
speeds we're getting with our OpenBSD modifications.

drellisus.ibm.com wrote:
>
> Archive: http://msgs.securepoint.com/ids
> FAQ: http://www.ticm.com/kb/faq/idsfaq.html
> IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
> HELP: Having problems... email questions to ids-owneruow.edu.au
> NOTE: Remove this section from reply msgs otherwise the msg will bounce.
> SPAM: DO NOT send unsolicted mail to this list.
> UNSUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
>
-----------------------------------------------------------------------------

>
> All of the applications (and research) that I have seen have put ID
in
> a user-level application. Has anybody looked into including ID
> functionality in the kernel?
> _______________
> Dan Ellis
> UC Santa Barbara
> ellisdcs.ucsb.edu
>
> Carpe Diem 

--
John S Flowers                   <jflowershiverworld.com>
Core R&D                         http://www.hiverworld.com
Hiverworld, Inc.       Continuous Adaptive Risk Management