Use rsync for filesystem integrity auditing

A few days ago, I discussed implementing an integrity auditing system using basic utilities. The point of that article was mostly to sketch out the often unexpected ways that a security professional can achieve good results using the tools already at his or her fingertips, rather than going out and purchasing a massive security suite that doesn't provide anything he or she doesn't already have.

But I also hinted at specific tools that can be used to provide the integrity auditing you need. Today, I'll provide an explanation of how one of those tools can be bent to your purposes.

As discussed in the previous article, an incremental backup tool called rsync can be used to provide integrity auditing capabilities on most, if not all, UNIX-like systems. This includes not only the various Linux distributions, but BSD UNIX operating systems such as FreeBSD, proprietary SysV UNIX operating systems such as Solaris, and even distant, proprietary cousins of proper BSD UNIX systems such as Mac OS X. You may be surprised to discover that you can even use rsync for checking filesystem integrity on Windows systems, though that's most easily accomplished from a separate, UNIX-based dedicated integrity auditing and/or backup server.

The key to integrity auditing is to have a "snapshot" of the filesystem you wish to audit from a "known good" state -- meaning from a time when you know, with reasonable certainty, that the system has not been compromised. You can then check a new snapshot against the old shot at a later date and, with fine-grained control depending on the sophistication of your integrity auditing solution, perform a comparison to determine whether unauthorized changes have been made.

There are a number of important matters to consider when choosing and implementing an integrity auditing system, such as the fact that rsync isn't frugal with disk space as compared with other integrity auditing solutions. (You must back up the filesystem you wish to audit, and use that backup as your snapshot.)

Rather than belabor the additional concerns of integrity auditing, such as maintaining a protected integrity auditing system separate from the audited systems, choosing which parts of a filesystem to audit, and so on, I'll just provide you with a quick overview of how rsync can be pressed into service as a Tripwire-like integrity auditing system.

  1. Given auditor and victim as the hostnames of two computers you have, we will make auditor your integrity auditing server, and victim the system whose filesystem integrity you wish to audit with rsync.
  2. Either install rsync directly on auditor or, for more well-protected integrity auditing capability, store the rsync binary on a CD that you'll keep in the optical drive of the victim system. In the latter case, let's assume that drive is mounted at /mnt/cdrom.
  3. Use the rsync program in auditor's /mnt/cdrom to copy the segment of victim's filesystem you wish to audit later, where /usr/bin is the directory you want to audit:

    auditor# rsync -av --rsync-path=/mnt/cdrom/rsync \

    --rsh=/usr/bin/ssh victim:/usr/bin /root/snapshot

  4. Later, audit the integrity of the contents of that directory using that same rsync binary:

    auditor# rsync -avn --rsync-path=/mnt/cdrom/rsync \

    --rsh=/usr/bin/ssh victim:/usr/bin /root/snapshot

You'll notice that the only difference is the addition of the -n option. The command line options used are as follows:

  • -a This option copies files in "archive" mode, ensuring that all file metadata is faithfully copied as much as possible, including ownership, file creation times, and symlinks (rather than the data in the linked file).
  • -v You can get a better sense of what's going on when running rsync by using this option for verbose mode operation. You'll need this output to check the integrity of your filesystem effectively.
  • -n This option doesn't actually copy anything. All it does is show you some information about what would have happened if you actually had gone ahead with a copy operation using rsync. This is where the integrity auditing magic happens.
  • --rsync-path To specify the path to the rsync binary you keep on a CD, mounted at /mnt/cdrom, you need this option.
  • --rssh The rsync utility generally operates over the RSH, or "remote shell," protocol. SSH is a much more secure remote shell program than RSH, as it encrypts all communications. The reason for using an encrypted protocol rather than a plain-text protocol for security utilities should be obvious.
  • The remainder of the command line is split to fit on your screen using the backslash. This character can be used to split commands at the shell, so copying it directly with the backslash will not hurt anything, but the backslash isn't strictly necessary.
  • The last two parts of the command specify the target system and the path to the part of the filesystem you wish to audit, first, and the location of the snapshot stored on the auditor system, second.

The rsync utility is used to speed up incremental backups. It does this by comparing the backup already in place against the current version that you wish to back up, then only copying the changes. Using the -n option instructs rsync to simply tell you what would happen if you were to copy the changes, by performing the comparison and outputting the changes it detects, without actually making a copy.

In this manner, you can use it to inform you of changes to the filesystem. Those changes that are expected and authorized can be dismissed, and those that are unexpected can be taken as an indication that the system may have been compromised.

Given a very, very small target directory, with only a single file in it, the output of the -n command to perform an integrity audit might look something like this:

receiving file list ... done

sent 20 bytes received 97 bytes 26.00 bytes/sec

total size is 0 speedup is 0.00

If there had been changes made to the contents of that directory, you would see a list of affected files between the "receiving file list" line and the "sent 20 bytes" line, as follows:

receiving file list ... done




sent 38 bytes received 131 bytes 48.29 bytes/sec

total size is 16 speedup is 0.09

This shows that changes have been made to the File.txt and File2.txt files in a directory named directory. In the case of the test run I made to produce this output, the already existing (but empty) File.txt file had text added to it, and the empty File2.txt file was created. Because I made both of these changes myself, I expected these changes and knew there was no unauthorized activity.

To update my snapshot, I would simply run the first rsync command again to create a new version of the backup as my new, up-to-date snapshot. If there had been any unexpected changes, however, I would not want to write over the original snapshot until I had determined whether the changes should be authorized.

The above command examples are suited to (almost) any Linux-based system. Some changes may need to be made for other systems. Obvious additional changes include alterations to the hostnames of the systems, paths to rsync binaries depending on where you mount your CD (or whether you run it from some other medium, including possibly the hard drive of the auditor system), and the paths to the parts of the filesystem you wish to audit and to the directory where you will store the snapshots.