A little over a week ago, I offered an explanation for how you might use rsync for filesystem integrity auditing, as a follow-up to my previous post about implementing integrity auditing with basic utilities. In the earlier article, I specifically mentioned two examples of basic utilities that can be used to implement a filesystem integrity auditing solution: rsync and mtree.
If you're an experienced Linux or UNIX administrator, you should already know that rsync is pretty basic; pretty much everyone knows about it, and it serves as an excellent tool for custom automated backup procedures. If you're specifically a Linux admin, however, you may not be as familiar with mtree — an even more basic utility for admins of BSD UNIX systems such as FreeBSD, NetBSD, OpenBSD, and even home desktop-oriented PC-BSD.
Unlike rsync, it's part of the base system. As such, if you're a BSD UNIX sysadmin and you aren't already using rsync for something else, you may find you're better off using mtree for simple integrity auditing purposes.
According to the manpage, mtree is a tool used to "map a directory hierarchy." The manpage goes into more detail in the DESCRIPTION section:
The mtree utility compares the file hierarchy rooted in the current directory against a specification read from the standard input. Messages are written to the standard output for any files whose characteristics do not match the specifications, or which are missing from either the file hierarchy or the specification.
The mtree version of a snapshot is known as a specification. Comparing a specification from a "known good" state of the filesystem to the current state of the filesystem provides the differentiation between filesystem states required for integrity auditing.
One of the benefits of using mtree instead of rsync is that, like Tripwire, it does not require a complete snapshot of the filesystem. The mtree specification is a list of files and their properties, not a complete copy of the files.
The actual comparison with rsync uses a similar specification, but it derives that from a copy of all the filesystem's contents, thus requiring a fair bit of storage resources to maintain its usefulness as an integrity auditing system. This is because rsync is designed as a backup tool, while mtree is the utility responsible for creating your directory structure in the first place when you installed an OS such as FreeBSD.
The mtree maintainers are fully aware of the usefulness of the utility as a filesystem integrity auditing tool, as indicated by the following from the EXAMPLES section of the manpage:
To detect system binaries that have been "trojan horsed," it is recommended that mtree -K sha256digest be run on the file systems, and a copy of the results stored on a different machine, or, at least, in encrypted form. The output file itself should be digested using the sha256(1) utility. Then, periodically, mtree and sha256(1) should be run against the online specifications. While it is possible for the bad guys to change the online specifications to conform to their modified binaries, it is believed to be impractical for them to create a modified specification which has the same SHA-256 digest as the original.
To actually get an mtree specification into a file, you can use mtree's -c option to dump it to standard output and a redirect to send that output to a file of your choosing. For instance, if you chose to name your SHA-256 digest specification mtree.txt, you might use the following command from the directory that tops the filesystem hierarchy you wish to audit:
mtree -c -K sha256digest > mtree.txt
This should be run from within the directory whose contents will require integrity auditing. An mtree binary can be run from nonwritable media such as a CD simply by mounting the media and giving the full path to the binary. Using tools such as SSHFS or NFS, you can even mount a filesystem on a remote machine to generate specifications from a server set aside specifically for integrity auditing.
Later, to perform a filesystem integrity audit, you can simply repeat the process and compare the results, perhaps using the diff command. You might also use mtree's built-in comparison capability, specifying the comparison specification with the -f option:
mtree -f /path/to/mtree.txt -K sha256digest
If there are any changes, it will let you know. For instance, if the file blah.txt is added before integrity auditing, you may get results like this:
modification time expected Sun Sep 2 14:15:41 2007 found Wed Sep 5 11:26:22 2007blah.txt extra
Otherwise, it should not output any information at all, indicating an unchanged filesystem. However, even if a change is made and then undone, mtree should report changes.
There are probably as many ways to go through the process of generating and comparing specifications with mtree as there are people doing it, with minor variations to suit preferences and the needs dictated by your circumstances. Additional security measures can be used to protect yourself against your integrity auditing system being compromised, such as remote integrity auditing, nonwritable storage of the mtree binary, and encrypting the specification file itself then saving it on nonwritable media as well.
Both mtree and rsync suffer from the theoretical possibility of the specification or snapshot itself being compromised, or of the filesystem being modified in a manner that cannot be detected using the utility's common functionality. The same applies to any filesystem integrity auditing tool, however, just as any encryption algorithm is theoretically crackable.
Ultimately, your level of paranoia is the only limit to how many obstacles you wish to throw in the way of malicious security crackers. By layering on additional protective measures, you can certainly make a target so impractical to crack that realistically it probably cannot be cracked with current technology. The caveat is simply that the meaning of "current technology" changes, and as such the definition of "paranoid enough" should also change.