Freeware Intrusion Detection Tools

Ido Dubrawsky

Firewalls and access control lists were once thought to be the ultimate solutions in preventing network intrusion. Unfortunately, neither tool provides the capability to respond to or provide real-time detection of an intrusion attempt. This is the gap that an Intrusion Detection System (IDS) fills. An IDS provides continual real-time or near-real-time monitoring of a host or a network.

Intrusion detection systems can be divided into two primary categories: network-based and host-based. Network-based IDS tools monitor network traffic on the local LAN, analyzing traffic that "fits" a known signature for a given exploit, and then notifies the proper contacts of its findings. Host-based IDS tools provide detection of an intrusion on a system within the network. Although the ideal case would be to prevent a system intrusion from happening, the fact is that even with a network IDS in place, it is still possible for an attacker to find ways around it. If that happens, a host-based IDS may be able to determine whether the attacker has succeeded in penetrating a given system.

Network-based IDS tools come in two forms: real-time and near-real-time. Real-time network-based IDS report suspicious traffic as soon as it is detected on the wire. Near-real-time IDS work by gathering network traffic and then at a predetermined time interval (such as once an hour) provide an analysis of the previous interval's data. One of the benefits of real-time IDS is the capability to respond to an attack as it is happening. Near-real-time IDS also provide sufficient notification of an attack in progress.

Host-based IDS monitor system files (such as wtmp/utmp on UNIX systems) and log files as well as check the integrity of system binaries to determine whether an intrusion has occurred. These types of IDS utilize an agent that resides on the host being monitored.

Some of the more popular network IDS tools include commercial products, such as the Cisco Secure Intrusion Detection System (CSIDS, formerly NetRanger), ISS's RealSecure, and NFR's Network Flight Recorder. Some popular host-based IDS tools include Tripwire (in its commercial form), Symantec's Intruder Alert, and Entercept by Entercept Security Technologies. However, you don't have to spend thousands of dollars to get the benefits of an IDS. Several freeware network and host-based intrusion detection systems are available on the Internet, and they can provide a comparable level of protection as their commercial brethren.

Snort

Snort is defined as a "lightweight Intrusion Detection System". By definition, lightweight IDS should have a small system footprint, provide for cross-platform support, and easy installation. Snort fits all three requirements. It utilizes the libpcap library (originally developed at Lawrence Berkeley Laboratory) for sniffing traffic and then analyzing the packet payloads.

Snort is configured by command-line options as well as Berkeley Packet Filter commands. The heart of the Snort detection engine is a set of rules written in a simple language that allows for per packet tests and actions. Snort's detection rules can also be modified and extended by the end user. There are three primary subsystems to Snort:

1. Packet decoder

2. Detection engine

3. Logging and alerting system

The packet decoder engine's subroutines impose order on the packet data in each of the TCP/IP layers by overlaying data structures on top of the raw network traffic. The detection engine utilizes a two-dimensional linked list of rules to identify network attacks. Finally, the logging and alerting system provides various mechanisms to notify the proper individuals of suspicious activity. The alert mechanisms include sending messages to syslog, logging to an alert text file, and using the WinPopup messages through sambaclient.

Imposing order on network traffic involves inspecting packets from the data link layer to the application layer, copying each layers data into internal data structures and then setting pointers to these data structures. In essence, Snort copies the essential traffic data into memory and then passes those data structures to the detection engine for analysis.

Snort monitors network traffic looking for predefined suspicious activity. The activity which snorts considers suspicious is contained within a database made up of rules that characterize various attack signatures. Attacks are not just identified based upon traffic to a port, but also by inspecting the packet payloads. For example, in order to recognize a IIS Unicode directory traversal attack, Snort must look at the data being sent to the Web server, which may be the target. However, other attacks may be identified based on destination port. Traffic on a network destined for port 12345 on a host may indicate the presence of the NetBus trojan on that host.

Installation

Snort is currently supported under many operating systems. The main requirement for installing Snort is the presence of the libpcap library. Although the libpcap library was originally developed at the Lawrence Berkeley Laboratory, development of the library is now done by the "TCPdump Group" (http://www.tcpdump.org). Libpcap-0.6.2 is the most recent version of the libpcap library as of this writing. Most BSD-based systems (i.e., FreeBSD, NetBSD, OpenBSD) as well as some Linux systems already come with libpcap installed. Be sure to check whether your system already has the libpcap software installed.

Snort can be downloaded from the main Snort Web site:

http://www.snort.org

The software can be unpacked after it is downloaded:

$ gzip -dc snort-1.7.tar.gz | tar -xvf -
snort-1.7/contrib/ACID-0.9.5b9.tar.gz
snort-1.7/contrib/SnortSnarf-111500.1.tar.gz
snort-1.7/contrib/Spade-0922001.tar.gz
...
snort-1.7/README.Spade.Usage
snort-1.7/LICENSE
snort-1.7/cdefs.h

$./configure
...(output from the configure script)
$ make
...(output from make), and
$ make install

var HOME_NET 192.168.1.1/30

var HOME_NET $ppp0_ADDRESS

Plug-ins

Plug-ins have been available in Snort as of version 1.5. Snort Plug-ins come in two forms: detection plug-ins, and preprocessors. Preprocessors provide for complex functions, such as TCP stream reassembly, IP defragmentation, or HTTP request normalization. Preprocessors are only called once per packet, can directly manipulate packet data, and even call the detection engine directly with their modified data. The IP defragmentation, HTTP request normalization, and portscan preprocessors are active by default in the snort.conf file. To activate additional preprocessors, simply uncomment the preprocessor directive in the configuration file.

Detection plug-ins check a single aspect of a packet for a value defined within a rule and determine whether the packet data meets the acceptance criteria. Detection plug-ins can be called multiple times per packet.

The configuration file allows for the definition of the Snort output. This is accomplished using the output plugins. These plug-ins allow for logging to syslog, a dedicated file, or a SQL database. The directive for output plug-ins has the form:

output <name of plugin>: <configuration options>

output alert_syslog: LOG_AUTH LOG_ALERT

output log_tcpdump: snort.log

{
  type filelog
  output log_tcpdump: snort.log
  output alert_syslog: LOG_AUTH LOG_ALERT
}

The final item to configure in the snort.conf log is the rule set. The latest Snort rules are available at http://www.snort.org or http://www.whitehats.com. Using all of the rule sets defined in the snort.conf at the same time can result in performance degradation. If you're not running a Web server, the Web plug-ins can be disabled in the snort.conf file. It is best to tailor the plug-ins to the services you provide. The current default list of rule sets in the snort.conf are:

web-lib      - For generic web traffic
webcgi-lib   - CGI specific exploits
webcf-lib    - Coldfusion exploits
webiis-lib   - Microsoft IIS specific exploits
webfp-lib    - Misrosoft FrontPage exploits
webmisc-lib  - Miscellaneous web exploits
overflow-lib - Buffer Overflow ruleset
finger-lib   - Finger exploit ruleset
ftp-lib      - FTP exploit ruleset
smtp-lib     - SMTP exploit ruleset
telnet-lib   - Telnet exploit ruleset
misc-lib     -  Miscellaneous exploit (i.e. SNMP, DNS, etc) ruleset
netbios-lib  - NetBIOS exploit ruleset
scan-lib     -  Monitors for scans (such as Nmap Fingerprinting, etc)
ddos-lib     -  Monitors for traffic between DDoS clients and handlers
backdoor-lib -  Monitors for traffic to and from backdoor software such as BackOrifice, Netbus, and others
ping-lib     - Monitors ICMP traffic
rpc-lib      - RPC exploit ruleset

# /usr/local/bin/snort -de -l /var/log/snort/packets -c /etc/snort.conf

Shadow

Another network IDS package is the Shadow system. Shadow grew out of another project called the Cooperative Intrusion Detection Evaluation and Response (CIDER) project. While Snort provides for a real-time network intrusion detection capability, Shadow provides a near-real-time intrusion detection. This difference grows out of the fact that Shadow updates its information at a predefined interval (the Shadow documentation speaks in terms of one hour time intervals). On the other hand, Shadow provides for data analysis. This analysis helps reduce false alarms.

One of the advantages of Shadow is that it provides for the ability to look at events over user-defined periods. If, for instance, an admin wishes to see all of the events of the previous 24 hours, Shadow can do that. Shadow comes with various scripts that allow an administrator to look for patterns in network traffic over a given period. One big advantage of the Shadow system over Snort is the ability to have a more distributed IDS model. Shadow allows an administrator to deploy sensors all over the network and have a single analysis system to collect all the logs from the sensors. This provides a single location where all data from the sensors can be viewed.

The Shadow system usually comprises two systems: a sensor and an analyzer. The sensor usually sits between an organization's firewall and its Internet connection. The analyzer is located behind the firewall. The Shadow sensor collects traffic going to and from the organization.

Shadow relies on the tcpdump software package (available at: http://www.tcpdump.org) as well as the libpcap library (also available at: http://www.tcpdump.org). The Shadow software can be obtained from the Naval Surface Warfare Center's Dahlgren Lab Web site at http://www.nswc.navy.mil/ISSEC/CID. The analyzer then collects the traffic logs from the sensor, examines the data and filters it, and finally, displays the network traffic on a Web page. The Shadow software package comes with a wide variety of filters that can be used to sift through the data collected from the sensor, and identify suspicious events. This helps the administrator remove any traffic that does not match the patterns defined in the filters before it is displayed. This also helps focus the administrator on the key events that may be traversing the network. Also, Perl, tcpdump, libpcap, nmap, tcpshow, sudo, and gzip are required for the Shadow system to work. Secure shell is also necessary. In essence, a Linux- or BSD-based host works very well as either a sensor, an analyzer, or both under Shadow.

Installation

The sensor is a UNIX-based system. Because of the way the Shadow software collects data, the authors recommend a system with at least 32 MB of memory and at least 9 GB of disk space. It is probably more reasonable to have 64 MB of memory and 20 GB of disk space, especially if the sensor will be capturing application layer data as well as the IP headers. The Shadow software requires a large partition mounted onto the /LOG directory of the sensor. After the sensor system is installed, compile and install the libpcap library and the tcpdump software package:

# gzip -dc libpcap-0.6.2.tar.gz | tar -xvf -
... output from tar
# cd libpcap-0.6.2
# ./configure
# make
# make install

# gzip -dc tcpdump-3.6.2.tar.gz | tar -xvf -
...output from tar
# cd tcpdump-3.6.2
# ./configure
# make
# make install

Unpack the Shadow tarfile (downloaded from the Naval Warfare Center's Web site mentioned previously):

# gzip -dc step.tar.gz
# cd SHADOW-1.6
# ls
accessories/      fetchem.pl*    one_day_pat.pl*     sites/
analyzer_crontab  filters/       one_day_script.pl*  sort_and_resolve.pl*
cleanup.pl        find_scan.pl*  pat_match.pl*       strip.pl*
docs/             httpd/         sensor/

# ls sensor
README.scripts  sensor_crontab    start_logger.pl*  stop_logger.pl*
gmt.filter      sensor_driver.pl  std.filter
gmt.ph          sensor_init.sh    std.ph

Once the files are installed on the sensor, you will need to install the cronjobs listed in the sensor_crontab file into cron. The sensor_crontab file contains three commands:

/usr/bin/rdate -s time-a.nist.gov,
/sbin/hwclock --systohc (meaningful only on Linux systems), and
/usr/local/logger/sensor/sensor_driver.pl std > /dev/null 2>&1

With the sensor installed, the analysis station can be set up. The fetchem.pl script should be installed in /usr/local/logger and an hourly cronjob should be added:

7 * * * * /usr/local/logger/fetchem.pl > /dev/null 2>&1

To customize all of these scripts, create a Perl header file, GENERIC.ph, in the sites directory. This file should be renamed to the name of your site, because the Perl scripts all require the site name on the command line. This Perl header file contains default values for variables used in all of the other Perl scripts.

Shadow also comes with CGI scripts written in Perl and other files for use on the analyzer. These should be in installed in the appropriate places of the Web server root directory. After all of this is complete, the Shadow will be ready for production use.

Host-Based Intrusion Detection

Host-based IDS utilize logfile information as well as file signatures to determine whether a system has been compromised. In this category are software packages such as Tripwire, AIDE, SWATCH, FCheck, LIDS, and Psionic Software's LogCheck, PortSentry, and HostSentry packages.

Tripwire

Possibly the original host IDS, Tripwire was originally developed in 1992 by Dr. Eugene Spafford and one of his graduate students, Gene Kim, while at Purdue University's COAST lab. In 1997, Gene Kim led the founding of Tripwire Inc. and licensed the Tripwire source code from Purdue. The original source of Tripwire is still available through Tripwire, Inc. as Tripwire 1.3.1-ASR (ASR stands for Academic Source Release). An open source version of Tripwire (based on the Tripwire 2.0 release) is available from: http://www.tripwire.org in pre-built binary form. The source code to the open source Tripwire can be found at: http://sourceforge.net/projects/tripwire. The rest of my discussion about Tripwire will focus on the open source version (currently 2.3.1).

Tripwire works by compiling a database of signatures (usually message digests) of specified system files. It then periodically compares the signatures of those specified files against the database. If the calculated signature of a file does not match the signature for that file in the database, a system compromise is assumed and the proper party (usually the systems administrator) is notified.

Installing Tripwire is fairly straightforward. To build the latest version of Tripwire, you will need gcc 2.95.2 or better on your system. When you have the software, unpack the gzipped tarfile and cd to the tripwire-2.3.1-2/src directory to edit the master makefile. This makefile controls the creation of the programs: Tripwire, twadmin, twprint, and siggen. Specify the platform type (Linux or FreeBSD) in the makefile by changing the value of the SYSPRE variable to the appropriate type. Then type "make release" to build the above binaries.

By default, Tripwire looks in /etc/tripwire for its configuration file, tw.cfg, its policy file, tw.pol, and its key files, site.key and $(HOSTNAME)-local.key. The tripwire database is stored in /var/lib, and the default report directory is /var/lib/tripwire/report.

The first step in setting up Tripwire once it has been built and installed is running it in Database Initialization mode. This creates a baseline database of the system. It is recommended that database initialization be done in single-user mode, right after the system has been installed so that there is no doubt that the database was created on a fresh, non-compromised system. Once database initialization is done, Tripwire should be periodically run from cron in the Integrity Checking Mode. Here Tripwire scans through the system looking at the files and directories it scanned in Database Initialization Mode. Tripwire calculates the signatures of these files and directories and compares them against the signatures stored in its database. If a difference is found between two signatures for the same file or directory, Tripwire notifies the systems administrator of the problem either through email or in a system logfile.

Another mode found in Tripwire is the Database Update Mode. This mode is used to update the tripwire database in case a patch or a new software package has been added to the system. In this way, the installation of the patch or software will not produce a false alarm because of the change in the signature of the files or directories affected.

AIDE

AIDE stands for Advanced Intrusion Detection Environment, and the software is meant as a free replacement to Tripwire. AIDE originally appeared when Tripwire was a strictly commercial product. AIDE is written in C and provides a variety of features including using a Postgres SQL database as a back-end for storing the hash signatures of the files AIDE is configured to monitor. The AIDE tarfile can be obtained from the Web site: http://www.cs.tut.fi/~rammer/aide.html. To install AIDE and compile:

# gzip -dc aide-0.7.tar.gz | tar -xvf -
# cd aide-0.7
# ./configure
# make
# make install

FCheck

FCheck, written by Michael Gumienny, is another freely available file integrity checker similar to Tripwire and AIDE. FCheck has the capability to monitor files, directories, or even complete filesystems for any additions, deletions, or modifications. It is a Perl program and requires only one other file, the fcheck.cfg configuration file. To install FCheck, simply download it from Michael Gumienny's page at: http://www.geocities.com/fcheck2000. The software can run on UNIX or Windows systems. To install, simply untar the gzipped FCheck tarfile, copy the FCheck program and the fcheck.cfg configuration file to wherever you want them kept and edit the configuration file to set a few variables. For example:

# gzip -dc FCheck_2.07.59.tar.gz | tar -xvf -
fcheck/
fcheck/license
fcheck/fcheck
fcheck/fcheck.cfg
fcheck/README
fcheck/install
# cd fcheck
# cp fcheck fcheck.cfg /usr/local/fcheck
# cd /usr/local/fcheck
# vi fcheck.cfg

SWatch

SWatch (short for the Simple Watcher) monitors the system logfiles for any suspicious activity. SWatch is written in Perl and relies heavily on regular expression matching. To operate, SWatch requires several Perl modules including Time::HiRes (which will require the Bit::Vector module), Date::Calc, Date::Format, and File::Tail. If these modules are not installed on the system, the SWatch Makefile.PL will ask if you want to download the module from CPAN. SWatch can be downloaded from:

http://www.stanford.edu/~atkins/swatch

# Perl Makefile.PL
# make
# make test
# make install
# make realclean

Logcheck/HostSentry/PortSentry

Logcheck, PortSentry, and HostSentry are products from Psionic Software. They are available from Psionic's Web site: http://www.psionic.com. Each package is designed to perform a unique function. HostSentry reacts to login/logout activity by monitoring the utmp/wtmp files on UNIX systems, LogCheck spots problems and security violations by processing information in various system log files on UNIX systems, and PortSentry can detect and respond in real-time to port scans against a target host. Of the three packages, HostSentry is still in the very early alpha stage. Logcheck and PortSentry are mature packages that can be utilized across an organization's network.

HostSentry

HostSentry is written entirely in the Python programming language. If you have Python already installed on the system, you will need to recompile it to activate the syslog and dbm/gdbm functions. Once Python is installed properly, simply type "make install" in the HostSentry directory. This will install the HostSentry software in the /usr/local/abacus directory.

To configure HostSentry, edit the hostsentry.conf file in /usr/local/abacus. There are several variables defining files that HostSentry needs. These must be defined in the hostsentry.conf. The file hostsentry.modules defines which modules HostSentry will use to generate alerts. The hostsentry.ignore file contains a list of users for which HostSentry should never generate an alert. Once all the configuration files have been edited, HostSentry can be started with the simple command:

# python hostsentry.py
PortSentry

1. Log the incident via syslog(),

2. Drop the "attacking" host by adding its IP address into /etc/hosts.deny,

3. Reconfigure the local host to that all traffic from the attacker to the target is then sent to a dead host, or

4. Reconfigure the local host to drop all packets from the attacker using a local packet filter (ipfw for BSD, or ipchains for Linux).

Installation of PortSentry requires editing the portsentry_config.h file. This file contains definitions for the location of the portsentry.conf file as well as the TCP_wrappers hosts.deny file. It also contains the definition of what syslog level and facility PortSentry will use when sending incident information to syslog. Once that is done, simply type:

# make <OS type>

# make install

Logcheck

The third software package available from Psionic Software is Logcheck. Logcheck runs automatically and checks system log files for security violations and unusual activity. Logcheck is comprised of a shell script and a C program called logtail. Logtail remembers the last position it read from in a log file and then uses this position on subsequent runs to process any new information. The logcheck.sh shell script is the heart of the Logcheck package. The logcheck.sh script is run from cron at a predetermined interval. This script calls logtail on the various logfiles it monitors, extracts the events that occurred since the last time it was called, and then mails the report to the systems administrator.

To build Logcheck, simply type:

# make <OS type>

5 * * * * /usr/local/etc/logcheck.sh

The Linux Intrusion Detection System (LIDS) is a kernel patch for the Linux kernel as well as an admin tool for enhancing security. LIDS implements a reference monitor and mandatory access control in the Linux kernel. When LIDS is in effect, file access, system and network administration operations, raw device file access, and memory and I/O access can be made impossible, even for root! LIDS not only provides protection but detection as well. Like PortSentry, LIDS can detect port scans against the host and notify the systems administrator. LIDS can also detect other access rule violations as well.

LIDS can also respond to any access rule violation. This response can either be through logging to syslog or even terminating a user session. LIDS' flexibility make it ideal as a host intrusion detection and response tool.

The kernel patch and LIDS administrative software can be downloaded from the LIDS Web site: http://www.lids.org. Incorporating LIDS into a Linux system requires that the proper kernel patch be applied to the kernel source tree -- that is for kernel 2.2.19, the LIDS patch lids-0.9.15-2.2.19 should be used. Once the patch is applied, the kernel should be rebuilt and installed. Also, the lidsadm program should be built and the LIDS system configured. After all of that is done, the system should be rebooted with the new kernel and then sealed. A detailed discussion of the LIDS system is beyond the scope of this article, however, the LIDS Web site contains excellent documentation of the LIDS software as well as how to integrate it into a Linux system.

Network IDS and host-based IDS can be used together to help protect a network. The network IDS can monitor all traffic on the network and identify an attack while the host-based IDS can provide administrators with the ability to detect if an attack against succeeded in compromising a host. As stated earlier, a network IDS only knows about attacks that match the patterns in its filters. All network IDS have this "blind spot". This is where a host- based IDS is handy in conjunction with a network IDS. A host-based IDS can remove the blind spot by providing continuous monitoring of hosts so that if an attack succeeds in evading the network IDS, a host compromise can still be detected.

Intrusion Detection Systems come in two predominant forms: host-based and network. These two categories can then be broken down further into real-time and near-real-time response systems. In the real-time category for freeware network IDS is Snort, whereas the near-real-time freeware IDS is Shadow. Under host-based IDS, the real-time packages include the Linux Intrusion Detection System (LIDS), PortSentry, and HostSentry. Near-real-time host IDS include Tripwire, FCheck, AIDE, and Logcheck. Utilizing any of these to protect a network or host provides systems and network administrators with greater capabilities in securing their systems.

Ido Dubrawsky has been working in UNIX and network administration field for nine years. When not working on security, he spends his free time with his wife, Diana, their two children, and their dog, Reidy. He is currently employed by Cisco Systems in the Cisco Secure Consulting Service as a Network Security Engineer.