Network and application layer tests reveal security gaps.

The Slammer worm virus struck in late January 2003. Exploiting a design flaw in Microsoft SQL servers, it quickly attacked Internet hosts around the world. As it spread, it doubled in size every 8.5 seconds, and within 10 minutes had infected more than 90% of vulnerable servers. The virus worked by generating 55 million scans per second across the Internet, crippling the vast network. The virus didn't carry a malicious payload, which is code meant to damage individual computers. It didn't need to.

The virus cut off all Internet access in wired South Korea for 8 straight hours. On U.S. turf, Bank of America ATMs slowed to a crawl, while 911 call centers struggled to operate with slow or frozen emergency data. Thousands of other financial centers and corporations were shut down or severely slowed as the virus spread world-wide, many sites losing millions of dollars as thousands of networks and applications were loaded beyond their limits.

This was a Denial of Service (DoS) attack, which issues a flood of packets to overwhelm network resources and slow down (or take down) whole systems. A DoS attack may launch from a single source, or from several sources, called Distributed DoS (DDoS). (In a nod to '50s horror movies, distributed computer attack hosts are called "zombies.") Worse still, hacker DoS attack tools are publicly available.

Networks can defend against DoS attacks, as well as from heavy network loads resulting from more innocent causes. Part of a protection strategy includes intrusion protection and establishing tight security, but another important part is load balancing--the ability to shift processing loads between servers. If some servers will under high processing demands, load balancers will transparently shift processing tasks to servers with more I/O. However, DoS attacks can overwhelm load balancers, compromising the network and deeply impacting application service levels.

Of course, DoS viruses aren't the only threat to networks--so is healthy data traffic resulting from demanding applications like Web services, VoIP, e-mail and IP-based enterprise applications. The sheer amount of this data strains individual servers and clusters, yet operations are demanding 24x7 continuous uptime. When an hour of downtime can equal a loss in millions of dollars, firms need to be certain their networks can handle performance loads and severe data spikes. This is true for corporate users as well as network service providers, including intra-enterprise networks, Application Service Providers (ASPs), Storage Services Providers (SSPs), Managed Service Providers (MSPs), Content Delivery Networks (CDNs) and many others.

So network administrators test for flaws, guard against intrusion and put in load balancers. But how can they be sure they're sufficiently protected without realistically testing their setup? They can't, without running data traffic tests--unfortunately, it's hard to deliberately flood a network with huge amounts of data traffic. And even if they could, what if they're wrong about the network standing up to the performance hits? Network administrators need testing technologies that can spawn heavy data traffic without hurting the network, and be able to analyze and report on how that traffic affects the network and its enterprise applications.

Best practices in enterprise load testing include:

* Simulate heart data traffic and massive network loads, then measure end-to-end performance and scalability of network transactions. Testing applications can create thousands of virtual network clients to emulate heavy network loads up to 10 Gigabits per second. Once the network appears fully loaded, network administrators can measure end-to-end performance for both network and applications. This allows administrators to test the relative performance and scalability of the network and applications under heavy load conditions, and can also test the impact that new enterprise applications will have on the existing network.

* Use virtual network clients with high-speed connections to generate millions of Web-page requests, then analyze performance and isolate bottlenecks. This test should stress the entire infrastructure at once, including application-aware switches, server load balancers, intrusion detection systems, firewalls, and Web servers. Administrators can also measure application response times under the load of heavy Web traffic--the very type of traffic the Slammer worm generated.

* Use virtual private network (VPN) technology to establish and test secure gateways throughout the network. Administrators can generate enterprise application loads on virtual VPNs, then measure the resulting response times and compare their performance to application service level requirements. Testing technology can create thousands of these gateways to measure tunnel capacity and establishment rates under heavy load conditions, and can send application-layer traffic over the tunnels to measure data performance.

* Test for security vulnerabilities by simulating distributed denial-of-service attacks. Since denial of service is a favorite hacker trick, administrators should mount virtual DDoS attacks on firewalls, servers, routers, and switches to test their network for security and intrusion points.

* Accurately predict application and network requirements in e-commerce and Web-based applications. Administrators can generate and analyze large volumes of high-rate user traffic in order to test bottlenecks, constraints and limitations within an application. The result is high-performance testing and analysis across intra-enterprise business networks.

Data Network Layers

Comprehensive testing technology should work on all network layers. The OSI has defined seven network levels for data networks. Some schemas present fewer levels--and not all OSI layers are distinct, but these classic definitions are still foundational to data network architectures.

Layer 1: Physical. Defines the cable or physical medium such as the Ethernet type. Converters from one media to another operate at this level.

Layer 2: Data Link. Defines the format of the network data frame (packet). This layer uses a network interface to handle physical and logical connections to the pocket's destination.

Layer 3: Network. Routes data traffic by directing collections of packets from one network to another. IP is the most common network interface.

Layer 4: Transport. Subdivides packets and enforces transmission control. TCP, for example, sits at the transport layer and establishes connections between two hosts on the network. It also keeps track of packet delivery order and resends lost or dropped packets.

Layer 5: Session. Determines when a user or process begins a session, how long it is used, and when it is closed. It also controls the data transmission during the session and supports security and name lookup between client and host.

Layer 6: Presentation. Converts the host's representation of data to a form the client can understand and can present to the next layer.

Layer 7: Application. Provides network services to end-users such as e-mail, file transfers and Web applications.

Layers 3 and 4 are heavily tested, since they're populated with network switches and routers and contain load-balancing technologies. Load balancers use Layer 3 and 4 information to make effective routing decisions between server clusters. Most networks use TCP/IP connections as two-way information pipes that transfer data from source to target. Under the pressure of growing traffic loads, servers and network routing equipment experience increasingly heavy performance demands. Developers have shunted more intelligence to the routing process so the equipment can help to control such features as load balancing, prioritizing and latency.

This technology can effectively load balance, using information from these two layers; but enterprise-testing technology is necessary to severely stress networks oil this level. Without testing, administrators set up intelligent routers and load balancers to the best of their ability, then do their version of "plug and pray." If they were able to adequately test this layer of network traffic, they could either be confident that their equipment could handle performance spikes and DoS attacks, or they would know immediately that they should change their load-balancing configurations.

Enterprise testing technology works in the upper layers also by measuring network stress on applications and content-aware routing. The tests work at the logical upper network levels to analyze and report traffic impacts on application metrics. This lets IT set realistic service levels for enterprise applications, and gives it ammunition if critical service levels are unacceptable under heavy load conditions.

SAN Testing

Enterprise testing isn't relegated to IP networks, but tests SAN fabrics as well--Fibre Channel switches, directors, bridges and ports. Specialized fabric testers can flood the SAN with virtual traffic, allowing developers, integrators, and storage administrators to carefully analyze the behavior and performance of Fibre Channel fabrics. By identifying true latency rates at the fabric level, administrators can use accurate QoS measurements instead of wishful thinking.

The testing procedure is similar to IP networks: generate last traffic streams at a full-line rate for both 1Gbps and 2Gbps Fibre Channel fabrics, then measure and analyze the resulting network loads and application performance hits. The more end-points the test impacts, the better the storage administrator can test such functions as the SAN's maximum capacity, switch response times in different scenarios and name-server commands, and state changes in the network.

Ideally, enterprise testing works over all major network configurations (LANs, WANs, MANs and SANs) and tests all network layers, including applications. These technologies have other important advantages beside reducing risk--they also reduce capital costs by identifying problems from design through deployment, improve operational efficiency by using sophisticated tools to replace manual functions, and increase productivity by improving application response times.

By testing performance limits on both sides of the data equation, both business applications and network infrastructure, businesses can know that their networks and critical applications will be there when they need them. 24x7.

Josh Goldstein is director of product management for Ixia (Calabasas, CA)

www.ixiacom.com]