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 support@apress.com 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 http://www.securityfocus.com/subscribe?listname=1 and the http://vulnwatch.org/ 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 http://www.rootkit.nl/projects/rootkit_hunter.html. 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 http://www.chkrootkit.org/. 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 http://geodsoft.com/howto/password/cracking_passwords.htm#howlong 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 http://www.openwall.com/john/, 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 http://zdnet.com.com/2100-11-530187.html?legacy=zdnn 3 http://www.crypticide.com/users/alecm/ 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 ftp://ftp.cerias.purdue.edu/pub/dict/ and ftp://ftp.ox.ac.uk/pub/wordlists/ 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 http://www.bastille-linux.org/. 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 http://www.bastille-linux.org/. 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 http://www.bastille-linux.org/perl-rpm-chart.html. There are also packages available for Debian here at http://packages.debian.org/cgi- 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: http://atrpms.physik.fu-berlin.de/dist/rh9/perl-Tk/perl-Tk-800.024-0_4at.i686.rpm http://atrpms.physik.fu-berlin.de/dist/rh9/atrpms/atrpms-9-0_1at.noarch.rpm http://www.bastille-linux.org/perl-Curses-1.06-219.i586.rpm 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%] [...]... Security Tools This is a list (by no means comprehensive) of some additional security tools that may be useful to you These include network scanners and sniffers, traffic capture tools, Network Intrusion Detection Systems, secure kernels and security auditing tools dsniff This suite of packet sniffing tools allows you to monitor traffic on your network for sensitive data It comes with a number of tools. .. useful for your own purposes in tracking the path of the attacker and it also provides input for any auditors who might become involved in reviewing the attack from a wider security perspective Additionally if your organisation chooses to involve law enforcement in the aftermath of an attack this record could eventually form some kind of evidence There are a few steps you should take to gather this information... will output the results of the NMAP scan in XML format This is very useful for populating monitoring tools like Nagios or to provide an input source for a script The second, -oG, outputs the scan results in a single line to make it easier to grep the resulting file for the results you want The –oN option will output the results of a scan in a human readable form much the same as the results that are outputted... the netmask in the form of /mask, for example 192.168.0.0/24 will scan the entire 192.168.0.0 Class C network The second method is the use of *’s to indicate an entire network, for example 192.168.0.* will scan all the hosts of the 192.168.0.0 network from 1 to 254 You can also specify target host ranges separated by dashes, for example 192.168.0.100-150 Let’s look at Example 6.24 for some typical NMAP... is Nessus 2.0.10 for Linux 2.4.21-9.EL compiled with gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24) Current setup : Experimental session-saving Experimental KB saving Thread manager nasl : enabled : enabled : fork : 2.0.10 libnessus : 2.0.10 SSL support : enabled SSL is used for client / server communication Running as euid :0 You should include these details for any requests for support via the... your other systems immediately for signs of attack Check logs, logins, run your collection of scanning tools * Change all your secure passwords, including your root passwords and passwords for network devices immediately Do not use electronic means to disseminate these new passwords * Examine your system for the source of the attack and if required involve any relevant law enforcement agencies * Attempt... option These options try to determine how long a device has been up for and also determine the statistical probability of being able to establish a forged TCP connection to the device If you use the verbose option –v NMAP will provide a description of the difficulty, for example ‘Worthy Challenge’ or ‘Formidable’ You can find more information about operating system finger printing here http://www.insecure.org/nmap/nmap-fingerprinting-article.html... 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... UDP packets You can find Netcat at http://netcat.sourceforge.net/ Sara Sara is the Security Auditor's Research Assistant which is a security analysis tool It is an inheritor of SATAN, the original security analysis tool SATAN has become outdated and obsolete in recent times and its core functionality has been overtaken by SARA It is able to perform a series of built in scans or can scan using third-party... 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 . information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. Chapter 6 Tools for Security Testing. 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