INTRUDER ALERT! Don’t trust your defences to a firewall alone. Nick Veitch sets up some booby-traps.
Securing your systems with iptables-based firewalls is sensible. Locking down services and closing ports you don’t intend to use is equally so. But you can’t leave security at that. Sure, nine times out of ten, when someone exploits a vulnerability and compromises your server they’ll leave a trail like a radioactive slug, which you’ll be able to use to fix things up again. But malicious hacker number ten may be smarter, and leave no clues about how they got in, or what they are up to...
A typical modern Linux workstation can have a quarter of a million files on it – KDE alone has over 16,000 components – and there’s no way you can spot when a corrupt binary has appeared, or a configuration file subtly edited, without outside assistance. Any good intrusion detection system should be able to securely monitor the files on your server or desktop and detect suspicious changes. One such tool is the excellent Tripwire. Tripwire is a policy-driven filesystem scanner – that is, it has a predefined set of configuration files and a database that tells it what your filesystem should look like. You can safely exclude those chunks of the filesystem that aren’t important to system integrity, such as individual user accounts: serious hacking attempts focus on subverting the operating system tools, and user data is rarely a target. When you first run Tripwire, you create a baseline database that contains a snapshot of your important files (and an MD5 checksum for each of them). You then place the baseline database on a read-only medium such as a write-protected floppy disk or a CD, so that if a hacker gains access to the machine they can’t spoof the database. Subsequently, you run the Tripwire tool to scan the filesystem, and it will report only those files that have changed. If you are confident that the machine is secure and the only changes are official ones, you can merge approved changes into a new baseline database copy: if you’ve been attacked, the output from Tripwire will tell you what files the attackers have changed. Tripwire1.x was originally a free software project, released under the GPL and written to run on any Unix system. The developers subsequently created a company, Tripwire Security (www.tripwire.com), to sell commercial versions of Tripwire and ‘change auditing’ products for business. However, the GPL version of the software is still available, supported by Tripwire the company. This app hasn’t changed much in the last couple of years, so you should have the
LXF66 MAY 2005
most up-to-date version already if you have a fairly recent distro. Packages are available for SUSE, Fedora, Mandrake, Debian and so on, or you can grab the source from http://sourceforge.net/projects/tripwire. Whichever way you get it, you’ll still need to do some work. As Tripwire is policy-based you need to create the policy files for your system. Let’s take a look at the build first.
Kim and Spafford wrote Tripwire in 1992 while at Indiana’s Purdue University. Kim is now CTO of the corporation that sells enterprise versions.
While Tripwire comes packaged with most modern Linux distributions the installers won’t set Tripwire up to work effectively with your system – they’ll usually provide a generic set of configuration files and nothing else. Also note that Tripwire 2.3 is only suitable for Intel Linux systems, while earlier versions ran on BSD and non-Intel Linuxes, as well as other Unixes. For this reason, some quite early versions of Tripwire are still kicking about; for example SUSE 7.3 ships with Tripwire1.2 rather than Tripwire 2.3. You can use the older, free, Tripwire; or download the Tripwire 2.3 sources from SourceForge and compile them yourself. To do this, extract the tarball, cd into the src subdirectory, and type make release. tar xvzf tripwire-2.3.1-2.tar.gz cd tripwire-2.3.1-2
15/3/05 6:03:29 pm
cd src make release The makefile provided with the sources doesn’t install
The task of editing a Tripwire policy file is made easier by the comments littered throughout.
Tripwire 2.3; to do that, you need to edit the file install.cfg (located in the subdirectory tripwire-2.3.1-2/install/), specifying the directories you want the Tripwire programs to go into, the various Tripwire installation options (such as the SMTP host to email reports through), and so on. Then run the script install.sh: sh install.sh This script reads the settings in install.cfg, edits the template configuration files that come with the distribution, and installs everything. It will also prompt you for a passphrase and uses this to digitally sign the configuration file, policy file, and database files (to make unauthorised modification harder).
The warning in the preceding code indicates a file that is labelled in the policy but wasn’t actually found on the filesystem – this will happen a lot if you just modify the default policy files. While it won’t stop the software from working, too many of these bogus files could prevent you from spotting a real problem!
MAKING POLICIES To set up Tripwire1.2, you need to create a tw.config file. This contains a list of directories to be scanned, and the type of changes Tripwire can safely ignore without reporting to the owner. The resulting information is collected in the tw.db database. Having created a tw.config file, you need to run tripwire -initialize to build the first tw.db file. This will be created in the directories specified to hold databases (at build time), and will be called tw.db _hostname (where hostname is the name of your computer). Tripwire 2.0 stores files in /etc/tripwire by default. The file tw.cfg stores the location of Tripwire’s data files, while the Tripwire policy file, tw.pol, specifies what system resources Tripwire should monitor, how the data should be collected, and who should be notified of policy violations. The files site.key and hostnamelocal.key are protected using a passphrase, and must be unlocked in order to decrypt the Tripwire configuration files before virtually any operation The command-line tool twadmin is used to manage these keys. Finally, the Tripwire databases are stored in a subdirectory called /var/lib/hostname.twd/, and report files are created under /var/lib/tripwire/report. To set up Tripwire 2.x, you use twadmin; its manual page will give you all its options, but for now note that twadmin --printpolfile prints the policy file in readable form. You can save this, edit it, and replace the policy file with twadmin --create-polfile policyfile.txt and twadmin will prompt you for the site password before encrypting the new policy file. The Tripwire 2.0 policy file format is defined in depth on the twpolicy manual page. Having specified a policy (or accepted the default one created by install.sh), Tripwire 2.x users should create a default database like this: /usr/sbin/tripwire -m i Please enter your local passphrase: Generating the database... *** Processing Unix File System *** ### Warning: File system error. ### Filename: /usr/sbin/fixrmtab ### No such file or directory ### Continuing... Wrote database file: /var/lib/tripwire/np1.plopcast The database was successfully generated.
TRIPWIRE IN EVERYDAY USE
CHECKING THE ESSENTIALS One useful tip to prevent disk thrashing and report overload is to maintain two separate databases/policies for Tripwire. This requires some advanced setup, but does mean that you can set up a very fast system for a small set of crucial files (index.html or /etc/passwd for example) that can be run every ten minutes without compromising the performance of the server, saving the more detailed checks for less frequent intervals.
To check your filesystem against the baseline database, and report deviations (such as changes to system configuration files or programs) using Tripwire 2.3, run: tripwire --check --email-report Tripwire will write a very lengthy report and email it to the administrator you have designated. The level of reporting can be specified in the config files, and it is strongly recommended that you are very careful with it. If Tripwire is sending out 30-page emails every half hour, you aren’t going to be any better off than when you weren’t using the software at all, because after the novelty wears off, the reports will just get binned. It is best to add the check to root’s cron jobs. How frequently you run it may depend on a number of factors such as: ■ How much damage could be done on your server. ■ How much time you have to spend on admin. ■ How busy the server is. ■ How big a filesystem Tripwire is checking. Because the report generation means checking all the marked files, be aware that the process will involve a lot of disk access and possibly a fair amount of processor time. When you change files legitimately on the server, you’ll need to remember to update the database. This can be done with the command tripwire --update, which will generate a report, then throw you into a text editor where you can enter Xs in checkboxes against each changed item. Tripwire will then digest the report and update its database accordingly as long as you give it the correct password. You should take the time to be sure that your system is clean at the time of an upgrade, otherwise modified files will slip through your defences. Tripwire will not prevent your server from being hacked. It will not stop someone from hijacking your site to send spam, nor prevent them from installing a root kit. However, it will tell you that these things have happened, and in a way that enables you to take action in a timely manner; and can even direct you towards what sort of action you need to take. As part of any co-ordinated security plan, you need a tool like Tripwire. ■■■
LXF66 MAY 2005
15/3/05 6:03:36 pm
Published on Jan 28, 2010
and compromises your server they’ll leave a trail like a radioactive slug, which you’ll Debian and so on, or you can grab the source from un...