Before Code Red, there was distributed denial of service. While distributed DoS attacks have not been the attack du jour as of late, they are still a strong threat to any network, providing the ability to cripple even the highest-bandwidth providers. Distributed DoS attacks are so threatening because they are difficult to identify.
Once identified, it is just as difficult to defend against them. Traffic filters are the best solution, but they must be manually implemented and they often also block legitimate network traffic. The distributed nature of the attack makes prevention virtually impossible because you never know where the next attack will come from.
Mazu Networks Inc.’s TrafficMaster Inspector helps solve some of these problems by providing a way to identify distributed DoS attacks in real time on large, high-speed networks.
While Inspector identifies distributed DoS attacks, it does not provide any assistance in filtering the identified attacks. (Mazu Networks’ Enforcer gateway, due later this summer, will provide this capability.)
Inspector resides upstream at the core of the network infrastructure and passively observes all traffic entering or leaving the network. It can reside anywhere on the network, but works best near the first-level routers, where it can directly monitor traffic to and from the Internet.
Inspector connects to the data path via a passive optical or copper splitter, which introduces no latency into the network and performs detailed analysis in real time. Other distributed DoS solutions (from companies such as Asta Networks and Arbor Networks) receive a sample of network traffic from routers for analysis. Inspector sits directly on the network connection and monitors all traffic, independent of the network routers for packet information. One reason Mazu’s solution is so expensive (US$100,000) is that the company had to develop a product that truly supported gigabit traffic levels.
Off To A Good Start
Overall, Mazu has a great start in developing a fast, efficient distributed DoS solution. Its approach to separate monitoring and defence mechanisms does not make Inspector an optimal solution on its own. If we have a tool that helps identify a distributed DoS attack, we’d also like that tool to at least recommend how to best defend against the current attack. We would probably wait until the Enforcer component becomes available (Mazu says Sept. 1) to provide a complete defence mechanism.
Analysis
Inspector examines packets on different metrics defined by the administrator and statistically determines whether an attack is occurring. These metrics can include, but are not limited to, packet size, source address, time to live (TTL) and payload.
For example, while attackers may spoof the source address on a packet, they cannot make changes to other aspects of the packet, such as payload. Inspector makes it difficult for an attacker to launch a surge of network traffic without introducing an anomaly that it is able to detect. This includes unusual variations or lack of variation in payload, port numbers, TTL and other metrics.
Inspector has two main components: the probe and the cluster head. Probes are individual sensors that can be distributed throughout a network to capture and analyse traffic. (They support up to eight Gigabit Ethernet links.) The cluster head is the master probe, or central reporting device. All probes report to the cluster head, which combines the data for a more thorough analysis and “big picture” of the network.
Within an Inspector probe, three main components are at work: user-level Mazu module, Mazu Kernel module and Mazu device driver. The user-level module is the brains of the product. It performs the packet analysis looking for anomalies that could be distributed DoS attacks. The Kernel module is optimized for rapid packet classification and routing to keep any latency introduced by its presence to an absolute minimum. The device driver optimizes packet processing, enabling Inspector to quickly and efficiently capture packets off the network.
Initially, Inspector baselines typical network activity (which takes about 30 minutes), documenting what is “normal” for the particular environment. It learns and adapts over time to the unique patterns of the network and is better able to separate legitimate increases in traffic from spoofed traffic with malicious intent.
To help avoid false positives, Inspector includes user-defined thresholds on up to eight aspects of the network traffic, including protocol levels and traffic flow, to trigger alerts at the first signs of possible distributed DoS attacks.
During testing, we launched a variety of distributed DoS attacks, and Inspector successfully identified each. We also created a sudden increase in legitimate network traffic to see if the Inspector could differentiate between legitimate and attack traffic, which it did. The attack information and characterization displayed in the Web-based reporting were accurate and informative. Based on our lab testing, Inspector is effective at analysing network traffic and determining when distributed DoS attacks are occurring.
Administration and Reporting
Inspector administration is performed either through the secure HTTP Web interface or directly on the console through Secure Shell. An embedded firewall developed by Mazu and based on the same packet-processing platform used for the Inspector distributed DoS analysis on the device limits access to these secure protocols. These administration tools provide four main functions: configuration, attack detection, attack characterization and traffic analysis monitoring.
Configuration settings allow you to enable SNMP monitoring and set system thresholds. With SNMP enabled, an alert can be sent via your network management system (which can then send e-mails or a page) when a distributed DoS attack is identified.
When Inspector determines an attack is under way, it alerts the administrator, either through SNMP or a message on the Web interface overview page. Then, it enters attack characterization mode. Attack characterization mode provides detailed information and analysis of a possible distributed DoS attack. Initial information is seen on the overview page during the attack.
The attack incident report page provides detailed information on attack histories and lets you drill down to specific packet details for each suspected attack.
Inspector lets you inspect your traffic from a high level down to individual packet contents. You can view a graph of all traffic and eliminate certain traffic types, such as all User Datagram Protocol (UDP) packets. You can also view traffic from specific IP addresses and time ranges. When under attack, this interesting view lets you see the differences in healthy traffic and attack traffic. The online reports are excellent and provide detailed information, but we would like to see some printable reports to present to management to summarize attacks, give an overview of what occurred and show other detail.
Conclusion
Inspector is an effective solution to identify distributed DoS attacks in large carrier-class networks. Starting at US$100,000 for only monitoring and attack characterization, it is not a solution for the faint of heart.
Overall, TrafficMaster Inspector provides fast, efficient anomaly-based monitoring, but it does not provide any filtering recommendations. To do that, administrators must create their own filters based on the attack characterization information provided by Inspector or purchase Enforcer, which will implement filters in real time on a packet-by-packet basis.
How We Did It
We set up a Gigabit Ethernet attack network with two servers, each a 900MHz Pentium III with 128MB of RAM, as an attacker and a server. TrafficMaster Inspector sat in the middle of these two machines, monitoring and capturing all network traffic.
We launched a variety of distributed denial-of-service attacks using various tools and packet generators available at the Packetstorm Web site. Attacks included ping floods, ACK attacks, random ICMP floods, random IP floods and TCP reset floods. The ping flood attack sent a large number of Internet Control Messaging Protocol (ICMP) packets. The ACK attack sent a large number of TCP packets with the ACK flag set. The random ICMP floods sent a large number of ICMP packets with various aspects, such as IP address and time to live, randomized. The random IP floods sent a large number of randomized packets, and the TCP reset floods sent a large number of TCP packets with the reset flag set. With each attack, approximately 50,000 to 60,000 packets per second were sent across the network.
We also used a traffic generator (Traffic Source available at http://_sourceforge.net/projects/traffic/) to generate several hundred megabits of traffic to simulate a sudden increase in legitimate traffic to see if Inspector flagged it as suspicious. This traffic included HTTP, FTP, SMTP and general broadcast traffic.
Mandy Andress is president of ArcSec Technologies Inc. a security consultancy. Her new book, Surviving Security, was recently published. She can be reached atmandy@arcsec.com.
