Carter Bullard | 15 Sep 16:34 1999

Argus 1.8 Code Freeze Tarfile

Gentle people,
   Here is the Argus-1.8 code release tarfile.
The work that still needs to be done is to merge
the CMU configure strategy and to update the documentation,
which includes man pages for the new clients.  Notice that
I renamed most of the clients to put ra at the beginning of
all the names.  This helped me to remove and copy so, if
that causes problems, please yell!!!

I still have some client testing to do, but ra(), racount(),
rasort(), raservices(), radjaceny(), radnstats() and ratemplate()
should be good to go.  Basically that just leaves raconnections().

   I believe that we deal with all the known bugs here,
and so please feel free to prove me wrong, if possible ;o)

Best Regards,

Carter



begin 600 argus-1.8.tar.gz
M'XL("'>MWS<``V%R9W5S+3$N."YT87(`[+UK8]LVLC"\7Z-? <at> :A.+#F2+#F.
MD]AU3A5;273JV%[+:=,39U5:HFQN)%(5*5^VR?GM[UP`$.!%E]3M[GG>>+<1
M"0*#P6`P&`P& <at> ]JZ,[F8AM5&[=GZW_ZDOWI]L_[TZ=._U1M;3QJ;C? <at> W_OM;
M?>OIUM.G&UN;3S&]\?C)TR=_>_)G(63^3</(F4"5?G`>]&_S\\W[CJW8:#R1
MC7IZ]XC^.7\UH_][ <at> 3_P+J83]X[KJ#>`($^>9/=_X^G3K2WJ__J3S<;F)O)"
MO?%D\RG\WC$>F7__/^__[^Z+]7//7P\O"X7OQ.NI&X;BRAG"KQ <at> $$Q'>AI$[
MJO;=L>OW73^";Q//.1_"9\?OB][$=2)7O'4^N0,/$FL(P_7=":3VA3.- <at> I$3
(Continue reading)

Carter Bullard | 16 Sep 15:17 1999

RE: Argus 1.8 Code Freeze Tarfile

Hey Peter,
So much for the code freeze %^}  You are right, but the topic
brings up an old dicussion as to what the signals should do.
Right now we catch them all and exit.

Chas wanted the ability to get an instantaneous report on
packets/flows for a ra() that is persistent and writing
output to a file.  This would be a good opportunity to
define what we want signals to do.

SIGINT would be a good one for the periodic report, if the
client supports it.  SIGQUIT and SIGKILL seem like they
should cause the client to exit().

Opinions are needed quickly, as I will be closing this up
soon.

Thanks again!!!

Carter

-----Original Message-----
From: Peter Van Epp [mailto:vanepp <at> sfu.ca]
Sent: Wednesday, September 15, 1999 6:33 PM
To: Carter Bullard
Subject: Re: Argus 1.8 Code Freeze Tarfile

> 
> Gentle people,
>    Here is the Argus-1.8 code release tarfile.
(Continue reading)

Peter Van Epp | 16 Sep 16:23 1999
Picon
Picon

Re: Argus 1.8 Code Freeze Tarfile (fwd)

> 
> Hey Peter,
> So much for the code freeze %^}  You are right, but the topic
> brings up an old dicussion as to what the signals should do.
> Right now we catch them all and exit.
> 
> Chas wanted the ability to get an instantaneous report on
> packets/flows for a ra() that is persistent and writing
> output to a file.  This would be a good opportunity to
> define what we want signals to do.
> 
> SIGINT would be a good one for the periodic report, if the
> client supports it.  SIGQUIT and SIGKILL seem like they
> should cause the client to exit().

	This sounds like a reasonable compromise. You might want to alias 
user1 and user2 for the periodic report too (I don't know how you generate
one or if you can from the keyboard). I was looking at the SYSV (Solaris) vs
FreeBSD man pages and signal action is different. It looks like Solaris will
take the default action (which would be exit in this case) but FreeBSD will
return from the signal (which is what it is doing) and I don't see an obvious
way to convince it to exit instead.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

Russell Fulton | 16 Sep 23:57 1999
Picon
Picon

Re: Argus 1.8 Code Freeze Tarfile (fwd)


On Thu, 16 Sep 1999 07:23:07 -0700 (PDT) Peter Van Epp <vanepp <at> sfu.ca> 
wrote:

> 
> 	This sounds like a reasonable compromise. You might want to alias 
> user1 and user2 for the periodic report too (I don't know how you generate
> one or if you can from the keyboard).

kill -USR1 <pid>

 I was looking at the SYSV (Solaris) vs
> FreeBSD man pages and signal action is different. It looks like Solaris will
> take the default action (which would be exit in this case) but FreeBSD will
> return from the signal (which is what it is doing) and I don't see an obvious
> way to convince it to exit instead.
> 

There are at least two major models of signal handling from what I 
remember (BSD and Sys V) now Posix have added another layer.  When 
investigating things for NeTraMet Project a while back I decided to 
follow POSIX since most systems offer some form of POSIX compatibility 
mode.

Again with the NeTraMet project I developed a configuation parser which 
set default configurations for NeTraMet and NeMaC. With NeMaC there 
were several functions that you could tie to signals and my 
configuration file allowed you to say things like:

Signal USR1 reload_ruleset.
(Continue reading)

Mark Poepping | 21 Sep 15:24 1999
Picon

FW: compile errors


just forwarding some further notes for the archive..
I think all of these had been reported before.  We're
closing in on the next snapshot..  then we'll be rid
of the fds-bits thing:-)..
mark.

> -----Original Message-----
> From: Tony Schliesser [mailto:aschlies <at> ezwv.com]
> Sent: Tuesday, September 21, 1999 8:31 AM
> To: Mark Poepping
> Subject: Re: compile errors
>
>
> Also, in tcp_wrapper.c, had to change the include for tcp.h to:
> #include <tcp.h>
>
> and change the server directory makefile to change the path for libwrap.a
> and libpcap (lines 79 and 80) to point to /usr/lib/ instead default. Don't
> know why the default did not work as the path was valid.  I don't
> guarantee
> that this was not addressed in the docs :)
>
> Anyhow, some feedback for you -- its compiled and working.
> ----- Original Message -----
> From: Mark Poepping <poepping <at> cmu.edu>
> To: Tony Schliesser <aschlies <at> ezwv.com>
> Cc: <argus <at> sei.cmu.edu>
> Sent: Tuesday, September 21, 1999 12:14 AM
> Subject: RE: compile errors
(Continue reading)

Russell Fulton | 23 Sep 06:23 1999
Picon
Picon

Time stamps in argus records

HI All,
	A quick query about the argus time stamps: I had assumed that 
for tcp traffic the start time was the start time for the session as a 
whole but on examining real output from ra I see I am clearly mistaken.

So, what are the start and last times?  Presumably the times for this 
particular argus record.

I was looking for a way of detecting long running tcp sessions without 
going to the bother of maintaining state info in the script which 
postprocessed the ra output.  I thought, that's easy just use -g but 
the longest time I got was aprox 2 minute.  Then I had a look at the ra 
times for the sessions and realised they incremented each record. 

Sigh...

Russell.

Carter Bullard | 23 Sep 17:23 1999

RE: Time stamps in argus records

Hey Russell,
   Combining multiple Argus records that belong to the same flow
is done with raconnections().  Feed a days worth of  argus records
into raconnections() and you should get single records for single
connections with the start and last timestamps correct.

Carter

> -----Original Message-----
> From: Russell Fulton [mailto:r.fulton <at> auckland.ac.nz]
> Sent: Thursday, September 23, 1999 12:24 AM
> To: argus <at> lists.andrew.cmu.edu
> Subject: Time stamps in argus records
> 
> 
> HI All,
> 	A quick query about the argus time stamps: I had assumed that 
> for tcp traffic the start time was the start time for the 
> session as a 
> whole but on examining real output from ra I see I am clearly 
> mistaken.
> 
> So, what are the start and last times?  Presumably the times for this 
> particular argus record.
> 
> I was looking for a way of detecting long running tcp 
> sessions without 
> going to the bother of maintaining state info in the script which 
> postprocessed the ra output.  I thought, that's easy just use -g but 
> the longest time I got was aprox 2 minute.  Then I had a look 
(Continue reading)

Alexander Bochmann | 23 Sep 20:28 1999
Picon

compiling argus on a BSDI box?

Hi,

has anyone tried to compile argus (-1.8) on a machine running BSDI 3? 

I have managed to compile at least the clients (the BSDI box here 
has the most diskspace and all the old argus data files are stored there), 
and I have encountered some minor problems (sorry, no diff's, because 
actually I have no clue about C programming and I should be preparing for 
my diploma right now instead of fiddling with software ;-) - but I have 
a short description...

include/cons_out.h:
It seems there is no struct ether_addr in netinet/if_ether.h on BSDI 3
I just added the following to cons_out.h:

#if defined(bsdi)
struct  ether_addr {
        u_char  ether_addr_octet[6];
};
#endif

(found in some include file on an OpenBSD machine :) ...)

common/argus_parse.c:
should probably use mktime instead of timelocal on BSDI (just added an 
-Dtimelocal=mktime to the DEFS in the Makefiles for now).

common/addrtoname.c:
uses ether_ntohost several times, which does not seem to exist on BSDI, 
so I just added something like an && !defined(bsdi) to the existing #if's 
(Continue reading)

Russell Fulton | 23 Sep 23:16 1999
Picon
Picon

Re: RE: Time stamps in argus records


On Thu, 23 Sep 1999 08:23:00 -0700 Carter Bullard 
<cbullard <at> nortelnetworks.com> wrote:

> Hey Russell,
>    Combining multiple Argus records that belong to the same flow
> is done with raconnections().  Feed a days worth of  argus records
> into raconnections() and you should get single records for single
> connections with the start and last timestamps correct.
> 

Right, I had forgotten raconnections! There is still one problem I 
think, and that is that my data is stored in hourly files and if I 
remember correctly none of the clients will read multiple files.

I know we have had this discussion before and I recognize that there 
will be problems if users feed files to client out of order but I 
strongly feel that the utility of having the data stored in managable 
chunks (eg. hourly) while retaining the ability to do long running 
analysis far out wieghs any problems.

What I suggest is a new flag ( -R ?) which gives the name of a file 
containing the list of input files.  I propose this rather than the 
usual list of filenames on the command line for two reasons: firstly we 
already have an undelimited string of tokens in the filter and secondly 
I want more flexibility in listing files than the shell globbing 
permits.

I will have a look at the client code today and see if I can figure out 
what is involved.
(Continue reading)

Carter Bullard | 24 Sep 02:54 1999

RE: RE: Time stamps in argus records

Hey Russell,
   So your mail enticed me to double check on the
raconnections.c that is in the current 1.8 tarfile, and
I need to replace it with its the current version.  Minor bug
fix that makes it useable.

   NO, you can specify multiple source files on the command
line of most argus clients, by using multiple -r options.  So
spanning multiple files with raconnections() is a no brainer. 
What I do is use ra() like this:

   ra -r file1 -r file2 -r file3 -r file4 -w - | raconnections -w - | ra
-unc

   which does pretty good.  Any of the clients support their
own filters, so you have a pretty flexible mechanism.

Carter

> -----Original Message-----
> From: Russell Fulton [mailto:r.fulton <at> auckland.ac.nz]
> Sent: Thursday, September 23, 1999 5:16 PM
> To: argus <at> lists.andrew.cmu.edu
> Subject: Re: RE: Time stamps in argus records
> 
> 
> 
> On Thu, 23 Sep 1999 08:23:00 -0700 Carter Bullard 
> <cbullard <at> nortelnetworks.com> wrote:
> 
(Continue reading)


Gmane