How to Set Up and Use Tripwire
Tripwire is an intrusion detection system (IDS), which, constantly and automatically, keeps your critical system files and reports under control if they have been destroyed or modified by a cracker (or by mistake). It allows the system administrator to know immediately what was compromised and fix it.
The first time Tripwire is run it stores checksums, exact sizes and other data of all the selected files in a database. The successive runs check whether every file still matches the information in the database and report all changes. Tripwire initially was released in 1992. Today, several programs share this name, one is GPLed and two are proprietary. The rest of this article discusses only the GPL version 2.3.1.
IDS tools are particular beasts, and Tripwire is no exception. Even if you don't need to be an expert programmer to use this package, actually taking advantage of it requires some patience, attention and manual work.
First, using Tripwire is one of those cases in which blindly pressing Enter at every prompt really isn't a smart thing to do. Do yourself a favor and check at least the relevant parts of the good documentation provided with the Tripwire programs (more on this later).
Second, using Tripwire for real makes sense only if it is installed, fully configured and initialized at the very first boot after an installation from scratch, before ever connecting to the Internet or doing anything else. It takes only one attack to install a back door. All you would accomplish by installing and using Tripwire after such an event would be to guarantee that the back door remains just as open as the day a cracker installed it! Of course, even if you don't want to or can't re-install everything now, nothing prevents you from downloading the package anyway and becoming familiar with it.
Here is how to explain to Tripwire what's important to you. The Tripwire distribution includes several binaries, the corresponding man pages and two files that regulate the program's behavior, which we will call, for brevity, the Tripwire system files. The first one (/etc/tripwire/twcfg.txt), where several variables are defined, is for general configuration and even may be the same for all the computers on the same LAN. Its contents go from the location of the Tripwire database to instructions on minimizing the amount of time the passphrases are kept in memory or the number of redundant reports.
Other important parameters are the editor (the default is vi) for interactive usage and how reports should be sent by e-mail. The complete syntax and meaning of all possible variables is described in the twconfig man page.
The other system file (/etc/tripwire/twpol.txt) contains the policy that declares all the objects that must be monitored and what to do when one of them is lost or altered. Unlike the configuration file, the policy could (and almost certainly will) vary across the several computers on the same network. For example, the packages installed on a firewall will be different from those on a development workstation or an office laptop, even if the same GNU/Linux distribution is used.
The first thing to do to create a good Tripwire policy (and, in general, have a less stressful sysadmin life) is to remove as many unneeded programs as possible before starting. Next, to make your usage of Tripwire as quick and effective as possible, your policy must cover everything you really need to monitor and nothing else. This includes, at least, all the system binary and library directories (that is, the contents of /bin, /sbin, /usr/bin, /lib and so on) and the corresponding configuration files in /etc/. The example twpol.txt files distributed with Tripwire contains anything that could be on a UNIX system, so it is guaranteed to complain about programs that you never installed or placed in a different location. This is an example of what you might see:
### Warning: File system error. ### Filename: /dev/cua0 ### No such file or directory ### Continuing...
There is a safe and easy way, even if potentially long and boring, to remove such bogus warnings. Simply run the initial configuration procedure described below several times. Scan the report each time, and comment out the checks that generated false alarms until they all disappear. Of course, before starting, do what should be done before configuring any new package—that is, make a copy of the originals:
cp -p twcfg.txt twcfg.txt.orig cp -p twpol.txt twpol.txt.orig
A Tripwire policy is a sequence of two kind of rules. Normal ones define which properties of a file or directory tree must be checked, in this format:
object_name -> property_mask (rule attribute = value);
The property_mask specifies which properties must be examine or ignored. Attributes provide additional, rule-specific information like the rule severity or who should be informed by e-mail if that rule is violated. The other kind of rules are stop points, which tell Tripwire not to scan a particular file or directory. Tripwire also understands several directives for conditional interpretation of the policy, diagnostics and debugging. To know all the gory details, print out and study the twpolicy man page.
Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Home, My Backup Data Center
- Android is Linux -- why no better inter-operation
1 hour 44 min ago
- Connecting Android device to desktop Linux via USB
2 hours 12 min ago
- Find new cell phone and tablet pc
3 hours 10 min ago
4 hours 39 min ago
- Automatically updating Guest Additions
5 hours 48 min ago
- I like your topic on android
6 hours 34 min ago
- Reply to comment | Linux Journal
6 hours 55 min ago
- This is the easiest tutorial
13 hours 10 min ago
- Ahh, the Koolaid.
18 hours 48 min ago
- git-annex assistant
1 day 48 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?