Published on (
 See this if you're having trouble printing code examples

TriSentry, a Unix Intrusion Detection System

by Glenn Graham

Intrusion detection isn't anything new. Throughout the history of computer networking, administrators have worked to find ways of tracking system security breaches and identifying the culprits behind them. Network administrators have a wide range of sophisticated tools to improve auditing, and to report and block intrusion. The TriSentry suite, from Psionic Technologies, is one such free tool.

TriSentry is composed of three applications. PortSentry detects, reports, and blocks port scanning. LogSentry examines system logs for security violations and generates administrative reports. HostSentry monitors user logins and activities, detecting breaches and unusual behavior.


Port scanning, or using an automated tool to probe a host for open TCP ports, is increasingly common on the Internet. Though intended to help administrators secure their networks, port scanners may also be used by malicious users to find vulnerable services. Common exploits include daemons such as portmapper and various database applications.

The PortSentry application detects and blocks these scans. It works well on Unix and Unix-like systems. Using the principle of socket binding, PortSentry listens on a series of unused ports. If a remote host attempts to connect, its IP address is added to a blackhole list, and cannot continue its scan or make any other TCP requests. Blocking is performed either through the appropriate firewall software (ipchains or iptables on Linux, ipfw on *BSD) or through the routing table (the route utility on most Unixes).

Related Reading

TCP/IP Network Administration
By Craig Hunt

Version 1.1, well-loved by many sysadmins, also supports stealth scan detection (only for Linux), multiple protocols, and various attack responses.

Installing and Configuring PortSentry

Download the PortSentry distribution from the Psionic site. As with all new installations, review the README file for the latest instructions.

Pass the OS name (e.g. freebsd, linux, or solaris) to the make command to configure the build. For a complete list of available options, type make with no argument. Executing make install as the root user will install the binaries and configuration files with the appropriate permissions.

PortSentry is also available through the FreeBSD ports collection, in /usr/ports/security/portsentry.

After installing, edit the configuration file. By default, it's located at /usr/local/etc/portsentry.conf. This file is well-commented; configuration is vital to the correct operation or PortSentry. For our example, we'll set the listening ports and configure the firewall and route blocking options for a FreeBSD box with IPFW compiled into the kernel. It's important to remember that when using the firewall option under FreeBSD, you must have IP_FW compiled into the kernel.

PortSentry will listen for TCP and UDP packets on all ports specified in the TCP_PORTS and UDP_PORTS directives, respectively. The ports must be expressed as a list of comma-separated values, with no embedded spaces. This example has had lines broken to fit on the page, but represents one logical line per directive:



In order to block malicious users with a kernel-level packet filter, use the KILL_ROUTE directive. PortSentry will replace the string $TARGET$ with the source address, executing the result as a standard command. On FreeBSD with ipfw, the configuration will resemble:

kill_route="/sbin/ipfw add 1 deny all from $TARGET$: \ 
   to any"

In the absence of some sort of packet filtering, KILL_ROUTE can use the venerable route command as a last-ditch backup. It will only work for TCP attacks, though. The command will look something like:

KILL_ROUTE="route add -net $TARGET$ -netmask \ -blackhole"

If you have iptables, ipchains, pf, or ipfw, use that instead. See the copious comments in the configuration file for more details.

The KILL_RUN_CMD directive is also useful. It specifies a command to run after blocking a scanner. I use a custom notification alarm to mail the system administrator. It's a simple shell script, in /usr/local/etc/notify. In the interests of security, it's owned by root and wheel, and has no write permissions.


echo "My computer has been attacked" | \
   mail -s "Strobe Attack on My System"

Enabling this in portsentry.conf is as you'd expect:


This option may also be used to execute a return attack on the host, although I don't recommend doing this :-)

Occasionally, we need to allow certain hosts the ability to scan our system without being blacklisted. PortSentry checks the file portsentry.ignore for these hosts. It should normally contain entries for and localhost. TCP-based blocked hosts are added to portsentry.blocked.tcp and UDP-based blocks are added to Portsentry.blocked.udp. Their contents will persist until the next system restart. Finally, the portsentry.history file contains a running history of all blocked hosts. This file remains constant even after a reboot. It may also be exported to a database for further analysis.

Starting and Testing PortSentry

Starting PortSentry is easy:

/usr/local/bin/portsentry -tcp & 

This example uses the classic TCP detection mode with the -tcp switch. Other options may be added. For example, -sctp enables Stealth Scan mode, on Linux. -udp enables UDP mode.

Once PortSentry is running, you should test it. Various port scanners I use are nmap, ISS (Internet Security Scanner), and Strobe (available with Slackware). We will use nmap for this example.

NOTE: If the test succeeds, you will not be able to reconnect from the probing host. Plan ahead!

Scanning with nmap is easy:

nmap -O target_host

To ensure the program has blocked the attacking IP, try re-connecting to the target host. It should fail. On the host, tail the message log to ensure the attacker is identified and blocked:

Sep 19 01:50:19 striker portsentry[129]: attackalert: \
   Host has been blocked via dropped route using command: \
   "/sbin/ipfw add 1 deny all from to any"
Sep 19 01:50:19 striker portsentry[129]: attackalert: \
   Connect from host: to TCP port: 9
Sep 19 01:50:19 striker portsentry[129]: attackalert: \
   Host: is already blocked. Ignoring

When using route to drop the IP, you can examine the routing table with netstat --nr. Blocked hosts will show routes pointing to the IP you designated as your blackhole.

PortSentry 2 Betas

The recent releases of PortSentry beta versions 2.0b have seen some notable improvements. These beta versions still require some work, but are worth playing with if you need these features:

Download PortSentry 2.0b1 from the Psionic Web site. (It is not yet available as a BSD port.) You will need to edit the portsentry_config.h file to match the file paths on your system. Follow the standard compilation and configuration instructions for version 1.1. (Remember to pass your architecture name to the make command.)

If you run into compilation errors during your build, re-check the paths in portsentry_config.h and compile again. This compilation is known to work under Linux and FreeBSD. Be sure to read the README file included in the installation.

Summing up PortSentry

I've been using PortSentry since its early release and find it to be an excellent complement to the TriSentry suite of applications. Though I prefer version 1.1 in a production environment, I have confidence that version 2 will become a favorite when it is officially released.


LogSentry, originally named Logcheck, is based on a log-auditing program called, featured in the GauntletTMfirewall 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 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 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

Several other supplementary files allow LogSentry customization: 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/ 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/ 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 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 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:

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:


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.


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 Check your messages log for something resembling the following:

Sep 20 19:24:08 striker hostsentry[30542]: adminalert: \
	LOGIN User: glenn TTY: ttyp6 Host:
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:
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

Copyright © 2009 O'Reilly Media, Inc.