Re: IDS: kernel implementations

From: mht@clark.net
Date: Sat Jul 22 2000 - 16:54:08 EST


It is not about the kernel, it is more about how to read in permiscious
mode directly from the network interface card. The other issue is being
abale to analyze and figure very quickly what type of traffic it is. So a
little AI should be wrapped around so that a IDS is able to figure out
whether it is normal traffic discard it, and only look for the anomalous
stuff. (i.e. James Bohem of so and so company normally logs in from 9 to 5,
strange for the last two days, there has been multiple login accounts on
his account at 3am and that session is sending pre-attack probes to some
IDS company in Atlanta. OK.. So that is pretty easy to figure out, ok
let's then go back to the normal day, when so and so has a couple or so
logins here and there, and some login portscanning some poor site.. OK,
most IDS do not have the correlation logic to put two and two
together. Using a kernel based type system still will not provide the
solution to the issue. The issue is more of understanding the patterns of
behavior and being able to capture and analyze the traffic with the least
amount of guessing thus reducing the load on the correlation and event
notification.. :)

The technology is there, it is the implementation of the technology that is
very confusing to people :)

/m

At 11:07 PM 7/22/00 +0200, Yoann Vandoorselaere wrote:
>mht@CLARK.NET writes:
>
> > Not quite. NFR has the same type of issues as their competitors do. None
> > of the current IDS applications are capable of handling a large amount of
> > packets (i.e. 1,000,000 jolt2 attacks).
>
>Using Netfilter (under Linux), would avoid many IDS to duplicate
>kernel work :
>
>for exemple it would avoid defragmenting IP packet.
>
>Actually, the only problem with Netfilter is that it
>automatically discard promiscuous received packet,
>which is bad for whole network based IDS.
>
>To quote the Netfilter hacking howto :
>
><snip>
>
>On the left is where packets come in: having passed the simple sanity
>checks (i.e., not truncated, IP checksum OK, not a promiscuous receive),
>they are passed to the netfilter framework's NF_IP_PRE_ROUTING [1] hook.
>
></snip>
>
>If Netfilter hook could be a little bit more fine grained (for exemple
>implementing a hook in order to get packet promiscuous received),
>could be a big advantage for things like network IDS...
>
>If that is done, network IDS will only have to defragment promiscuous
>received fragmented packet, which would be a big gain.
>
>Anyway, your IDS is also limited to the way your operating system
>handle packet... if it is vulnerable to an attack like jolt2, your
>IDS will also suffer of it.
>
>
>Ps : i've CC'd this message to lkml & Rusty because i thought
> netfilter kernel hacker could comment on the subject.
>
>--
> -- Yoann http://www.mandrakesoft.com/~yoann/
> It is well known that M$ product don't make a free() after a malloc(),
>the unix community wish them good luck for their future development.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:19 EST