Argus 2.0 wishes

[Peter Van Epp]

> > 	Or as a network tool that runs on a stripped down box that really isn't
> > Unix anymore (since Argus is really mostly a state machine that understands
> > the network).
> 
> Hmmmm... we still maintain a DOS version of NeTraMet, it's got all the 
> packet capture code...  Also there is Trinux ( http://www.trinux.org/ )
> which would be a lot more straight forward.
>
	I was actually looking at the example code done in the Circuit Cellar
Inc magazine intended for the embedded market. They started with protected
mode boot code (creating gdts and all those lovely Intelisms) and as I recall
moved up to stubs or perhaps an interrupt driven serial driver. Its not clear
to me that we are going to be able to even use C until we are at the TCP
processing stage, I suspect performance will require assembly at the bottom 
end. I'm presently researching speeds in preparation for a presentation on what
kinds of performance issues are going to leap out and bite the unwary (for 
sure TCP window starvation MTU size, hardware speed issues such as disk speeds
and latency) as we implement CA*net3 at a gigabit in the wide area. Because as 
well as the Universities (who have been bitten before) the research network is 
going to extend to local hospitals (who probably haven't). As part of that I 
looked at my new ASUS motherboard which claims to be able to do a gigabyte per 
second to memory. Then I looked at the real specs for a DIMM: 80 nsec cycle 
time for 8 bytes of data i.e. around 100 Mbytes per second. At full speed 
gigether you can just (maybe) get the data to memory, once (no copies).  Now 
I'm looking for a motherboard that has interleaved memory. At gig speeds I 
think we are going to have to dedicate a page to a packet (or possibly packets 
in the same stream to conserve memory) and then do "copies" by manipulating 
the page tables rather than trying physical copies. The alternative would be 
to build our own hardware with static ram, but I doubt thats viable. It is 
going to be exciting finding the bandwith to even get the packets out a second 
interface to get to an analysis machine. The saving grace being that we likely 
don't have any hardware that can fill a gig pipe, so likely we only have to be 
able to deal with routers that will puff up their cheeks and spit a stream out 
at wire speed for a few packets. Of course that same router can aggregate a 
bunch of 100 meg streams (which we probably can create) and do pretty close
to filling the wire as well. The machines I know of that can deal with this
(i.e. big SGIs) are a little too expensive for IDS systems ...
	All that said, I'm not sure that snort isn't the appropriate place to
devote the IDS effort and leave Argus as it stands as an auditing tool that 
does a different (but equally needed) job of allowing for long term logging
in affordable disk space rather than try and make it do both (with the 
possibility of doing neither well). There looks to be a lot of open source 
interest (and thus lots of bodies with knowledge and time) working on snort 
from what little I've seen.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada