Argus 2.0 wishes

[Peter Van Epp]

> 
> 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.....

	I must admit I don't worry about this because I'm on a big dedicated 
machine. I've (by accident) had argus run without a HUP for more than 20 days
(I was on vacation) with no problems such as memory leaks or crashes. The log
file got a little large, but there is also lots and lots of disk on that 
machine so it wasn't a space issue. The machine is on our diesil backed up
UPS so power isn't an issue, and FreeBSD doesn't typically crash unless 
intentionally booted (usually to install the latest version every 6 months
or so).

> 
> 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

	What I'm suggesting (maybe unclearly from Carter's comment) is that 
the current HUP action be replicated in another signal that processes the 
current log file as if a HUP had been issued (i.e. flush all incomplete flows
to the log file which may or may not be useful) but without shutting down 
Argus. The intent is to roll the log file on a time initiated basis (by having
cron send the signal to argus). Instead of shutting Argus down with a HUP 
moving the file then restarting what I'm suggesting is that Argus do the 
same processing it would do on a HUP to the current log file, then do the 
close and mv (in the form of opening a new log file) that we would have done
by shutting down argus. To do this Argus needs the format that a new log file
name should take, and it would get that from the config file to allow the user
flexablity in what they name their log files (in the case that multiple arguses
are running for instance you may want to have a different prefix for each 
instance to tell them apart). For one this eliminates the small window of 
something bad getting through undetected when argus is down for the file to 
be changed in the current HUP restart method. It may indeed not be sensible to 
flush the incomplete flows to the log file at this time, I only asked for it 
because that is the current behaviour. 
	The signal to roll log files makes file frequency your choice (and 
less cost in that you don't lose records while argus is shut down). If you 
want to do it every 15 minutes you can or once a day as I usually do as well. 
	For IDS purposes you are better to have the IDS code getting data piped
real time from the Argus daemon while it runs (and sends the audit log to the
log file) rather than post process the audit log. I believe this is how 
Russell is running (I'm sure he will correct me if I'm wrong :-) ). For me
the valuable thing about the Argus log records is that I can go back in time
when something bad (that happened a while ago) is reported.

> 
> 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?

	I admit since I always log everything with no filters (and filter in
ra etc. post capture) this isn't an issue for me.

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