What to do in this situation

[Chris Newton]

This sounds great Carter.  An implementation like this, will keep Argus alive 
as long as possible, meaning usable output for determining 'what happened'.

  I have used other flow generators (I moved from them, to Argus), and some of 
them made no allowances for times when there was just 'way too much traffic' 
to deal with.  They'd swallow memory, gulping up packets, and then eventually 
crash.  Not useful if you are trying to provide solutions to DoS attacks, when 
those very attacks take out your solution :)

  For my purposes (and everyone's I suspect), it is best that Argus stays 
alive at all costs, even if the value of what it is reporting lowers 
significantly (just reporting bytes/packets/protocol type, or other basic 
components of the traffic).  Good reporting from Argus that it starting to 
have problems, and/or when it starts to transition flow models, would round 
the whole thing out.

Thanks, sounds like a great idea.

Chris

>===== Original Message From <carter at qosient.com> =====
>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
>>
>>

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

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