js#vista.png msort nsort
js#vista.png msort nsort
;#; Large portions of this text was originally published by: Yunliang Yu firstname.lastname@example.org from Duke University my changes are published here for reference only and is a work in progress to bring this up to date. ;#;
A setup for the popular filesystem integrity checking program, Tripwire, is described in this article. This tripwire auditing system is easy to set up and manage, and it scales well to hundreds of clients. It makes the daily monitoring of client systems much easier and we believe it's more secure than the default client based tripwire installation.
Like many .edu sites, we have been running tripwire on our systems since the earlier days of the program. It's a nice way to detect if anything has ever happened to those important files in your systems and is also a valuable assessment tool after a break-in. Over the years we've made some improvements to it to make it easier to run on hundreds of machines and make it more secure. The best idea we have come up with so far is to start tripwire from a centralized secure host (I'll call it the secure host from now on) over ssh, and not install anything on the client systems. Here is an excerpt of an email message I sent to email@example.com back in 1998 which described our basic setup:
In a local network, set up a secure UNIX machine without ANY network services running. The only access to it is at the console. This is going to be the tripwire monitor host; it hosts all tripwire binaries for different OSes on the network, and stores all tw.db_* files. A cron job is running on this machine to log on remote hosts on the network through ssh secure shell to run tripwire at randomly selected time and collect data when tripwire is done. RSA authentication is used and the private key never leaves this secure host. Before each tripwire run on a remote host, tripwire binary and database for that host are copied over to a randomly selected directory. Then the following command is issued immediately through the ssh connection:
tripwire -tsig 2ChmQx2X43JfLdfRVKbvqo -dsig 2t3FRZSoXbtjRx88DZQxgq -csig 1Lq2wfGJJWTtIicS9wvJSj
where -tsig is the MD5 signature of the tripwire binary itself, -dsig the signature of the database, -csig the signature of the config file. In tripwire source code, MD5 signature is calculated for every fgets and fprintf. If any of the signatures doesn't match, the program quits and reports to admin staff at once. The temporary database is written to this randomly selected directory instead of /tmp and has its MD5 signature reported back to the secure host through the secure connection. After each run, the secure host collects all the temporary databases, check their signatures, and generates report, etc. The temporary databases will be used to update the databases when needed.
We have changed the setup somewhat since then. For example, it now won't send the database to the client anymore, and a sampling scheme is used to reduce the number of reported changes. We'll describe it in more detail later in this article.
Advantages of our setup over the current tripwire-2.3.x default install include:
A crontab entry was added by the tripwire user on the secure host which will start a run script for the tripwire system at a random time every night. The run script first creates a restricted ssh config file to protect the ssh connections to clients. It then starts ssh-agent and load in the pass phase for the secret key. It next spawns tripwire jobs for each hosts listed in the tw.hosts config file. In order not to overwhelm the network, it runs at most 15 concurrent jobs at a time. The tripwire job does the following:
cat tw.config | timer -7200 ssh -x -l root $rhost \ "cd $dir && ./tripwire -tsig md5_sig"
–where timer is an alarm to kill the connection if the run takes more than 2 hours,
On average, we spend about 5 minutes every morning to monitor about a hundred hosts. How to set up: The setup described here is based on the Tripwire 1.3.1 Academic Source Release which you can download from the tripwire web site. The same procedure should be easily adoptable for the older 1.2.x versions or the Open Source 2.3.x releases.
Thanks: Thanks for the Duke Sysadmin group (Andrew Schretter et al.) for interesting discussions.