Re: System log monitor
Steve wrote:
>
> "Rene" == Rene Mayrhofer <rene.mayrhofer@vianova.at> writes:
> > This is a small followup to my last message. After thinking a bit
> > about it, I think it might be better (performance-wise and when
> > multiple files include the same rules - this will happen during the
> > transitition period when packages start to bring logcheck rules
> > files, but when they are still covered by the logcheck-shipped
> > defaults) to use an update-logcheck script (like update-modules)
> > that pre-generates the rules for logcheck.sh. Then they do not have
> > to be generated during run-time and therefore some fancy sorting and
> > filtering of duplicates can be done without getting performance
> > problems.
>
> I agree that this would be useful, but mainly as it would be a good
> place to filter out the dreaded blank-lines in ignore files.
Yes, that's also a good point. Nearly forgot it.
> However,
> WRT duplicates, if you have duplicate rule I think you would have a
> problem, as that would imply that those rules were too general.
I am thinking about rules that are shipped with logcheck at the moment, but will
be shipped with the package they belong to in the future. During the transition
period, it might (and probably) will happen, that for some time, both logcheck
and the other package contain the same rules.
> One issue that occurs to me is the danger of one badly formed ignore
> regexp for a package can strip real violations out of other package
> violations. Package-specific violations and ignores should be done in
> separate scans i.e. system-wide common violations and ignores are
> scanned for first, and then the resulting output is run though each
> group of package-specific violations and ignore rules *separately*,
> rather than in series.
Hmm, but how would you then decide, which of the separate output should be sent
to the administrator ? When e.g. the logcheck package brings some rules to
filter most common messages, and the administrator really does not want to see
them, then logcheck has to run the common output through these rules before
sending them to the admin (I hope I have understood you correctly). At the
moment, I can not see how the separated results could be "unified" before
mailing them. My only idea idea of implementing this is that the update-logcheck
strip just collects all rules (e.g. for ignore) and puts them in one file,
cutting out blank-lines and duplicates.
But you have definitely a good point here. How can it be prevented that some
package messes up with a security relevant package ? Maybe I should only allow
rules that start with the package name ? I don't think that this would work
(even when all daemon packages had the same name as the running daemon), because
that would be too much of a restriction. E.g. the isdnutils package should bring
rules, that filter out the kernel isdn messages (like my "workstation" default
configuration is doing it now).
Comments ?
Rene
Reply to: