CATCH LINUX SYSTEM INTRUDERS .. ;) ..

There's no doubt that Linux is a secure operating system. However, nothing is perfect. Millions of lines of code are churned through the kernel every second and it only takes a single programming mistake to open a door into the operating system. If that line of code happens to face the Internet, that's a backdoor to your server.

The eyes have it

Patches are often released quicker and more often for Linux systems than they are for proprietary products. This is because anyone can take a look at the code – and thousands of developers regularly do. This 'many eyes' approach, which was advanced by Linus Torvalds, means that problems like back doors are usually found quickly. It also means that fixes are released just as quickly.

There's been a very vocal debate on the Linux kernel mailing list recently, with developers arguing about whether security bugs that are fixed should be formally announced and documented. Torvalds believes that making a big song and dance about security patches attracts the attention of miscreants like bees to honey. Others believe that anything but complete openness goes against the philosophy of Free Software.

The debate is still burning, but while the overlords of the Linux kernel are deciding which way to swing, there's a great deal you can do to protect your system, even if an Internet facing service is compromised in some way.

Watching for traps with Tripwire

Tripwire generates checksums from all the essential binaries that are running on your system. Every file has a completely unique checksum. If a single bit of data changes in the file, the checksum it generates will be completely different.

These checksums can't be cracked or duplicated because they rely on a tried and tested method of encryption. Using this database of checksums, Tripwire will periodically recheck the value of each binary file in its database. If any file has changed, the wire is tripped and an alarm is signalled.

This system is incredibly effective, because the first thing a hacker usually does when they gain access to your system is replace important system files with their own version. This is known as a 'rootkit', and it means that the hacker can always access your system – even after you locate and update the original 'back door' security problem.

There are various tools that look for the tell-tale signature of a rootkit installation, but Tripwire pre-empts these tools by catching changes to the file system – hopefully before the rootkit can even be used. For this reason, you can find Tripwire in the package repository of nearly every Linux distribution we can think of. Just search for it and install.

Tripwire defence has been so successful that a proprietary company has been launched on the back of the original Tripwire product; both are confusingly called Tripwire. Thankfully, however, the opensource version of the software is still popular, despite the fact that, like all Linux security tools, it takes a considerable effort to get it working.

Most of that effort is to do with editing arcane configuration files. Choosing Ubuntu or Debian can help with this, as both of these distributions include a quick setup wizard when you install the packages. We've used Ubuntu Hardy Heron in the example configuration below. We've also provided the manual commands for configuration if you're using a different distribution.

Make sure everything that needs to be installed is installed. If you add more packages after the Tripwire installation, you'll have to go through a rather convoluted reconfiguration routine. For this reason, it's more straightforward to install Tripwire after you've configured and set up the server exactly as you need it.

Configuration

After installing the Tripwire packages, you'll be presented with the Tripwire configuration wizard. The first question asks whether you want to create or use your site passkey. This is the unique encryption key that's used to generate the checksum information for your files, and Tripwire uses two – one for files that are only going to be used on the installation machine (such as the Tripwire configuration files themselves), and another for files that may be accessed and used on other machines across a network. The next page of the wizard will ask you for these.

However, there is a caveat. If someone else has a copy of the same keys, they can potentially create files that appear authentic. There's a slight security risk with keys generated by the Debian installer, so if you're in any doubt about the security of your system, you should generate the keys manually (see the next paragraph for how to do this). Otherwise, continue with the next page of the wizard, enter long phrases that you can easily remember for both configuration keys and let the set-up wizard generate the configuration file.

To generate both the local and server keys manually, open a terminal and switch to using the System Administrator's account. Type the following (Ubuntu users should precede both lines with 'sudo'):

twadmin -m G -S /etc/Tripwire/site.key
twadmin -m G -L /etc/Tripwire/ hostname-local.key

You should replace 'hostname' in the second command with your machine's hostname. In Ubuntu, this is the word that comes after the 'username@' symbol in the command line. In both cases, you'll be asked for a passphrase to generate the key. You need to use these keys to encrypt the two configuration files used by Tripwire, both of which reside in the '/etc/Tripwire' directory in plain text – which is why they have the '.txt' extension. Encrypt the first by typing the following command:

cd /etc/Tripwire
twadmin -m F -S site.key twcfg.txt
Enter pass phrase:

As you can see in the above commands, you will be asked for your passkey, and you will need to enter the passphrase that you used to generate the server-side key earlier. The second configuration file that we need to encrypt is called 'twpol.txt' . This is Tripwire's policy file, and it contains all of the policies and rules used by Tripwire to govern its file protection. Debian/Ubuntu creates a default set of policies that should be more than adequate for most installations. If you take a look at the policies themselves, you will see small sections of code that look like the example given below:

{
rulename = "Critical system boot files",
severity = $(SIG_HI)
}
{
/boot
/lib/modules
}

The syntax above is relatively straightforward, if a little verbose. The section above is protecting critical system boot files, as explained in the rule name. You can see which directories specifically in the lower section.

The boot directory contains both Grub and the Linux boot loader. A rootkit or trojan that changes any files here could cause serious damage. The '/lib/modules' directory contains all the kernel drivers for your system. A subtle change to the modules here could cause all kinds of subtle and not so subtle havoc. For this reason, both directories have been given a severity of SIG_HI, which is the strongest possible signal from Tripwire that something is wrong.

Earlier on in the configuration file, SIG_HI is given a point score of 100. If you have directories and files that aren't part of a standard Ubuntu installation, and these need to be protected, then you'll need to create your own policies for those locations. After you've finished looking at the policy file, it's time to encrypt it as we did the first one. Just type the following:

twadmin -m P twpol.txt

You will be asked for your passphrase again before the encrypted file can be generated. And that's all the configuration you need. The next step is to type 'Tripwire --init' to start building the database from the locations specified in your configuration file. The time this takes is dependent on how many directories and files need to be scanned, but expect to wait long enough for the kettle to boil and the tea to stew.

When you come back to the screen, you'll probably see some error messages as Tripwire complains about directories specified in the configuration file that don't exist. You can safely ignore these. Tripwire is now ready to defend your system.

Testing your current file system against the copy held in the Tripwire database is as simple as typing 'Tripwire --check'. After a few minutes, Tripwire will start to report any detected changes. As an experiment, try editing one of the files covered by your policy.

You could add a new group, for example, or change a user's password. Either of these actions will change a configuration file, making it different from the one held in the Tripwire database. The generated report will include a useful table, so that you can see exactly what has changed and what kind of severity the issue has raised. Below the table, the output goes into greater detail. Here's a snippet from Tripwire's output if you change a password:

Rule Name: Security Control (/etc/shadow)
Severity Level : 66
Modified:
"/etc/shadow"

You can see the rule name under which the password files fall under (shadow is the encrypted file used to store passwords), and you can also see the severity for the issue. At a security level of 66, it's less severe than a change detected in the boot files and modules directories, but it's still notable. Because the output from Tripwire is quite detailed, you can decide for yourself the likelihood of a compromised system. The output is stored in an encrypted form in the '/var/lib/ Tripwire/report' directory, and if you take a look at it, you can see a file for every report you've run.

If you want to make any discovered changes permanent and flag them as acceptable, type 'Tripwire --update -r hostnamereport. twr', inserting the name of the report you want to edit instead of our placeholder. This will decrypt the report's contents into a Vim editing session (as set in one of the configuration files). Instructions are embedded within the file, but you generally just need to remove an 'x' from the files you want to update.

Quitting the editor will run the scan again, with your changes added. With everything running correctly, you might want to schedule a regular time interval for Tripwire checks. Running a check at least once every 24 hours is recommended, but this all depends on the vulnerability of your system. If you know that your system has security issues, try running Tripwire once every few hours. As long as you check the reports, you can be completely certain that your system hasn't been compromised.

Update: removed incorrect space in wadmin -m G -S /etc/Tripwire/site.key. Apologies! - Ed.