FCheck: A Solution to Host-Based Intrusion Detection
Ron McCarty In September 1999, my Sys Admin article “Intrusion Detection Strategies and Design Considerations” gave an overview of intrusion detection. In February 2000, I followed up with an introduction to Snort, a network intrusion detection system (IDS), so it is about time I got around to a host-based IDS. A host-based IDS is responsible for notifying administrators that key system files have changed on a particular system. Intrusion detection provides a very important function, but many administrators come to rely on their host-based IDS to provide an audit trail for changes made by their peers and themselves in the regular course of systems administration. This value added auditing feature has encouraged the use of free software (especially Tripwire [http://www.tripwire.com], which was freely available in the past) for this purpose even in shops that would not normally allow “free” software installation. Since there is no capital expenditure for the product, the system auditing functionality can be used in as many systems as possible. This is definitely win-win: it provides a broader spectrum of host-based IDS and allows administrators to more effectively manage systems through better auditing. FCheck:
http://sites.netscape.net/fcheck/download.html)is an Open Source freely available host IDS that will run on both UNIX and Windows systems. FCheck is written in Perl, which will be considered an advantage by many admins. Perl 5 or later is required. FCheck Architecture FCheck definitely supports the UNIX philosophy of using small, specific task-oriented tools to create larger, general purpose tools. FCheck can use any system executable or script for reporting, which gives it great flexibility. syslog (using the logger command) or lpr are common reporting methods for IDS. Using lpr and a printer gives the added security feature of using a write once media, which is very hard to change after a system compromise. FCheck also uses external programs to determine signatures of files with MD5 (RFC 1321) being the likely choice. Keep in mind that this flexibility does have a weakness: the md5 executable could be replaced during a root compromise with a program that outputs the same signatures that FCheck is expecting. FCheck comprises the fcheck Perl script, the fcheck.cfg configuration file (which is normally kept in /usr/local/etc/), the database directory, and files it uses to determine whether changes have been made to the system. FCheck does not have to be run as root; however, the program requires read permissions on all files being monitored. Setting read permissions on files that would otherwise not have them can make the deployment very complex and could open additional holes. FCheck currently does not allow individual files to be monitored with one entry such as /etc/passwd, which seemed like a major weakness to me when I first took a look at the IDS. However, the small footprint and ease of use convinced me that, despite this weakness, FCheck still had merit. To overcome this weakness, I've written the simple fcheck_file_support script that creates the necessary output to create the configuration entries to simulate individual file support. See the sidebar fcheck_file_support for an overview and some other useful pointers. I hope this item will be fixed in a future release. Installation Installation of FCheck is very straightforward. For the installation covered here, RedHat 6.2 and Perl 5.005.03 were used, but installation on other versions of UNIX is very similar. Ideally, any IDS should be installed following a new system install; however, this is simply not practical in many situations. At the time of this writing, FCheck's current version is 2.7.51, which will be covered here. As root, download the FCheck archive from:
http://sites.netscape.net/fcheck/ \ FCheck_2.07.51.tar.gzand place it in /usr/local/src/, or an appropriate place on the file system. If this is a new system, a network connection should not be used (the system should not be hooked up to the network until completion). FCheck weighs in at less than 100 KB, so if the system has a floppy, sneakernet can be used. Move into the source directory and unzip the archive:
cd /usr/local/src/ gunzip FCheck_2.07.51.tar.gzNow untar the archive:
tar xvf FCheck_2.07.51.tarThe Perl scripts fcheck and fcheck.cfg need to be put in the proper location. I normally recommend a dedicated directory structure for new software; however, there are only two files involved here, so we'll follow the author's suggestion and place the fcheck script into /usr/local/bin/ and fcheck.cfg into /usr/local/etc/:
cp /usr/local/src/fcheck/fcheck \ /usr/local/bin/ cp /usr/local/src/fcheck/fcheck.cfg \ /usr/local/etc/Check the first line (#!/usr/bin/perl) of the /usr/local/bin/fcheck script and ensure it points to the proper location of Perl on the system that FCheck is being installed on. Next, create the data directory for FCheck:
mkdir /usr/local/data/This directory can be modified...replace the “DataBase = /usr/local/data” entry in the /usr/local/etc/fcheck.cfg configuration file. Running FCheck Before running FCheck, let's create a simple configuration that will monitor the /etc/ directory for changes. Edit /usr/local/etc/fcheck.cfg using vi or your favorite editor and search of the entry Directory = /tmp. Change the entry to “Directory = /etc”. By leaving off the trailing / we are telling FCheck to not check sub-directories. Save the file and run FCheck with:
/usr/local/bin/fcheck -acsA quick breakdown of the parameters are:
-a -- Automatic scan of all the directory configuration. -c -- Create the initial (baseline) database to which subsequent scan comparisons will be made. -s -- Create signatures (fingerprints). The documentation that comes with FCheck does not emphasize the use of -s, but I highly recommend its use since permissions, dates, and file sizes can be manipulated by skilled hackers and hacking tools. FCheck will use the program defined with the $Signature parameter in the fcheck.cfg configuration file.
After running the program, take a look in the /usr/local/database/ directory. You'll notice that FCheck has created a file containing a list of the file names being monitored with the file information and signature listed on the same line. The file name is in the format hostname._directory and is a standard text file that can be read with UNIX programs that work with text as input. Now, we can make a change that FCheck should notice. Change the password of your normal user (non-root) using the passwd program. You can use the old password -- we are simply getting the system to make a change to the password file and its shadow counterpart. Run the program with only the -a as the parameter:
/usr/local/bin/fcheck -aThis should result in the following output:
PROGRESS: validating integrity of /etc STATUS: WARNING: [lefty] /etc/passwd Inode Permissons Size Created On Name 293999 -rw-r--r-- 707 Oct 01 08:11 2000 /etc/passwd ** Was modified to reflect the following: ** 294000 -rw-r--r-- 707 Oct 01 11:35 2000 /etc/passwd WARNING: [lefty] /etc/passwd- Inode Permissons Size Created On Name 293243 -rw-r--r-- 707 Oct 01 08:11 2000 /etc/passwd- ** Was modified to reflect the following: ** 293243 -rw-r--r-- 707 Oct 01 11:35 2000 /etc/passwd- WARNING: [lefty] /etc/shadow Inode Permissons Size Created On Name 294000 -r-------- 629 Oct 01 08:11 2000 /etc/shadow ** Was modified to reflect the following: ** 294001 -r-------- 629 Oct 01 11:35 2000 /etc/shadow WARNING: [lefty] /etc/shadow- Inode Permissons Size Created On Name 293772 -r-------- 629 Oct 01 08:11 2000 /etc/shadow- ** Was modified to reflect the following: ** 293772 -r-------- 629 Oct 01 11:35 2000 /etc/shadow-You may have noticed the output went to standard out. This is because only the -a was used. If the -l parameter were used, then the output would have been piped to the program defined with the Logger parameter in the configuration file fcheck.cfg. Of course, the standard out can also be redirected on the command line. For example, to mail the above output, use:
/usr/local/bin/fcheck -a | mail \ root@localhostReplace “root@localhost” with the appropriate recipient. The output can also be directed to write to medium, such as printer or CD-R, which might be desired on very sensitive hosts. Configuration: A Brief Look There are six simple parameters in the fcheck.cfg. To view the ones that are active in your configuration, use:
grep -v ^# /usr/local/etc/fcheck.cfg \ | grep -v ^$This will give output similar to this:
Directory = /etc Which Files and How Often? Determining which files to monitor can be difficult, and it becomes more difficult on systems that often change. My general rule is to monitor all system files that are stored in /etc/ as well as the binaries usually stored in /bin/ and /sbin/. If the system is a centralized services or application server with very few changes outside of the application's directory structure, then a larger umbrella makes sense. Monitoring a larger directory structure will not add very much additional work. Systems known for unauthorized software use can be monitored as closely as needed. After the initial configuration and several days of fine tuning, you'll generally not need to adjust the IDS, but don't hesitate to adjust the configuration to meet new needs as applications and users change. Baselining, or creating snapshots for new databases should be taken seriously, especially where binaries and authentication files (password, trusted hosts, etc.) are concerned. If your systems have a lot of configuration changes such as adding and removing users, then separate FCheck processes should be set up to meet both needs. One process can monitor the password files and have a daily baseline (if necessary), and the other FCheck process can be used to monitor the other system configuration and binary files. The -f parameter can be used to tell FCheck to use another configuration file. The other separation file should be set up to use its own database directory structure for storage. Use the crontab facility to integrate FCheck into the system. FCheck's documentation suggests calling “fcheck -a” every ten minutes. Every ten minutes is reasonable in many environments, but may be overkill initially as you get a feel for the system. Remember to keep an eye on the system log files or output files that you are recording. If files are being kept outside the normal system log files, then a procedure for rotating or moving the files offline will also be needed. Summary FCheck is still a bit rough around the edges, but it definitely has a place in many network administrators' toolboxes. The program is easy to implement, the Perl source code is available, and it does what it is supposed to do. Keep an eye on it because it only gets better.I'm looking forward to advanced reporting tools and support of differences in text files.
About the Author
Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty works for Lucent Technologies as a senior systems engineer on a customer team responsible for a major telecommunications carrier. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: ronald.mccarty@gte.net.
|