Tài liệu Tools for Security Testing ppt

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

these tools need to be installed on your local system (and some should be removed when
you’re finished with them to prevent them from providing aid to an intruder) and some can be
run across your network or from another host. We take you through installing and running
those tools and how to interpret the results of those tools. These tools are by no means the
only tools available to you. There are a variety of other security tools that are useful. We'll
list some of those at the end of the chapter with a brief description of each.
Do not take the results of any of these tools as ‘security gospel'. They are fallible. Just
because a particular security tool tells you your systems are secure simply means that they are
secure against all the exploits or vulnerabilities the author(s) of that tool have envisaged or
addressed. You need to keep up to date with new vulnerabilities, bugs and exploits and
ensure your systems and applications are kept up to date as we have discussed in Chapter x.
As previously mentioned two good places to start if you want to keep track of
vulnerabilities and exploits are the Bugtraq mailing list at
and the />site and associated mailing lists.
We're also going to look at some methods of detecting a penetration that don't require any
tools. Lastly we're going to look at the worse case scenario. That someone has penetrated
your system and now you need to know how to respond and recover. We'll cover some
general ideas about how to respond and offer some advice on recovering your systems.
Inner Layer
Your inner layer security consists of the operating system level of your system, the various
programs, configurations and settings that make up a well-secured and administered system.
We're going to look at three types of applications to assist with your inner later security. The
first type is security-scanning software that can check for operating system exploits, rootkits,
weaknesses and vulnerabilities. The second type is a password cracker that allows you to test
the security and strength of your system's and user's passwords. The last type of software
checks the security related settings of your system.
Scanning for Exploits and Rootkits
A rootkit is one of a variety of hacker toolkits. It can perform a number of functions
depending on the flavor of the rootkit. The original core of most rootkit applications was
some kind of network sniffing tool designed to allow the attacker to find additional user

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

Rootkit Hunter is designed to help you scan your system for signs of a rootkit installed and to
perform a variety of other checks on related logs, commands, processes and some
configuration settings.
You can download Rootkit Hunter at It's
available in the form of a source download or an RPM. Download it in the form that best
suits you.
If you've downloaded it Rootkit Hunter in source form unpack your source archive,
change into the created rkhunter directory and install it using the command in Example 6.1.
Example 6.1 Installing Rootkit Hunter via source
puppy# ./installer.sh
If you've downloaded the RPM you can install it using the command in Example 6.2.
Example 6.2 Installing Rootkit Hunter via RPM
puppy# rpm –Uvh rkhunter-version.rpm
Rootkit Hunter installs a shell script, rkhunter into /usr/local/bin and the rest of its files,
including Perl scripts and databases into the directory /usr/local/rkhunter.
You need Perl installed to run Rootkit Hunter correctly.
You can run Rootkit Hunter from the command line or via cron. In Example 6.3 we show a
sample run of Rootkit Hunter.
Example 6.3 Running rkhunter
puppy# rkhunter --checkall --createlogfile
In Example 6.3 we are running rkhunter with --checkall which runs all of the Rootkit Hunter
tests and with the option --createlogfile with creates a log file called rkhunter.log in /var/log.
There are a variety of other useful command lines options we can use which are detailed in
Table 6-1 and we'll discuss each of those.
Table 6-1 Rootkit Hunter command-line options
Option Description
--cronjob Run as a cron job
--help Show help
--nocolors Don't use colors in rkhunter output
--report-mode Cut down report useful when running for crontab

--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

if you use the --createlogfile option for any positive results.
Chkrootkit
Chkrootkit is another tool for checking for the presence of rootkits. It also contains some
additional tools to check if interfaces are in promiscuous mode, lastlog and wtmp deletions
and a check for hidden processes (though these additional tools are run when you run the
primary chkrootkit script they can be run in a stand-alone mode too).
You can get Chkrootkit from You download a source archive
and unpack it to a directory. Enter that directory and compile Chkrootkit using the command
in Example 6.6.
Example 6.6 Compiling chkrootkit
puppy# make sense
This will create a shell script called chkrootkit in the chkrootkit-version directory together
with the additional binary tools mentioned in the previous section. You can move these files
to a directory of your choice. Example 6.7 shows how we normally do this.
Example 6.7 Installing Chkrootkit
puppy# rm –f *.c Makefile
puppy# mkdir /usr/local/chkrootkit
puppy# mv * /usr/local/chkrootkit
Chkrootkit can be run from the command-line or via cron. Example 6.8 shows us running
Chkrootkit from the command line.
Example 6.8 Running Chkrootkit from the command line
puppy# chkrootkit
You can run Chkrootkit without any command-line options and it will perform all available
checks by default. You can also use the command-line options in Table 6-2 to alter
Chkrootkit's behavior.
Table 6-2 Chkrootkit command-line options
Option Description
-d Debug mode
-q Quiet mode
-x Expert mode

-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

Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'... not infected
Checking `du'... not infected
Chkrootkit then checks for the presence of logs files from sniffer programs and then for
the presence of a variety of rootkits.
Testing Your Password Security
In Chapter 5 we talked about controlling the variables associated with your passwords to
ensure that your users must use the most secure passwords possible. We also talked about
ensuring you make use of modern password encryption techniques such as MD5 and shadow
passwording. While this greatly enhances the security of your password it is not always a
guarantee that you passwords are totally impenetrable. Further testing is a good idea to add
further reassurance that your passwords are strong and secure. We're going to show you how
to use the password cracker, John The Ripper, to test the strength of your passwords.
Password cracking can be construed as a serious attack on a system. Do not run
password cracking on a system which you do not control or do not explicitly have
permission to run password cracking on.
The two most common forms of password cracking are brute force and dictionary-based
cracking. Brute force cracking requires throwing computing resources at a password you
wish to crack. Usually a brute force password-cracking program generates character
sequences starting with 1 characters and then incrementing from there and testing those
character sequences against the password. This often requires considerable time and
resources and if your passwords are secure then an attacker is unlikely to break them unless
they are prepared to very patient. For example a random password 8 characters in length and
created from the 94 displayable ASCII characters would take a cracker approximately 1,930
years to crack using a typical desktop PC.
1
Of course the more computing power you can
throw at problem the shorter you can make this time. Thus password cracking highly lends

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

password". You are directed to a page with a very useful looking piece of software that you
then download and install. It turns out to be a Trojan Horse program which at the very least
does something malicious with any password files it tests or passwords it cracks if not
actually rootkits your system. So we want to make sure we download a safe password
cracker.
So firstly download JTR from preferably verifying it
using its MD5 signature.
We used John The Ripper version 1.6.37 for this explanation.
Unpack the archive and change in the src directory. You have to tell JTR what sort of system
you are running. Type make to see a list of potential systems. Example 6.10 shows the
possible Linux based builds you can compile.
Example 6.10 Making John The Ripper
puppy# make
To build John the Ripper, type:
make SYSTEM
where SYSTEM can be one of the following:
linux-x86-any-elf Linux, x86, ELF binaries
linux-x86-mmx-elf Linux, x86 with MMX, ELF binaries
linux-x86-k6-elf Linux, AMD K6, ELF binaries
linux-x86-any-a.out Linux, x86, a.out binaries
linux-alpha Linux, Alpha
linux-sparc Linux, SPARC
If you have an Intel system then your best choice is to compile JTR with:
puppy# make linux-x86-any-elf

2
/>3
/>This will create a binary called john in the directory john-version/run.
You run JTR from the command line. A basic run of JTR is shown in Example 6.11.
Example 6.11 Running John The Ripper from the command-line

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

efforts may take a long time. JTR allows you to stop and restart a session later if required.
To do this when first starting JTR add the option --session=name replacing name with the
name you want for this session. You can then stop that session using Ctrl-C, check the status
of that session later and then if you wish restart it. Example 6.12 shows us stopping, checking
the status of a session and then restarting that session.
Example 6.12 Starting, printing the status of and restarting a John The Ripper session
puppy# john --session=testsess passwd.1
Loaded 2 password hashes with 2 different salts (FreeBSD MD5 [32/32])
guesses: 0 time: 0:00:00:02 0% (2) c/s: 1896 trying: ranger
Session aborted
puppy# john --status=testsess
guesses: 0 time: 0:00:00:03 0% (2) c/s: 1264
puppy# ./john --restore=testsess
The next option, --show, prints out any passwords that JTR cracked in its last session. The
final option, --test, allows you to run benchmarking tests on your system to determine how
fast it is capable of cracking particular encryption formats. This is useful for choosing a
suitable machine to run JTR on.
Most systems these days use shadow passwording. JTR comes with a function that
allows you to create a file combining your passwd and shadow files that JTR can attempt to
crack your shadow passwords with. Example 6.13 shows how to do this using the unshadow
binary in the run directory.
Example 6.13 Creating a John The Ripper file for cracking shadow password files
puppy# unshadow /etc/passwd /etc/shadow > passwd.1
This combines the contents of your passwd and shadow files into a file that JTR can attempt
to crack.
You can also run JTR using a brute force method. Example 6.14 shows JTR running
brute force against the passwd.1 file we created in Example 6.13.
Example 6.14 Running John The Ripper in brute-force mode
puppy# john passwd.1
Be prepared to wait a long time using this method to crack a reasonably secure password!

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

cover every individual potential security setting that you can manipulate with Bastille
because the Bastille team already provide excellent documentation about the various security
settings and the implications of changing those settings. We'll also take you through how to
undo any changes you've made with Bastille.
Installing Bastille Linux
You can get Bastille from the Bastille site at It requires some
additional prerequisites, perl-TK (if you wish to use the graphical interface) and perl-Curses
(if you wish to use the console-based tool) that you need to install before you can install
Bastille. Let's look at installing those first. We're going to install both to give us the option
of either using the graphical or console based installation. You can install these prerequisites
either via RPM or download and compile them via CPAN (CPAN is potentially less secure
than a confirmed RPM from a safe source – you need to assess the risk here). Probably the
easiest and safest path is to install the RPMs recommended for your version of your
distribution. Bastille provides a compatibility table for a variety of Linux versions that
indicate which are the recommended versions and sources for the required prerequisites. This
chart is located at />There are also packages available for Debian here at
/>bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=b
astille.
As there are so many version of the prerequisites depending on the distribution and
version of that distribution you are using we are going to look at installing on Red Hat 9 as a
baseline and you can adapt this installation to accommodate you're specific requirements
based on the required combinations of prerequisites. From the compatibility chart we see we
need to download the following RPMs:
/> /> />Download the RPMs and install them on your system:
puppy# rpm –ivh atrpms* perl-Tk*
Preparing... ########################################### [100%]
1:atrpms ########################################### [100%]
2:perl-Tk ########################################### [100%]
puppy# rpm –ivh perl-Curses-1.06-219.i586.rpm
Preparing... ########################################### [100%]

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

-r Revert Bastille changes
The first option, -h, displays some help text for Bastille command line operation. The next
two options allow you to specify what mode you'd like Bastille to run in, -c for console mode
and –x for X-Windows. The next option, -b, tells Bastille to run in batch mode and apply the
configuration contained in the /etc/Bastille/config file to the system. As discussed above this
is useful for ensuring multiple systems have the same security settings.
If you run Bastille using the –b switch then you need to have a configuration file
containing the Bastille run you'd like to duplicate in the /etc/Bastille/ directory in a file called
config. Example 6.16 shows the start of a Bastille run using an already existing
configuration.
Example 6.16 Running Bastille Linux in batch mode
puppy# bastille -b
NOTE: Entering Critical Code Execution.
Bastille has disabled keyboard interrupts.
NOTE: Bastille is scanning the system configuration...
Bastille is now locking down your system in accordance with your
answers in the "config" file. Please be patient as some modules
may take a number of minutes, depending on the speed of your machine.
The next option, -l, requests the location of the file containing details of the last interactive
run of Bastille performed. Finally the –r option allows you to revert to your previous
configuration. We'll cover that option a little further on in this section.
We're going to show you how to use Bastille running in console mode. To launch
Bastille run the command:
puppy# bastille -c
If this is the first time you've run Bastille it will show you its license and disclaimer. To
acknowledge the license and disclaimer type accept when prompted and Bastille will show
you a screen explaining how to use the console based text interface. Bastille uses a very
simple set of controls. You can use the Tab key to move between menu items and options
and Enter to select the required option. Thus from the explanation screen you can select the
< Next > option using the Tab and hit Enter to continue through and launch the first of the

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

/var/log/Bastille. There are two principal logs generated, action-log and error-log. You
should check them both to confirm the actions Bastille has taken and any potential errors
generated during the Bastille process. Example 6.18 shows a sample of the contents of the
error-log file.
Example 6.18 Bastille Linux error-log file
{Mon May 24 10:55:34 2004} ERROR: open /etc/pam.d/kde failed.
{Mon May 24 10:55:34 2004} # Couldn't prepend line to /etc/pam.d/kde, since open failed.
{Mon May 24 10:55:34 2004} ERROR: Unable to open /etc/pam.d/kde as the swap file
etc/pam.d/kde.bastille already exists. Rename the swap file to allow Bastille to make desired file
modifications.
{Mon May 24 10:55:34 2004} ERROR: open /etc/pam.d/kde.bastille failed...
{Mon May 24 10:55:34 2004} ERROR: open /etc/pam.d/kde failed.
{Mon May 24 10:55:34 2004} # Couldn't append line to /etc/pam.d/kde, since open failed.
These are mostly harmless errors indicating that KDE is not installed. But you should review
the file for other potential errors that could indicate that part of the hardening process has
failed. This has the potential to leave your system exposed without your knowledge.
Outer Layer
Your outer layer security is critical because not only it is the first line of defense for your
system but it is also the layer most commonly targeted by people seeking information about
your system. An attacker can tell a lot about your system and the applications running on it
from examining that outer ‘crust’ - including what ports are open and applications you have
running. Indeed many common applications and daemons routinely respond to queries with
their name and version that greatly assists attackers in tailoring exploits and picking the
vulnerabilities of your system.
We examine two very useful tools, NMAP and Nessus, that will allow you to see what a
potential attacker sees when they scan your system. Both tools perform different functions.
The NMAP tool is a powerful network scanner/mapper and Nessus is a security and
vulnerability scanner that will help you find and offer suggestions for resolution of potential
exposures in your systems and applications.