TriSentry, a Unix Intrusion Detection System
Pages: 1, 2
LogSentry, originally named Logcheck, is based on a log-auditing program
frequentcheck.sh, featured in the GauntletTMfirewall package by Trusted Information Systems Inc., and cloned under license by
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
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
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
- Ensure your search path is correct.
- Set the
SYSADMINvariable to the person who will receive violation messages.
- Verify the full path to
Several other supplementary files allow LogSentry customization:
logcheck.hackingcontains keywords that identify attacks on your system.
logcheck.violationscontains keywords of negative system events. Examples include denied or refused connections, such as
striker [proftpd] connection refused.
logcheck.violations.ignorecontains keywords that are reverse-searched against the
logcheck.violationsfile. Violations are not reported if one of these keywords is present. For example, local mail errors can be skipped with the line
logcheck.ignoreis 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
syslog.conf. For maximum benefit, set the latter to
report as much information as possible.
Before running LogSentry, verify that the file has the proper permissions.
I recommend setting a mode of
700 and an owner and group of
wheel. Next, ensure it is error-free by
/usr/local/etc/logcheck.sh by hand. If that works, add an entry to
cron. I like to redirect all output to
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
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.
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
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.
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:
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: adminalert: \ LOGIN User: glenn TTY: ttyp6 Host: 192.168.1.1 Sep 20 19:24:08 striker hostsentry: securityalert: \ First time login for user: glenn Sep 20 19:24:08 striker hostsentry: securityalert: \ Action being taken for user: glenn Sep 20 19:24:08 striker hostsentry: securityalert: \ Module requesting action is: moduleFirstLogin Sep 20 19:24:08 striker hostsentry: securityalert: \ Foreign domain login detected for user: glenn from: 192.168.1.1 Sep 20 19:24:08 striker hostsentry: securityalert: \ Action being taken for user: glenn Sep 20 19:24:08 striker hostsentry: securityalert: \ Module requesting action is: moduleForeignDomain
Finally, automate the startup using standard scripts, such as
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.