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.
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
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
# Private network
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 255.0.0.0
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
# mkdir /mnt/fcheckdb
In the fcheck.cfg file you will need to tell FCheck to use the NFS/FCheck
# 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 fcheck.sh 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 \
# 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 trans_dbf.sh
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: Jason.Perlman@gst.com.