File Tamper Checking
James W. Meritt
A typical system administrator is responsible for dozens, perhaps hundreds of separate systems. On each of these systems there are dozens of files, the integrity of which must be maintained. Or, at least the administrator must know if they have been changed. This is too daunting a task to handle.
My solution is a script, called niswatch, shown in Listing 1, that automatically checks the multitude of files then emails the results of that check to me. The program automatically, via cron, checks a nearly unlimited number of files and systems and reports the observed changes. This program, as well as the databases it maintains, runs on a system that is more closely monitored (i.e., mine).
To use this script, you will need to perform some preliminary setup. You will need a list of programs used, along with the location of configuration/control files/tables and temporary files. You will also need to determine the best mail setup for the script's reports. These variables will all be used by niswatch and should be checked before use. The programs used (such as awk and ls) must be specified for the individual system. It is essential to set the "MAILTO" variable so that the results are mailed to the proper, valid address.
The flow of the program (shown in bold) is:
Get the systems currently responding to RPC queries
This is necessary for large dynamic networks, though a simple list read in from a file or set as a variable may be used for a small number of systems. The latter setup would avoid the necessity of ensuring the correct RPC setups on all systems.
For each of the systems responding,
Check for the database of files for a particular system
Determine the most recent and previous system files
If niswatch identifies a particular system as one previously scanned, it takes a long listing of the previously identified files and compares the two listings. Although this is less comprehensive than taking the checksum of the specified files (using MD5, for example), it is faster and less computationally intensive. If a change is evident, this method allows the determination of exactly what changed, instead of merely checking whether a change occurred.
If there is only one file, keep it
Otherwise, remove the previous file. This keeps the space requirements for the monitoring (secure) system within reasonable limits.
If the system is not recorded as being previously scanned, the following is performed for the configuration/setup of that system for future comparison. This list is built by combining:
- A default list. This default list needs to be built by the sys admin and should contain a list of such files as the passwd file and whatever else the administrator thinks is vital. This list will vary with each organization and should be made using your favorite text editor. Give the full path description of the file (e.g., /etc/passwd), one entry per line.
- A find on ".???*", which should locate all "dot" files on the system
- Configuration files
- Files ending with "rc"
- Files ending with "tab"
- profile
- cshrc
- Host files
- crontab entries
- inetd configuration file
Please be aware that this list is built by examining the entire disk multiple times for files that are not in expected locations, thus, it is very intensive on disk I/O. It should not be done while someone else is planning to use the system. They will not be able to.
The list is then cleaned up by making sure that no entry is duplicated and by removing files that have been identified as not needing to be monitored. There is a message identifying which file this configuration is in so that the operator can add or delete particular files for monitoring as s(he) wishes. The file can then be edited by any text editor to delete any file that is not desired. Any file that the sys admin wants "to keep an eye on" may also be included.
Create a directory
This directory will be used to hold the information for that particular system. The files that contain the long listing of the identified files are called "snapshots" and contain the ls -l information for each file specified - size, creation date, and permissions.
Take a snapshot
The system reads the file listing and then takes a snapshot of the files identified, which is placed into the snapshots directory.
Check for new executable items selected directories
These are: /bin, /etc, /usr/ucb, /usr/local, /usr/bin, /usr/sbin, and /usr/ucb.
Check the NIS plus database
I perform extracts of the NIS password file and host listing.
Perform check/retain on NIS information
This is essentially the same check that was done on the previous system configurations.
Email the file-check report
Email this report to the previously identified address and remove temporary files.
I've used this program successfully. Although I have no proof that it has failed to identify files that were tampered with by a hacker, it has identified when upgrades were installed (changing configuration files), new software installed (directory names have their dates changed), and similar actions. In every case, it was a simple matter to call one or two people who might have been responsible for what I saw and confirm that it was an approved alteration. Of course, it would have been nice if I had been told about it first, but I did confirm that the system was working!
It is possible to use system lists instead of the rup check. Another modification I haven't included is the use of checksums against the identified files. Of course, the program can be operated at any time and not just executed from cron, but remember that the first time a particular system is scanned, it will put a heavy load on the system. This should not be done when the system is in use. Other methods of identifying essential files could be added, and "common" essential files could be entered in the default setup file.
About the Author
Jim Meritt is currently working for Wang Global, Inc as a Senior Security Analyst, and has been involved with Unix systems and networking for more than a decade. His email address is: JWMeritt@AOL.com.