argus-server: argus interface monitoring confusion

[Richard Gadsden]

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