argus-server: argus interface monitoring confusion

[Carter Bullard]

Hey Richard,
   Your example is best done with two independent
images of argus, especially from an OS perspective.

   I think that the problem is that people are not
happy with a lot of flexibility and want the software
to keep them from making dumb mistakes.  Since you
can specify multiple interfaces in configuration
files and the command line, it doesn't seem too
long of a stretch to imply the desire of the user.
Does he/she really want to open two interfaces?
If so they should explicitly declare that in a
single place, rather than putting one in one file
and having to add the second in another.


Opinions?

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: Tuesday, May 20, 2003 9:47 AM
> To: 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,
> >    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.
> 
> I still think that it might be useful to allow for 'additive' options
> between conf files, but with some restrictions.
>  
> >    Argus supports independent filters per interface,
> > but only one filter per interface.  
> 
> Can anyone give me an example of how you'd do this on the 
> argus command
> line today, i.e. how would you open multiple interfaces and apply a
> different filter to each one?
> 
> > 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?
> 
> This is where some sanity-checking restrictions might be 
> imposed. In the
> case you describe, I think argus should just report an error 
> and die. Or
> if you really wanted to give the user what he asked for, then open the
> same interface twice and apply the second filter to both 
> streams. Ugh. But
> hey, that's what the user asked for -- interface options are 
> additive, so
> you should open 'both' interfaces -- and filter options are 
> not additive,
> so you should apply only the 'last' filter to the whole argus 
> instance.
> 
> >    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!!!!
> 
> Again, I think you could choose to follow one of two approaches:
> 
>  1) Declare that this is insane (violates some documented 
> restriction on
> the combining of additive options across conf files) and die with an
> error, or
> 
>  2) Give the user what he asked for: open all 3 interfaces 
> (one of them
> twice) and apply the 'last' filter to all the streams.
> 
> > What do you think?
> 
> I do like open ended questions :-) Here's an example, which I 
> think is not
> altogether unrealistic, that illustrates how one might combine both
> additive and non-additive options across multiple conf files, in a way
> that might be useful:
> 
> /etc/argus.conf:
> ARGUS_DAEMON=yes
> ARGUS_MONITOR_ID=`hostname`
> ARGUS_ACCESS_PORT=561
> ARGUS_BIND_IP=w.x.y.z
> etc.
> 
> eth1.conf:
> ARGUS_INTERFACE=eth1
> ARGUS_OUTPUT_FILE=eth1.out
> 
> eth2.conf:
> ARGUS_INTERFACE=eth2
> ARGUS_OUTPUT_FILE=eth2.out
> 
> Then run argus as follows:
> 
>  argus -F /etc/argus.conf -F eth1.conf -F eth2.conf
> 
> The "desire" here would be to have a single instance of argus open two
> interfaces, and record all flows seen on the first interface 
> in one file,
> and all flows seen on the second interface into a different file. Does
> this make sense? Or should argus record all flows from both 
> interfaces to
> both files? Whatever it is that argus should do, could you 
> get the same
> behavior using -i,-w options, e.g. as follows?
> 
>  argus -F /etc/argus.conf -i eth1 -w eth1.out -i eth2 -w eth2.out
> 
> Now, what would happen if you added filter expressions to the 
> conf files,
> for example:
> 
> eth1.conf:
> ARGUS_INTERFACE=eth1
> ARGUS_OUTPUT_FILE=eth1-telnet.out
> ARGUS_FILTER="tcp and dst port 23"
> 
> eth2.conf:
> ARGUS_INTERFACE=eth2
> ARGUS_OUTPUT_FILE=eth2-smtp.out
> ARGUS_FILTER="tcp and dst port 25"
> 
> I think the "desired" outcome here is clear, but should argus 
> really apply
> each filter separately to each interface? Or just use the 
> 'last' filter on
> both interfaces?  Is it even possible to document the syntax 
> and semantics
> of this kind of conf file combinatorics in a way that people 
> can actually
> use without getting led astray?
> 
> Although I think there may(?) be some utility in being able to use
> settings from multiple conf files, it's not indispensable if 
> you can get
> the same results using -r,-w,-i options (and filter 
> expressions?) on the
> command line. And I can see where unrestricted combining of conf files
> would open some cans of worms, and might lead down the path 
> towards the
> kind of confusion we wish to avoid in the first place.
> 
> Perhaps the only 'simple' way to avoid these problems is to 
> declare that
> you can use one and only one -F argument with any argus instance, i.e.
> argus can read no more than one conf file, or argus will ignore all -F
> options except the last. The concept of having a 'base' 
> config file like 
> /etc/argus.conf would be history.
> 
> What's the alternative? Don't allow additive directives 
> within conf files?  
> Or allow them, but somehow isolate their effects from each other?
> 
> Sorry I seem to have more questions than answers...
> 
> Thanks,
> Richard
> 
>