What to do in this situation

[Carter Bullard]

Hey Russell,
   Well, I don't have any problems with throwing queued records
away rather than shutting down the facility.   I think that
the key to dealing with an attacker is to take away the ability
to deterministically hide his/her tracks, with great emphasis
on the word deterministically.

   I think a successful strategy would be to throw away small
numbers of records from the front of the queue, if the queue
is actually getting records out, each time.  If not, then you
have a problem where you probably need to go to sleep for a short
while to give the other process a chance to service the queue.
Both of these tactics would generate a kind of random discard,
one on output records, the other on input packets.  The
attacker would have to deal with the statistical behavior
of the monitor under load, so completely hiding would be a
statistical challenge.

   What do you think?  And yes it should be a task for
at least argus-2.0.1 ;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-----
[snip]
> 
> Hmmm... how about flushing the buffer and dumping a message to syslog 
> then waiting configurable length of time before trying again?
> 
> What we did with Netramet was to allow one to define a fallback rule 
> set which would generate fewer flows (our standard accounting 
> rule set 
> drops all external i.e. non 130.216/16 addresses, thus cutting the 
> number of flows dramatically).  You can also specify high and 
> low water 
> marks for memory usage that contol when netramet will switch between 
> its normal and backup rulesets and vice versa.
> 
> This model does not fit argus all that well but I wonder if in the 
> longer term we could do something like this.
> 
> My worry is that a smart attacker who knows we are running argus will 
> flood the network with something that will overwhelm argus 
> and cause it 
> to stop logging to disk before launching his/her real attack. 
>  A flood 
> of tiny disjoint fragments with random addresses springs to 
> mind.  Each 
> would be a separate flow that would need to be timed out.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20010314/45304e36/attachment.html>