/usr/share/doc/tiger/README.ignore is in tiger 1:3.2.3-10.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 | Tiger's ignore mechanism
------------------------
Tiger, since version 3.2, provides a new 'ignore' mechanism. This ignore
mechanism is a way for administrators to customize their policy in such
a way that messages generated by any of Tiger modules will be 'ignored'.
The ignore file needs to be stored in $CONFDIR (the location of this
directory depends on how it has been autoconfigured, by default is
/usr/local/tiger/) and is named 'tiger.ignore'
The idea for this mechanism is derived from logcheck's mechanism and follows
a similar behaviour. If the file does not exist all messages are reported.
If the file exists, all the entries (line by line) are used as extended
regular expressions that are compared against each message (notice that
it will introduce some overhead which grows with the size of the file).
As a matter of fact EGREP is used to interpret it.
As logcheck says:
# Use your judgement before putting words
# in here or you can miss really important events. The default is to leave
# this file with only a couple entries. DO NOT LEAVE THE FILE EMPTY. Some
# grep's will assume that an EMPTY file means a wildcard and will ignore
# everything! The basic configuration allows for the more frequent sendmail
# error.
Tiger by default does not ship an 'ignore' file, although some versions
(like Debian) might ship with a 'baseline' that provides some entries
for messages that should be ignored in the running operating system
since it's not a security policy violation but rather the default behaviour.
In any case, be careful how you use wildcards (*) or regular expressions
in the tiger.ignore file or you might miss important events reported by
Tiger.
This mechanism can be also useful to avoid messages from some checks which
might produce spurious results depending on your system. A common bug
reported for the Debian GNU/Linux package has been the messages related to
the 'check_listeningprocs' script which might report a listening process
that when investigated later on does not appear any longer. This is due
to some servers opening UDP listeners to receive DNS queries (usually
servers that use a lot of DNS resolution like proxies -squid-, mail servers
-qmail- and the like). In this case you can either use a mechanism in
the check to filter these messages out, if some is available
(in the check_listeningprocs you can use the Tiger_Listening_ValidProcs
or Tiger_Listening_ValidUsers variable) or you can add a proper regular
expression in the ignore file to remove this (but not other) messages.
-- Javier Fernández-Sanguino Peña <jfs@computer.org>
Thu, 17 Apr 2003 19:00:20 +0200
|