Argus 2.0 wishes

[Neil Long]

Perhaps it would help if I try and indicate when I would want to send
signals??

The argus daemon did tend to grow rather big and reserved a lot of swap
space (1.7beta) so I got in to the bad habit (!) of killing it every hour
when I mv'd the data file however in an ideal world.....

a) Clean shutdown - currently SIGHUP but the system has very high uptimes
(where's the wood...)

b) rotating data files - is mv the best method or is there something to be
gained by sending a signal as Peter suggested for flushing all records? It
is always a trade off between file size and frequent processing for
portscans, etc

c) change of filter file / configuration file - need to change the internal
tables in argus but what about existing flows which may now be ignored?

d) debug modes - SIGUSR1, SIGUSR2 - I haven't played with these


For IDS I would normally merge for specific hosts/nets/ports and then rasort
or raconnections so patching over the cracks might be more important to some
than others - for traffic flow a 24hr cycle may be better whereas 30mins or
1hour would be more typical for IDS?

Neil


-----Original Message-----
From: Carter Bullard <cbullard at nortelnetworks.com>
To: 'Peter Van Epp' <vanepp at sfu.ca>; argus at lists.andrew.cmu.edu
<argus at lists.andrew.cmu.edu>
Date: 16 March 2000 16:45
Subject: RE: Argus 2.0 wishes


    Hey Peter,
       We can implement your suggestion with Neil's approach.
    Maintaining internal argus state is indeed really
    important.  As long as the configuration file hasn't
    changed when we get the SIGINT, then we don't have to
    reinitialize the Argus.  We can switch files, but I'd
    like to hear more justification for flushing all the
    records.

    Carter



    > -----Original Message-----
    > From: Peter Van Epp [mailto:vanepp at sfu.ca]
    > Sent: Thursday, March 16, 2000 11:22 AM
    > To: argus at lists.andrew.cmu.edu
    > Subject: Re: Argus 2.0 wishes
    >
    >
    >       The discussion on signals jogged my mind for another
    > request (which
    > fits in with the config file). I'd like a signal that will
    > switch log files.
    > When the signal hits, argus flushes all the open flows to the
    > current log
    > file (but keeps the current state in memory still) as if it
    > had sigHUPed,
    > writes the terminate record, closes the file and opens a new
    > one (file name
    > created from parameters in the argus config file) and
    > continues on without
    > really shutting down. I'm working on something like that
    > (slowly!) externally
    >  with the shadow startup perl scripts, but internal to argus
    > would be even
    > better because of not loosing current active state from shutdowns.
    >
    > Peter Van Epp / Operations and Technical Support
    > Simon Fraser University, Burnaby, B.C. Canada
    >
    >