Project

General

Profile

Logcheck » History » Version 1

Charles Atkinson, 24/08/2020 06:56

1 1 Charles Atkinson
h1. Logcheck
2 1 Charles Atkinson
3 1 Charles Atkinson
{{toc}}
4 1 Charles Atkinson
5 1 Charles Atkinson
h1. Introduction
6 1 Charles Atkinson
7 1 Charles Atkinson
This page documents logcheck and how to extend it with local filter files.
8 1 Charles Atkinson
9 1 Charles Atkinson
h2. Related documentation
10 1 Charles Atkinson
11 1 Charles Atkinson
* For developers: http://logcheck.org/docs/
12 1 Charles Atkinson
* As installed: directories /usr/share/doc/logcheck and /usr/share/doc/logcheck-database.
13 1 Charles Atkinson
Regards logcheck-database/README.logcheck-database.gz, multiple local-<package name> files have the advantage of being installable and removable with the associated Debian packages
14 1 Charles Atkinson
* logcheck man page
15 1 Charles Atkinson
16 1 Charles Atkinson
Extended regular expressions:
17 1 Charles Atkinson
* Man pages: grep (includes egrep) and regex (man pages section 7, not 3).
18 1 Charles Atkinson
* Wikipedia: http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions.
19 1 Charles Atkinson
* The Linux Documentation Project: http://tldp.org/LDP/abs/html/x17046.html
20 1 Charles Atkinson
21 1 Charles Atkinson
h1. How does logcheck work?
22 1 Charles Atkinson
23 1 Charles Atkinson
This description applies to a default installation on Debian.  The default configuration may be different for other distros.  The configuration may have been changed since installation.
24 1 Charles Atkinson
25 1 Charles Atkinson
h2. Scheduled job and disabling
26 1 Charles Atkinson
27 1 Charles Atkinson
Logcheck is run via /etc/cron.d/logcheck.  /etc/cron.d/logcheck runs logcheck at reboot and at 2 minutes past every hour.
28 1 Charles Atkinson
29 1 Charles Atkinson
Logcheck's scheduled job can be disabled, for example by:
30 1 Charles Atkinson
<pre>
31 1 Charles Atkinson
mv /etc/cron.d/logcheck{,.disabled}
32 1 Charles Atkinson
</pre>
33 1 Charles Atkinson
34 1 Charles Atkinson
h2. Selecting messages to mail
35 1 Charles Atkinson
36 1 Charles Atkinson
Logcheck reads each new line (message) from /var/log/syslog and /var/log/auth.log.  For each message:
37 1 Charles Atkinson
38 1 Charles Atkinson
# If the message matches a regular expression in one of the files in /etc/logcheck/cracking.d, it is selected for the ATTACK ALERT section of the email and processing continues with the next message. 
39 1 Charles Atkinson
# If the message matches a regular expression in one of the files in /etc/logcheck/violations.d then:
40 1 Charles Atkinson
## If it also matches a regular expression in one of the files in /etc/logcheck/violations.ignore.d it is ignored and processing continues with the next message.
41 1 Charles Atkinson
## Otherwise the message is selected for the SECURITY EVENTS section of the email and processing continues with the next message
42 1 Charles Atkinson
# If the message matches a regular expression in one of the files in /etc/logcheck/ignore.d.server then:
43 1 Charles Atkinson
## The message is ignored and processing continues with the next message.
44 1 Charles Atkinson
## Otherwise the message is selected for the SYSTEM EVENTS section of the email.
45 1 Charles Atkinson
46 1 Charles Atkinson
Note: in the first two steps, a match selects the message.  In the last step a match discards the message.
47 1 Charles Atkinson
48 1 Charles Atkinson
If logcheck doesn't select any messages for the email, the email is not sent.
49 1 Charles Atkinson
50 1 Charles Atkinson
h2. Mailing
51 1 Charles Atkinson
52 1 Charles Atkinson
The subject of the mail is prefixed with "Reboot: " when logcheck is run at boot.
53 1 Charles Atkinson
54 1 Charles Atkinson
Mail is sent to logcheck.
55 1 Charles Atkinson
56 1 Charles Atkinson
The "from" address is "logcheck system account".
57 1 Charles Atkinson
58 1 Charles Atkinson
h1. Terminology and naming
59 1 Charles Atkinson
60 1 Charles Atkinson
* *filters, patterns and rules*  The logcheck documentation uses "filter", "pattern" and  "rule" interchangeably, applying them to directories, files and individual regular expressions.  On this WIKI page, only "filter" is used.  It is used only to mean a single filter (a line in a file).  On this page, a file of filters is called a "filter file".
61 1 Charles Atkinson
* *server and workstation* are filtering levels, not computer roles.  From README.logcheck:
62 1 Charles Atkinson
&nbsp;&nbsp;"ignore.d.server; as the name implies, this is intended to cut out the routine messages ..."
63 1 Charles Atkinson
&nbsp;&nbsp;"ignore.d.workstation.  "... is only appropriate for relatively sheltered, non-critical machines"
64 1 Charles Atkinson
* *Filter file names*  The filter file for generic messages is called "logcheck".  The rest of the filter files are named after a Debian package and contain filters for messages generated by software in the package.
65 1 Charles Atkinson
66 1 Charles Atkinson
h1. Emails sent by logcheck
67 1 Charles Atkinson
68 1 Charles Atkinson
h2. Unwanted messages under ATTACK ALERT
69 1 Charles Atkinson
70 1 Charles Atkinson
If the messages should be filtered out:
71 1 Charles Atkinson
# Enable /etc/logcheck/cracking.ignore.d by setting SUPPORT_CRACKING_IGNORE to 1 in logcheck.conf
72 1 Charles Atkinson
# Develop one or more filters for the messages
73 1 Charles Atkinson
# Put the filter(s) in a filter file in /etc/logcheck/cracking.ignore.d
74 1 Charles Atkinson
75 1 Charles Atkinson
Note: the messages are discarded and do not appear anywhere in the email.
76 1 Charles Atkinson
77 1 Charles Atkinson
h2. Unwanted messages under SECURITY EVENTS
78 1 Charles Atkinson
79 1 Charles Atkinson
If the messages should be filtered out:
80 1 Charles Atkinson
# Develop one or more filters for the messages
81 1 Charles Atkinson
# Put the filter(s) in a filter file in /etc/logcheck/violations.ignore.d
82 1 Charles Atkinson
83 1 Charles Atkinson
Note: the messages are discarded and do not appear anywhere in the email.
84 1 Charles Atkinson
85 1 Charles Atkinson
h2. Unwanted messages under SYSTEM EVENTS
86 1 Charles Atkinson
87 1 Charles Atkinson
This section applies in the most common case when unwanted messages appear in the SYSTEM EVENTS section of the logcheck emails.
88 1 Charles Atkinson
89 1 Charles Atkinson
The first task is to decide whether the unwanted messages should be filtered out:
90 1 Charles Atkinson
* If a message shows there's an issue to be resolved, filtering the message out would hide essential information.
91 1 Charles Atkinson
* If a message is generated rarely, it is not worth the work of filtering it out.  Server boot messages are a good example.
92 1 Charles Atkinson
* Often it is not clear from the message itself whether it shows there's an issue to be be resolved or not.  Research work is required.
93 1 Charles Atkinson
94 1 Charles Atkinson
If the messages should be filtered out, the next task is to develop one or more regular expressions (filters) that match the messages.
95 1 Charles Atkinson
96 1 Charles Atkinson
For a single filter, when it works and assuming logcheck has the default configuration, the next step is to put it in a file in /etc/logcheck/ignore.d.server – either in an existing file or a new one.
97 1 Charles Atkinson
98 1 Charles Atkinson
h2. Unwanted boot messages
99 1 Charles Atkinson
100 1 Charles Atkinson
Typically logcheck sends messages associated with booting the first time it runs after reboot.
101 1 Charles Atkinson
102 1 Charles Atkinson
This can be fixed by modifying /etc/cron.d/logcheck, inserting a sleep that delays logcheck until the boot sequence has finished:
103 1 Charles Atkinson
<pre>
104 1 Charles Atkinson
@reboot logcheck if [ -x /usr/sbin/logcheck ]; then sleep 10; nice -n10 /usr/sbin/logcheck -R; fi
105 1 Charles Atkinson
</pre>Explanation: during boot, logcheck runs when the cron daemon is started.  This is normally part way through the boot sequence.  Any messages already in the logs are sent in the mail with subject "Reboot: ...".  This is done because it is not practicable to have logcheck filters for all the messages generated during boot.  Any later messages are sent in the next mail, subject to the usual filtering.
106 1 Charles Atkinson
107 1 Charles Atkinson
h2. Missing messages
108 1 Charles Atkinson
109 1 Charles Atkinson
This section applies when messages appear in the logs but do not appear in the emails.
110 1 Charles Atkinson
111 1 Charles Atkinson
Is the log with the message a log that logcheck is searching?  logcheck searches the logs configured in /etc/logcheck/logcheck.logfiles (default /var/log/syslog and /var/log/auth.log) or whichever file is nominated by logcheck's -L option.
112 1 Charles Atkinson
113 1 Charles Atkinson
Is the message matched by a filter in an ATTACK ALERT or SECURITY EVENT ignore filter file?
114 1 Charles Atkinson
115 1 Charles Atkinson
If the log is being searched and the message is not matched by an ignore filter file, the message must be matched by a SYSTEM EVENTS filter.  In a default installation these are in filter files in the /etc/logcheck/server.d directory, otherwise they are in the /etc/logcheck/<report level>.d directory where <report level> is the value of REPORTLEVEL in /etc/logcheck.conf.
116 1 Charles Atkinson
117 1 Charles Atkinson
h2. Disabling all logcheck emails
118 1 Charles Atkinson
119 1 Charles Atkinson
Disable the cron job.  For example:
120 1 Charles Atkinson
<pre>
121 1 Charles Atkinson
mv /etc/cron.d/logcheck{,.disabled}
122 1 Charles Atkinson
</pre>
123 1 Charles Atkinson
124 1 Charles Atkinson
h1. Custom filters
125 1 Charles Atkinson
126 1 Charles Atkinson
"Custom filters" is used here to mean ones not installed by Debian packages.  They might come from third parties or later versions of logcheck.  They might be developed locally.
127 1 Charles Atkinson
128 1 Charles Atkinson
h2. Filters from third parties
129 1 Charles Atkinson
130 1 Charles Atkinson
Sometimes software includes filter files, for example "snoopy":http://sourceforge.net/projects/snoopylogger/, provides filters "here":http://sourceforge.net/projects/snoopylogger/.
131 1 Charles Atkinson
132 1 Charles Atkinson
There are some published filter file libraries to extend the logcheck standard filters, for example:
133 1 Charles Atkinson
* Ties de Kock's at https://github.com/ties/logcheck-extrarules/tree/master/ignore.d.server
134 1 Charles Atkinson
* sdeziel.info's at https://sdeziel.info/local-logcheck/ignore.d.server/
135 1 Charles Atkinson
* Blue Light's available by running git clone git://git.bluelightav.org/logcheck
136 1 Charles Atkinson
137 1 Charles Atkinson
When considering third party filters, be aware that they may be designed to suit particular local conditions so not as widely suitable as filters from logcheck and other packages.  For example, filter files may have been designed to suit low reliability Internet connections; in other locations, they would filter out messages indicating an unusual event requiring attention.
138 1 Charles Atkinson
139 1 Charles Atkinson
h2. Backports
140 1 Charles Atkinson
141 1 Charles Atkinson
Sometimes required filters can be found in filter files in packages from the backports reopsitories.
142 1 Charles Atkinson
143 1 Charles Atkinson
h2. Developing a filter
144 1 Charles Atkinson
145 1 Charles Atkinson
h3. Find a filter for a similar message
146 1 Charles Atkinson
147 1 Charles Atkinson
For example, suppose logcheck was mailing something like
148 1 Charles Atkinson
149 1 Charles Atkinson
@May 23 10:08:33 LS1 @%{color:green}nmbd%@[1199]: *****@
150 1 Charles Atkinson
151 1 Charles Atkinson
The part in green is usually the name of a daemon or command.  In some cases it is more.  For example ovpn-client uses ovpn-client.<configuration file name>.
152 1 Charles Atkinson
153 1 Charles Atkinson
Find filter files for similar messages by, for example
154 1 Charles Atkinson
<pre>
155 1 Charles Atkinson
cd /etc/logcheck/ignore.d.server && grep --files-with-matches ovpn-client *
156 1 Charles Atkinson
</pre>Choose one of the filters in the file(s) listed as the basis for developing a new one.  If no files are listed, choose any filter; almost all messages match the message format above up to the last ":" except for the part in green in the example.
157 1 Charles Atkinson
158 1 Charles Atkinson
h3. Structure of a typical filter
159 1 Charles Atkinson
160 1 Charles Atkinson
A filter is an egrep regular expression, for example:
161 1 Charles Atkinson
<pre>
162 1 Charles Atkinson
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ (openvpn|ovpn-[._[:alnum:]-]+)\[[[:digit:]]+\]:( ([-_.@[:alnum:]]+/)?[.[:digit:]]{7,15}:[[:digit:]]{2,5})? Replay-window backtrack occurred \[[[:digit:]]+\]$
163 1 Charles Atkinson
</pre>Notes:
164 1 Charles Atkinson
# To ensure a complete match, filters begin with ^ and end with $
165 1 Charles Atkinson
* Match from start of the line through the time stamp and server name:<pre>
166 1 Charles Atkinson
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+
167 1 Charles Atkinson
</pre>
168 1 Charles Atkinson
# Match the the daemon or command name:<pre>
169 1 Charles Atkinson
(openvpn|ovpn-[._[:alnum:]-]+)
170 1 Charles Atkinson
</pre>
171 1 Charles Atkinson
# Match the PID:<pre>
172 1 Charles Atkinson
\[[[:digit:]]+\]:
173 1 Charles Atkinson
</pre>
174 1 Charles Atkinson
# The remaining regular expression, up to but not including the $ is specific to the specific message(s) to be matched.
175 1 Charles Atkinson
176 1 Charles Atkinson
h3. Design considerations
177 1 Charles Atkinson
178 1 Charles Atkinson
When developing a filter, you can usually use parts 1 to 4 above from a similar filter and develop part 5.  It should be designed to match the messages you want to filter in or out – and only those messages. 
179 1 Charles Atkinson
180 1 Charles Atkinson
If your regex is too general it may filter messages that show there's an issue to be resolved.  For example ...
181 1 Charles Atkinson
<pre>
182 1 Charles Atkinson
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ (openvpn|ovpn-[._[:alnum:]-]+)\[[[:digit:]]+\]:.*$
183 1 Charles Atkinson
</pre>... would filter out all openvpn log messages.
184 1 Charles Atkinson
185 1 Charles Atkinson
If your regex is too specific you may need several filters to address closely related messages.  For example ... [TODO: add example]
186 1 Charles Atkinson
187 1 Charles Atkinson
If you are not familiar with egrep regular expressions, it may be worth studying some existing logcheck filters alongside samples of the messages they filter to see how they work.
188 1 Charles Atkinson
189 1 Charles Atkinson
h3. Regex snippets
190 1 Charles Atkinson
191 1 Charles Atkinson
* *Day of week (three letter, English)* @(Mon|Tue|Wed|Thu|Fri|Sat|Sun)@
192 1 Charles Atkinson
* *Disk device name (with or without /dev/ and partition number)* @(/dev/)?(sd[[:lower:]]+[[:digit:]]*)|(dm-[[:digit:]]+)@
193 1 Charles Atkinson
* *Domain name* @[A-Za-z0-9.-]+\.[A-Za-z]{2,4}@
194 1 Charles Atkinson
* *Email address* @[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}@
195 1 Charles Atkinson
* *Hostname (with or without domain name)*  @[-[:alnum:]]+(\.[-[:alnum:]]+)*@ 
196 1 Charles Atkinson
&nbsp;&nbsp;Rationale: adequate and simpler/faster than the accurate regex for a hostname with domain name @([a-zA-Z0-9]([a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,6}@
197 1 Charles Atkinson
* *hh:mm:ss*  @[:[:digit:]]{8}@
198 1 Charles Atkinson
&nbsp;&nbsp;Rationale: adequate and simpler/faster than the accurate regex 
199 1 Charles Atkinson
* *IPv4 address*  @[.0-9]{7,15}@
200 1 Charles Atkinson
The above is conventional.
201 1 Charles Atkinson
More precise: @[[:digit:]]+(.[[:digit:]]+){3}@
202 1 Charles Atkinson
Precise:  @\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b@
203 1 Charles Atkinson
* *IPv4 port number* @[[:digit:]]{1,5}@
204 1 Charles Atkinson
Rationale: adequate and simpler/faster than matching 0 to 65535.
205 1 Charles Atkinson
* *IPv6 address*  @[[:xdigit:]]*:*[:[:xdigit:]]*:+[[:xdigit:]]+@
206 1 Charles Atkinson
Rationale: matches both full IPV6 address and the minimal loopback address ::1.  The flexibility of valid IPV6 address representations makes a more precise regex impossible.
207 1 Charles Atkinson
* *Month of year (three letter, English)*  @(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)@
208 1 Charles Atkinson
* *Network interface name*  @(eth|lo|tap|tun)[[:digit:].]+@
209 1 Charles Atkinson
* *Persistent network interface name*  NEEDS TESTING.  NEED TO EXTEND for virtual and VLAN interfaces @e(n(p[[:digit:]]+)?(o|s)[:digit:]]+)|x[[:xdigit:]]+@
210 1 Charles Atkinson
* Network interface chip name (not complete, simplistic)  @(ATL1C|ATL1E|atl1c|atl2|bcm5700|bcmemac|bnx2|bnc2x|e100|e1000|e1000e|netxen_nic|uli526x)@
211 1 Charles Atkinson
* *User name*  @[^ ]+ @
212 1 Charles Atkinson
Rationale: although there are conventions for user names, they are not universally enforced and a wide variety of names is possible.
213 1 Charles Atkinson
* *Time zone abbreviations (three letter)*  @[[:upper:]]{3}@
214 1 Charles Atkinson
Rationale: adequate and simpler, faster and easier to maintain than matching valid time zone abbreviations.
215 1 Charles Atkinson
216 1 Charles Atkinson
h2. Testing and debugging
217 1 Charles Atkinson
218 1 Charles Atkinson
Filters are tested by seeing if they match sample message(s).
219 1 Charles Atkinson
220 1 Charles Atkinson
h3. Finding sample messages
221 1 Charles Atkinson
222 1 Charles Atkinson
The first step is to find which log the sample message(s) are in.  In a default logcheck installation this will be either /var/log/syslog or /var/log/auth.log.  /var/log/syslog is assumed in the examples below.
223 1 Charles Atkinson
224 1 Charles Atkinson
If /var/log/syslog has been rotated since logcheck found the message(s), they will be in syslog.1 or syslog.*.gz.  They can all be searched using:
225 1 Charles Atkinson
<pre>
226 1 Charles Atkinson
zgrep <your string> /var/log/syslog*
227 1 Charles Atkinson
</pre>For the log file names only:
228 1 Charles Atkinson
<pre>
229 1 Charles Atkinson
zgrep --files-with-matches <your string> /var/log/syslog*
230 1 Charles Atkinson
</pre>
231 1 Charles Atkinson
232 1 Charles Atkinson
h3. Running tests
233 1 Charles Atkinson
234 1 Charles Atkinson
Having the filter(s) in a file in an editor is useful.  Then it's easy to change, redo and undo between tests.  Assuming the filter(s) to be tested are in /tmp/my_filter and the messages are in /var/log/syslog, they can be tested by:
235 1 Charles Atkinson
<pre>
236 1 Charles Atkinson
sed -e 's/[[:space:]]*$//' /var/log/syslog | egrep --file /tmp/my_filter
237 1 Charles Atkinson
</pre>
238 1 Charles Atkinson
Note: the @sed -e 's/[[:space:]]*$//'@ emulates logcheck internals which strip trailing spaces from messages.
239 1 Charles Atkinson
240 1 Charles Atkinson
When the messages are in a compressed log:
241 1 Charles Atkinson
<pre>
242 1 Charles Atkinson
zcat /var/log/syslog.3.gz | sed -e 's/[[:space:]]*$//' | egrep --file /tmp/my_filter
243 1 Charles Atkinson
</pre>When the messages are in compressed and uncompressed logs:
244 1 Charles Atkinson
<pre>
245 1 Charles Atkinson
    zgrep --no-filename . <list of log files> | sed -e 's/[[:space:]]*$//' \
246 1 Charles Atkinson
        | egrep --file /tmp/my_filter
247 1 Charles Atkinson
</pre>If the filter does not work these can help:
248 1 Charles Atkinson
* Progressively right-truncate the regex until it does match.  Then the last part discarded contains the error.
249 1 Charles Atkinson
* Use egrep's --only-matching (-o) option to see what the regex is actually matching.
250 1 Charles Atkinson
251 1 Charles Atkinson
h2. Installing filters in a filter file
252 1 Charles Atkinson
253 1 Charles Atkinson
The directory for the filter file is as listed in "Unwanted messages under ATTACK ALERT in the emails", "Unwanted messages under SECURITY EVENTS in the emails" or "Unwanted messages under SYSTEM EVENTS in the emails" above.
254 1 Charles Atkinson
255 1 Charles Atkinson
Filter file names must be made of upper and lower case letters, digits, underscores, and hyphens.  This is because logcheck uses  run-parts --list  to select the filter files.
256 1 Charles Atkinson
257 1 Charles Atkinson
h3. Choosing the file name
258 1 Charles Atkinson
259 1 Charles Atkinson
Custom filters can most easily be kept in local-<something> filter files.  The alternatives are harder to administer:
260 1 Charles Atkinson
* Changing the files installed by the logcheck package means those files will not be upgraded when logcheck is upgraded.
261 1 Charles Atkinson
* A single file for all local filters does not allow installing a local filter file at the same time as a package is installed or upgraded (the format of the log messages may change with the upgrade).
262 1 Charles Atkinson
* Having multiple local filter files is helpful when a filter has accidentally been added which matches too many messages; individual files can be disabled until the file causing the problem is identified (a powerful technique when the first step is to to disable half the files, and so on in a "binary search").
263 1 Charles Atkinson
* If the filters are for messages generated by software not installed by a package (such as locally developed software or software installed from source), it is convenient to have a local-<something> file to install with the software in the same way that it might have files for /etc/cron.daily or /etc/logrotate.d.  The local- prefix ensures such a file will not be clobbered by a package that happens to have the same name.
264 1 Charles Atkinson
* If the local filter extends the filters in an as-installed <package name> filter file, the relationship can be made clear by putting it in local-<same package name>.
265 1 Charles Atkinson
266 1 Charles Atkinson
If the package name is not obvious from the message, it can usually be found by finding which file corresponds to the message and which package the file comes from.  For example, for message @Jul 12 09:19:55 LS1 named[1329]: listening on IPv4 interface tun0, 10.8.0.1#53@ the package is bind9:
267 1 Charles Atkinson
<pre>
268 1 Charles Atkinson
# type named
269 1 Charles Atkinson
named is /usr/sbin/named
270 1 Charles Atkinson
# dpkg -S /usr/sbin/named
271 1 Charles Atkinson
bind9: /usr/sbin/named
272 1 Charles Atkinson
</pre>In case a standard set of local-* filter files are installed on multiple computers:
273 1 Charles Atkinson
* The processing load can be reduced by installing them with extension .disabled and only removing it when needed.
274 1 Charles Atkinson
* Host-specific filter files can have prefix local-local-
275 1 Charles Atkinson
276 1 Charles Atkinson
h3. Filter file backups
277 1 Charles Atkinson
278 1 Charles Atkinson
If updating an existing file, the original can be backed up with a name which is not entirely of upper and lower case letters, digits, underscores, and hyphens; for example local-openvpn.bak.  These files will not be used by logcheck.
279 1 Charles Atkinson
280 1 Charles Atkinson
h3. Filter file contents
281 1 Charles Atkinson
282 1 Charles Atkinson
Filter files may have comment lines (beginning with #) and empty lines (containing only none or more spaces and tabs).  These are ignored by logcheck.
283 1 Charles Atkinson
284 1 Charles Atkinson
Filter files can be sorted to help identify duplicate and similar filters.  If doing so, using sort's --version-sort (-V) option may avoid surprises.
285 1 Charles Atkinson
286 1 Charles Atkinson
h2. Example filter development session
287 1 Charles Atkinson
288 1 Charles Atkinson
The message was @Sep 16 17:33:31 rose gnome-keyring-prompt: could not grab keyboard: already grabbed@
289 1 Charles Atkinson
290 1 Charles Atkinson
Found the package:
291 1 Charles Atkinson
<pre>
292 1 Charles Atkinson
# dpkg -L gnome-keyring | grep gnome-keyring-prompt
293 1 Charles Atkinson
/usr/share/applications/gnome-keyring-prompt.desktop
294 1 Charles Atkinson
/usr/lib/gnome-keyring/gnome-keyring-prompt-3
295 1 Charles Atkinson
/usr/lib/gnome-keyring/gnome-keyring-prompt
296 1 Charles Atkinson
</pre>Found no existing filters:
297 1 Charles Atkinson
<pre>
298 1 Charles Atkinson
# grep gnome-keyring-prompt /etc/logcheck/ignore.d.server/*
299 1 Charles Atkinson
[no output]
300 1 Charles Atkinson
</pre>Found the log with the message:
301 1 Charles Atkinson
<pre># grep 'could not grab keyboard' /var/log/syslog
302 1 Charles Atkinson
# grep 'could not grab keyboard' /var/log/syslog.1
303 1 Charles Atkinson
# grep 'could not grab keyboard' /var/log/auth.log
304 1 Charles Atkinson
Sep 16 17:33:31 rose gnome-keyring-prompt: could not grab keyboard: already grabbed
305 1 Charles Atkinson
</pre>Developed a filter by copying an existing filter and modifying it.  Tested it:
306 1 Charles Atkinson
<pre>
307 1 Charles Atkinson
# cd /etc/logcheck/ignore.d.server && egrep  --file /tmp/my_filter /var/log/auth.log
308 1 Charles Atkinson
Sep 16 17:33:31 rose gnome-keyring-prompt: could not grab keyboard: already grabbed
309 1 Charles Atkinson
</pre>
310 1 Charles Atkinson
Added filter to existing local filter file local-gnome-keyring and sorted the content.
311 1 Charles Atkinson
312 1 Charles Atkinson
h2. Gotchas
313 1 Charles Atkinson
314 1 Charles Atkinson
If a valid filter in a filter file in /etc/logcheck/ignore.d.server filter does not work:
315 1 Charles Atkinson
* Does the message match a filter in a filter file in /etc/logcheck/cracking.d or /etc/logcheck/violations.d?  Note: if this is the case, the unfiltered message would not be in the SYSTEM EVENTS section of the emails.