Preliminary release of my perl scripts for argus-2.0

[Russell Fulton]

On Wed, 17 Jan 2001 09:42:29 -0500 Carter Bullard <carter at qosient.com> 
w> Hey Russell,
>    Sorry for the delay at looking at your stuff %^o
> 
> OK for specifics in getting your package to run.  There
> are some modules that a plain perl5 Linux installation
> will need, DateManip and libnet-1.0703.  Seems that RH 7.0
> doesn't have all the libnet modules installed.  These two
> will complete the perl5 modules that are needed.

I did mention in the notes (which will become a readme) that these CPAN 
mudules would be needed.  I'll make that more prominent.

> 
> After that running the scripts plain out of the box generates
> errors for look_for and watcher.  scan_watch is well behaved
> but of course generates no output.
> 
>    I'm getting this when I run 'look_for' on one of my data
> directories.  I haven't dived into the Argus::Archive library
> but it seems to be a problem there.  My data directory is
> not the same format as your, so consider this just simple
> runtime testing.

I obviously did not explain things in my note well enough.
I.e I need some explict install instructions.

1/ make sure you have Date::Manip and Libnet installed,
2/ modify Archive.pl to match your archive structure.

> 
> .% /look_for -D ~argus/data
> defined(@array) is deprecated at ./look_for line 50.

Ok, I'll fix that.  You have a newer version of Perl.

> 	(Maybe you should just omit the defined()?)

Yup, it is redundant, but should not stop things running.

> Use of uninitialized value in string at ./look_for line 51.
> Died at ./look_for line 51.

Hmmm, likely consequence of not having found any directory. I'll look 
at it and make it print a sensible error message.

> 
>    Watcher () is having a bunch of problems, mostly because
> of the paths in Argus.pm.
> 
>    We'll need to come to some concensus as to what we want
> these entries to be, such as variable names, location of
> scripts and the like.  None of these are problems, we just need
> to come to agreement.
> 
>     For instance, could we use the $ARGUSHOME environment
> variable for some of this?  That way we get people to actually
> set the variable and take advantage of the features.  Also,
> can we use $ARGUSPATH, for some of the path issues in some
> of your perl scripts?  argus and ra look for these environment
> variable, so we can put them in the documentation and start
> to rely on them.  That may solve some problems.

OK, I'll look at using the enviroment vars.

I already have perl variables that correspond to these and if they 
don't exist I will default to $ArgusHome $ENV{HOME} and Path to
$ArgusHome/bin:$ArgusHome/lib

It would be good if make install put the files in the right place too.

> 
>    Scan_watch is looking for archive files in a particular 
format.
> I have a script, mvargusdata.sh, in the ./examples/bin directory
> that generates archive files with a different naming scheme
> than yours.  It would be nice if we could be consistent between
> tools.   The script generates an archive filestructure with
> this name convention:
> 
>     yyyy/mm/dd/argus.yyyy.mm.dd.hh.mm.ss.gz

Hmmm... I've got 3 years data archive under my scheme and I bet most 
others have their own schemes that they are more or less wedded to.
That's why I wrote the Archive.pl module to isolate all the access 
code. 

That said, I think it would be a good idea if we promoted a 'standard' 
and certainly all tools distributed with argus should agree on the 
format.  I'll modify the distributed copy of Archive.pl to use the 
above format and ship Carter a copy (I assume that you have some 
archived data ;-). I'll try and do that today -- I've been flat out 
recently have had as many compromised (4) over last weekend as we had 
in the whole of last year :-( including a worm that spread via ftp.

Using the argus logs you could see the initial probe, banner grab, 
compromise, download of root kit and scanner starting, all in 100 
seconds elasped time.  Shit! 

> 
> It would be great if we had some consistency between tools.

Agreed. But they should also be easy to adjust to other enviroments.


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