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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
logcheck-database (1.4.0) unstable; urgency=medium
logcheck rules that target /var/log/syslog likely need to be updated
if you are using rsyslog.
Since version 8.2210.0-3, rsyslog defaults to 'high precision
timestamps' so rules (including locally generated rules) that target
/var/log/syslog are likely to stop working unless they are
modified. The rules provided by the logcheck-database package have
been updated but you will need to update all your local rules (or
configure rsyslog to use the 'old' format).
The following can be run as root to update all local rules:
for rule in /etc/logcheck/*.d*/local-*; do
sed --in-place --regexp-extended \
's,^\^((\\w|\[\[:alpha:\]\])\{3\} \[ :(0-9|\[:digit:\])\]\{11\}),^(\1|[0-9T:.+-]{32}),' \
"$rule"
done
This replaces "^<old prefix>" with "^(<old prefix>|<new prefix>)" in
all rules that start 'local-' -- if you have added rules not named
like that you will want to apply a similar change.
The ^<old prefix> includes the following four regexes which were
commonly used to match the start of the 'old-format' timestamp used
by rsyslog in debian bullseye:
^\w{3} [ :0-9]{11}
^\w{3} [ :[:digit:]]{11}
^[[:alpha:]]{3} [ :[:digit:]]{11}
^[[:alpha:]]{3} [ :0-9]{11}
Each of these match timestamps such as "Tue 06 Dec 21:00:00", which
is the format used by the systemd journal and by rsyslog without the
'high-precision' format.
The <new prefix> is '^[0-9T:.+-]{32}' which matches timestamps that
look like "2022-12-06T21:00:00.123456+01:00", the new
'high-precision' format which is now used by a default rsyslog
installation.
It is recommended to retain the '<old prefix>' in rules to ensure
rules can also be used against log entries from the systemd journal:
checking the journal is not done by default (yet), but can be
enabled by writing the string 'journal' into
/etc/logcheck/logfiles.d/journal.logfiles
-- Richard Lewis <richard.lewis.debian@googlemail.com> Tue, 6 Dec 2022 21:00:00 +0100
logcheck-database (1.3.0) unstable; urgency=low
logcheck-database dropped violations.d/logcheck a while ago because it was
causing too many false positives and required insane amounts of rule
duplication. As a result, unless packages themselves elevate their log
messages (and provide their own filters), logcheck now uses only the
ignore.d.* layer by default.
If you prefer to continue use of violations.d/logcheck, then repopulate the
file; the violations.ignore.d/logcheck-* filter files are still being
distributed (but no longer maintained). They will be dropped in a future
release.
If you don't like this, please work with the package maintainers of the
packages responsible for messages that are elevated to security events
(violations) and ask them to provide package-specific elevation filters in
violations.d/<packagename> and appropriate ignore filters in
violations.ignore.d/<packagename>.
-- martin f. krafft <madduck@debian.org> Fri, 18 Jul 2008 15:38:40 +0200
logcheck-database (1.2.49) unstable; urgency=low
logcheck-database now filters all SMART attribute changes reported by
smartd, except for temperature changes (attribute 194) if the target value
is greater than or equal to 55, which will be reported as security events
(violations.d), and changes to the following four attributes, which will be
reported as security alerts (cracking.d):
Reallocated_Sector_Ct
Current_Pending_Sector (when > 0 only)
Offline_Uncorrectable (when > 0 only)
UDMA_CRC_Error_Count
This decision was made based on several arguments, which have been brought
up as part of a mailing list discussion [0]. Among these were:
1. smartd can send warning mails and is configured to do so by default on
Debian.
2. attribute values are not standardised, so it is not possible to sensibly
filter out truly informational messages which are of no interest to the
administrator.
3. logcheck does not have any context information and can thus not filter
attributes whose values simply oscillate.
[0] http://marc.theaimsgroup.com/?t=116015459000003&r=1&w=2
Unfortunately, some harddrives manufactures in the USA use the Fahrenheit
scale for the temperature values (braindeadedness!), so these will generate
spurious security events which you will have to filter out by uncommenting
the appropriate line in /etc/logcheck/violations.ignore.d/logcheck-smartd.
-- martin f. krafft <madduck@debian.org> Wed, 18 Oct 2006 19:57:18 +0200
logcheck-database (1.1.1-8) unstable; urgency=low
[This message was previously issued with debconf and has now been moved to
a NEWS file (where it should be). If you are seeing this again, do note that
it applies to an ancient version and you probably know all this already.]
From version 1.1.1-8, logcheck supports run-parts controled rule
directories:
- /etc/logcheck/cracking.d
- /etc/logcheck/cracking.ignore.d [for local use only]
- /etc/logcheck/violations.d
- /etc/logcheck/violations.ignore.d
- /etc/logcheck/ignore.d.workstation
- /etc/logcheck/ignore.d.server
- /etc/logcheck/ignore.d.paranoid
The ignore.d.{workstation,server,paranoid} directory to be used is set by
the REPORTLEVEL option in the file "/etc/logcheck/logcheck.conf".
These directories may contain files prefixed with "logcheck-" (containing
generic alert/override patterns), named "(packagename)" (containing patterns
specific to that one package), or named "local" respectively prefixed with
"local-" (created by the local administrator to contain patterns tailored
for a particular site). Logcheck will then use rules collected from all the
files found in the appropriate directories.
Please see /usr/share/doc/logcheck for more details.
-- martin f. krafft <madduck@debian.org> Sat, 8 Jul 2006 16:00:09 +0200
|
