Although small-scale DoS attacks can be mimicked by simply running a DoS program from a single machine connected to the target network, larger-scale tests that seek to mimic a DDoS attack may need to utilize many machines and large amounts of network bandwidth, and may therefore prove to be quite time consuming and resource intensive to set up and run. As an alternative to using many generic servers to generate a DDoS attack, hardware appliances such as those listed in Table 3.15 can be used to create huge volumes of network traffic (more than tens of thousands of network connection requests per second and millions of concurrent network connections) and even come with attack modules (which are updateable) designed to emulate the most common DoS attacks.
Table 3.15: Sample List of DoS Emulation Tools and Services
NAME ASSOCIATED WEB SITE
FirewallStressor www.antara.net
Exodus www.exodus.com Mercury Interactive www.mercuryinteractive.com
SmartBits www.spirentcom.com WebAvalanche www.caw.com
Rather than having to set up an expensive test environment for only a few short DDoS attack tests (that will hopefully not have to be repeatable), another option is to use an online service. (Table 3.15 lists some sample vendors that offer this service.) For a relatively small fee, these online vendors use their own site to generate the huge volumes of network traffic that typically characterize a DDoS attack and direct this network traffic over the Internet to the target network—an approach that can be much more cost effective than an organization trying to build its own large-scale load generators.
In addition, some of the traditional load-testing tools listed in Table 3.16 can also be utilized to simulate DoS attacks that necessitate creating large volumes of Web site requests.
Table 3.16: Sample List of Traditional Load-Testing Tools
NAME ASSOCIATED WEB SITE
Astra LoadTest and LoadRunner www.mercuryinteractive.com
e-Load www.empirix.com OpenSTA www.sourceforge.net Portent www.loadtesting.com QALoad www.compuware.com RemoteCog www.fiveninesolutions.com SilkPerformer www.segue.com TestStudio www.rational.com VeloMeter www.velometer.com Web Application Stress Tool (WAST-"Homer") and
Web Capacity Analysis Tool (WCAT)
www.microsoft.com
WebLoad www.radview.com
Web Performance Trainer www.webperfcenter.com
WebSizr www.technovations.com WebSpray www.redhillnetworks.com Table 3.17 summarizes the checks that the testing team can perform to help evaluate how
prepared an organization is against a DoS (or DDoS) attack.
Table 3.17: DoS Attack Checklist YES NO DESCRIPTION
□ □ Has a documented strategy been developed to defend against DoS attacks?
□ □ Is there a documented inventory of the specific DoS attacks for which countermeasures have been put in place?
□ □ Have the procedures that the on-duty security staff should follow when the network is under a DoS attack been documented?
□ □ When emulating each of the defended DoS attacks, are the attacks detected by the on-duty security staff?
Summary
The network infrastructure that each network application resides on represents the electronic foundation of the application. No matter how good an application's security procedures are, the application can be undermined by vulnerabilities in the underlying network that the application depends on for its network connectivity. This chapter has outlined a series of steps and techniques (summarized in Figure 3.5) that a security-testing team can follow (or customize to their unique situation) to first define the scope and then conduct a network security-testing effort.
Figure 3.5: Network security-testing approach summary.
One final point is worth emphasizing: In order for the testing effort to be as comprehensive and systematic as possible, the security-testing team must be granted access to highly sensitive documentation such as a diagram depicting the network's topology. It goes without saying that the testing team should take every feasible precaution to prevent this sensitive information from being leaked to a potential attacker (external or internal) and that any test results (regardless of whether or not they demonstrate the existence of a security vulnerability) must be kept under lock and key and only distributed on a need-to-know basis. Finding any of these artifacts could save an intruder a considerable amount of time and effort, and increase the possibility of a successful penetration. Additionally, the testing team should be careful to clean up after themselves, making sure that once the testing is complete, any testing tools that could be utilized by an attacker are removed from all of the devices they were installed upon.
Chapter 4: System Software Security
Overview
This book uses the term system software to refer to the group of commercial and open- source software products that are developed and distributed by an external organization. These include operating systems, database management systems, Java 2 Platform Enterprise Edition (J2EE) implementations, file-sharing utilities, and communication tools. Table 4.1 lists some specific examples of such products.
Table 4.1: Sample List of System Software Products
NAME ASSOCIATED WEB SITE
Apache www.apache.org Linux www.redhat.com Notes www.lotus.com MS SQL Server www.microsoft.com pcAnywhere www.symantec.com WebLogic www.bea.com
Typically, whatever Web application that an organization has deployed or will want to deploy will depend upon a group of system software products. Before developing any application software, an organization would be well advised to evaluate any system software that the application is expected to utilize. Such an evaluation would ensure that the planned system software and the specific installation configuration do not have any significant security issues. Determining security flaws or weaknesses early is important, as trying to retrofit a set of patches or workarounds to mitigate these system software security vulnerabilities can cause significant reworking. For example, applications might have to be reconfigured, as the original ones were developed using different, often default, system software configurations. Or perhaps, worse still, the applications would need to be ported to a new platform, because the original platform was found to be inherently unsafe.
This chapter looks at the tests that should be considered to ensure that any system software that is going to be deployed has been configured to remove or minimize any security vulnerabilities associated with this group of software products and thereby provide a firm foundation on which Web applications can be built.