There are a number of good reasons to keep an eye on your server security. Few sysadmin types absorb the necessary security knowledge required to keep their infrastructure safe without enthusiasm and effort. If you’re anything like me, there have been a few bumps along the way, such as when I had a server compromised around the turn of the millennium thanks to a nasty PHP bug, or when I was faced with and repelled two relatively signifi cant DDoS attacks.
This chapter will cover another attack vector, rootkits, and a fantastic piece of software called Rootkit Hunter (you may know it as rkhunter). You will start off, however, by exploring how to monitor your filesystem’s important files, such as its executables.
Filesystem Integrity
I used Tripwire (http://sourceforge.net/projects/tripwire). It’s now referred to as Open Source Tripwire, thanks to the availability of other products. Tripwire ran periodically (overnight using cron) and used cryptographic hashing to monitor any fi le changes on your system.
By generating and recording the hashes of any files visible on the filesystem initially, during its first run, Tripwire was able to alert the administrator if any hashes didn’t match those it had recorded on each subsequent run. If the fi le had been altered in any way the hash would be changed. It’s a clever approach, despite being I/O resource intensive on older hardware, and has since given birth to great-grandchildren. One example is the popular AIDE (Advanced Intrusion Detection Environment), which is described as “a fi le and directory integrity checker” at http:// aide.sourceforge.net. I would certainly recommend trying AIDE or Tripwire on a development virtual machine if you get the chance. Be warned, however, that if you are lax with the initial configuration, then you will be bombarded with false positives.
This type of security often appears under the umbrella of host-based intrusion detection systems, or HIDS, and it was reportedly one of the first types of software-based security because mainframes had few externally risky interactions over networks.
If you don’t want to run nightly filesystem checks or you aren’t in a position to receive daily system reports, then that’s not a problem. You can opt to go for an older approach where you only scan your filesystem once, after you have built your server, in order to collect information about what files are installed on the filesystem. I will explain why this is useful in a moment.
Rootkits
Let’s now move onto a different approach to fi le fingerprinting.
If you’re interested in protecting your files against rootkits (which contain code that allows someone else to access or control one of your machines), then you should consider an excellent tool called RootKit Hunter (also called rkhunter; http://rkhunter.sourceforge.net).
At install time, the RootKit Hunter manual warns that if you’re trying to run the software on a presumably compromised system and the following standard commands or utilities aren’t present, then you probably won’t be able to run it successfully: cat, sed, head, or tail.
I’m pointing this out for good reason: these commands might be corrupt or missing on a compromised machine. If you’ve installed RootKit Hunter to hunt down evil files and you discover that your system has been compromised, then you really need to rebuild your machine. Don’t assume that the remedial work you do from that point onward will make your machine secure enough for ongoing use. It’s simply not worth it due to the time you will spend repairing the machine again in the future.
In other words, use software to identify successful attacks for exactly that purpose: identifi cation. Also, always assume that you’re going to need to run through a full rebuild afterward. I know from experience that these insidious rootkits are like filesystem limpets. You might fi nd (as I have in the past) that you spend more time chasing your tail attempting to clean the system than a rebuild would actually take.
Lectures aside, let’s look at using Rootkit Hunter. Once you have installed this sophisticated software, using the following commands, you can continue easily without any problem.
On Debian derivatives:
# apt-get install rkhunter On Red Hat derivatives:
On Red Hat derivatives:
# yum install rkhunter
Assuming that your installation didn’t throw up any errors, you can run a few simple commands to get started. The following command populates the fi le properties database with data about the files on your machine:
# rkhunter—propupd Next, in order to scan any new software being installed and to trigger after software updates have occurred, you should enable the APT_AUTOGEN option to yes in the fi le /etc/default/rkhunter. I have only verifi ed this on Debian derivatives with Apt Package Manager; there might be a different option on Red Hat derivatives.
Having made that change, you’re now ready to make your first run of RootKit Hunter, as follows:
# rkhunter—check
Note that there are subtle differences between versions or distributions, so try adding -c or –checkall if errors appear.
Periodically you can also update your rkhunter threat list with the following command (you could create a specifi c cron job if you like) to keep track of the latest threats:
# /usr/local/bin/rkhunter—update
As you can see, Rootkit Hunter is paying attention to the key directories that contain executable fi les (/usr/sbin in this example). These are exactly the types of binary files (among many others) that become infected by a rootkit.
Think for a moment of the Greeks and the Trojan horse allegory. In addition to those rootkits that immediately infect binaries, a piece of code can remain dormant for any period of time until executed by a legitimate user or on a schedule. Following that, a system compromise takes place.
Configuration
To configure Rootkit Hunter, you can edit its long confi g fi le, which can be found at /etc/ rkhunter.conf.
To receive overnight reports on the integrity of your machine, you just need to edit two confi g parameters, one defi ning the e-mail address of the recipient and the latter of which is adjustable if the standard mail command won’t work on your system by default.
Once inside the confi g fi le, look for these salient lines, uncomment them, and adjust them to your needs:
#MAIL-ON-WARNING=me@mydomain root@mydomain #MAIL_CMD=mail -s “[rkhunter] Warnings found for ${HOST_NAME}” The fi rst line, once uncommented, specifi es where to send the reports (multiple addresses can be separated by a space). The second line deals with the mail command and the subject line for the e-mail reports sent to those addresses.
20
Chapter 2: Digitally Fingerprint Your Files
c02.indd 04/15/2016 Page 20
Simply re-run the software with rkhunter—check to test if these changes work correctly and check your e-mail inbox.
To inspect the cron job that helps schedule when these reports will be generated, you can look in the fi le /etc/cron.daily/rkhunter. By default, cron.daily will generally run between 0100 hours and 0500 hours each morning on many distributions.
If you want to change how the e-mails look, then you can search for the following lines in the cron.daily file:
if [ -s “$OUTFILE” -a -n “$REPORT_EMAIL” ]; then
( echo “Subject: [rkhunter] $(hostname -f)—Daily report” echo “To: $REPORT_EMAIL” As ever, it might be prudent to create a copy of this fi le before altering it.
echo “Subject: [rkhunter] $(hostname -f)—Daily report”
echo “To: $REPORT_EMAIL”
As ever, it might be prudent to create a copy of this file before altering it.
Summary
You’re now armed with the ability to digitally fingerprint the files on your filesystem. As a result, you can quickly compare former MD5sums to see if your files have been altered, and also run Rootkit Hunter, either every night or periodically. The nice thing about rootkit checkers is that they also offer peace of mind by having a scheduled scan point out a confi g mistake that you’ve made. You can then hopefully remedy the mistake before it causes you further security issues.
From what I have covered, there are two rules that you should keep in mind:
■ Always keep your recorded MD5sums (or any other hashes) somewhere safe (encrypted and password protected) and far away from the server.
■ Don’t rely on rootkit tools to reduce your efforts postevent; just use them to identify the issue. From there, figure out how a compromise was possible before you set about rebuilding your machine.
0 Comments