Logcheck devel - Jun 2005 - [ttroxell@debian.org: Re: Logcheck rules from other packages]

I'm not sure if this message ever made it to you, Jamie.  I had a reverse
DNS
problem shortly after it was sent.

----- Forwarded message from Todd Troxell <ttroxell at debian.org> -----

Date: Wed, 1 Jun 2005 01:22:18 -0400
From: Todd Troxell <ttroxell at debian.org>
To: "Jamie L. Penman-Smithson" <jamie at silverdream.org>
Subject: Re: Logcheck rules from other packages

Hey Jamie,

On Mon, May 30, 2005 at 09:57:32PM +0100, Jamie L. Penman-Smithson
wrote:
> Hey Todd,
> 
> I'm not so sure about the policy of handing over responsibility for
> package specific rules to some maintainers is a good idea. For example,
> there has been one or two bugs against the supplied logcheck rules with
> packages which could have lead to vast amounts of messages being
> ignored. If a script kiddy was attempting to break in to the system at
> the same time, logcheck wouldn't have reported it.
Yeah, I'm not crazy about the idea of relying on rules from other
maintainers
either.  Maybe dh_installlogcheck could run some simple sanity checks on the
rules from other packages before they are installed.

An idea I've had in working on pylogcheck for dealing with this is somehting
I
was calling "directors"

Syslog message prefixes to the corresponding rule file, so lines like:

^Jun  102:16:32 localhost dhcpd.*$

would be directed to (and processed only by the dhcpd rule file.)

Certainly there are complications with this, and I never actually planned to
implement it in Logcheck proper, but it's something to think about, I guess.

I'm not really sure how the policy change would go down...  I'd love to
see
some algorithms for sanitizing rules.  I am not sure how much of this is
possible, but they would be useful in the future for web-based rule
submission and whatnot.
> My point is not all maintainers knowledge of regular expressions is the
> same. Exporting responsibility over rules is good in that it reduces our
> workload. It's bad however because it makes it harder for end-users to
> know where they should file bugs, sure we can reassign bugs. It's also
> bad because we don't have any input in the rules that are created, they
> may not be of the same quality as those included with logcheck.
> 
> Another thing, if we have rules that are maintained by others (not the
> logcheck team), we should make it crystal clear which rules are included
> in logcheck and which rules are included in other packages. The bugs
> filed against qpopper (that were three years old) were filed in the
> wrong place, somehow we need to make it clearer that say, bugs in
> qpopper logcheck rules should be filed against logcheck. Then again, if
> we include the rules from other packages in logcheck again, this problem
> will cease to exist.
Maybe add some docs to the tune of "please run dpkg -S $RULEFILE before
submitting a bug."

Cheers,
-- 
[   Todd J. Troxell                                         ,''`.
      Student, Debian GNU/Linux Developer, SysAdmin, Geek  : :' :
      http://debian.org || http://rapidpacket.com/~xtat    `. `' 
                                                             `-     ]



----- End forwarded message -----

-- 
[   Todd J. Troxell                                         ,''`.
      Student, Debian GNU/Linux Developer, SysAdmin, Geek  : :' :
      http://debian.org || http://rapidpacket.com/~xtat    `. `' 
                                                             `-     ]

On Fri, 03 Jun 2005, Todd Troxell wrote:
> Syslog message prefixes to the corresponding rule file, so lines like:
> 
> ^Jun  102:16:32 localhost dhcpd.*$
> 
> would be directed to (and processed only by the dhcpd rule file.)
> 
> Certainly there are complications with this, and I never actually planned
to
> implement it in Logcheck proper, but it's something to think about, I
guess.
indeed in some time we will need stats about our rules.
because many of them may never match anything real,
witout us noticing anything.
 
--
maks

[Forgot to Cc my reply to the list..]

On Fri, 2005-06-03 at 12:27 -0400, Todd Troxell wrote:
> I'm not sure if this message ever made it to you, Jamie.  I had a
reverse DNS
> problem shortly after it was sent.
It did, eventually. :)

Hey Todd,

On Wed, 2005-06-01 at 01:22 -0400, Todd Troxell wrote:
> On Mon, May 30, 2005 at 09:57:32PM +0100, Jamie L. Penman-Smithson wrote:
> > I'm not so sure about the policy of handing over responsibility
for
> > package specific rules to some maintainers is a good idea. For
example,
> > there has been one or two bugs against the supplied logcheck rules
with
> > packages which could have lead to vast amounts of messages being
> > ignored. If a script kiddy was attempting to break in to the system at
> > the same time, logcheck wouldn't have reported it.
> 
> Yeah, I'm not crazy about the idea of relying on rules from other
maintainers
> either.  Maybe dh_installlogcheck could run some simple sanity checks on
the
> rules from other packages before they are installed.
What happens if they fail to pass the sanity check? Other maintainers do
not care about logcheck rules as we do. They are secondary to the rest
of the package. Sometimes they're so badly written that they ignore
security sensitive messages.

If we're running sanity checks, what can we do about it? Not much. These
rules should be packaged with logcheck and have the same scrutiny that
all the other rules have.

The other issue that isn't being discussed is with a central logserver,
you might not have all the packages installed but you definitely want
all the rules for those packages installed.. Currently, if logcheck is
used on a central logserver all the rules from other packages need to be
installed (and updated) manually.
> An idea I've had in working on pylogcheck for dealing with this is
somehting I
> was calling "directors"
> 
> Syslog message prefixes to the corresponding rule file, so lines like:
> 
> ^Jun  102:16:32 localhost dhcpd.*$
> 
> would be directed to (and processed only by the dhcpd rule file.)
> 
> Certainly there are complications with this, and I never actually planned
to
> implement it in Logcheck proper, but it's something to think about, I
guess.
In terms of security this addresses part of the problem, but doesn't
stop maintainers from adding rules that ignore problematic messages from
their own daemons.
> I'm not really sure how the policy change would go down...  I'd
love to see
> some algorithms for sanitizing rules.  I am not sure how much of this is
> possible, but they would be useful in the future for web-based rule
> submission and whatnot.
With regard to web-based rule submission sanitizing the rules is going
to be a must. I just don't think it'll work with rules included from
other packages.

<snip> 
> > Another thing, if we have rules that are maintained by others (not the
> > logcheck team), we should make it crystal clear which rules are
included
> > in logcheck and which rules are included in other packages. The bugs
> > filed against qpopper (that were three years old) were filed in the
> > wrong place, somehow we need to make it clearer that say, bugs in
> > qpopper logcheck rules should be filed against logcheck. Then again,
if
> > we include the rules from other packages in logcheck again, this
problem
> > will cease to exist.
> 
> Maybe add some docs to the tune of "please run dpkg -S $RULEFILE
before
> submitting a bug."
I'll add that to README.logcheck-database, but I'm not sure that many
people will see it :)

-- 
-Jamie L. Penman-Smithson <jamie at silverdream.org>
 t: +44 1273 424795; f: +44 1273 424795
 PGP: C0A7 955E EED6 A309 23D7 863B C76A 26A3 F0DC FCA8
 never send mail to: oubliette.z at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20050604/8995a0c7/attachment.pgp