TriSentry, a Unix Intrusion Detection System
Pages: 1, 2

LogSentry

LogSentry, originally named Logcheck, is based on a log-auditing program called frequentcheck.sh, featured in the Gauntlet^TMfirewall package by Trusted Information Systems Inc., and cloned under license by Psionic.

LogSentry automates log-file auditing by grepping for predefined keywords within message and mail logs. When it finds a match, it notifies the System Administrator by mailing a security alert. The application is known to run under platforms ranging from Linux to Solaris and FreeBSD. It can be configured to report entries containing specific keywords and to report entries that do not contain other keywords.

LogSentry comes in two pieces, a shell script named logcheck.sh and a binary named logtail. The shell script runs hourly (from cron), reading the most recent messages from the log files, looking for attack messages from syslog or PortSentry. Any violations are mailed to the system administrator. The binary keeps track of the last position of each log file, so as not to re-review old messages.

Installing and Configuring LogSentry

To obtain LogSentry, download the tarred source available from Psionic. Optionally, you may choose to install this as a packaged port under FreeBSD called /usr/ports/security/logcheck. Be sure to read the INSTALL and README files prior to proceeding.

LogSentry configuration requires editing the well-commented logcheck.sh file. While reviewing the variables below, scroll through the script to familiarize yourself with its functionality.

Provided you have compiled under a supported platform, the default configuration should be sufficient. To be sure, check the following within logcheck.sh:

• Ensure your search path is correct.
• Set the SYSADMIN variable to the person who will receive violation messages.
• Verify the full path to logtail.

Several other supplementary files allow LogSentry customization:

• logcheck.hacking contains keywords that identify attacks on your system.
• logcheck.violations contains keywords of negative system events. Examples include denied or refused connections, such as striker [proftpd] connection refused.
• logcheck.violations.ignore contains keywords that are reverse-searched against the logcheck.violations file. Violations are not reported if one of these keywords is present. For example, local mail errors can be skipped with the line mailer=local.
• logcheck.ignore is the catch-all file for keywords to ignore. Messages containing these words will not be reported. Be sure not to add too many wildcards or messages that may indeed be system breaches.

logcheck.sh may also be customized to check various logs as defined under syslog.conf. For maximum benefit, set the latter to report as much information as possible.

Starting LogSentry

Before running LogSentry, verify that the file has the proper permissions. I recommend setting a mode of 700 and an owner and group of root and wheel. Next, ensure it is error-free by running /usr/local/etc/logcheck.sh by hand. If that works, add an entry to cron. I like to redirect all output to /dev/null explicitly:

0 * * * *    root  /usr/local/etc/logcheck.sh 1> /dev/null 2> /dev/null

LogSentry also works well in larger networks, where dozens or hundreds of servers may report syslog activity to a central server. An administrator can tail the output, grabbing local logs as necessary. (Each server must use some method to synchronize its time; I use ntpdate). For more information on syslogd and how to set up a remote monitor, please refer to Michael Lucas's article on syslogd.

Summing up LogSentry

Understanding LogSentry is easy. Once installed, it outperforms many commercial products. Overall, I give LogSentry two thumbs up for performance, compatibility, and stability.

Related Reading Python Cookbook By David Ascher, Matt Margolin, Alex Martelli

HostSentry

HostSentry is the third application in the TriSentry suite. It uses a dynamic, Python-based database to track user activity. This helps it to detect unusual logins, suspicious domains and directories, tampered command histories, and unknown login attempts. Administrators can quickly respond to anomalies and compromised accounts.

HostSentry requires Python. Download version 2.2.1 or greater from http://www.python.org/. It's also in the FreeBSD ports collection. If you compile it, be sure to activate the syslog and gdbm modules.

The database records login and logout events, as well as login problems. The current version of the schema includes the following fields:

• username, the login name of the user.
• recordCreated, the date in Unix epoch time when the record was first created.
• firstLogin, the first login recorded for this user
• trackLogins, a list of logins the user has made. This list is variable in size, depending on your configuration. Old logins roll off of the end once maximum size is achieved.
• validLoginDays, the days this user is allowed to log into the system.
• validLoginHours, the hours this user is allowed to log into the system.
• adminDisabled, a flag indicating this account has been disabled by an administrator.
• securityDisabled, a flag indicating this account has been disabled by an automated module action.
• totalLogins, total logins this user has had since HostSentry began operation.
• version, the database schema version.

HostSentry Configuration

On most systems, the default configuration will suffice. Configuration takes place by editing any or all of the three initial files. They are well-commented.

hostsentry.conf contains file paths and the main configuration. Ensure that each path is correct:

IGNORE_FILE="/usr/local/abacus/hostsentry/hostsentry.ignore"
ACTION_FILE="/usr/local/abacus/hostsentry/hostsentry.action"
MODULE_FILE="/usr/local/abacus/hostsentry/hostsentry.modules"
MODULE_PATH="/usr/local/abacus/hostsentry/modules"
WTMP_FILE="/var/log/wtmp"
DB_FILE="/usr/local/abacus/hostsentry/hostsentry.db"
DB_TTY_FILE="/usr/local/abacus/hostsentry/hostsentry.tty.db"

hostsentry.modules determines which modules to execute on login and logout and the order in which to execute them. To prevent a module from running, remove it from this file. This is a simple instructional set of how each loaded module executes and in what order.

moduleLoginLogout
moduleFirstLogin
moduleForeignDomain
moduleMultipleLogins
moduleRhostsCheck
moduleHistoryTruncated
moduleOddDirnames

hostsentry.ignore contains a list of user names for HostSentry to ignore. For example, the ftp user might be ignored, as a large number of legitimate-but-anonymous logins would cause many false alarms. Place usernames that you want to ignore in this file, with one user per line:

ftp

After completing the configuration, test the program with the command python hostsentry.py. Check your messages log for something resembling the following:

Sep 20 19:24:08 striker hostsentry[30542]: adminalert: \
	LOGIN User: glenn TTY: ttyp6 Host: 192.168.1.1
Sep 20 19:24:08 striker hostsentry[30542]: securityalert: \
	First time login for user: glenn
Sep 20 19:24:08 striker hostsentry[30542]: securityalert: \
	Action being taken for user: glenn
Sep 20 19:24:08 striker hostsentry[30542]: securityalert: \
	Module requesting action is: moduleFirstLogin
Sep 20 19:24:08 striker hostsentry[30542]: securityalert: \
	Foreign domain login detected for user: glenn from: 192.168.1.1
Sep 20 19:24:08 striker hostsentry[30542]: securityalert: \
	Action being taken for user: glenn
Sep 20 19:24:08 striker hostsentry[30542]: securityalert: \
	Module requesting action is: moduleForeignDomain

Finally, automate the startup using standard scripts, such as rc.local.

Summing up HostSentry

To understand HostSentry fully, you should have some knowledge of Python. The Python DevCenter has more information. I've been using HostSentry for about three months and find it a robust method of monitoring user logins and anomalies.

Glenn Graham has been working with telecommunications since 1977.

---

Return to ONLamp.com.