Re: IDS: kernel implementations

From: Yoann Vandoorselaere (yoann@mandrakesoft.com)
Date: Sat Jul 22 2000 - 17:43:01 EST


mht@clark.net writes:

> It is not about the kernel, it is more about how to read in
> permiscious mode directly from the network interface card.

Your OS is here to let you interface with any kind of network
card it support...

Talking directly with the network seem to me the wrong thing
to do... And even if it is not, you'll duplicate kernel work
doing this that way, thus, lost of CPU time.

> The other
> issue is being abale to analyze and figure very quickly what type of
> traffic it is.

You have no choise but looking at the packet.

> 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.

You can not discard any traffic.
A general purpose network IDS must look at all kind of packet,
searching, for exemple, suspect string...
You can't even say that your IDS must not analyze your internal
network, because internal security is an issue.

> (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

That is easily detected by an host based IDS.

> session is sending pre-attack probes to some IDS company in Atlanta.

That is network IDS job.

> 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.

The system administrator must do the correlation, that's not up to
the IDS.

> Using a
> kernel based type system still will not provide the solution to the
> issue.

You misunderstood me :
I'm not talking about using a kernel based IDS ( userspace is the place
for IDS ), i'm talking about using netfilter (which is kernel) to get
packet in order to avoid duplicating kernel work ( avoiding having the
IDS defragmenting IP fragmented packet, which the kernel already does ).

As i've already said, Netfilter allow you to plug to hook in the tcp/ip
stack, so for exemple, your IDS could plug before & after the
ip defragmentation part.

Unfortunnelly, what is currently lacking to Netfilter in order for IDS
to do that is the ability to caught promiscuous received packet.

> 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.. :)

For many kind of attack detection, there is always a small amount
of speculations.

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

read above.

-- 
		-- 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