SQUAT warnings and logcheck

[Ross Boylan]

On Friday 25 May 2007 09:51, Sven Mueller wrote:
> Ross Boylan schrieb:
> > logcheck is reporting lots of errors like
> > Security Events
> > =-=-=-=-=-=-=-=
> > May 23 07:03:13 corn cyrus/imap[11735]: SQUAT failed
> > May 23 07:05:25 corn cyrus/imap[11734]: SQUAT failed
> > May 23 07:05:25 corn cyrus/imap[11734]: SQUAT failed
> > May 23 07:05:25 corn cyrus/imap[11734]: SQUAT failed
>
> That's a debug level message given by search_prefilter_messages() in
> imap/search_engines.c, as I understand it, they should be preceeded by
> "failed to open index" messages. logcheck/ignore.d/cyrus2_2 should
> filter those out.
I think that "fail" is a pattern in violations.d, so ignore.d patterns will 
not affect it (but violations.ignore will).  See later for more on logcheck.
> I added a rules to violations.ignore, too though. 
syslog shows
May 24 07:00:42 corn cyrus/imap[25598]: SQUAT failed to open index file
May 24 07:00:42 corn cyrus/imap[25598]: SQUAT failed
May 24 07:00:42 corn cyrus/imap[25598]: SQUAT failed to open index file
May 24 07:00:42 corn cyrus/imap[25598]: SQUAT failed
May 24 07:00:42 corn cyrus/imap[25598]: SQUAT failed to open index file
May 24 07:00:42 corn cyrus/imap[25598]: SQUAT failed

syslog.conf has
*.*;auth,authpriv.none		-/var/log/syslog
which I think means it is logging debug messages.  I thought I had the package 
defaults, though it's possible I changed them.  I certainly have had various 
problems I've tried to debug, and I may have changed it then.

If I understand you, you're saying that if syslog weren't logging debug 
messages, the messages would not show up.  Is that right?

I don't see any debug or message related settings on in cyrus.conf or 
imapd.conf.
>
> > I notice that /etc/logcheck/violations.ignore.d/cyrus2_2, which is part
> > of the cyrus-common-2.2 binary, has this pattern (one line in original):
> > ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ cyrus/(imaps?|pop3s?|lmtp|
> > lmtpunix)\[[0-9]+\]: SQUAT failed to open index file$
> >
> > Is "SQUAT failed" the new text of this error, or does it indicate some
> > other condition?  I have not run squatter, so I have no indices.
> >
> > If the wording has changed, it would be good to adjust the logcheck
> > patterns.
>
> As far as I can tell, the wording didn't change (since a matching rule
> already was in ignore.d/cyrus2_2).
>
So is "SQUAT failed" a general error message, triggerred by failure to open 
index files and, potentially, other causes as well?
> > Also, if this is a relatively trivial error, it would be nice if that
> > were more apparent.  For example,
> > 1) Change the text:
> > May 23 07:03:13 corn cyrus/imap[11735]: INFO: SQUAT failed (no index
> > files?). 2) Change the syslog level.
>
> The level already is "DEBUG". Actually I wonder why you even have it in
> your logs. Under normal circumstances, you shouldn't even have them
> there. Logging debug level messages only makes sense while looking for a
> specific problem.
It does look as if I'm logging DEBUG.
>
> > 3) Change the logcheck patterns to report this as a lower severity event,
> > if it is reported at all.  I'm not sure if the last is possible; the
> > presence of "fail" in the string may impy it will either be reported as a
> > Security Event or not reported at all.
>
> I'm not sure how logcheck works. All I know is that you can add certain
> patterns that are completely ignored.
>
logcheck is tricky.  As I understand it
match pattern in cracking -> reported breakin attempted
  (by default cracking.ignore.d is not processed)
match pattern in violations -> report security error unless filtered out by
  violations.ignore.d
otherwise, report as system event, unless filtered out by ignore.d.* 
appropriate to level.

Further, there are additional rules about exactly which ignore rules can 
filter out which events that would otherwise be reported.

So, for example, dropping a rule in ignore.d.xxx will not quiet a message that 
comes from match to violations.d.

As I said, I'm not sure if a line that matches a pattern in violations.d but 
then is excluded by violations.ignore.d gets passed on for possible reporting 
at the lowest (system event, filtered out iwth ignore.d.*) level of severity.

Ross