This chapter is provided on an “as is” basis as part of the Apress Beta Book Program. Please
note that content is liable to change before publication of the final book, and that neither the
author(s) nor Apress will accept liability for any loss or damage caused by information
contained.
Copyright © 2004 for further information email
All rights reserved. No part of this work may be reproduced in any form or by any means,
electronic or mechanical, including photocopying, recording, or by any information storage
or retrieval system, without the prior written permission of the copyright owner and the
publisher.
Chapter 6
Tools for Security Testing
So you think you’ve got world-class security and a hardened site and systems? But do you
really? Just because no one has penetrated your systems yet doesn’t mean they are secure nor
does it mean you should rest on your laurels. If you are serious about security you need to be
constantly updating, refining and most importantly testing your security and hardened
systems. Though this by no means guarantees your security as new exploits and
vulnerabilities are discovered on a daily basis but it is the best way to become as confident as
possible that your systems are secure.
We look at three layers of security testing: the inner security layer, the outer security
layer, and the application security layer. We define the inner layer as consisting of the
operating system of your systems including such elements as your kernel security, file
security, and user and password security. Outer layer security consists of what is best
described as the ‘crust’ of your system. These are your system’s network connections, ports
or anything else that connects your systems to an intranet, the Internet or other systems. The
application security layer consists of the security of the applications running on your system.
In each chapter where we discuss hardening a particular application, we provide methods and
tools to help you test that particular application for any security holes or vulnerabilities.
Additionally one of the outer layer security tools, Nessus, acts as a security scanner which
often highlights potential issues with the applications or versions of applications you have
running.
We look at a variety of tools for testing the different layers of your security. Some of

names and passwords. More recently these functions have expanded to include capturing
passwords using Trojan programs, providing backdoors into your system, and masking the
fact that your system has been penetrated by purging or filtering logs. Rootkits can also
contain functionality designed to hide the attacker's logins and any processes they are
running.
To install and run a rootkit successfully, your attacker needs root access to your system.
Thus they have totally compromised your system and are now looking to expand their hold
on it. Think about a rootkit like a crowbar. Your attacker has penetrated your system,
probably using a user name and password of a low level user. They seize root access through
an exploit and use the rootkit to pry open your system further, to grab other user names and
passwords and to provide themselves with a jumping off point to attack other systems in your
environment.
We discuss seizing root access in Chapter x.
Recovery is going to be a long process. Your system has been seriously penetrated by the
time your attacker has installed a rootkit. Even if he has only cracked open the door slightly
there is still significant risk that he has subverted a variety of your resources. The first thing
most attackers do when they have penetrated your systems is to secure their foothold so it'll
be harder for you to get rid of them. We recommend that if you spot a rootkit then you
should pull the plug on that system immediately and isolate it from your network. Then look
at the recommendations later in the chapter in the section Detecting and Recovering from a
Penetration or Attack.
We look at two tools that are capable of detecting a variety of rootkits. These tools are by
no means infallible. They are generally not going to pick up rootkits that are new or changed
since the tools were released (depending on how they identify rootkits). Nor are they
substitutes for actually knowing what is running on your systems including activities such as
ongoing log analysis and comprehensive systems monitoring. They are after-the-fact tools.
They are only useful for telling you what has happened post-mortem an attack. Finally they
are capable of generating false positives. Some applications can appear to be acting like a
root kit. So investigate all results carefully before taking drastic action.
Rootkit Hunter

--skip-keypress Run in batch mode
--versioncheck Check for the latest version of Rootkit Hunter
The first option --cronjob adjusts the output of Rootkit Hunter to be suitable to run as a cron
job. It is usually run in conjunction with the --report-mode option which cuts down the report
to the essentials. The --cronjob option doesn't actually install the rkhunter as a cron job. You
need to add a crontab entry such as Example 6.4 which runs the rkhunter via cron and mails
to the user or alias admin once a month at 9pm.
Example 6.4 Rootkit Hunter crontab entry
0 21 1 * * /usr/local/bin/rkhunter --cronjob --report-mode 2>&1 |/bin/mail -s "Rootkit Hunter report"
admin
The next option --help provides a listing of all the possible command-line options. The --
nocolors option can be used for those terminals which do not have color support. We've
discussed --report-mode previously. The next option --skip-keypress runs Rootkit Hunter in
batch mode and removes prompts for key presses. The last option, --versioncheck, checks
the Rootkit Hunter website for a new version and reports if there is a new version and its
version number.
So what does Rootkit Hunter report? Well after some initial self-checks it checks a list of
commonly penetrated binary commands for any sign they have been subverted. Example 6.5
shows some of the results from this check.
Example 6.5 Binary command checks in Rootkit Hunter
* System tools
Performing 'known bad' check...
/bin/cat [ OK ]
/bin/chmod [ OK ]
/bin/chown [ OK ]
/bin/csh [ OK ]
/bin/date [ OK ]
/bin/df [ OK ]
Then Rootkit Hunter checks for the presence of a variety of rootkits and then finally for a
number of Login backdoors, rootkits files and sniffer logs. Check the onscreen or the log file

-n Skip scanning NFS mounted directories
-r directory Use directory as the root directory
-p directory1:directory2 Alternate paths for the external commands used by chkrootkit
The –d option runs Chkrootkit in debug mode that provides considerable amounts of
information about how Chkrootkit performs its checks. The –q option runs Chkrootkit in
quiet mode where it will only return output if it finds a rootkit or suspicious result. This is
useful if you want to run Chkrootkit as a regular cron job. The –x option runs Chkrootkit in
expert mode. In expert mode Chkrootkit leaves the analysis of strings found in binaries files
to determine the presence of a trojan to you. We recommend you pipe the output from expert
mode through more or into a file which you can then search using a tool such as grep. The –n
tells Chkrootkit to skip NFS mounted directories.
The –r option allows you to specify an alternative location as the root directory. This is
useful if you have removed the disk or disks from a compromised system and mounted them
on another system, for example an isolated test system. You can specify the root of the
mount as the starting point for your Chkrootkit scan.
Chkrootkit uses a variety of commands to perform its checks: awk, cut, egrep, find, head,
id, ls, netstat, ps, strings, sed, uname. Of course if your system has been penetrated then an
attacker could have subverted these commands too. This could mean that Chkrootkit has
unpredictable results or fails to identify the presence of an intrusion. Chkrootkit uses the –p
option to allow you to specify an alternate directory which you can populate with copies of
the commands you know are safe, for example installed from your installation media. You
can list multiple directories separated by colons.
When run Chkrootkit first checks a variety of binaries for the presence of trojans.
Example 6.9 shows a sample of these results.
Example 6.9 Sample Chkrootkit output
puppy# chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found

itself to parallel processing and using multiple systems to work on cracking passwords
simultaneously.
The second form of password cracking relies on inputting a dictionary of potential
passwords, encrypting them using the algorithm used by your password encryption, and then
testing them against the encrypted password. This sort of cracking assumes users have
chosen everyday words or combinations of everyday words as their password. This is quite
common unless you force your users not to use this style of password. The system
administrator's cliché of easily hacked systems with passwords such as "sex", "god", and
"love" is still alive and well out there. Given the choice your users will want to use a

1
/>password they can easily remember, often containing personal information such as birthdays
or pet's names, rather than a complex string of characters and symbols.
2
This is simply the
most dangerous form of password we strongly urge you not to let your users use ANY word
that is a dictionary word for a password.
As we mentioned in Chapter 5, there are also password generators available that can
assist your users in generating random passwords in suitable form to match your
password rules.
Running a password cracker over your password files on a regular basis is a good way to
ensure your users aren’t choosing weak or easy to guess passwords.
John The Ripper
We use a password cracker called John The Ripper (JTR). There are a few password
crackers out there, including the now venerable Crack.
3
We've chosen to look at JTR because
is it regularly updated, is fast and fairly simple to use. The other consideration we're making
is that it’s a known quantity. Consider this scenario: You decide you'd like to test your
passwords and go to a search engine and type in "password cracking my Linux root

puppy# john --wordlist=password.lst passwd
Example 6.11 shows JTR performing a dictionary-based attack using a list of words
contained in the file password.lst against passwords contained in a file called passwd. John
The Ripper comes with a simple file, password.lst, which is a collection of popular
passwords. You will need to need find some additional dictionaries and wordlists including
wordlists in other languages, especially if you have users who speak English as a second
language and may use foreign language words as passwords. This does not make it any
harder for attackers to penetrate their passwords. Attackers also have access to foreign
language dictionaries and wordlists.
You can find dictionary files in a few places. Try />and for a variety of lists including several foreign
language lists.
JTR comes with a number of command-line options you can use to modify its behavior.
We'll show you the list of the most useful in Table 6-3 and take you through their functions.
You can see the others by running the john binary without options from the command-line.
Table 6-3 John The Ripper Command-line options
Option Description
--wordlist=file | --stdin Read in a wordlist or text from standard in
--stdout=length Output passwords to standard out instead of cracking
--session=name Give this cracking session a name
--status=name Print the status of a particular session
--restore=name Restore a previous stopped session
--show Show any passwords JTR has cracked
--test Perform benchmark testing
The first option, --wordlist, we have seen in Example 6.11 and it allows you to test your
passwords against a list of words or a dictionary specified after the = symbol. Or you can add
the option --stdin to this option and read in a list of words from standard input which is useful
for inputting passwords to be tested programmatically. The second option, --stdout, does not
actually crack passwords but rather outputs the list of words and combinations of characters
that JTR would be testing against your passwords.
The next options relate to starting, stopping and restarting JTR. Obviously some cracking

We can't tell you how often to run your password cracking. We'd recommend if this is a
new concept to you or you have recently tightened your password rules to make your systems
more secure that you check all your existing systems using a tool such as JTR. JTR also
comes with an additional script, mailer, which is also in the run directory, which you can
modify and use to mailout to any users that JTR finds with weak passwords. You can also
incorporate JTR into a script of your own and disable or expire the passwords of any users
JTR finds with weak passwords. After securing your passwords we'd recommend you
consider adding a JTR dictionary-based scan to the cycle of your regular security checks.
Perhaps on a weekly or monthly basis timed in conjunction with your password expiry and
automated with a cron job or script.
Automated Security Hardening with Bastille Linux
On a Linux system there are a number of possible settings that can have an impact on
security. In this book we’ve tried to cover a lot of the basic settings that you need to secure
your system and overall how to implement a hardened security configuration methodology.
There are, however, a lot of individual settings that can be overlooked or are time consuming
to modify and secure. We look at an application, Bastille Linux, which will help you secure
many of those items.
What is Bastille Linux?
This application is a tool called Bastille Linux (hereafter Bastille) which is a Perl-based
hardening 'script'. Bastille can be run in a graphical mode under X or via the console. It is
designed to harden or tighten a variety of system security settings. Essentially Bastille takes
a system administrator through a variety of potential options that they can control, tries to
educate the administrator about those options and the implications of a variety of settings and
then provides the option (with a clear explanation of the consequences) to change those
settings to make them more secure.
Currently Bastille supports a variety of platforms including several Linux flavours: Red
Hat, Mandrake, SuSe, Debian and TurboLinux. Bastille is primarily developed by Jon Lasser
and Jay Beale and is available at It is an open source
application which is freely available under a GPL license.
We're going to take you through installing and using Bastille Linux. We're not going to

1:perl-Curses ########################################### [100%]
Now download the current version of Bastille, which at the time of writing was version 2.1.2-
01 and install it.
puppy# rpm –ivh Bastille-2.1.2-0.1.i386.rpm
Preparing... ########################################### [100%]
1:Bastille ########################################### [100%]
Bastille is now installed and ready to use.
Running Bastille
Running Bastille is very easy. It can be run in interactive or non-interactive (or batch)
modes. The first mode allows you to answer Bastille's configuration questions on screen
interactively. The second mode allows you to adjust your configuration based on the
information contained in a file. This means you can quickly replicate the security settings of
a previous run of Bastille onto the system. This is very useful for replicating security settings
across multiple systems. You only need to run Bastille interactively once, take the
configuration file it has created and then run Bastille with that configuration file on any other
systems. Starting it in interactive mode is simple and you can see the required command in
Example 6.15. It will generally detect whether it is able to start in console or graphical mode
or you can override that with a command line switch.
Example 6.15 Starting Bastille
puppy# bastille
Bastille has some additional command-line switches that are useful and we'll take you
through those next. Table 6-4 lists all the potential Bastille command line switches available
at the time of writing.
Table 6-4 Bastille Linux command line switches
SwitchDescription
-h Help text for the Bastille command
-c Use console mode
-x Use the graphical mode
-b Use batch mode and a saved configuration file
-l List the configuration file from the last run of Bastille

configuration screens.
Figure 8-1 shows you Bastille's usage explanation screen.
Insert 0349f0801.tif
Figure 8-1 Bastille's usage explanation screen
So what does Bastille do? Well it runs a variety of modules that allow you to configure
system-level security. These modules include such things as:
* Securing administration utilities
* Removing setuid from a variety of tools
* Setting password aging
* Setting a default umask
* Protecting GRUB and single-user mode
* Restricting root logons
* Disabling insecure network services
* Restricting use of the compiler
* Configuring firewalling
And a number of other functions. Bastille explains in some detail what making each change
will entail and why it is useful or more secure to change a particular setting and we'd
recommend reading very carefully through each section before making any changes.
After you've run Bastille you need to reboot your system! This is important and without it
the Bastille hardening process will not be fully active.
You can also undo the changes you have made on your system with Bastille. To do this
run the command in Example 6.17.
Example 6.17 Undoing the Bastille Linux changes
puppy# bastille –r
This generally works fine but there a caveat associated with using this. If you have changed a
great deal of your configuration since running Bastille it may not properly recognize what
needs to be undone. In this case Bastille will terminate with an error rather than try to revert
your configuration back to what it had previously stored.
Bastille Logging
Finally you can see a log of what Bastille has done. These logs are located in