argus-server: argus interface monitoring confusion

[Carter Bullard]

Hey Richard,
   Well you raise an interesting question about filters
and interfaces that makes it even more complex, which
suggests that we should not support additive objects
between configuration files.

   Argus supports independent filters per interface,
but only one filter per interface.  What if
conf1 specifies interface eth0 and filter f1, and
conf2 specifies the same interface, but a different
filter, f2.  Should argus attempt to use both filters
on the same interface?  Combining filters is somewhat
tricky, should it be "and"d or "or"d to get the desired
effect?

   And of course the worst scenario is conf1 specifies
2 interfaces and one filter, and conf2 specifies 2
interfaces, with one overlapping with conf1, but with
different filters.  What should the user expect?  Seems
like a good opportunity to punt!!!!

What do you think?

Carter


> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu 
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of 
> Richard Gadsden
> Sent: Monday, May 19, 2003 2:29 PM
> To: Carter Bullard
> Cc: argus-info at lists.andrew.cmu.edu
> Subject: RE: argus-server: argus interface monitoring confusion
> 
> 
> On Mon, 19 May 2003, Carter Bullard wrote:
> 
> > Hey Richard,
> >    Ok, I've got almost all of the changes for
> > the configuration file and command line option
> > changes finished.  Here is a situation where I'd
> > like to know what the user should expect.
> > 
> > In this example, each configuration file specifies
> > a different interface to open:
> > 
> >    argus -F conf1 -F conf2
> > 
> > what should we expect?  The new argus will not
> > open /etc/argus.conf (-F options present), open
> > conf1 and conf2 and process them in that order.
> > If either don't exist we fail.  With regard to
> > the interfaces, we'll only open the interface
> > specified in conf2.
> 
> Hmmm, I think in this situation you'd want to open both the 
> interface(s)  
> in conf1 and the interface(s) in conf2. That would seem to be the most
> useful behavior, otherwise wouldn't you lose the ability to 
> get 'additive'
> behavior from configuration files?
> 
> For example, if conf1 contains ARGUS_INTERFACE=eth1 and conf2 contains
> ARGUS_INTERFACE=eth2, then it seems most natural to me that 
> argus should
> open both eth1 and eth2, to remain faithful to the inherently additive
> nature of the ARGUS_INTERFACE option.
> 
> The order of processing config files should matter for non-additive
> options like ARGUS_FILTER, but for additive options like 
> ARGUS_INTERFACE
> and ARGUS_OUTPUT_FILE, order should not matter, and these 
> options should
> still behave additively even if read from multiple config files.
> 
> > Last example is:
> > 
> >    argus -i eth0 -F conf1 -i eth1 -F conf2 -i eth3
> > 
> > Same behavior as above with regard to config files,
> > where are processed first.  After conf2 is read,
> > we'll start processing the -i options, and we'll
> > only open eth[1-3].
> > 
> > Is that appropriate?
> 
> Yes, I think this would make the most sense, following the 
> convention that
> any options which are explicitly given on the command line 
> should override
> options specified in configuration file(s).
> 
> Thanks,
> Richard
> 
>