You're the target of a DoS (denial of service) attack when an assailant does something that denies resources -- be it network bandwidth, available connections or available services -- to legitimate users. The resources do not have to be fully denied, however: causing degenerated and/or degraded service also counts as a denial of service attack.
Traditionally, there are two classes of DoS: "magic packet" attacks and resource-exhaustion attacks. Magic packet attacks usually exploit a vulnerability in the OS or application by sending one or a few particular packets, and typically result in a highly abnormal response, excessive CPU utilization or a full system crash. The infamous Ping of Death and WinNuke attacks fall in this category.
Resource-exhaustion attacks do not rely on a vulnerability; instead, they take advantage of a basic fact of life: Computing resources are finite. Your server has only so much RAM, can handle only so many clients at a time, and can shuffle only so many bytes per second through the attached networks. A resource-exhaustion DoS is when an attacker knowingly attempts to take up as many resources as possible, robbing other users. Keep in mind your server can be overloaded by 100 percent legitimate traffic as well. An advertisement or special event leading lots of users to your Web site could result in an infrastructure overload ... but not by a DoS attack.
Attack #1: ICMP echo request flood
The first attack is a spoofed-source ICMP echo request flood generated by TFN2K (Tribe Flood Network 2K). The attack is meant to target the overall available bandwidth, causing packet-per-second rates to boost more than 20,000 at times. However, our baseline had no ICMP traffic, thus mitigation should have been easy: Block all ICMP traffic. Since ICMP floods are a classic DoS type, and the mitigation was simple, this attack was used as a trigger test to ensure that the devices were properly identifying and mitigating traffic that was anomalous to the normal baseline traffic.
Attack #2: TCP SYN flood from single host
The second attack is a single-source TCP SYN flood against our Web server, targeted to Port 80. The mitigation of attacks coming from a single host (or a small number of hosts) is not very complex: Block traffic from those few addresses. So we wanted to have at least one attack where a single address was used, knowing that the mitigation should be a cinch. Like the first attack, this attack was included to test the fundamental analysis and mitigation abilities of the devices. In reality, a victim should be so lucky as to have an attack originate from a single source address.
Attack #3: TCP SYN flood from random/spoofed hosts
The third attack is nearly identical to the second attack with a slight but important difference: Source IP addresses are randomly spoofed. This raises the bar in mitigation because the device can't simply block the source. (Well, it can, but more traffic will be coming in from other source addresses).
Attack #4: Open connection exhaustion from semirandom/spoofed host
We used a modified version of Naptha (a tool by Bindview's Razor team) to cause a connection exhaustion flood on the Web server. This is similar to a SYN flood, except Naptha completes the three-way handshake, thus establishing a legitimate TCP connection. The intended goal is to drain the Web server of available incoming sockets, impacting other HTTP requests. The number of connections generated by Naptha was kept low -- about 400 connections per second, for a grand total of around 60 Kbps of traffic. This makes attacks of this type very lethal because they consume very little bandwidth, follow the TCP connection-establishment rules and impact the server in a devious manner. To track this attack, the anti-DoS device will have to count open/established connections to the Web server.
Attack #5: TARGA3 flood from random/spoofed hosts
We added this last attack as an evil trick on the devices. The TARGA3 attack, as spewed from TFN2K, generates invalid IP packets of various protocols. The traffic does not affect the end server -- most packets are invalid and discarded immediately. However, it does make a slight bandwidth impact.
We chose this attack to provoke the devices into attempting some form of mitigation. Essentially, we wanted to test the devices' sensitivity to anomalous traffic and determine how over-zealous they were at deflecting the attack at any cost -- including blocking legitimate traffic in the process. If the device gets ambitious and starts blocking legitimate traffic in an attempt to block the attack traffic, the attack performs a DoS attack using the anti-DoS device!
REPORTS
ANALYTICS
Follow 
