|
|
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/
| Note |
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
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----- \ »$PATH/logs/system-scan_$DATE $PATH/bin/rpm Va | grep .^..[5?]'>$PATH/logs/RPMV_$DATE #compare current to our "golden" baseline file $PATH/bin/cliff $PATH/lods/RPMV_$DATE $PATII/1ogs/RPMV_2004-02-\ 29_golden| $PATH/bin/grep "bin\ /">>$PATH/logs/system-scan_$DATE $PATH/bin/echo ^^^^^END RPM DIFFERENCES^^^^^ >>$PATH/1ogs/system-scan\ _$DATE $PATH/ bin/echo >>$PATH/logs/System-scan_$DATE ### 2) Quickly check for any immutable bit hacks -->"system-scan_[date]" $PATH/bin/echo >>$PATH/Iogs/systern-scan_$DATE $PATH/bin/echo -----IMMUTABLE CHECK--------- >>$PATH/logs/system scan\ _$DATE $PATH/bin/lsattr /bin/* /sbin/* /usr/bin/* /usr/sbin/* | grep ' i --'>>$PATH/\ logs/sys tern-scan_$DATE $PATH/bin/echo ^^^^^END IMMUTABLE CHECK ^^^^^>>$PATH/logs/system-\ scan_$DATE ### 3) Root Kit Scan - ->"system-scan.[date]" $PATH/bin/echo >>$ PATH /logs/system-scan_$DATE $PATH/bin/echo -----CliKROOTKIT ------- >>$PAFH/logs/system-\ scan_$DATE cd $PATH/chkrootkit-0.43/ ./chkrootkit -q | grep INFECTED >>$PATH/logs/system-scan_$DATE cd $curdir $PATH/bin/echo ^^^^^END CHKROOTKIT ^^^^^>> $PATH/logs/system-\ scan_$DATE ### 4) Daily Log Scan&Grep -->"system scan_[date]" $PATH/bin/echo-----LOG-SCAN----->>$PATH/logs/system-scan_$DATE $PATII/bin/echo --POSSIBLE BREAK IN ATTEMPT>>$PATII/logs/system-scan_$DATE $PATH/bin/cat /var/log/messages | grep POSSIBLE >>$PATII/logs/system\ -scan_$DATF $PATH/bin/echo >>$PATH/logs/system-scan_$DATE $PATH/bin/echo --SYN SCAN>>$PATH/logs/system-scan_$DATE $PATH/bin/cat /var/log/messages | grep SYN >>$PATH/logs/system-\ scan_$DATE $PATH/bin/echo >>$PATH/logs/system-scan_$DATE $PATH/bin/echo --portsen»$PATH/logs/system-scan_$DATE $PATH/bin/cat /var/log/messages | grep portsen»$PATH/logs/system-\ scan_$DATE $PATH/bin/echo >>$PATH/logs/system-scan_$DATE $ PATH/bin/echo --LOGIN>>$PATH/logs/system-scan_$DATE $PATH/bin/cat /var/log/messages | grep LOGIN>>$PATH/logs/system-\ scan_$DATE $PATH/bin/echo >>$PATH/logs/system-scan_$DATE $PATH/bin/cat /var/log/messages | grep sshd>>$PATH/logs/system-\ scan_$DATE $PATH/bin/echo >>$PATH/logs/system-scan_$DATE $PATH/bin/echo ^^^^^END LOG-SCAN ^^^^^>>$PATH/logs/system-\ scan_$DATE $PATH/bin/echo >>$PATH/logs/system-scan_$DATE $PATH/bin/echo --DONE-->>/mnt/tmp/logs/system-scan_$DATE ### 5) Mail out the "system-scan_[date]" file to MYMAIL $PATH/bin/cat $PATH/logs/system-scan_$DATE | $PATH/bin/mail \ -s"System Scan for $DATE" $MYMAIL cd $CURDIR umount $PATH ###Remove All Comments Once You Get It Fully Customized
Set permissions with the command chmod 750 filename so that it will run.
This is a straightforward and basic script using only command-line functions. Of course, you can build much more complex scripts with their own logic, real-time monitoring triggers, and various e-mail messages. However, this script will do the simple dirty work that's necessary.
| Note |
Section 4 of this script is used to look for SSH logins, port scans, SYN flood attacks, and the like in your system log file put there from the Portsentry portscan detection package. Portsenty is a useful package that watches your system for pre-attack-type traffic such as port scans, stealth scans (both TCP and UDP based), Denial of Service attacks, and so on. You can even have Portsentry block would-be attackers, and even launch counterstrikes (really not recommended). If you want to implement this function, install Portsentry. See the Intrusion Detection Resources section for more information on this valuable package and where to get it. |
Test your script a few times to be sure it works, before you start to rely on it. Before running it, . set up your system to register some positive signs of cracker activity so you'll be sure to see what it looks like. Do this by modifying a system binary in /bin/ (back it up first), putting a test rootkit binary on your system (carefully), or setting an immutable bit on a file, such as /bin/ls or /bin/ps. If you decide to install and run Portsentry, have an administrator portscan you from another network to verify that it sees the scan and blocks it (with iptables in most Linux installs). After you do some of this, test your script.
When you get the output from your test session, you will see something that looks like this if the box has been compromised.
146M 1.2M 137M 1% /mnt/tmp -----DIFFERENCES IN RPM-DB AS OF 2004-03-01----- > .M...... /usr/bin/smbmnt > S.5....T /bin/netstat > S.5....T /bin/Is > S.5....T /usr/bin/passwd > S.5....T /bin/login > S.5....T /bin/ps ----TESTING bin/ for MD5SUM Changes, Nothing ^^Above^^ Means System Is Secure - - ^^^^^END RPM DIFFERENCES^^^^^ ------IMMUTABEE CHECK-------- ----i-------- /bin/Is ^^^^^END IMMUTABLE CHECK ^^^^^ ----- -CHKROOTKI -------- Checking 'ls'... INFECTED ^^^^^^END CHKROOTKIT --- LOG-SCAN----- --POSSIBLE BREAK IN ATTEMPT --SYN SCAN --portsen --LOGIN --SSHD Mar 1 03:31:02 localhost sshd: sshd -TERM succeeded Mar 1 13:42:30 office101-89 sshd: succeeded ^^^^^END LOG-SCAN^^^^^ --DONE---
As you can see, the script found a number of file integrity violations on critical system files. In addition, the /bin/ls system binary now has an immutable bit set, and possibly has also been infected with a rootkit. Any of these three violations would give you reason to start digging through history files. If this were for real, with hits on all three, this box would definitely be considered compromised.
Compare the output of the compromised box above to this, which is the output from a clean machine.
146M 1.2M 137M 1% /mnt/Lmp -----DIFFERENCES IN RPM-DB AS OF 2004-03-01----- ----TESTING bin/ for MD5SUM Changes, Nothing ^^^Above^^ Means System Is Secure - - - ^^^^^END RPM DIFFERENCES^^^^^ ------IMMUTABLE CHECK------- ^^^^^END IMMUTABLE CHECK^^^^^ ------CHKROOTKIT -------- ^^^^^END CHKIROOTKIT ^^^^^ -----LOG-SCAN----- --POSSIBLE BREAK IN ATTEMPT --SYN SCAN --portsen --LOGIN --SSHD Mar 1 14:38:023 localhost sshd: sshd -TERM succeeded Mar 1 16:42:30 ofice101-89 sshd: succeeded ^^^^^^END LOG-SCAN^^^^^ --DONE---
A script like this is an essential part of ensuring that your security measures are working. If you keep your server patched and locked down, and you implement the foundational security policies as described in the troubleshooting section of this chapter, and in the Internet Server Security article listed in the resources, then you may never have to see the "unhappy" version of the script's output.
Once you've verified that the script works, it's time to automate the daily scan. This could be as simple as adding an entry to root's crontab file with a bit of camouflage.
# crontab -e 01 1 * * * /some/dummy/script.sh 02 2 * * * /some/out/oftheway/dir/sys-cl eanup.sh 03 3 * * * /some/other/dummyscript.sh
A stealthier option is to attach the script to another automated system, like logrotate.
/var/log/messages /var/log/secure /var/log/maillog
/var/log/spooler /var/log/boot.log /var/log/cron {
prerotate
/some/out/oftheway/di r/sys-cleanup.sh
endscript
sharedscripts
postrotate
/bin/kill -HUP 'cat /var/run/syslogd.pid 2>
/dev/null'2> /dev/null | | true
endscript
}
However, cron is easily killed by an invader. Using cron, or anything spawned by cron, is probably not the best idea. Consider using the at scheduler to put the script on a timer, and running it from some other system shell script or from /etc/inittabasa daemon instead.
| Tip |
Do a man at to learn more about how to use this often-overlooked scheduling tool. |
|
|