Messages in this thread | | | Date | Sat, 22 Jul 2000 14:54:08 -0700 | From | mht@clark ... | Subject | Re: IDS: kernel implementations |
| |
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/
| |