Jason: This is interesting and it's good to see more people using this tool. However, I've got a new design that you may want to consider and I'd recommend for this type of tool along with any Tripwire type tool and possibly even others. Create a chkrootkit server. On this machine you have binary builds for your different platforms along with a data repository of output data. Deployment works by scp, moving the files to the target hosts and running chkrootkit and copies the results back to the chkrootkit server and removes all traces of chkrootkit running on the target machine. The output data is processed and email to admin or dumped to a webpage for review. This way the binaries are not sitting on the machine you are trying to protect and any attacker is unaware chkrootkit is being run until the process comes by the machines, effectively surprising the attack if they notice at all. I've created a similar tool for file integrity monitoring, running once every half hour and found it is also effective as a change control tool. Futhermore, there is added piece of mind knowing that if someone does break in, they would have to disable or prevent the integrity tool from running essentially without prior knowledge it was running. Anyway, just a suggestion that I have found works well for large deployments and doesn't really count on the machine you are trying to monitor. Thanks, Jon On 25-Feb-2002, Jason Dixon wrote: > A few updates... > > 1) Change the standard file attributes on the md5 file before setting > the immutable flag. I make mine 0400 so it's read-only by the superuser. > (chmod 0400 /etc/chkrootkit.md5) > 2) You may need to edit the location of your mail program in line 18 > (changed mine from /usr/bin/mail to /bin/mail). > 3) Line 32 of the script will need to be adjusted on Linux boxes... the > md5 output is reversed. Simply replace the command 'pop' with 'shift'. > > -Jason > > On Fri, 2002-02-22 at 17:55, Jason Dixon wrote: > > Thanks to an article on the O'Reilly network > > (http://linux.oreillynet.com/pub/a/linux/2002/02/07/rootkits.html), I've > > started using chkrootkit (http://www.chkrootkit.org), a utility that checks > > for rootkits on your Linux/BSD/Solaris install. It looks for certain > > signatures in trojaned system binaries and compares them against known > > rootkits. It includes other tools that check for network promiscuity > > (ifpromisc), lastlog deletions (chklastlog), wtmp deletions (chkwtmp), > > wtmpx deltions (check_wtmpx - Solaris only), and checks for signs of LKM > > trojans (chkproc). > > > > I've performed some extra steps which allow me to automate the running of > > chkrootkit, while also authenticating the validity of the chkrootkit binary > > itself. I'm including the steps here, in case anyone else would like to > > try this on their own systems. Please note... this utility is great for > > checking against *known* rootkits... it's not a substitution for common > > security practices. I would also suggest that anyone serious about > > preventing rootkit modifications also ensure they install Tripwire on all > > new installations. However, in situations where a box does not already > > have Tripwire installed, chkrootkit is a great tool to help gain back some > > peace of mind. This document covers Linux and *BSD installs only. > > > > Installation of chkrootkit is very simple. Grab the tarball, uncompress, > > and run 'make sense' (as root). Copy the binaries to a standard system bin > > (I used /usr/local/sbin). Cd to the new location and run the chkrootkit by > > hand to make sure everything looks good.... > > > > tar zxf chkrootkit-0.35.tar.gz > > cd chkrootkit-0.35/ > > make sense > > cp chkrootkit /usr/local/sbin/ > > cp chkwtmp /usr/local/sbin/ > > cp chklastlog /usr/local/sbin/ > > cp chkproc /usr/local/sbin/ > > cp ifpromisc /usr/local/sbin/ > > ./chkrootkit > > > > The output will look something like this... (snipped for brevity's sake) > > > > ROOTDIR is `/' > > Checking `amd'... not infected > > Checking `basename'... not infected > > Checking `biff'... not infected > > Checking `chfn'... not infected > > Checking `chsh'... not infected > > Checking `cron'... not infected > > Checking `date'... not infected > > ... > > Checking `sniffer'... > > dc0 is not promisc > > sl0 is not promisc > > ppp0 is not promisc > > bridge1 is not promisc > > gif0 is not promisc > > Checking `wted'... nothing deleted > > Checking `z2'... nothing deleted > > > > Ok, now for the extra layer of security. To ensure that no one tampers > > with my chkrootkit binaries, I've created a new file (/etc/chkrootkit.md5) > > containing the md5sum for each binary. Next, we want to modify the md5 > > file so nobody can tamper with it. We want to turn on the *immutable* bit > > for this file. Making a file immutable means that no one can modify the > > delete the file. In linux, we want to use the 'chattr +i' command... in > > *BSD, the same command is 'chflags schg'. To view special attributes, you > > must use 'lsattr' in Linux and 'ls -lo' in *BSD. Note that in Linux, the > > immutable flag can be removed by the superuser at any time with 'chattr > > -i'. In *BSD systems, you can only remove the "system immutable" (schg) > > flag in securelevel 0 or -1 (single-user mode is an example of securelevel 0). > > > > md5sum chkrootkit >> /etc/chkrootkit.md5 > > [run the same command for each binary; command is 'md5' in *BSD] > > > > chattr +i /etc/chkrootkit.md5 [Linux] > > chflags schg /etc/chkrootkit.md5 [*BSD] > > > > To automate these utilities, I've setup a cron job to execute a perl script > > I've created which first authenticates our stored md5 digests against the > > current md5 values. It uses the Digest::MD5 perl module to run the > > digests. Installing the perl module is very simple... grab the tarball, > > uncompress to a directory, run (as root) 'perl Makefile.pl', 'make', 'make > > test' and 'make install'. > > > > wget http://www.cpan.org/authors/id/GAAS/Digest-MD5-2.16.tar.gz > > tar zxf Digest-MD5-2.16.tar.gz > > cd Digest-MD5-2.16/ > > perl Makefile.pl > > make > > make test > > make install > > > > Here is the script... I make no guarantees... YMMV. Note the variables > > that should be changed specific to your usage... $md5_sav_file (location of > > your trusted md5 file), $runpath (location of your chkrootkit binary), and > > $admin_mail (your email address... make sure to escape the '@' with a > > backslash or perl won't interpret it correctly). The script will first > > compare the known and trusted md5 sums found in our immutable file to the > > current md5 sums of the binaries. If there are any discrepancies, it will > > report them. Next, it will cd to the system bin (as defined by $runpath) > > and run the chkrootkit binary. It needs to cd to the directory, as > > chkrootkit will attempt to run the other utilities within it's current > > directory. > > > > #!/usr/bin/perl -w > > # safe_chkrootkit.pl > > > > use strict; > > no strict 'subs'; > > use Digest::MD5(md5_hex); > > > > my $md5_new; > > my $md5_sav; > > my $md5_sav_file = "/etc/chkrootkit.md5"; > > my $file; > > my $file_and_path; > > my $path = "/usr/local/sbin"; > > my @files = qw( ifpromisc chkproc chkrootkit chklastlog chkwtmp ); > > my @input; > > my $admin_mail = "admin\@localhost.com"; > > > > open(MAIL, "|/usr/bin/mail $admin_mail"); > > print MAIL "Running authentication tests on chkrootkit binaries...\n\n"; > > > > while (<@files>) { > > $file = $_; > > $file_and_path = "$path/$file"; > > open(MD5,"$file_and_path") || die "Can't open file for reading: $!"; > > $md5_new = Digest::MD5->new->addfile(MD5)->hexdigest; > > close(MD5); > > open(TST,"$md5_sav_file",) || die "Can't open file for reading: $!"; > > while (<TST>) { > > chomp; > > if (/$file/) { > > @input = split(/ /,$_); > > $md5_sav = pop(@input); > > unless ($md5_new eq $md5_sav) { > > print MAIL "\t\t\t*** WARNING ***\n"; > > print MAIL "The binary file for " . $path > > . "/" . $file . " has been altered.\n"; > > print MAIL "The original md5 sum for $file > > was\n\n"; > > print MAIL "\t\t$md5_sav\n\n"; > > print MAIL "and the new md5 sum is\n\n"; > > print MAIL "\t\t$md5_new\n\n"; > > print MAIL "Please investigate ASAP\n"; > > print MAIL "\t\t\t*********************\n"; > > } else { > > print MAIL "\[$file\]\n"; > > print MAIL "Current: $md5_new\n"; > > print MAIL "Trusted: $md5_sav\n\n"; > > } > > } > > } > > close(TST); > > } > > > > I hope that others find this as useful as I have. I've implemented this on > > my OpenBSD firewall, and plan on installing it on my Linux workstation > > ASAP. Keep in mind that there are many other facets of system security > > that should still be scrutinized, but this is a nice tool to help out > > nonetheless. If anyone has any questions, comments or suggestions > > regarding my usage of this program, or the functionality of the script, > > please let me know. > > > > -Jason > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > ---------------------------------------------------------------------------- > > This list is provided by the SecurityFocus ARIS analyzer service. > > For more information on this free incident handling, management > > and tracking system please see: http://aris.securityfocus.com > > > > ---------------------------------------------------------------------------- > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com > ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Feb 25 2002 - 16:09:06 PST