First of all well done for choosing to install a filesystem integrity checker. I think everyone who values their machines should do that. Most people think it's only purpose is security but it may help in terms of management (for instance listing configuration changes) and recovery (being able to compare file hashes) too.
Originally Posted by lugoteehalt
tripwire - a file integrity checker for UNIX systems, says the best thing is to reinstall the "system binaries" and then start it going.
I hope that's your interpretation
of what it reads and not what it actually
reads. The gist of the message, a best practice, is to install a filesystem integrity checker right after
OS installation but before connecting
the machine to any network. This maximizes detecting changes. System binaries
are those packages that are vital for operating the OS (think ps, ls, du, init et cetera or rather whole dirs like /lib, /sbin, /bin, /etc and such) as they are the usual targets for subversion by rootkits. I'll go into this all in detail below but anyone reading should realize this is about differentiation
. Those that misinterpret this as paranoia may skip the rest and simply dream on.
Installing a filesystem integrity checker long after your OS was exposed to any network is pretty much useless unless you have independent means to verify integrity of package contents
(not the MD5 or SHA1 or GPG sig of a package!) by for instance the distributions package manager (if it is capable). This implies that you have stored a backup of the package manager configuration and databases or data dirs off site and are able to verify the integrity of that backup. Debian offers debsums
but the obvious problem with that is that it basically is as much an add-on as anything else and not integrated: you can not install it before
anything else, you have to (remember to) install it, you have to activate
it once manually (if post install scripts don't do that right now). But once you have you can run 'debsums package.deb' using the checksums generated the "package.deb" archive. To top it off, verifying hashes should be done running a rescue or Live CD to avoid tainting results where taints aren't detected.
About choosing a filesystem integrity checker. I don't know whether it's due to hearsay, outdated web logs, outdated articles or lack of coverage elsewhere (I know I pretty much cover this topic at least once a year) but it does surprise me that people still install tripwire while alternatives exist that are not troubled with licensing problems, that are easier to use and that are maintained and supported. But before going into that there's a distinction you may not be aware of: passive versus active
Applications that need to be started manually or run as cronjob are called passive because they do not run as daemon, continuously. It is important to make this distinction because it means that usage relies on either the person running it or a subsystem driving it: points of failure in terms of forgetting to run it or failing to notice cron daemon or cronjob failures.
In terms of subversion you should also realize the length of any detection cycle is an opportunity for an attacker to modify the configuration and checksum database to enable her to remain undetected. Whichever product you choose it is important to store copies of the binary, configuration, database off site. Also running a filesystem integrity checker may take time. When using a passive filesystem integrity checker you may want to spread risk and load by running different configuration files. For instance you could configure and run Aide on only /lib, /etc, /bin, /sbin once per two hours and use a different configuration to run it on /usr or /usr/local at a different interval.
Examples of passive filesystem integrity checkers are Aide, Integrit, Osiris, Fcheck. (And since the 1.3 series Rootkit Hunter also allows you to checksum system binaries.) The only active one I know of is Samhain. Samhain can run daemonized and offers features like its own LKM to detect kernel changes, encrypted database and (SSL-capable) client-server setup to run with a remote central database-serving host for more resistence against tampering and easier management. Since Samhain runs as daemon it also means it can be run from init, and as you know /sbin/init does not like applications to die and will restart them, meaning one more step towards being tamper-resistant.
* Finally auditing shows one more human point of failure. People may set up the most splendid system but fail to realize that to be able to take (counter)measures one needs to actually read reports