Freeware Intrusion Detection Tools
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
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
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:
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)
...(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 192.168.1.1 with a netmask of
255.255.255.252, the configuration would be:
var HOME_NET 192.168.1.1/30
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:
var HOME_NET $ppp0_ADDRESS
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:
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 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
Once the snort.conf file is tailored to the specific environment,
the Snort program can be started. To start Snort in network intrusion
# /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
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.
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
# make install
When libpcap is built and installed, tcpdump can be
# gzip -dc tcpdump-3.6.2.tar.gz | tar -xvf -
...output from tar
# cd tcpdump-3.6.2
# 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
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/
The files for the sensor can be found in the sensor directory.
# 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
These files are written in Perl and include a start script, sensor_init.sh,
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 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
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
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
The fetchem.pl 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,
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
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
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
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
# 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
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 -
# 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 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
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 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 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
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
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
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>
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 logcheck.sh, 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 logcheck.sh
at a desired interval. For example, to run Logcheck once per hour
at five minutes past the hour:
5 * * * * /usr/local/etc/logcheck.sh
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
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.