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, this tutorial will cover an interesting piece of software named Tripwire, an 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).
In this tutorial you will learn:
- What is an Intrusion Detection System?
- How to install Tripwire on major Linux distros
- How to use Tripwire with commands
- How to configure Tripwire settings files
|Category||Requirements, Conventions or Software Version Used|
|System||Any Linux system|
|Other||Privileged access to your Linux system as root or via the
# – requires given linux commands to be executed with root privileges either directly as a root user or by use of
$ – requires given linux commands to be executed as a regular non-privileged user
What is an Intrusion Detection System?
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 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.
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).
How to install Tripwire on major Linux distros
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.
You can use the appropriate command below to install Tripwire with your system’s package manager.
$ sudo apt install tripwire
$ sudo dnf install tripwire
$ yay -S tripwire-git
Depending on your distro, you will see some prompts show up during installation. These are self-explanatory and will allow you to configure some of Tripwire’s settings already.
You will be asked to configure a passphrase as seen below. Be sure you don’t forget this password!
How to use Tripwire
With Tripwire installed, we are ready to start using it.
- Tripwire works by using modes. A mode is a function tripwire can execute, basically speaking. 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 can write:
# 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
-f(we invite you to find out what they do). Tripwire’s GitHub has also a manual, if you loathe the
mancommand. 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
This 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,
twprintcomes 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
wcreturns 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
~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
twadminwill 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 below) or as an command line option (second example below) 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
There are a few different configuration files generated by Tripwire. These exist inside of the
$ ls /etc/tripwire $hostname-local.key site.key tw.cfg twcfg.txt tw.pol twpol.txt
$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, one
.cfg and one
.pol file. If you look closer you might notice a pattern in the naming of these four files, and you’re right. The
.pol 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.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.
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.
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 dnf, 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
/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.
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.