>Much better :) Would a static analysis be enough (e.g. have syslog-ng
run with a special command line argument in which case it >goes to
filter-test-mode, just like the sendmail debug mode)? Or you want to
enable this kind of logging on the running daemon?
Some of you have emailed me directly and I thank you for your advice. I
am still looking into the syslog(3) recommendation.
For me I see syslog-ng as another application. And as an application I
believe I should be able to get logging on what it is doing. I should
be able to go to something like
var/log/loghost/2004/05/14/syslog-ng.log and see an entry on a filter
action like described below.
Example of a syslog-ng.conf filter entry:
filter f_loghost_ssh { host("(loghost)") and program("sshd.*") and
match("(ailed|enied|illegal)"); };
Log entry I would like to see something like in
/var/log/loghost/2004/05/14/syslog-ng.log:
syslog-ng.log:May 14 10:09:10 loghost syslog-ng[5902]: FILTER: f_loghost
matched program sshd[3459] on {failed} destination of entry
/var/log/loghost/2004/05/14/info.log
As for the SEC recommendation. That was the third time this week I saw
a reference by someone to SEC so I checked it out. It looks like it
could be useful but not for this problem. I something like a hundred
different directory trees with 4 - l8 log files in each branch so SEC
would be very difficult to use on a central syslog-ng server. That is
why I use syslog-ng to catch real-time events and not something like
swatch or SEC now.
Bill Clark
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Fri May 14 2004 - 11:52:58 PDT