TrustedBSD Extensions Project

[Andrew Alston]

>> IDS is a relatively new field; that said, I think automatic processing of
>> event audit data is a natural fit with a trusted operating system.

> Again, I'm not questioning the validity of the concept of IDS and
> usefulness of an IDS.  But Orange Book doesn't require it.

Hi All, I guess its time I made some contribution here with regards to IDS.

If we are planning to implement intrusion detection systems under Trusted
BSD, I MAY have code that I can modify to place into the kernel's ip stack
that is code Ive been working on now as a company project for the last few
months.  The code is intrustion detection code, that basically processes
packets real time.

Currently the system is implemented under freebsd, and uses a threaded
daemon that gets its data from a raw divert socket.  
I push the data to a divert socket using freebsd 4's ipfw tee command with
slight modifications to make the tee command function properly (My thanks to
Luigi for the ipfw tee fix).

At current the daemon runs passively, only analyzing and not responding.


The daemon then analyzes a number of things...

A.) It does portscan checks based on configurable trigger values
B.) It does ICMP Denial of service checks based again on configurable
trigger values
C.) It has a VERY large section of code which does RFC Compliancy checks for
about 80 protocols at current, more coming, analyzing each packet and
actually assembling the streams into something it can read, and then
checking the data to see if what is coming into the server is valid, and
that strings that are coming in are correct length etc.
D.) It does exploit signaturing against a configurable database of generic
exploit code

Im wondering if this code could be streamlined enough and hacked enough to
actually fit into the kernels ip stack, with an interface similar to
freebsd's ipfw to configure and manage it as it runs.  

The disadvantage of the system running in an active manner and having the
IDS system directly in the ip stack is that we may be looking at some
performance loss on the ip stack, where as at the moment because its running
as a userland daemon and being fed by ipfw tee that does not actually
"process" the packets there is little to no performance loss on the system,
though I must say when running at 10mbit at flat out speed with the daemon
enabled it is eating a fair amount of CPU power to do the packet processing.


The code is currently still in alpha testing and is not yet ready for
release, but I will be releasing a userland mode version within a week or 2.

Im quite prepared to try and hack this into the IP stack as an IDS option
for TBSD if anyone is interested.  Let me know


Thanks

Andrew Alston
Citec Network Securities (Director)
Phone: +27 11 787 4241
Fax: +27 11 787 4259
Email: andrew at cnsec.co.za
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message