信息来源：Stanley
In years past, the term intrusion detection had a general meaning: the methods by which an administrator learned about system intrusions, or about attempts to intrude, on a given system. As in most technological areas, intrusion detection has evolved and specialized. The security industry has grown to include a number of disciplines and subspecialties, each with its own cadre of professionals. Why worry about intrusion detection if you have a good firewall? Just remember: no lock is unpickable. Firewalls have holes so that services can run (web, mail, and so on). Where there's a hole, there's a way. Furthermore, most security experts will tell you that security is not a destination, but a journey. Even if you have outstanding security policies in place, rock-hard firewalls, and a completely trustworthy user and administrator base, you still need to watch your system like a hawk to make sure that everything remains safe.
In this article, we explain the basic concepts of intrusion detection and response. We also show you how to use common Linux tools and shell scripts to maintain the security of your system, keep a watchful (and automated) eye on your system, and offer some solutions to common intrusion detection problems.
Intrusion Detection and Response: An Overview
Modern intrusion detection covers a wide range of systems, functions, and tools. Some of these tools simply detect, log, or report intrusion attempts. Others respond to such attempts proactively. It's easiest to understand security as a multilayered issue. Firewalls and network intrusion detection systems (NIDS) make up the outer shells of a comprehensive security solution. In this article, we take a host-centric view of security, and thus view these external forms of intrusion detection as the outer layer of defense.
Once past these outer layers, you'll find other security tools for the inner layers. These host-level ID tools, or HIDS, monitor local user, file, and log activity. Some HIDS are host-network-based, but many are not network-based at all. These programs watch for signs of user escalation violations, deviations of regular activity from baseline comparisons, and log or file monitoring, among other functions.
Network-based intrusion detection tools watch for attack precursors (scans), attempts, and related network signatures. Generally, these tools are referred to as intrusion detection systems, or IDS. There are many subcategories of IDS, such as network-node-based IDS (NNIDS) and network-based IDS (NIDS), as well as host-based IDS (HIDS). In addition to these, you'll also find passive and reactive xlDS systems. Reactive systems can be tied into firewalls and are called intrusion prevention systems, or IPS. Learn more about these security tools at
http://www.securityfocus.com/infocus/1733.
Even though it's common to think that the greatest threat to a system is external, remember that valid local user accounts should also be considered untrusted or potentially hostile. System attacks that succeed usually install a rootkit of some sort, software that compromises your system and leaves a back door daemon installed and running. Thus, to add to your layers of security, you should also consider local file-system-level forms of intrusion detection in the form of file alteration and system baseline scan comparisons, as well as system to watch for signs of trojans, worms, and new, related cracking tools. These defense tools can include both native and third-party tools or suites. Examples of these would include cracking and rootkit detection tools, automated systems that keep an eye on local user access, accounts, user and system files, and common security auditing tools (which can be maliciously used to serve the cracker's needs).
This article is, by necessity, a mere introduction to the basics of host-based intrusion detection for Linux systems. We show you the basics of file alteration monitoring, a useful aspect of host-based intrusion detection, as well as offer pointers to other tools that may be useful in your installation. However, if you are responsible for security, take advantage of the many other books and resources on these topics. Don't take our word for it-do your own homework. You'll find a list of references and resources at the end of this article
Intrusion Detection Tools
Many Linux distributions include stock operating system tools that make file alteration monitoring easy and reliable if properly configured. In this section, we introduce some security functionality built into Red Hat and Fedora Core Linux, as well as additional common file alteration monitoring tools that you can download and install. If you want to purchase a commercial alternative, you can certainly do so; however, equally effective tools are available at no charge and as part of your regular installation. There's no excuse. Additionally, home-brewed security tools are sometimes seen as more secure than commercial OTS (of the shelf) solutions, as there is no known program for the intruder or his tools to detect as being installed.
Red Hat Package Manager
You probably think of RPM, or the Red Hat Package Manager, as an easy way to install and track software packages. Did you know that it also tracks individual file size, stock permission, user, group, and time settings, and even each file's MD5sum, or personal "fingerprint"? Using all this install-time information, you can check for all sorts of changes on your system. As you will see, all this information makes RPM an effective security tool in and of itself.
With RPM, you can are able to track every file on your system that was installed via RPM. With a bit of creative scripting and automation, you can even use RPM to watch all your files for changes over time. This is called file alteration or file integrity monitoring, and it is a critical aspect of host-based intrusion detection. Such monitoring shows you local intrusions in a way that network-based tools can't.
Learn more about RPM's file attribute tracking capabilities by issuing the command man rpm. Search down to the QUERY OPTIONS section, as well as the mnemonic keyword for much more detail on RPM file alteration tracking.
File System Tools
You can use other native Linux file system tools to detect cracker presence on your system. After a successful break-in, crackers like to use the command-line tool chattr (change attribute) to lock in their cracked changes at the ext2/3 file system level. However, you can use the counterpart of this tool, lsattr (list attribute), to sniff out the infiltrators and detect files that they have replaced and locked.
If you're using the Debian Linux distribution, consider using the debsums program. Just like RPM on Red Hat or SuSE Linux, debsums tracks MD5sums and other file attributes. Not all Debian packages use debsums yet, but an increasing number are being released with this capability.
An MD5sum or digest is a mathematical checksum, or "fingerprint," that can be generated for any given file. One way of creating an MD5sum is with the md5sum command-line tool. When the md5sum command is run against a file, it reads in the entire file and generates a 32-hexadecimal character label that is statistically unique to that file. If even one bit of data in the file changes, the MD5sum will be completely different the next time the digest is generated. This is a robust method for tracking the validity of files on your system, and is used in most commercial grade file alteration suites.
Watching Your System
Other basic Linux tools can help you keep an eye on your system and let you know what's going on, whether through e-mail or in real time. If you prefer to get regularly scheduled information through e-mail, consider logwatch. This program scans the various log files on your machine and sends a daily report (usually depending on log rotation frequency) of important system activity, ranging from e-mail access attempts to SSH login attempts on your system.
The logwatch automated monitoring service is configured by default on Red-Hat- and Fedora-Core-based systems. Do a man logwatch or locate logwatch on other systems to see if you have it installed and configured.
If you'd rather get your information in real time from the console, consider the Red Hat System Logs tool. To run this program, issue the following command.
redhat-logviewer
The tool will open a graphical system log tool. You can use the System Logs tool to look through the various log files, filter them for keywords, or even scan installed RPM packages to quickly see what version of a given package or packages you have installed.
On non-Red-Hat-based systems, the various log files are usually located in /var/log/, and these files can each be parsed or searched with your favorite tools for any of the information discussed above.
Third-Party Tools
If you're ready to move beyond the basic tools included with your Linux distribution, check out some of the third-party software solutions. There are a number of excellent IDS and host-based security suites for Linux, most of which are open source, and are free. Just because they aren't installed shouldn't keep you from giving them a try.
One of the most popular and powerful IDS for Linux is Snort. This tool does real-time traffic analysis and packet logging, as well as full-blown intrusion detection. It can detect a wide range of attack, probe, or scan types. Snort can even identify buffer overflows, port scans, CGI attacks, SMB probes, OS fingerprint attempts, and stays current with all the latest signatures that the cracker community is using. Once Snort notices an intrusion attempt, it can log the attack, fire off a script, or spawn another program to rebuff it.
Learn more about Snort at
www.snort.org/about.html
If you need to monitor kernel system calls, check out SNARE. It's a client application and kernel module combination, which work together to set up a monitoring tool that's truly operating system-wide. Any time a system call is made, whether for a simple file permission change or a file deletion, SNARE will log the information. Note that if you're installing SNARE on a Red-Hat-based machine, you'll probably need to recompile the kernel.
Find more information on SNARE at
http://snare.sourceforge.net
Finally, many Linux administrators rely on Portsentry. This is a small package that can be easily integrated into your iptables- or netfilter-based firewall. Portsentry is a port scan detector and blocking tool, and does a great job of identifying would-be crackers who are rattling your doors and windows for vulnerable services. Even though it's small, it's very responsive and a critical defense mechanism to many high profile Internet sites.
Portsentry is distributed as part of the sentrytools package, found at
http://sourceforge.net/projects/sentrytools/
Verifying Your Files with RPM
In order for any file alteration tracking method to work, you must have a baseline snapshot of your system so that you can compare the potentially compromised files to the intact versions. In this section, we show you how to do host-based file integrity checks with RPM. Later in this article, we'll show you how to use it to create a system-wide security baseline, and how to automate file alteration scanning, using RPM so that it becomes a regular part of your security routine.
If you want to use RPM's file alteration tracking capabilities as part of a truly secure installation, you should consider moving your system's RPM database and some basic system tools off the hard drive and onto write-protected removable media. These tools include many of the programs in /bin, /sbin, /lib, and /var/lib/rpm, as well as RPM's binaries and some statically compiled tools like /sbin/sash or /bin/ash.static. The truly savvy cracker might be able to compromise RPM itself, making it meaningless as a security tool
Using RPM for Maintenance
RPM is much like a scientific calculator. While it's got a huge array of functions and features, most people just use it to manage packages and installations, just like most people use scientific calculators to figure percentages and do long division. However, if you poke around RPM a bit, you'll find a number of ways to simplify package maintenance, track files and package versioning, and even utilize methods for bolstering system security.
You probably already use RPM for basic package management. For example, you can use the query mode to track package versions, with the following command
# rprn -q sendmail
sendmail-8.12.10-1.1 .1
RPM will show you all the packages on your system that have a given string in their name
# rprn -qa | grep mail
mailx-8.1.1-31.1
fetchmail-6.2.0-8
sendmail-cf-8.12.10-1.1.1
mailman-2.1.2-2
mailcap-2.1.14-1.1
sendmaiI-8.12.10-1.1.1
sendmail-doc-8.12.10-1.1.1
redhat-switch-mail-0.5.21-1
mozilla-mail-1.4.1-18
squirrelmail-1.4.0-1
procmail-3.22-11
You can even use RPM to figure out what package a deleted or missing file belonged to, so that you can reinstall or repair the damage.
# rm /bin/ping
rm: remove regular file '/bin/ping'? Y
# rpm -qf /bin/ping
iputils-20020927-9.1
By querying the RPM system for the missing file (with -qf), you can see what package the file belonged to, and which package would need to be reinstalled to fix the system. Assuming that you have already downloaded the package to be installed, here's how to use RPM to upgrade (reinstall), verbosely (with hashes), the package iputils
# rpm -Uvh iputils-20020927-9.1.i386.rpm
Preparing... ################### [100%]
package iputils-20020927-9.1 is already installed
Because the system thinks that the package is already installed, you may need to force it to reinstall (we'll also do the install from a remote copy of the package located on an FTP server).
# rpm -Uvh --force
ftp://example.com/pub/RPMS/iputils-20020927-9.1.i386.rpm
Retrieving
ftp://example.com/pub/RPMS/iputils-20020927-9.1.i386.rpm
Preparing... ####################################### [100%]
1:iputils ####################################### [100%]
The problem should be fixed. Use the following command to check it.
# ping -c 1 localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=64 time-0.113 ms
--- localhost.localdomain ping statistics ---
1 packets transmitted, 1 received, 0% packet loss. time 0ms
rtt min/avg/max/mdev = 0.113/0.113/0.113/0.000 ms, pipe 2
The example shows the usefulness of this functionality; however, most newer administrators never even use RPM to this level. If this basic functionality is surprising to you, just think about how much else you're missing out on.
How can you use RPM to track changes to critical system files? Let's revisit the example just shown.
# rm /bin/ping
rm: remove regular file '/bin/ping'? Y
# rpm -V iputils
missing /bin/ping
Here, we've used the --V switch, for verify. This option tells RPM to go through a listing of all of the files that were originally installed by the package being referenced, and compare all the file attributes (size, date, MDSsum, and so on) to those that now exist. Any differences are listed. If nothing is output from the command, then nothing has changed since the package install time
This verify option can also be used against all packages installed on the system (and all their files), to see what files are missing or changed.
# rpm -Va | grep missing
missing /usr/src/linux-2.4.22-1.2129.nptl/arch/i386/math-emu/.depend
missing /bin/ping
RPM compares the existing file listings to the RPM database of files that were installed and should be present. Anything that's different is listed. In the example, we're missing a file called .depend, as well as our deleted ping.
Always send the output of such RPM verifies into grep to filter it down. Otherwise, the output will flood your console, since many files on the system get modified in one way or another after they're installed (for example, config files, user files, logs, and the like). You usually want to use grep like this to return only the things that you're interested in.
The RPM database is rebuilt each time a new package is installed. Every database entry contains a list of the files that should be included in each package and what these files should look like. Very useful.
Using the -V or verify option is disk-and processor-intensive. Only run this command on a machine under light load, or run it during nonprime times. For example, the rpm -Va|grepmissing command shown above took nearly 15 minutes to run on a 1.6 GHz system, and drove the system load over 1.2 at times. This is not a tool for the heavily used production system.
Using RPM to Check Security
Yes, knowing whether a file is missing is helpful. What if a file still exists, but has changed? If a cracker has gotten into your system and replaced a critical system file with a version that includes a trojan or back door in place, you need to know about it. Use the verify all option again, but this time, limit the output to files that have the string bin/ in their path, like this.
# rpm -Va | grep 'bin/'
.M...... /usr/bin/smbmnt
S.5....T /bin/netstat
S.5....T /bin/Is
S.5....T /usr/bin/passwd
missing /bin/ping
S.?....T /bin/login
S.5....T /bin/ps
This output shows that someone has modified several of the system files with bin/ in their path. The 5 mnemonic indicates that the MD5sum, or fingerprint, of the file has changed. A question mark shows that RPM could not calculate the MD5sum of the file for some reason. If you have one or more critical system files with a modified fingerprint, it's likely that you've been cracked.
Commonly attacked files on Linux systems to watch out for include /bin/ls, /usr/bin/passwd, /bin/login, /bin/netstat, /bin/ps., /sbin/ifconflg, and /usr/bin/chattr, just to name a few.
Once a system has been compromised, you can no longer trust anything, not even unmodified files. The only solution is to get the system off-line, get all nonexecutable content off the system, and reformat and reinstall fresh.
RPM stores a number of attributes about every file on the system for which it's responsible. These attributes are represented by the following mnemonics:
S: File size
M: Modes (includes permissions and file type)
5: MD5sum
D: Device major/minor numbers
L: readLink(2) paths
U: User ownership
G: Group ownership
T: Timestamp
You can use RPM to check for differences between the install time and the existing file system using any of these attributes.
If you're going to use RPM as a security tool, commit to it. Avoid mixing RPM package management with other forms, such as pkg, tarball, source code files, or converted Debian packages. Everything needs to be installed through RPM so that you can count on the RPM database when you need accurate information.
Once you've checked the existing files against the RPM's MD5sum information in it's database, you may need to look at the files a bit more closely. A compromised system sometimes includes other tracks or evidence. Collecting such information is referred to as intrusion forensics.
Other evidence you may detect on a compromised system may include special file attributes that shouldn't be on a normal Linux system, hidden within the ext2 and ext3 file system itself. One of these of these cracker-utilized file system attributes is the immutable control bit. On a compromised system, you might see settings in the /bin directory, from the output of the list attribute or lsattr command, that look like this.
# lsattr/bin/* /sbin/* /usr/bin/* /usr/sbin/*| grep "i--"
----i-------- /bin/login
----i-------- /bin/netstat
----i-------- /bin/ps
----i-------- /sbin/insmod
----i-------- /sbin/kallsyms
----i-------- /sbin/ksyms
----i-------- /sbin/lsmod
----i-------- /sbin/modprobe
----i-------- /sbin/rmmod
----i-------- /usr/sbin/sshd
Unless you've set these files to be immutable yourself, this is another good indicator that your system has been cracked. These immutable bits keep even the root user from deleting, moving, changing, or even reinstalling the files. The ultimate fix, as previously mentioned, is a complete reinstall. However, the way in which you "un-set" these bits is with the chattr command, like this.
# chattr -i /bin/login
# lsattr /bin/login
------------- /bin/login
Now this file, at least, appears to be back to normal. Just remember, we really can't trust our own eyes on this system as even the kernel could be faking us out and we would never know it. This type of fix is really more of a band-aid to give you a stopgap measure on a production system (to get it as patched up as you can) until you can migrate all the content off and reformat the system
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/sendmail.mc
S.5....T c /etc/mail/statistics
SM5....T c /etc/mail/submit.cf
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 article 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 Secure---
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."
First, download the latest version of the program (this link is from
www.chkrootkit.org).
# wget
ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
Untar it:
# tar xzvf chkrootkit.tar.gz ; /bin/rm chkrootkit.tar.gz
Then, compile it.
cd chkrootkit-0.44/
# 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.44/ /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.44
This should work just fine. To be sure, test it.
# cd /mnt/tmp/chkrootkit-0.44/
# ./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.
Automating System Scanning and Notification
At this point, you've created some basic security tools and built a secret place to store them. Now, you need to bring it all together and build a single coherent system-scanning mechanism customized for your machine. This mechanism should be automated so that you get the results of a daily check-up without having to remember to run it. In this section, we build a script that will tie all these host-based intrusion detection elements together.
As you begin to build your scanning tool, you need to decide how you want your system to be monitored. In general, we recommend the following daily tasks:
Run an RPM verify and compare it against the RPM baseline you created
Scan for ext2/3 immutable attribute file settings (created with chattr +i ), using the lsattr program
Run chkrootkit to see if any known tools have compromised your system
Scan system logs for unusual entries
Have the program place the output of all these operations into a file for daily system-scan results, and e-mail this scan summary to you
With these actions, all system scans are output into a single location. You can then set it up so that the results are e-mailed to you daily. If there's a problem, chances are that you'll detect it with one of these tools. In the worst case, you won't get your daily report, indicating that the crack has sufficiently crippled the system to stop all cron jobs. In either case, you'll know something is wrong.
To begin this process, make sure that your soft partition is still mounted. We're going to group all the necessary programs and command-line tools in this hidden location.
First, make two subdirectories in the soft partition.
# mkdir /mnt/tmp/bin
# mkdir /mnt/tmp/logs
Next, copy the packages that the script will need in order to function.
# cp -a /bin/Is /bin/echo /bin/cat /bin/mail /bin/rpm /usr/bin/lsattr /usr/bin/diff /bin/grep /mnt/tmp/bin/
This is not a full complement of programs, as you are not adding the required libraries or using a static compilation. If you set this partition up as a part of your regular security protocol, be sure you have everything necessary for the programs to run properly, including a static shell. Another popular addition to this stash of tools is a statically compiled shell such as BusyBox (see
www.busybox.net).
Finally, move the RPM baseline file you created earlier.
# mv RPMV_2004-02-29 /mnt/tmp/logs/RPMV_2004-02-29_golden
A Simple Scanning Script
Now that everything's in place, you can create the shell script that will run all the programs and get the output you want. This sample script runs under the bash shell; if you prefer another shell, we assume that you've already got the skills to duplicate these functions in that environment. Create a script similar to this one, and place it somewhere unexpected on your disk with an inconspicuous name.
#!/bin/bash
MYMAIL=bob@example.com
PATH=/mnt/tmp
DATE="$(date +%Y-%m-%d)"
### Setup System ###
mount -o loop /home/bob/Desktop/chk-file $PATH
# Report usage of mount point into system-scan file
df -h | grep mnt /tmp > $PATH/logs/system-scan_$DATE
curdir=$(pwd)
### 1) Daily RPM Verify -->"system-scan_[date]"
$PATH/bin/echo -----DIFFERENCES IN RPM-DB AS OF $DATE-----
