Creating a Security Baseline

Creating a Security Baseline

In order to get useful information about your system, you need to compare the existing reality against a known standard, or baseline. While the RPM database has a recording of all packages as they were when installed, many things get modified by administrators and users after that point. It's important to get a production system up and running (but not yet live), and create a secure operational baseline against which you can regularly measure against as a security check. It is best to create this baseline as soon as you get your operating system installed, configured, and ready to go online. Be sure to make the baseline before you connect this machine to the Internet. It's no good to baseline a machine that's already compromised.

Making an RPM Baseline

In this section, we show you how to create a system baseline with RPM. We'll store the baseline in a directory called /root/stuff/ -don't call it anything obvious like /root/security/original.baseline unless you want the crackers to find it. The first step is to build an RPM change-snapshot of the system (what's been changed since install time-MD5sum differences), and store that in a baseline file.

   # rpm -Va | grep "..[5?]'>/root/stuff/RPMV_$(date +%Y-%m-%d)

This command invokes a full system verify, producing a list of files that have the MD5sum state of 5 (changed), or ? (unknown/cannot check), and saves it to the filename with a date stamp in the name. In about 15 minutes on a reasonably fast machine, you should have a file with a name similar to RPMV_2004-01 - 30. The contents of the file will look like this.

   S.5....T c /etc/pam.d/system-auth
   S.5....T c /etc/1 dap.conf
   S.5..... c /etc/rndc.key
   S.5....T c /etc/sysconlig/named
   S.5....T c /etc/xinetd.d/ktalk
   S.5....T c /etc/ssh/sshd_config
   S.5....T c /etc/yum.conf
   S.5....T c /etc/sysconfig/redhat-config-securityleve1
   S.5....T c /etc/xinetd.d/telnet
   S.5....T c /etc/xinetd.d/amanda
   S.5....T c /etc/krb.conf
   S.5....T c /etc/sysconfig/pcmcia
   S.5....T c /etc/auto.master
   S.5....T c /etc/aliases
   S.5....T c /etc/mail/
   S.5....T c /etc/mail/statistics
   SM5....T c /etc/mail/
   S.5....T c /etc/httpd/conf/httpd.conf

All these files have changed since the time they were first installed and their original MD5sum fingerprint was recorded. Note that these are mostly configuration files (the lower case c next to the T); if you're making the baseline as part of the installation process, it's obvious that you probably changed these things yourself. This file is now the template against which you will run the diff command to check system file integrity in the future.


If you're storing other security tools on write-protected media like a floppy disk, this file should probably go there as well. However, later in this chapter we show you how to store baseline files on a special hidden area of the system.

Next, append this single line to the end of the RPMV file you just created.

----TESTING bin/ for MD5SUM Changes, Nothing ^ ^ Above^ ^ Means System Is

This line is used as a trigger during the diff comparison of the baseline and the daily scan. It will prove that the daily scan is working. If anything shows up in the daily report displayed above this line, then you know you've got some type of suspicious change on your system to check out further. Now that we have a baseline file established, let's turn to another tool. We'll come back to RPM in a minute.

Adding chkrootkit Scans

It's a good idea to get multiple sources of input when you're scanning your system for signs of intrusion. The chkrootkit package is an excellent addition to RPM baseline comparison checks. This intrusion detection tool is a set of automated reporting programs run through a single shell script that can be updated with the latest rootkit signatures to detect all the latest cracker exploits. Think of it as a "cracker virus scanner."


Obviously, if a cracker sees chkrootkit on your system, he'll probably delete it. From this point on, we begin to hide security tools in a secret spot on the disk, where crackers are unlikely or unable to look.

First, download the latest version of the program (this link is from

   # wget

Untar it:

   # tar xzvf chkrootkit.tar.gz ; /bin/rm chkrootkit.tar.gz

Then, compile it.

   # cd chkrootkit-0.43/
   # make sense
   gcc -DHAVE_LASTLOG_H -o chklastlog chklastlog.c
   gcc -DHAVE_LASTLOG_H -o chkwtmp chkwtmp.c
   gcc -DHAVE_LASTLOG_H -o ifpromisc ifpromisc.c
   gcc -o chkproc chkproc.c
   gcc -o chkdirs chkdirs.c
   gcc -o check_wtmpx check_wtmpx.c
   gcc -static -o strings-static strings.c

Now it's time to create the hiding place. These next commands make a soft partition of 150MB. You can think of a soft partition as a "floppy image file," used to store data without a hard location on the drive.

Use the dd command to create the boundaries of the soft partition:# dd
 if=/dev/zero of=/home/bob/Desktop/chk-file bs=150M count-1

Then, format the partition.

   # mke2fs /home/bob/Desktop/chk-flle
   mke2fs 1.34 (25-Jul-2003)
   /home/bob/Desktop/chk-file is not a block special device.
   Proceed anyway? (y,n)  y
   Filesystem label= OS type: Linux
   Block size=1024 (log=0)
   Fragment size=1024 (log=0)

Make a mount point for the new soft partition and mount it as a loop device file system.

   # mkdir /mnt/tmp
   # mount -o loop /home/bob/Desktop/chk-file /mnt/floppy/

See what we just created?

   # df -h
   Filesystem                 Size Used Avail Use% Mounted on
   /dev/hda3                   18G 7.5G  9.5G  44% /
   /dev/hda2                   99M 12M    83M  13% /boot
   none                       109M 0     109M   0% /dev/shm
   /home/bob/Desktop/chk-file 146M 1.2M  137M   1% /mnt/tmp

Now you can hide the chkrootkit scanning tool in the new partition.

   # cd ..
   # mv chkrootkit-0.43/ /mnt/tmp/
   # Is -la /mnt/tmp/
   total 12
   drwxr-xr x   3 root   root   4096 Feb 29 22:59 .
   drwxr-xr-x   8 root   root   4096 Feb 29 22:58 ..
   drwxr-xr x   2 1000   1000   4096 Feb 29 22:52 chkrootkit-0.43

This should work just fine. To be sure, test it.

#  cd /mnt/tmp/chkrootkit-0.43/
#  ./chkrootkit | grep INFECTED

Just as planned. If the scan had found evidence of some back door or cracker rootkit on your box, you would have seen an INFECIED flag pop up from that last command. Go ahead and try running it without the grep filter to see what the output normally looks like, and what files on your system get scanned.

Now we have a second cool scanning tool that we can bring up (by mounting its soft partition on the fly), quickly scan the system with for cracker tools or signs of intrusion, and then unmount again when done. By hiding the program in the soft partition, we can't see it by stupid script kiddie scripts. Leave the soft partition mounted for now, because we're going to develop and hide our RPM baseline comparison scanner system in that soft partition file as well.


Write-protected removable media is still the best thing to use for this type of project. Something like a floppy, USB flash disk, or the like will give you better security even still. The former is probably more common; the latter probably better overall. Some added level of physical security and assurance can also be found by bringing a USB bus to the inside of your server case (via either motherboard USB connectors or USB card), and just leaving the solid-state flash disk permanently hooked up inside the locked server's case. This would ensure that your new intrusion detection tool kit isn't tampered with, removed, or stolen.

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows