Argus tweaking and design considerations

[Chris Newton]

>===== Original Message From Peter Van Epp <vanepp at sfu.ca> =====
>>
>> Argus tweaking and design considerationsMy comments mirror Peter's..
>>
>> I think we should optimize for performance to get as much through as
>> possible.
>> Once we exceed maximum performance, it would be good to degrade as
>> gracefully as possible, but I think we should prefer beefier/specialized
>> hardware
>> to overflow handling that produces suboptimal results anyway. I think that
>> accuracy is *highly* important, up to the maximum data flow possible.
>
>	One thing on my (infinitely long :-)) list of interesting things to
>poke at is an open source embedded OS that was mentioned in Circuit Cellar 
Inc
>magazine. It runs an "optimised for performance" version of the 
FreeBSD/BSD4.4
>IP stack and would probably make a good base for a dedicated sensor such as
>has been discussed on the NFR list (bootable from CDrom, everything in memory
>no file system per se, grabs packets, processes them in a way requested by
>an external managment machine and forwards them (or the interesting parts of
>them) out a link to the machine that deals with the exceptions. In the argus
>case, it would aggregate the flows and shove only updates toward the 
management
>reporting station. In the IDS case I'd see something like VJ header 
prediction
>which strips uninteresting (i.e. expected headers) and only forwards as much
>of the recovered data as the management station wants, but also forwards
>unexpected header values (i.e. ones that don't match the forward prediction)
>as being a possible attack. Fragments with different offsets would be one
>case of this, unused flag bits changing state would be another). The 
advantage
>is that you can limit the amount of processing you need to do at wire speed.
>In this case you add in the mininum number of tasks needed to do your
>processing without any of the general purpose support a full OS needs (which
>is both overkill and overhead in this application). There is a port that
>runs on PC hardware (for easy development) but it can be ported to custom
>hardware (possibly required for the level of perfomance we are starting to
>talk about i.e. multistreams of DWDM on fibre).
>	The first step in this is to do what I started out to do and
>characterize what load a given CPU/motherboard chipset/interface 
card/operating
>system configuration will handle with argus which tells us were we are
>compared to where we want to be (and what the bottlenecks are to getting 
there).



  Grat idea Peter.  I'd be very interested in working on a project related to 
this if you/'a team' start down this road.  I might even (if we get our 
project funded), eventually have man power to throw at such a thing.


Chris

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Chris Newton, Systems Analyst
Computing Services, University of New Brunswick
newton at unb.ca 506-447-3212(voice) 506-453-3590(fax)