Contents

1. Introduction

Whether you're an experienced system administrator or a Linux beginner, whether you're managing an enterprise-grade network or just your home network, you must be aware of security issues. One common mistake is to think that if you're a home user with few world-facing machines you're exempt from malicious attacks. The attacker will not get from you what (s)he can get from a large corporate network, but that does not mean you're safe. The earlier you become security-aware, the better. While the subject of network security is huge, today at LinuxCareer.com we chose an interesting piece of software named tripwire, a HIDS (Host-based Intrusion Detection System). Of course, besides learning about tripwire you will learn what an IDS is, its' uses, traps and pitfalls. A little network knowledge will definitely help you, plus a degree of paranoia (it's your decision to make if that was a joke or not).

1.1. Intrusion Detection Systems

Intrusion Detection Systems, which will be henceforth referred to as IDS, are software applications that monitor a network for any suspicious activity, the keyword here being "monitor". The difference between an IDS and a firewall is that while the former usually just reports any unusual activity, a firewall is an application created to stop said activity. So it's basically a case of passive vs active. Like we said above, while you can use an IDS in a SOHO network, its' true value is shown in larger networks with lots of of subnets and valuable data. There are also IDPSs, where the extra 'P' stands for prevention, which means that an IDPS will also try to reconfigure the firewall to reflect a new threatening situation, for example, so in this case passive meets active. We will let you dig deeper in the abundant documentation on the subject, since security in general isn't the object of our article, and we will try to focus on the types of IDS, so we can get to our subject, which is tripwire.

1.1.1. Major types of IDS

There are NIDS and HIDS, that is Network IDS and Host-based IDS. The first try to detect intruders by monitoring network traffic (Snort, for example), while the HIDS monitor file alterations on the monitored system(s), syscalls, ACLs and so on, in order to achieve the same result. Sometimes a HIDS can be configured to also monitor network packets, just like a NIDS, but this is not an article about general classification of IDS. There are various opinions out there about the efficiency of various IDS types, but we say use the right tool for the right job. HIDS were the first type of Intrusion Detection software designed, and, as one can easily assume, it's more appropriate when the traffic with the outside world is less frequent (since at the time, network traffic was rather sparse, at best), or the network design is of such nature that it permits the use of both HIDS and NIDS, depending on the traffic (think DMZ).

2. Installing tripwire

Before we start, a very important piece of advice : try to install tripwire right after you install the system, because this way there are better chances it'll be clean, unaltered by malicious individuals. Tripwire creates a database of information related to your system, then compares that to what it finds when ran regularly, which it should, in order to get some real use out of it.

2.1. Debian

You can find tripwire in Debian's repos, easy to install as

# apt-get install tripwire && tripwire --init

We say easy because the configure script asks you some basic configuration questions like system-wide passwords, so you get an easier start. dpkg-reconfigure will help you if something goes wrong and you want to reset. As you will see below, you will have to initialize tripwire's database, and this is applicable to every system tripwire is able to compile on.

2.2. Fedora

Fedora repos also have tripwire, so by doing

# yum install tripwire

you'll have installed in a snap (tripwire is a small, basic dependency program, written in C++). You can use

# tripwire-setup-keyfiles && tripwire --init

for a similar utility as Debian's configure script, plus the mandatory database initialization. We will not repeat the init part everywhere, but please remember it is mandatory.

2.3. Gentoo

# emerge tripwire

will install tripwire for you, provided you have the necessary USE flags set up, especially ssl. Before --init, you must run

# sh /etc/tripwire/twinstall.sh

2.4. Slackware

Slackbuilds.org offers a slackbuild of aide instead of tripwire, which is seen as a simpler alternative. We haven't honestly tested aide to see how it is, but if you install it and like it, just use that. Since our topic, however, is about tripwire, we recommend you download the source, along with the documentation, install and read on.

2.5. Arch

You can find tripwire in AUR by following this link and following the usual build procedure. But, since there's a compilation error (reported in June already), this won't work. The same compilation error is seen with the latest version (AUR provides 2.4.2 from March 2010 and the latest stable is 2.4.2.1, July 2011), by hacking the PKGBUILD or by good ol' configure/make. If you are an Arch user and want to try tripwire, use aide or insist towards the maintainer's direction for a fix. [EDIT] See tripwire's AUR page for a hack I posted that allows one to compile 2.4.2 or 2.4.2.1 . Hope that'll help someone.

3. Using Tripwire

Tripwire works by using modes. A mode is a function tripwire can execute, basically speaking. We already spoke of the first mode to use, the init mode. All tripwire modes can also be seen as actions, and every action-related flag (like --init) has a short equivalent, prefixed with -m. So, to initialize the database we could have written

# tripwire -m i

One will obviously want to use tripwire after all this talking, so that can be done by using the check mode :

# tripwire -m c

One flag you can use often in check mode is -I, which stands for interactive. You will find a huge number of problems found by tripwire when scanning, but don't panic. And of course, don't rely only on HIDS to check your system's integrity. IDS software in general are known to generate false negatives/positives, hence the reports from such systems must be taken with a grain of salt. So, our check mode command becomes

# tripwire -m c -I

Before we go on to database update mode, we must remind you to check the manual. Each mode has its specific options which you most likely will find useful, plus other options common to all or some of the modes, like -v, -c or -f (we invite you to find out what they do). Tripwire's site over at sourceforge has also a manual in pdf format, if you loathe the 'man' command. Needless to say, since you will have to use these commands frequently, you should use cron or whatever tool you use for scheduling. For example, this line in root's crontab will do the trick:

45 04 * * * /usr/sbin/tripwire -m c

which will run the command daily at 04:45 AM.
In time, files on a system are changing. System updates, new installs, all these increase the discrepancies between the real thing and what tripwire knows about your system (the database). Hence the database must be updated regularly in order to get reports as accurate as possible. We can easily accomplish this by typing

# tripwire -m u

If you want to see the database in its' current form, twprint comes to the rescue :

# twprint -m d

We strongly suggest, especially on slow terminals or remote connections, but also if you want to actually read anything, to either use a pager like less or to redirect the output to a file. Piping the above command's output through wc returns 769078 lines. You have been warned.
If you are even remotely involved in system security you will know what the term policy means. In tripwire terms, you define the policy in a file which will contain rules about which system object will be monitored, and how, to put it basically. '#' starts a comment, and the general rule for a line in the policy file is

#This is a comment and an example 
 # object -> property
/sbin -> $(ReadOnly)
! /data1

So, an object is basically a folder in your system, and here the second line shows how you should tell tripwire to leave the /data1 directory alone by using the '!' operator (C, anyone?). Regarding objects, take note that names like $HOME or ~ are never valid object identifiers and you will likely get an error message. There are many things one should be aware of when writing or updating a policy file (rule attributes, variables, and so on), and tripwire looks promising and versatile in this respect. You will find everything you can do with tripwire's policy file options in the manual page and some fine examples in /etc/tripwire/twpol.txt (at least on Debian systems). twadmin will also be helpful when creating or checking configuration files or keys. For example, this command will print the policy file in its' current state:

# twadmin -m p

Finally, the test mode. What good is a monitoring tool if it can't report properly to you? This is what the test mode does. It e-mails the administrator, based on the settings found in the configuration file (first example) or as an command line option (second example) and if the mail is received correctly, life is good. This of course assumes your mail system is properly set up. Let's see :

# tripwire -m t 
 # tripwire -m t -e $user@$domain

4. Tripwire files

Tripwire doesn't install a lot of files: as we said, it's pretty small. Doing a

 $ rpm -ql tripwire | wc -l

on an OpenSUSE system yields 31, including manual pages. For people that don't use rpm, the above command lists the files installed by the package given as an argument. Although it installs a smallish number of files, some of them are very important when configuring tripwire, especially the files that reside in /etc/tripwire on most Linux systems. On our Debian sid machine, the following files reside inside /etc/tripwire (after configuration and key generation) :

$hostname-local.key site.key tw.cfg twcfg.txt tw.pol twpol.txt

Of course $hostname is the output of the hostname command on any Linux box. Now, the two .key files are site-wide and local keys for tripwire, and there are, as you can see, two .txt files and two .cfg ones. If you look closer you might notice a pattern in the naming of these four files, and you're right. The .cfg files are generated from the corresponding .txt files, like so :

 # twadmin -m F /etc/tripwire/twcfg.txt
 # twadmin -m F /etc/tripwire/twpol.txt

This will generate the tw.cfg and tw.pol files, respectively, which are, like we said, essential to configuring tripwire. tw.cfg is the file by which one configures the program, and tw.pol defines the policy. Let's look at the syntax a bit.

4.1. tw.cfg

The subtitle is intentionally misleading, because tw.cfg is generated from a text file, much the same as sendmail configuration is done, and it's binary, unreadable to normal human beings. So, what one does is change the values of the objects in twcfg.txt, then "recompile" tw.cfg . You will see that there aren't many options to change, given the nature of the program. Here's the first few lines of our setup:

 
ROOT           =/usr/sbin
POLFILE        =/etc/tripwire/tw.pol
[...] 
LATERPROMPTING =false
[...]

Again you are invited to open the twcfg.txt file as root and tweak it to your liking.

4.2. tw.pol

The binary vs text story holds here too, so we won't say it again. Instead, we will concentrate on some good-to-know values in the twpol.txt file that you might just want to alter. The general syntax is the same as above. Now, one value you may want to change here and in twcfg.txt (there you will see it as the ROOT object, here as TWBIN) is the place where the executables are. If you installed using a package manager like aptitude or yum, the location will most likely be /usr/sbin. But if you installed from source, since, as you've seen, not everyone packs tripwire for their distro, maybe you installed to to /usr/local and if you don't alter these locations nothing will work as it should. We suggest the use of symlinks, however :

 # ln -s /usr/local/bin/tripwire /usr/sbin/tripwire

Like any such file, the policy defines which locations in your system are of what importance (/boot is critical, for example). This is the essence of what a policy file does. You may of course change the values, but we do recommend care and a very good reason. For example, the critical security section is defined as

SEC_CRIT        =$(IgnoreNone) -SHa ; # Critical files that cannot change

After defining all of the security categories, twpol.cfg defines every important location's security importance, as seen above. The policy file is almost 300 lines long, but well commented to make your life easier. Hopefully your first tripwire installation won't go into production, so take some time to experiment with policy definitions until you find the right spot.

5. Final thoughts

This trip (!) in IDS-land was a short one, considering how many things can be learned about the subject, use cases, real-world examples, testing, and so forth. We only wanted to introduce you to tripwire and Intrusion Detection Systems in general, leaving it to you to think about what security scenarios are best at your site.

Tuesday, October 4, 2011

Intrusion detection systems : Using tripwire on Linux