18.2 Backing Up System Files

In addition to performing routine backups of your entire computer system, you may wish to make separate backup copies of system-critical files on a regular basis. These backups can serve several functions:

• They can help you quickly recover if a vital configuration file is unexpectedly erased or modified.

• They can help you detect unauthorized modifications to critical files, as well as monitor legitimate modifications.

• They make installing a new version of your operating system dramatically easier ( especially if you do not wish to use your vendor's "upgrade" facility) by isolating all site-dependent configuration files in a single place.

Ideally, you should back up every file that contains vital system configuration or account information.

Setting up an automatic system for backing up your system files is not difficult. You might, for instance, simply have a shell script that makes a tar file of the /etc directory on a regular basis. Or you might have a more sophisticated system, in which a particular workstation gathers all of the configuration files for every computer on a network, archives them in a directory, and sends you email each day that describes any modifications. The choice is up to you and your needs.

18.2.1 Which Files to Back Up?

If you are constructing a system for backing up system files on a regular basis, you should carefully consider which files you wish to archive and what you want to do with them.

By comparing a copy of the password file with /etc/passwd , for example, you can quickly discover whether a new user has been added to the system. But it is also important to check other files. For example, if an intruder can modify the /etc/rc file, the commands he inserts will be executed automatically the next time the system is booted . Modifying /usr/lib/crontab can have similar results. (Chapter 23 describes what you should look for in these files.)

Some files that you may wish to copy are listed in Table 18-1.

Table 18-1. Critical system files that you should frequently back up

Filename	Things to look for
/etc/passwd	New accounts
/etc/shadow	Accounts with no passwords
/etc/ group	New groups
/etc/rc*, /etc/init.d (some systems)	Changes in the system boot commands
/etc/ttys/etc/ttytab/etc/inittab	Configuration changes in terminals
/usr/lib/crontab/usr/spool/cron/crontabs//etc/crontab/etc/cron.*	New commands set to run on a regular basis
/usr/lib/aliases/etc/aliases/etc/mail/aliases	Changes in mail delivery (especially email addresses that are redirected to programs.)
/etc/exports (BSD) /etc/dfs/dfstab (SVR4)	Changes in your NFS filesystem security
/etc/ netgroups	Changes in network groups
/etc/fstab (BSD) /etc/vfstab (SVR4)	Changes in mounting options
/etc/inetd.conf /etc/xinetd.d/*	Changes in network daemons
/etc/pam.conf, /etc/pam.d/*	Changes in PAM that control security for various programs
/etc/*.conf	Changes to other configuration files

18.2.2 Building an Automatic Backup System

For added convenience, keep the backups of all of the system-critical files in a single directory. Make certain that the directory isn't readable by any user other than root , and make sure it has a nonobvious name ”after all, you want the files to remain hidden in the event that an intruder breaks into your computer and becomes the superuser! If you use a public key encryption system, you can configure your backup system so that the files are encrypted with a public key so that they can be decrypted only with your specially authorized private key. ^[7] If you have a local area network, you may wish to keep the copies of the critical files on a different computer. Another approach is to store these files on a removable medium, such as a writable optical drive, that can be mounted when necessary.

^[7] If you use public key encryption for backups, you probably don't want to use PGP, as PGP creates temporarily files while it's running. If you're encrypting a large partition, you might overflow your /tmp partition. On the other hand, you could use PGP to encrypt a session key.

You can use tar or cpio to store all of the files that you back up in a single snapshot. Alternatively, you can also use RCS (Revision Control System), CVS (Concurrent Versions System) or SCCS (Source Code Control System) to archive these files and keep a revision history.

Never Underestimate the Value of Paper

Keeping printed paper copies of your most important configuration files is a good idea. If something happens to the online versions, you can always refer to the paper ones. Paper records are especially important if your system has crashed in a severe and nontrivial fashion because in these circumstances you may not be able to recover your electronic versions. Finally, paper printouts can prove invaluable in the event that your system has been penetrated by nefarious intruders because paper is a physical record. Even the most skilled network intruders cannot use a captured account to alter a printout in a locked desk drawer or other safe location.

A single shell script can automate the checking described above. This script compares copies of specified files with master copies and prints any differences. The following sample script keeps two copies of several critical files and reports the differences. Modify it as appropriate for your own site.

 #!/bin/sh MANAGER=/u/sysadm FILES="/etc/passwd /etc/ttys /etc/rc /etc/crontab" cd $MANAGER/private for FILE in $FILES do  /bin/echo $FILE  BFILE='basename $FILE'  /usr/bin/diff $BFILE $FILE  /bin/mv $BFILE $BFILE.bak  /bin/cp $FILE $BFILE done 

You can use cron to automate running this daily shell script as follows :

 0 0 * * * root /bin/sh /u/sysadm/private/daily  mail -s "daily output" sysadm 

The nightly security script that is run with FreeBSD automates this process. Similar approaches are available on other Unix operating systems.

One disadvantage of using an automated script to check your system is that you run the risk of an intruder discovering it and circumventing it. Nonstandard entries in /usr/lib/crontab are prime candidates for further investigation by experienced system crackers.

See Chapter 20 for additional information about system checking.