Cover V13, i12

Figure 1


Using FCheck

Jason Perlman

One of the main tasks for systems administrators is monitoring their systems for file tampering. This can be accomplished by using commercial products such as Tripwire or, in this case, FCheck. I have come up with a blueprint and scripts that improve the usability and security of FCheck.

In this article, I will discuss my methods and procedures for using FCheck in a more effective manner. FCheck was written by and maintained by Michael A. Gumienny. The installation and configuration of FCheck is clearly documented in the README file.

Figure 1 gives a high-level illustration of the network architecture.

Hardware Requirements

An inexpensive PC serves as the NFS server and FCheck database repository. A CD-ROM burner is required for the server along with a second network interface card (NIC). A second NIC is also required for all clients. A decent switch and the appropriate network cables complete your private network hardware requirements.

Configuring Server and Clients

Setting up the server and clients is relatively straightforward. After installing the second NIC on the NFS server, configure the interface to use the private network. Remember to place an entry in /etc/hostname.interface in order for your configurations to survive a reboot.

In my case, I used a private Class A network. Place entries in /etc/hosts. Here is an example from my NFS/FCheck master server /etc/hosts table:

# Private network nfserver-p hooey-p dooey-p louie-p
On the NFS server, place entries in /etc/exports to share out your CD-ROM drive, there are different flags and options depending on your Unix flavor. Here are the options that I use in my /etc/exports file:

/cdrom -maproot=root -network 10.0 -mask
Start up NFS on the server. The process of setting up the FCheck clients is similar to the FCheck server minus the NFS setup and startup tasks. Install and configure FCheck according to the instructions provided in the README file.

You will need to create a mount point for the FCheck server's CD-ROM:

# mkdir /mnt/fcheckdb
In the fcheck.cfg file you will need to tell FCheck to use the NFS/FCheck server's CD-ROM:

# The baseline database files are to be kept under the "DataBase" 
# directory that is defined next.
DataBase        = /mnt/fcheckdb/fcheckclient_hostname.dbf

# If you are using a read-only location. You can write the database
# files to one location, and read from an alternate read-only 
# (CD-ROM?) location.
ReadDB          = /mnt/fcheckdb/fcheckclient_hostname.dbf
#WriteDB        = /usr/sadm/fcheck/fcheckclient_hostname.dbf
I have created a script called that automates the mounting and unmounting of the FCheck server's CD-ROM and calls the fcheck executable. Here is the script that I use on Solaris clients:

# This script mounts the remote database  and calls fcheck
# Jason Perlman 01/29/2004
/usr/sbin/mount -F nfs nfsserver-p:/cdrom /mnt/fcheckdb

/usr/sadm/fcheck/fcheck -aidr | mailx -s "'hostname' fcheck \
  report" you@mailserver

sleep 5;
/usr/sbin/umount  /mnt/fcheckdb
# end of script
As valid changes are made to your system, the FCheck baseline needs to be updated. The first step is to uncomment the WriteDB line in the fcheck.cfg file. Then run:

#  ./fcheck -acd
This creates a new .dbf file and can now be secure-copied over to your NFS/FCheck server. I have written a short script called to accomplish this procedure:
# this script should be run after the fcheck database is updated
# Jason Perlman 03/24/2004

/usr/local/bin/scp 'uname -n'.dbf root@nfsserver-p:/var/fcheck/.
echo "completed transfer of database"
# end of script

The NFS/FCheck server should be an ultra-hardened machine (e.g., OpenBSD). External and internal access should be severely restricted. Your best option is to allow connections only to the private interface. The FCheck database files should be burned to a new CD-R once a week. All clients should have IP forwarding disabled. To do this on Solaris, type the following:

# ndd -set /dev/ip ip_forwarding 0
On Linux, IP forwarding is turned off by default. To verify:

# cat  /proc/sys/net/ipv4/ip_forward
The value in the file should be zero. On FreeBSD, it is turned off by defaut. To verify, make sure you do not have the following value in your /etc/sysctl.conf file:


Following these procedures and architecture gives you a secure, easy-to-manage solution for monitoring systems.

Jason Perlman is a graduate of the University of Maryland. He is a Systems Administrator for Global Science and Technology. He can be reached at: