Argus 2.0 wishes

[Neil Long]

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


Yes - I have  FreeBSD based firewall in a couple of places (one with uptimes
well over 650 days).

Maybe I will go look for another PC just for Argus data - what are people
seeing as the max memory size after extended time periods?

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


What is lost in the data file by a simple 'mv argus.file
argus.dateformatstring' vs HUPing argus since for the former the argus
process keeps internal state??


I find rolling hourly has the big advantage in that a quick 'ls -lrt|tail'
shows up abnormal high flows indicating trouble with flooders. Having the
data files for historical analysis is just as relevant for hourly
interpretation as for going back a few months.



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


agreed.

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

I have a second host for analysis - when the data file is rolled I copy the
file (not move) over to the analyser and run Dave Brumley's perl code
(modified slightly - anyone have anything which does a better job on udp
scans - I can't figure out why it picks up tcp far better than udp
scanning). When there are net floods this tends to go ape and one run takes
longer than the rollover interval and so on and eventually all hell breaks
loose. But I always have the original data on the argus log host.

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

Yes - I would rather not but I am not interested in flows for web traffic -
other systems are record that, etc.



Very useful thread though.

Anyone have any comments on pre-filtering before it gets to the argus tap?
i.e.

promisc < ---- filter ---- > promisc <---- argus log

I checked ipfilter but tcpdump still sees the packets.

Cheers
Neil