7.3.1 What 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 if 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 11, Protecting Against Programmed Threats , describes what you should look for in these files.)

Some files that you may wish to copy are listed in Table 7.1 .

Table 7.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*	Changes in the system boot sequence
/etc/ttys, /etc/ttytab , or /etc/inittab	Configuration changes in terminals
/usr/lib/crontab, /usr/spool/cron/crontabs/ , or /etc/crontab	New commands set to run on a regular basis
/usr/lib/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	Changes in network daemons
UUCP files (in /usr/lib/uucp or /etc/uucp )
L.sys or USERFILE	Changes in the UUCP system
Systems or Permissions

7.3.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 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 have a local area network, you may wish to keep the copies of the critical files on a different computer. An even better approach is to store these files on a removable medium such as a floppy disk or a cartridge disk that can be mounted when necessary.

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) or SCCS (Source Code Control System) to archive these files and keep a revision history.

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 sample script included below 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/group /usr/lib/aliases\ 
/etc/rc* /etc/netgroup /etc/fstab /etc/exports\ 
/usr/lib/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[7]:

[7] This example assumes that you have a version of cron that allows you to specify the user under which the cron script should be run.

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

NOTE: A significant disadvantage of using an automated script to check your system is that you run the risk that an intruder will discover it and circumvent it. Nonstandard entries in /usr/lib/crontab are prime candidates for further investigations by experienced system crackers.

See Chapter 9, Integrity Management , for additional information about system checking.