Logcheck – Scan your logs and warns you.

Jun 242011

tux On our server we have (or you should have) tons of logs generated, logs from various daemons (ssh, iptables, monit, fail2ban), services (apache. nginx, bind, ftp, etc.) and system logs (syslog, messages, kernel).

So i’m sure that every day you check these logs and look if something bad has happened, right ?

Well, perhaps i’m more lazy, but i prefer to use an automatic log scanner, and among many an old good program is Logcheck

Logcheck is a simple utility which is designed to allow a system administrator to view the logfiles which are produced upon hosts under his control.

It does this by mailing summaries of the logfiles to him, after first filtering out “normal” entries.

Normal entries are entries which match one of the many included regular expression files contain in the database.

Installation

Logcheck is usually available in all major distributions so, use your package manager to install it.
On Debian and Ubuntu

aptitude install logcheck

This will install also the package logcheck-database and logtail an executable that remembers position of last reading (tracks size and inodes of log files)

Configuration

The first configuration file that you have to setup is /etc/logcheck/logcheck.conf

Here you must setup the level of filtering, the address that will receive the email and if the messages are sent inline in the body or as attachments of the email.

The second file to edit is /etc/logcheck/logcheck.logfiles in this file put in every line the complete path to a log you want to check like

/var/log/syslog
/var/log/auth.log
/var/log/sulog

Rules

Rules are loaded thanks to the package logcheck-database, there are three layers of sets of filtering rules, all of which are
normal egrep pattern-matches, applied in turn.

1. the “ATTACK ALERTS” layer, designed to detect the traces of active intrusion attempts.

Patterns raising the alarm go in “/etc/logcheck/cracking.d”; any event that matches one of these patterns turns the report into an urgent “Attack Alerts” report, with the relevant event moved to a special section.

Patterns cancelling such maximum-priority alarms are not used in the default logcheck configuration, but if the local administrator enables this layer of filtering in logcheck.conf, then the rules go in the directory “/etc/logcheck/cracking.ignore.d”. Matches with cracking.ignore rules will then reclassify the alert as a false alarm (compare violations.ignore below). Note that this means they are totally ignored – log messages handled at one layer are not carried over to lower layers.

2. the “SECURITY EVENTS” layer, designed to detect less critical events still considered worthy of special attention.

Patterns raising the alarm go in “/etc/logcheck/violations.d”; matches with these result in a “Security Events” alert, with the relevant event moved to a special section.

Patterns cancelling such alarms go in the standard directory “/etc/logcheck/violations.ignore.d”; apparent “Security Events” that match with violations.ignore patterns are discarded as false alarms.

3. The “SYSTEM EVENTS” layer, handling leftover log messages.

Every message that has not matched layer 1 and 2 is automatically a “System Events”.

You can ignore trivial and common messages adding them in the directory “/etc/logcheck/ignore.d”

Examples of rules

Kernel in /etc/logcheck/cracking.d

kernel: Oversized packet received from

Kernel in /etc/logcheck/violations.d

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel:( \[[[:digit:]]+\.[[:digit:]]+\])? [[:alnum:]]+: media error \(bad sector\): status=0x[[:xdigit:]]+ { DriveReady SeekComplete Error }$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel:( \[[[:digit:]]+\.[[:digit:]]+\])? end_request: I/O error, dev [[:alnum:]]+, sector [[:digit:]]+

How it works

Run logcheck.sh using cron
logcheck.sh calls logtail
logtail determines when reading was last time and parses off “old” lines
logcheck.sh greps text from hacking/violations/violations.ignore/ignore files
messages found are e-mailed, I guess to you

Conclusions

Logcheck can be your eyes in checking every single log and reporting to you critical events.
At the start it will need some setup and probably you’ll receive a lot of “spam” but with some practice you’ll be able to clean all the emails and get consistent reports.

Linuxaria