Part One: Installing and Configuring LogSentry
by Urbana Der Ga’had
If you haven’t automated the monitoring of your system logs, you’re flying blind. By proactively identifying hardware failures, unusual patterns of user behavior, and intrusion attempts, you can often solve problems before they become painful. festering. scars that won’t heal. Oh yes! In Part One of this article we will install and configure LogSentry(formerly logcheck) on a stand-alone Red Hat Linux system. In Part Two we will set up a central syslog server, centralize the log checking, and configure the client systems to use the central syslog server. In Part Three we will look at ways to further enhance the security and performance of this setup.
First go visit the fine folks at Psionic, who also produce PortSentry and HostSentry, two other great security products. LogSentry is free and now licensed under the GPL.
Untar and build the software.
bash-2.04# tar xvzf logsentry-1.1.1.tar.gz bash-2.04# make linux make install SYSTYPE=linux make: Entering directory `/usr/local/src/logcheck-1.1.1' Making linux cc -O -o ./src/logtail ./src/logtail.c ./src/logtail.c: In function `main': ./src/logtail.c:51: warning: return type of `main' is not `int' Creating temp directory /usr/local/etc/tmp Setting temp directory permissions chmod 700 /usr/local/etc/tmp Copying files cp ./systems/linux/logcheck.hacking /usr/local/etc cp ./systems/linux/logcheck.violations /usr/local/etc cp ./systems/linux/logcheck.violations.ignore /usr/local/etc cp ./systems/linux/logcheck.ignore /usr/local/etc cp ./systems/linux/logcheck.sh /usr/local/etc cp ./src/logtail /usr/local/bin Setting permissions chmod 700 /usr/local/etc/logcheck.sh chmod 700 /usr/local/bin/logtail chmod 600 /usr/local/etc/logcheck.violations.ignore chmod 600 /usr/local/etc/logcheck.violations chmod 600 /usr/local/etc/logcheck.hacking chmod 600 /usr/local/etc/logcheck.ignore Done. Don't forget to set your crontab. make: Leaving directory `/usr/local/src/logcheck-1.1.1'
By default the software will be installed in /usr/local/etc. Edit logcheck.sh to configure the user who should receive the logcheck reports. Search for:
Change this variable to some appropriate alias that you use to receive security related mail. You can also check out the command paths in this script to make sure they’re ok for your system, they have been fine on our Red Hat system.
Add a cron job, using either the crontab command to edit root’s crontab (in /var/spool/cron/) or adding an entry in /etc/crontab if you prefer. I am old-fashioned so I use crontab to edit the old style crontab.
Add a line like this:
0,30 * * * * /usr/local/etc/logcheck.sh
We recommend running the logcheck script at least every thirty minutes.
Now you can start customizing the filters. Do peruse the README files that come with LogSentry. There are excellent tips about how to configure syslog, what the keywords and filters mean and suggestions as to how one should respond to security violations.
[root@goblin etc]# ls -al total 44 drwxr-xr-x 4 root root 4096 Jun 4 08:45 . drwxr-xr-x 22 root root 4096 May 26 16:36 .. -rw------- 1 root root 1037 Jun 4 08:45 logcheck.hacking -rw------- 1 root root 1172 Jun 4 08:45 logcheck.ignore -rwx------ 1 root root 10633 Jun 4 08:45 logcheck.sh -rw------- 1 root root 407 Jun 4 08:45 logcheck.violations -rw------- 1 root root 14 Jun 4 08:45 logcheck.violations.ignore
The files logcheck.hacking and logcheck.violations contain patterns which trigger security alerts when matched. The files logcheck.violations.ignore and logcheck.ignore contain patterns which will be ignored when found in the logs.
There are three levels of alert in the logcheck reports. “ACTIVE SYSTEM ATTACK” will include messages which matched patterns in logcheck.hacking. “Security Violations” will include anything which matched patterns in logcheck.violations and did not match when reverse checked against logcheck.violations.ignore. “Unusual System Activity” will include anything found in the logs which did not match an entry in logcheck.ignore, the catch-all file for patterns which are safe to ignore. This is the file you want to work with, following the theorem of “that which is not explicitly permitted is forbidden.”
Once you’ve got LogSentry installed and the cron job set up to run it periodically, you will start getting a bunch of mail. This is how you start to determine which messages are safe to ignore. Be careful to make the strings as specific as possible, you want to control very closely what is ignored. As an example, we are going to exclude some ordinary pop3 messages from the alerts. These log entries came from /var/log/maillog, and were sent to us in our logsentry report. We will paste the entry from the report into logcheck.ignore, and edit the line to make it a valid pattern for logsentry to match.
Jun 2 04:06:17 goblin ipop3d: Login user=cindy host=hop.pop.com [220.127.116.11] nmsgs=0/0 Jun 2 04:06:18 goblin ipop3d: Logout user=cindy host=hop.pop.com [18.104.22.168] nmsgs=0 ndele=0
goblin ipop3d.*: Login user=cindy host=hop.pop.com [22.214.171.124] nmsgs=.* goblin ipop3d.*: Logout user=cindy host=hop.pop.com [126.96.36.199] nmsgs=.*
Notice the use of the wildcard .* to match 0 or more characters, also special characters such as () or  should be escaped with a backslash. Also, be sure there are *no* blank lines in your logcheck.ignore or logcheck.violations.ignore files, because that will cause logsentry to ignore everything! Not what you want.
Next Time: let’s centralize control.