SNAREing Intruders in Linux

Kristy Westphal

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.

Installation

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

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:

gunzip snare-core-0.9.tar.gz

tar xvf snare-core-0.9.tar

# make   clean
# make
# make   install

# ./audit   start

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:

# ./autogen.sh
# ./make
# ./make install

# snare &

Configuration

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 to do

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, see http://sunland.gsfc.nasa.gov/info/emacs/Regexps.html)

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.

Objective Logging

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

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.

Kernel Testing

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.

Uses

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

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 to do!

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!

Conclusions

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: ckwestphal@cox.net.