What to do in this situation

[Carter Bullard]

Hey Guys,
   Argus does have the hooks to change its fixed flow model
on the fly, but coming up with a set of transition models and
strategies will be interesting.  Here are some thoughts.

My goal with Argus is to, above all else, account for all the
packets that it receives, into some flow model.  If we transition,
there are a number of things we can do, and they really represent
turning off features by going down the "stack".

First we can turnoff application data processing.  This is
memory copy intensive when we have a large number of flows.

The second is to turn off TCP specific processing, such as
packet loss detection, and jitter measurements.  These will
immediately decrease the size of output records.
They will not decrease the number of output records, but it
will give you more cycles, which may free up the bottleneck.

To decrease record generation, you can increase the status
interval timer, but this won't have much of an effect in DOS
attacks as the attack will be to generate a flow per packet.
To counter this, we would want to systematically change our
flow model.  See http://qosient.com/argus/flow.htm for a definition
of what flow models argus is using by default.

The first thing to do is to go to a strict 3 tuple model, where
we are tracking by Src and Dst IP addrs and protocol.  Then
to a two tuple model, and then to a zero tuple model, where
all packets go into one flow.

The triggers will be interesting, but changing the model on
the fly is easy.

One thing to watch though.  When you change the model, you will
generate new flows, and the old flows will still be in the
flow cache.  That's why I call it flow model transition.  You'll
want to accelerate dumping flows, while you are building your
new flow model cache.

How's that?  This is definitely argus-2.0.1 work ;o)

Carter


Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

> -----Original Message-----
> From: Scott A. McIntyre [mailto:scott at xs4all.nl]
> Sent: Thursday, March 15, 2001 12:36 PM
> To: Chris Newton
> Cc: Carter Bullard; argus; Peter Van Epp
> Subject: Re: What to do in this situation
> 
> 
> Hi,
> 
> (Gosh, something from me that isn't a crash report....)
> 
> > I like this idea as well.  What I am working on, partially 
> has to do with DoS 
> > attacks, and though I know there will be times when a 
> machine/argus just can't 
> > keep up to the traffic levels, it should try veyr hard at 
> warning someone 
> > real, about the problem.  So, I like the graduated warning 
> when argus is 
> > nearing it's limits.  I also like the idea of a 'last ditch 
> effort', where 
> 
> This begs the question, is it possible to have argus have a "traffic
> threshold" for reporting any one flow type?   This would dramatically
> reduce the load on a machine.
> 
> Perhaps this is difficult to implement however.  
> 
> What I have in mind is specifying a maximum number of packets or bytes
> between any two points (src, dst, sport, dport, whatever); beyond that
> amount information alerting that the threshold has been exceeded is
> logged, but no more data will be recorded for T timeticks (variable).
> 
> Dynamic filters, in other words.
> 
> (I think I just heard Carter groan)
> 
> Scott
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20010315/59277ff1/attachment.html>