Introduction / Background

After consulting the RPMFind.net site for the Logcheck log file monitoring program discussed in class, I decided to install LogSentry (from Psionic.com). LogSentry is the new name for Logcheck and is maintained by Psionic for use on Linux and Unix systems (the LogSentry README file still references Logcheck; the executable is logcheck.sh). The LogSentry/Logcheck program checks system log files on a regular basis scheduled via cron for security violations or other unusual activity. It sends email reports of it's findings to the System Adminstrator.

LogSentry is part of Psionic's "TriSentry" freeware system monitoring/securiy suite which also includes HostSentry and PortSentry. Per Psionic's site: "The TriSentry freeware suite (formerly the Abacus Project tools) is designed to enhance the security posture of your computing network, and reduce the chance of malicious activity. Psionic's TriSentry suite is composed of three key components: PortSentry„˘, HostSerny™, and LogSentry„˘. Designed to operate in most UNIX based operating systems, they work together to protect your companies' networks and hosts, and provide a simple reporting tool."

While LogSentry/Logcheck is similar in function to the LogWatch program that comes with the RedHat Linux OS and does not run continuously like some monitoring software (e.g. Saimhaim), it seems a good first choice for system monitoring installation since it is a fairly straightforward, configurable and provides the opportunity to work a bit more with CRON.

Overview

"LogSentry (formerly Logcheck) automatically monitors your system logs and mails security violations to the System Administrator on a periodic basis. It is based on a program [frequentcheck] that ships with the TIS Gauntlet firewall but has been improved upon in many ways to make it work nicely for normal system auditing." (Psionic site)

The LogSentry/Logcheck executable (logcheck.sh) runs on a schedule (e.g. hourly, monthly) that the System Administrator determines via a cron job configured in /etc/crontab. The logcheck.sh runs a companion executable (logtail) that remembers the last position in each logfile previously processed by logcheck.sh and only text new since the last time logtail was run is checked. LogSentry/logcheck.sh greps the latest text for system attack messages (defined in logcheck.hacking), then security violation messages (defined in logcheck.violations), next for security violations to ignore (defined in logcheck.violations.ignore) and finally for all messages to ignore (defined in logcheck.ignore). Any messages found are mailed to the System Administrator(s) defined in the configuration section of logcheck.sh.

1. First, verify that logsentry/logcheck is not already installed using which, locate, and ps commands (which logcheck, locate logcheck, ps -ef | grep logcheck)

2. Search rpmfind.net site to locate a source site and download the binary tarball from Psionic.com (RPMs available elsewhere but decided to take the more challenging tarball route.)

$ wget http://www.psionic.com/downloads/logsentry-1.1.1.tar.gz

3. Copied the package to /usr/local, unzipped and checked (tar -tf logsentry-1.1.1.tar | head) to package would detar into its own directory. It will, so detar the package and cd into new /logsentry-1.1.1 directory.

4. Review README and INSTALL files and proceeded with the configuration and isntallation.

5. Per INSTALL instructions, consult syslog.conf man pages (man syslog.conf) and check the system logging configuration file (/etc/syslog.conf) to ensure it sends all messages to /var/log/messages. INSTALL recommends adding the line *.info /var/log/messages and restarting. However, the existing setting is pretty close to this already:

*.info;mail.none;authpriv.none;cron.none /var/log/messages

This will log anything except mail of priority level info or higher to /var/log/messages. Private authentication messages (authpriv) and cron messages will not be logged. Ok to start.

6. Check the messages and other log files in /var/log to make sure their permissions are set to 600 (root read/write only) and that they are owned by user root and group wheel (root group should be ok).

7. Edited /etc/logrotate.conf file to ensure that when logfiles are rotated out and new ones created that the permissions on the new ones are 600.

8. cd to /usr/local/system/linux and review the logcheck.sh file to ensure that it is appropriately configured. I did not change the default installation paths (/usr/local/bin, /usr/local/etc). I left SYSADMIN set to root since my account is set up in /etc/aliases to receive mail sent to root. messages, secure, maillog logfiles are all set to be processed by logcheck.

9. Install LogSentry/logcheck:

$ make linux

10. Edit /etc/crontab to set logcheck.sh to run every hour. Added the following line to crontab:

00 * * * * root /bin/sh /usr/local/etc/logcheck.sh

11. Restart crond daemon:

$ kill -1 907 (ps id for crond)

12. Run logcheck manually

$ /usr/local/etc/logcheck.sh

13. Exit root account and re-su back to root to create a loggable/reportable event for LogSentry. Then check mail for messages (more /var/spool/mail/barrie ). Message from LogSentry had arrived; LogSentry is working! Rebooted the system to ensure that nothing is broken; run some loggable commands (su, sudo tcsh) and check mail after LogSentry has had time to run per automated hourly routine.

Instructions for Use

Per hourly scheduled task in the /etc/crontab file, LogSentry will check logfiles every hour and send notable changes to those files in mail to the root (and my) email accounts. This automated logfile check will be helpful in monitoring use of this system. LogSentry may also be run manually at any time from the command line: /usr/local/etc/logcheck.sh A brief comparison of LogSentry messages with those that come from LogWatch indicates that LogSentry notifies on a larger variety of activity ("Unusual System Events")... at least when it's definition files (logcheck.violations, logcheck.hacking, logcheck.violations.ignore, logcheck.ignore) are configured with their default settings. For example, LogSentry reported system output on shutdown/reboot and boot up which LogWatch did not. Follow-up exploration activities with this software will be to analyze the current messages for things that might not need reporting and (very) judiciously add some keywords to logcheck.violations and/or logcheck.violations.ignore to tweak what is reported. However, I imagine I will leave the reporting as verbose and broad as possible for improved security; better to err on the side of over-reporting than under-reporting. In any case, analysis of LogSentry's fairly verbose findings will also assist in identifying potential security weaknesses on the system.

LogSentry successfully sends mail messages to root and so per /etc/aliases and my .forward account to me. Here is a sample LogSentry report:

From root@magnolia.brighton.org  Sun Nov 24 23:00:01 2002
Return-Path: 
Received: from magnolia.brighton.org (magnolia.brighton.org [127.0.0.1])
        by magnolia.brighton.org (8.12.5/8.12.5) with ESMTP id gAP401ku007696
        for ; Sun, 24 Nov 2002 23:00:01 -0500
Received: (from root@localhost)
        by magnolia.brighton.org (8.12.5/8.12.5/Submit) id gAP401w7007693
        for root; Sun, 24 Nov 2002 23:00:01 -0500
Date: Sun, 24 Nov 2002 23:00:01 -0500
From: root 
Message-Id: <200211250400.gAP401w7007693@magnolia.brighton.org>
To: root@magnolia.brighton.org
Subject: magnolia.brighton.org 11/24/02:23.00 system check


Unusual System Events
=-=-=-=-=-=-=-=-=-=-=
Nov 24 22:46:22 magnolia su(pam_unix)[7565]: session closed for user root
Nov 24 22:46:26 magnolia su(pam_unix)[7614]: session opened for user root by (ui
d=500)
Nov 24 22:53:29 magnolia su(pam_unix)[7614]: session closed for user root
Nov 24 22:46:12 magnolia sendmail[7612]: gAP3kBku007611: forward /home/barrie/.f
orward: Group writable file

To see more verbose reporting during shutdown/boot up and the hourly regularity of messages successfully sent by LogSentry, see LogSentry function script.