Intruders in Linux
The Solaris operating system has the BSM (Basic Security Module)
to enable granular-level kernel logging, and now there's a
tool for Linux, too. SNARE is a new host-based Intrusion Detection
System (IDS) made especially for Linux. When I first heard about
SNARE, I decided to install it and try it out. Through my tests,
I found it to be a pretty good plug-in for auditing kernel events
on Linux. Besides that, it's free, easy to set up, and easy
to deploy. This article will show how to install SNARE, how to test
it, and suggest some uses for the tool on your Linux boxes.
SNARE, which stands for System iNtrusion Analysis and Reporting
Environment, is made by InterSect Alliance, an Australian IT security-consulting
firm. According to the Web site (http://www.intersectalliance.com/projects/Snare),
the company began the SNARE project to "enhance the security
of the Linux operating system by providing a comprehensive event
logging facility". They explained that one reason Linux is
not typically being deployed across more IT enterprises is the lack
of comprehensive logging tools. Thus, they created auditd,
a tool that works as a dynamically loadable kernel module that runs
as a daemon.
More specifically, the "comprehensive event logging facility"
that they refer to includes logging of:
- Opening and accepting network connections
- Reading or writing to files and directories
- Modifications to a user's identity or group
- Modifications to program usage
Depending upon how you configure SNARE, you can detect when a
user or attacker has stopped a key program, switched to the root
account, or even installed files in a key system directory. Furthermore,
SNARE can audit system calls themselves, such as when files are
opened or renamed, when a chroot or reboot is executed, or when
mkdir or mknod is used.
Installing a host-based intrusion detection system will not protect
any system by itself. This article assumes that the server on which
you install SNARE has already been hardened by turning off unnecessary
services, changing default file permissions, and installing the
Packages for the SNARE application can be found on InterSect's
Web site, http://www.intersectalliance.com/projects/Snare.
SNARE comes in two parts: the core package and the GUI. The rpms
for Red Hat 7.1 and 7.2 are available on the Web site, as well as
source rpms and code. I like to install from the source code to
make sure everything runs properly in my environment, so I downloaded
the latest release of source code, which happens to be version 0.9
(what InterSect has dubbed "Great Expectations"). That
gave me two gzipped tar files -- snare-0.9.tar.gz and
snare-core-0.9.tar.gz -- for my Red Hat 7.1 box.
Deciding that it made sense to install the core package first,
I gunzipped it:
then untarred it:
tar xvf snare-core-0.9.tar
The SNARE distribution is small and includes the documentation that
is also available on InterSect's Web site. The auditd
daemon is already compiled, but you can simply type:
# make clean
# make install
to get a fresh copy (which I highly recommend). The auditd
daemon will be installed to /usr/sbin, and an audit start/stop
script placed in the /etc/init.d directory. A link is then
created in the /etc/rc2.d directory for S98audit to
link back to the audit start/stop script. You can start the auditd
process by cding into the /etc/init.d directory and
# ./audit start
when you're done compiling.
The GUI is a more standard compilation package. However, I do
not recommend following the generic instructions that are given
in the INSTALL file. Instead, cd into the snare-0.9
directory and follow the directions included in the core documentation
and install using:
# ./make install
The GUI files will then be copied into the /usr/local/share.
Once this is complete, the GUI can be started by typing:
# snare &
See Figure 1 for a screen shot of the GUI.
Once SNARE is up and running, you must configure it. Like the
syslogd daemon has syslog.conf, the auditd
daemon has the audit.conf file. When installed, this file
is placed in the /etc/audit directory. I suggest that this
file be edited only via the GUI to ensure that it is formatted properly;
the file is somewhat intuitive, but this recommendation is a safe
one. To configure the file, you can go to the "Setup, Audit
Configuration" menu. Here you can change the following parameters:
AuditType -- Default is "Objective"; the other available
option is "Event"
HostID -- You can specify the name of a remote host to display
its SNARE log files
Objectives -- The granular levels of auditing that you want
Events -- All possible kernel calls that you can audit
Output -- Where you would like to store the log file; the
default is /var/log/audit/audit.log
The audit.conf file consists of the same elements no matter
what you are auditing. When you have selected Objective auditing,
the rule file that is displayed will be applied. When you select
Event logging, the calls listed under the Event section will show
either a 0 or a 1 to indicate whether they are being logged. Note
that you can do Objective logging or Kernel logging, but you cannot
do both at the same time.
The real flexibility in SNARE, however, comes in the configuration
of rules through the Objective logging. Which type you choose will
depend on your reason for using the tool, but if you want to have
a lot of control over what is audited, then Objective auditing is
the way to go.
When you add an objective rule (click on the "Add an Objective"
button on the Current Objectives tab in Audit Configuration), you
can see the options for configuring rules (Figure 2). SNARE breaks
it into five steps:
1. The high-level configuration
2. The filter by which you want to audit, which can include the
use of regular expressions (for a good discussion of regular expressions,
3. Whether you want to audit the event on success, failure, or
success and failure of the filter
4. Whether you want to audit the event for all users, selected
users, or audit users other than the ones that are "selected"
(accounts specified in the selected users area)
5. Which alert level you think this event should be
The options for alert levels range from Critical to Clear. Clear
indicates neither good or bad; it just notes that something happened.
Information notes that something good occurred and is indicated
by a green dot. Warning warrants a yellow dot; Priority is orange;
and Critical is red.
The default Objective configuration certainly covers the basics
of what you may want to audit: it monitors read, write, or creating
of the /etc/shadow file; the writing or creating of the /etc/passwd
file; and read, write, or creating of the audit files. Further,
it monitors adjustments to files or directories in the /sbin,
/usr/sbin, /bin, and /usr/bin directories;
the use of the su program; acceptance of new connections; use of
the newgrp program; changes to the /etc and /var/log
directories; and opening of outgoing network connections. For a
more complete auditing system, I recommend monitoring some additional
files, which again depend upon your available resources and disk
My primary focus when adding files to monitor is to include the
files that typically change when someone decides to install a rootkit
on your box. These files can include: login, telnet,
ftp, netstat, ifconfig, ls, ps,
ssh, find, du, df, sync, reboot,
halt, and shutdown. You could set up a rule to watch
for modification of each specific file to supplement the rule that
looks for writing or creating files in the /sbin, /usr/sbin,
/bin, and /usr/bin directories. This may seem like
overkill, but the default ruleset does not currently monitor this,
so potential problems may be overlooked.
Other files for which you might want to monitor modification activity
are the /etc/lilo.conf, /etc/syslog.conf (ironically),
/etc/resolv.conf, and /etc/sendmail.cf files. A change
to the lilo.conf file should cause concern if it gets modified,
especially if you haven't updated the kernel recently! A change
in the resolv.conf file might indicate that someone is trying
to have you resolve hosts at a DNS server that is not where you
want to resolve hosts. An attacker who wants to cover his or her
tracks may modify the syslog.conf. Also, if you are running
Sendmail, I recommend setting a filter for the sendmail.cf
file. Modifications here may indicate that someone is turning on
services that you do not want running in your Sendmail environment
(e.g., VRFY and EXPN), which can give away too much
information about your mail accounts.
You might also want to monitor any custom application files for
non-native applications running on your Linux server. You will probably
need to experiment with your ruleset to make sure that the hardware
platform that you are running on will handle the load, depending
upon how many files you want.
Event (Kernel) Logging
As mentioned previously, if you use kernel logging, be aware of
how much disk space is available and how much kernel logging you
actually do! There are many options that can be logged, and at the
kernel level, they can be very chatty.
The areas available through SNARE include: Resource Access and
Security, Command Execution, and Resource Creation and Deletion.
Resource Access and Security includes such calls as setuid,
open, rename, chmod, and chown. Command
Execution includes calls such as chroot, reboot, and
socketcalls. Resource Creation and Deletion includes symlink,
create_module, and mknod. These calls are audited
regardless of user. You can select them all, but this is recommended
only for servers that need a very detailed level of logging.
Testing Your Configuration
I tested both the Objective and Kernel logging to see how each
functions. I have learned that no matter how sure I am that I set
something up correctly, I still need to test it. In this case, I
did minimal testing (Objective, used the default audit.conf
file; and Event, used the selective kernel calls) to get the feel
of how SNARE operated. Then, I logged in as a user and did some
maneuvering around the system to see what type of traffic I could
generate with auditd.
I tried to look at the audit.conf file and attempted an
outgoing telnet connection. The audit.conf file is
set to look for both these activities. I then looked at the audit
log itself, which logged quite a bit more information besides what
was shown in the GUI about the telnet sessions (e.g., what type
of call was made, the permissions on the program, what the return
code was). This may be something to remember while you review what
is displayed on the GUI. All of my actions were appropriately captured
through the filters.
I puttered around with a few more items, such as changing a user's
password. This action was not noted in the log because root is excluded
from this rule in the configuration. Then, I su'd over
to a user (noted), changed my passwd (noted), and tried to
relocate the ls program to /tmp. Not only did I not
have permission to do so, the only error that came up in the log
was that the program mv had been executed. I added a rule
to watch for the modification of /bin/ls, tried my action
again, and this time it was captured.
The kernel testing took a lot more resources (as was promised).
As soon as I flipped it on, messages began chugging away on the
screen, and I hadn't even touched the keyboard yet! I selected
only a few calls to watch for: open, setuid, setgid,
chown, link, mkdir, chroot, and exit.
I attempted a few commands (i.e., made a directory, chowned
a file, and linked the directory to a file in /tmp). I had
to turn off the open logging because the entries were running so
quickly past the screen from all of the open commands that I couldn't
read anything else!
Kernel logging takes a lot of tweaking to get what you really
want. However, it can certainly be useful if you need that level
of detail or if you just need to watch the performance of an application
on the system.
Many types of log files are available on Linux, but SNARE allows
for a much more granular logging than you can do with syslog. While
syslog looks more at kernel and processes (mail, daemon, printing,
and authorization), SNARE looks at connections, file access, and
file modification. Additionally, SNARE is more flexible in setting
up its rules -- you can use regular expressions to create filters,
whereas you cannot do this in the native syslog.
One way to foil hackers when they go through log files and try
to clean up their trails is to create a secure, central log server.
SNARE is ideal for this type of configuration -- only a few
clicks away through the GUI. This logging can be accomplished in
the Audit Configuration screen, where you can either log locally,
log to a networked host, or to both. Which option you choose can
depend on how much disk space you have on your host, how much disk
space you have on your remote host, and how your network connection
to the loghost is configured. You might consider having a separate
VLAN to the loghost, because the traffic will be running UDP and
can be quite chatty depending on the extent of your configuration
SNARE is not a typical host-based intrusion detection system.
Many host-based IDSs run on the premise that they store the MD5
checksums of key files on your system in a database. When you suspect
a problem, you re-run the script to check the checksums and see
what has changed since the original run of the script. SNARE looks
in real-time to see whether they have changed, and can notify administrators
via email when an event occurs. SNARE is configurable down to what
type of alerts that you want (based on Critical-, Warning-, Priority-,
Information-, or Clear-level of message) and the maximum number
of messages that should be sent per hour.
There are other uses for this type of IDS. SNARE would be a valuable
tool for putting together a homemade honeypot. You could rename
the daemon to something else and let it collect data on the files
that you want to watch on the system. (Note that if you do decide
to rename the daemon, you should also reconfigure the startup files,
as it looks for an auditd process.) Furthermore, you can
set auditing on actions that normal log files don't record
(e.g., when a user opens a network connection, or when a connection
is accepted). This can be extremely useful when running a honeypot.
Audit logs like this can also assist in incident handling and
forensic investigations. Again, if you rename the daemon to something
other than audit, the intruder might not recognize the audit daemon
and happily continue pillaging your system. You would then have
a nice record of everything the intruder touched!
Policy compliance might be an excellent reason to have SNARE enabled
on your Linux boxes. If your information security policy at your
site includes the control of the root account -- whether log
files are reviewed on a frequent basis or how accounts are added
-- the auditd daemon can assist in monitoring these types
of actions on the system. These logs can be reviewed by an auditor
to ensure that your site is actually doing what it's supposed
Auditing and legal requirements are another reason to have this
type of logging. If you need C2-compliant logging, or you need to
retain detailed logging information for legal purposes, then this
setup might enable you to be more flexible with the type of operating
system that you can implement in your environment.
Advantages and Disadvantages
The disadvantages of SNARE are few, but could be significant depending
on your environment. First, SNARE chews up some CPU and memory,
and can grab even more when it gets busy. This will be a trade off
with the amount of configuration you set up in your audit.conf
file. Second, it works only with newer kernels, so if you are running
anything older that Red Hat 7.1, you may be out of luck, unless
you can get it to compile! The third disadvantage that I see is
that it seems to also have difficulty working on older equipment.
If you are deploying Linux on older equipment, you may need to experiment
to see whether you can spare the CPU cycles.
The advantages are fairly significant for the over-burdened systems
administrator. SNARE is incredibly easy to set up. It's easy
to deploy. After you set up your audit.conf file and your
distribution is compiled and running, you can simply tar
those files and distribute accordingly to your other servers. Putting
the startup files in their appropriate place can be done by script.
Best of all -- it's free!
SNARE is a nice tool that Intersect Alliance has provided the
Linux community. It is configurable, portable, and easy to use.
SNARE is not a fancy host-based IDS that monitors specific ports
and closes threatening connections. It is a more comprehensive kernel-logging
tool, and although it may steal some CPU, memory, and disk space,
it will greatly simplify auditing (and a few other things) on Linux.
For more information about SNARE, see: http://www.intersectalliance.com/projects/Snare
For information on Solaris BSM, see: Auditing in the Solaris 8
Operating Environment --http://www.sun.com/solutions/blueprints/0201/audit-config/pdf
"Implementing C2 Auditing in the Solaris Environment",
by Kevin Wenchel and Stephen Michaels (Sys Admin, November
2000) -- http://www.samag.com/documents/s=1157/sam0013d/
Kristy Westphal is a versatile network administrator, skilled
in troubleshooting and process analysis. Her 8+ years of experience
in the IS field have allowed her to become knowledgeable in UNIX
and NT, as well as project management and security/disaster recovery
planning. She currently works as Information Security Officer for
Pegasus Solutions. She can be reached at: email@example.com.