What to do in this situation

[Russell Fulton]

On Wed, 14 Mar 2001 18:30:09 -0500 Carter Bullard <carter at qosient.com> 
wrote:

> 
>    Why were getting to this point, I'm not quite sure, but one
> of the machines is having difficulty probably is either
> underpowered or the scheduling is terrible, as its reporting
> that its dropping ~5% of the packets on the floor.
> 
>    In the fix, I've added kill the process and wait,
> to deal with the resulting zombie, and then continue on,
> writing some strong language to syslog().

It is important to log any problem which causes us to look data or 
shutdown processed!  

> 
>    Now the question.  Should argus() exit if the problem
> output process is the one writing to the file?  If the output
> process is a network based remote access, I'd say keep going,
> but if its the file, we should exit so that we can start again
> as soon as possible.  Does this sound reasonable?

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.

Someone has written a tool (not yet publically released) called stick 
that floods the target network with packets containing attack 
signatures which will overhelm a NIDS.  ISS's realsecure IDS is reputed 
to stop dead in its tracks...

So having some generic stategy for keeping going in the face of 
resource starvation would be a neat trick if it can be done.

Definitely for 2.1 though ;-)

Russell Fulton, Computer and Network Security Officer
The University of Auckland,  New Zealand