Cover V10, I08



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 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.


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" ( 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:
The software is available as a source-code tarball, RPM package, a Solaris package, a Win32 prebuilt executable in a WinZip file, or as a Win32 source code in a WinZip file. The current version of Snort as of this writing is version 1.7. The installation described here will assume that the source-code tarball is being used to install the Snort software.

The software can be unpacked after it is downloaded:

$ gzip -dc snort-1.7.tar.gz | tar -xvf -
To build the software, cd to the Snort directory and run the configure script. To determine all of the possible flags that the configure script takes, use the ./configure --help command. Snort allows for various options including the use of a database back-end for log writes. The databases currently supported include mySQL, postgreSQL, and Oracle. To build the basic version of Snort:

...(output from the configure script)
$ make
...(output from make), and
$ make install
Snort uses a configuration file called snort.conf. This sample file provides detailed instructions on how to configure Snort. One of the first things to do when configuring Snort is to set the HOME_NET variable to reflect the local network. The network can be specified explicitly using network/mask style notation or it can be specified using a global environment variable $<intname>_ADDRESS. For example, if the local network was with a netmask of, the configuration would be:

If the IP address assigned to the system running Snort is provided dynamically by an ISP, you can use the $<intname>_ADDRESS to have Snort determine the IP address upon startup. In this case, the HOME_NET variable would be similar to:

With the HOME_NET variable defined, the next section to configure for Snort are the preprocessors.


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>
A typical output would be:

output alert_syslog: LOG_AUTH LOG_ALERT
This output says to log all Snort output to the syslog daemon using the LOG_AUTH facility and LOG_ALERT level. To log to a dedicated logfile:

output log_tcpdump: snort.log
It is possible to define new rule types and associate one or more output plug-ins with that type. To have logs go to both the syslog facility as well as a dedicated logfile:

  type filelog
  output log_tcpdump: snort.log
  output alert_syslog: LOG_AUTH LOG_ALERT
Rule Set Configuration

The final item to configure in the snort.conf log is the rule set. The latest Snort rules are available at or 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
Once the snort.conf file is tailored to the specific environment, the Snort program can be started. To start Snort in network intrusion detection mode:

# /usr/local/bin/snort -de -l /var/log/snort/packets -c /etc/snort.conf
The -de flag tells Snort to dump the application layer data as well as log the layer 2 packet header data. The -l specifies the directory where suspicious packets should be logged. The -c flag specifies the Snort configuration file. (For more information on Snort, refer to Kristy Westphal's articles in the September 2000 and June 2001 issues of Sys Admin.)


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: as well as the libpcap library (also available at: The Shadow software can be obtained from the Naval Surface Warfare Center's Dahlgren Lab Web site at 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.


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
When libpcap is built and installed, tcpdump can be built.

# gzip -dc tcpdump-3.6.2.tar.gz | tar -xvf -
...output from tar
# cd tcpdump-3.6.2
# ./configure
# make
# make install
By default, the configure script looks for the libpcap.a library in ../libpcap-0.6.2, so be sure to build the libpcap library in the same parent directory as you build the tcpdump software. Also by default, cryptographic support is built into tcpdump to help analyze IPSec traffic. With the libpcap and tcpdump built and installed on the sensor, Shadow can now be installed.

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/**     sites/
analyzer_crontab  filters/*****
docs/             httpd/         sensor/
The files for the sensor can be found in the sensor directory.

# ls sensor
README.scripts  sensor_crontab**
gmt.filter  std.filter
These files are written in Perl and include a start script,, which should be installed in /etc/rc.d/init.d if the sensor is a Linux system. This file is Linux specific and must be modified to work under a non-Linux system. Copy over the Perl files, the Perl header files, and the filter files to the /usr/local/logger/sensor directory on the sensor.

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,
/sbin/hwclock --systohc (meaningful only on Linux systems), and
/usr/local/logger/sensor/ std > /dev/null 2>&1
The last command is the one that starts and stops the tcpdump process on the sensor and also manages the tcpdump output files in /LOG. Because tcpdump requires access to the network interface, it will require root privileges. To avoid running tcpdump, suid root the Shadow crontab entries should be put into root's crontab.

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

7 * * * * /usr/local/logger/ > /dev/null 2>&1
The script will copy over the tcpdump output file and place it on the analysis system. It then calls tcpdump to read the file and output the information to the Web page. Some of the other scripts in the shadow system include one to clean up the sensor's /LOG directory to prevent data loss due to the partition filling up, a script to search through a tcpdump log file for signs of port scans, scripts to look for patterns across a whole day's worth of tcpdump, output, and scripts to sort the data by source IP, date, and time.

To customize all of these scripts, create a Perl header file,, 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.


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: in pre-built binary form. The source code to the open source Tripwire can be found at: 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 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: To install AIDE and compile:

# gzip -dc aide-0.7.tar.gz | tar -xvf -
# cd aide-0.7
# ./configure
# make
# make install
To configure the software, edit the aide.conf file. There are basically three types of lines in the configuration file: configuration lines, selection lines, and macro lines. Configuration lines have the format of parameter=value; selection lines determine which files and directories AIDE will monitor; and macro lines define variables in a similar fashion to Tripwire. AIDE supports md5, sha1, rmd160, and tiger checksums but also permits custom rules to define multiple checksums. AIDE can monitor file or directory permissions, inode changes, size, and other parameters to determine whether a system compromise has occurred.


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: 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 -
# cd fcheck
# cp fcheck fcheck.cfg /usr/local/fcheck
# cd /usr/local/fcheck
# vi fcheck.cfg
The fcheck.cfg contains information such as which directories, files, and filesystems to monitor, as well as what signature type to use, where to keep the FCheck database, and even how to notify the systems administrator when a discrepancy has been discovered, thus making FCheck a very versatile and flexible tool.


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:
and the latest version as of this writing is 3.01. Installing SWatch is straightforward. Once the downloaded tarfile is untarred:

# Perl Makefile.PL
# make
# make test
# make install
# make realclean
Configuration and customization of SWatch is done through the swatchrc file. The SWatch configuration file utilizes two keywords: watchfor and ignore. The watchfor keyword notifies SWatch of a regular expression value to look for in the logfiles it is monitoring; the ignore keyword provides SWatch with the ability to bypass messages containing the expression values defined on that line. The configuration file also contains action values like echo, bell, exec, pipe, mail, and write. These actions can be used to define how Swatch notifies the systems administrators of possible problems.


Logcheck, PortSentry, and HostSentry are products from Psionic Software. They are available from Psionic's Web site: 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 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
PortSentry uses one of four "stealth" detection modes to identify whether a port scan is occurring. If it detects a portscan, PortSentry can do one of four possible actions:

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>
where <OS type> is either linux, bsd, solaris, hpux, hpux-gcc, freebsd, openbsd, netbsd, bsdi, aix, osf, or generic. If the PortSentry build succeeds, then type:

# make install
The default installation directory for PortSentry is /usr/local/psionic, but this can be changed. With PortSentry installed, edit the portsentry.conf file and define which ports PortSentry will monitor and how it will respond to a suspected port scan. One variable to be especially careful with is the value of SCAN_TRIGGER. This variable determines the number of port connects permitted before an alarm is raised. The default is 0, which means react immediately. A value of 1 or 2 will reduce false alarms. It is possible to configure PortSentry in such a way that it will have a "hair trigger" and literally block out every other host on the network, especially if the LAN is a large broadcast domain. PortSentry if very useful when you wish to have the ability to respond to port scan in real-time.


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 shell script is the heart of the Logcheck package. The 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>
where <OS type> is one of linux, bsdos, freebsd, sun, generic, hpux, or digital. This will both build the logtail program as well as install it in /usr/local/bin. The, and the configuration files will be installed in /usr/local/etc. Once the package is built and installed, add a line to the root crontab launching at a desired interval. For example, to run Logcheck once per hour at five minutes past the hour:

5 * * * * /usr/local/etc/
Linux Intrusion Detection System

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: 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.