DDoS Mitigation Techniques - State of the Art

This article discusses different DDoS mitigation schemes in use among the state of the art DDoS mitigation appliances.

Contents

• Introduction
• SYN Proxy
• Connection Limiting
• Aggressive Aging
• Source Rate Limiting
• Dynamic Filtering
• Active Verification through Legitimate IP Address Matching
• Anomaly Recognition
• Protocol Analysis
• Granular Rate Limiting
• Country Based Access Control Lists (ACL)
• White-list, Black-list, Non-tracked Sources
• State Anomaly Recognition
• Stealth Attack Filtering
• Dark Address Scan Prevention
• A Typical DDoS Mitigation StackWhat About Botnet Attacks?

lessmore

Permanent link to this knol:

Link

Jain, Hemant. DDoS Mitigation Techniques - State of the Art [Internet]. Version 20. Knol. 2011 Jun 27. Available from: http://knol.google.com/k/hemant-jain/ddos-mitigation-techniques-state-of-the/2ql6ju5b4fae/3.

CitationEmailPrintFavoriteCollect this page

---

Introduction

Firewalls, switches, Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS) have been commonly used in the past as security perimeter appliances. A new generation of attacks has now become common that cannot be stopped using the above appliances. Distributed Denial of Service (DDoS) attacks have become very common because of easy availability of botnets. New techniques have evolved in the industry to thwart DDoS attacks. This knol discusses the new and upcoming techniques.

 

SYN Proxy

This is one of the earliest techniques to handle spoofed DDoS attacks. During SYN flood, a few machines start spoofing IP addresses and start sending SYN packets. When a server receives these connection requests, it responds by sending TCP SYN/ACK packets and adding those connection entries into its own connection table. Since these spoofed IP addresses don't really exist, they don't respond to the SYN/ACK and thus the connection table remains filled for a long duration. This effectively denies the access to new and legitimate connections.

SYN Proxy is a mechanism, usually done by intermediate appliances that sit before the actual server and proxy the responses. Until the spoofed IP or un-spoofed IPs respond with the ACK, the connection requests are not forwarded.

This ensures that under SYN flood, all connection requests are screened and only those that are legitimate are forwarded.

Connection Limiting

 

Too many connections can cause a server to be overloaded. By limiting the number of new connection requests, you can temporarily give the server respite. This is done by giving preference to existing connections and limiting the new connection requests.

 

Aggressive Aging

Some botnet attacks involve opening a legitimate connection and not doing anything at all. Such idle connections fill up the connection tables in firewall and servers. By aggressively aging such idle connections, you can provide some relief to them. Aggressive aging involves removing connections from the tables and may also involve sending a TCP RST packet to the server/firewall.

Source Rate Limiting

 

When a limited number of sources are available to a bot-master, he/she can use them to aggressive send packets. These high rate packets can burden the server. Multi-threaded attacks cause such patterns of attack. By identifying outlier IP addresses that break norms, you can deny them access to excessive bandwidth. Since IP addresses in such attacks are not predictable, it is important to keep track of millions of IP addresses and their behavior to isolate outliers. Such isolation can only be done in silicon and it is difficult to achieve using software only techniques due to excessive memory bandwidth requirements.

Dynamic Filtering

 

Static filtering is a common technique in firewalls, switches and routers and is usually achieved using Access Control Lists (ACLs). Dynamic filtering is required when the attack and the attackers change constantly. Dynamic filtering is done by identifying undisciplined behavior and punishing that behavior for a short time by creating a short-span filtering rule and removing that rule after that time-span.

Active Verification through Legitimate IP Address Matching

 

While SYN Proxy is a great technique for anti-spoofing, everytime there is a SYN flood, within a short duration, if the appliance keeps sending SYN/ACK packets back, that would add too much outbound traffic. To avoid such reverse flood, it is necessary to cache identified legitimate IPs in to a memory table for a limited period of time and then letting them go without the SYN proxy check. It is quite possible for the attackers to misuse such holes, therefore it is necessary to have further checks on legitimate IP addresses by rate limiting zombies which are able to complete 3-way-handshakes.

Anomaly Recognition

 

Most DDoS attacks are written using scripts which continuously vary a few parameters in the network packets. By performing anomaly checks on headers, state and rate, an appliance can filter out most attack packets which otherwise would pass simple firewall rules.

Protocol Analysis

 

Similar to header, state and rate anomalies, further protocol analysis can bring out issues that would otherwise pass through a generic firewall.

Granular Rate Limiting

 

DDoS attacks are unpredictable and usually managed using scripted BOTs. The packets which reach the server are different from each other. There is however some self-similarity among all attack packets in a single attacks.

Granular Rate Limiting is a technique that identifies rate violations from past behavior. Rate thresholds are set based on past behavior set during a training session and adjusted adaptively over time.

 

Granularity refers to various parameters available in layer 3, layer 4 and layer 7 headers. These include packet rates for source, destination, protocol, fragment, ports, and HTTP methods, URLs, User-Agents, Cookie, Host, Referer etc.

Country Based Access Control Lists (ACL)

 

Most botnet traffic originates from a limited number of countries. These countries may not be the places from where you expect traffic. By filtering traffic based on countries, you can reduce the traffic load signficantly including the spoofed traffic. However, doing this in software may have a lot of performance penalties. Look for hardware logic implementation.

White-list, Black-list, Non-tracked Sources

 

In any network, there will always be some IP addresses that you want to deny or allow. White-listing and Black-listing capability are useful during DDoS attack to ensure that such rules are honored despite rate violations or in spite of rate-violations.

Since rate anomalies are behavioral, all behaviors are learned from past. Therefore if you don't want some behavior not to be learned, you must not track such behavior by creating an exception. Such non-tracked sources include backup IP machines etc. that do large amounts of IOs at specific times or Content Data Network (CDN).

State Anomaly Recognition

 

TCP is most commonly used protocol for web infrastructure. TCP is a stateful protocol and follows certain rules. Since most bots are scripted, many a times, they break these rules. A state anomaly recognition engine looks for illegal TCP state transition anomalies, foreign packets (packets in connections that are not properly established) and TCP window-violations.

Stealth Attack Filtering

 

Before an attack, there are precursors to attacks. These are in the form of scans. Network scans to discover IP addresses in use are common and so also Port Scans to discover TCP and UDP ports that respond to connections. By identifying, such attacks and corresponding attackers, you can take some precautions for a future full-blown attack.

Dark Address Scan Prevention

 

Dark addresses are IP addresses that are not yet assigned by IANA. These are also called bogon addresses. Any packets coming from or going to dark addresses are signs of spoofing. By blocking them, you can block a substantial percentage of DDoS packets that are spoofed.

 

 

 

A Typical DDoS Mitigation Stack

What About Botnet Attacks?

Now that you understand the techniques for previous generation of DDoS attacks, how about learning more about the current generation of botnet attacks which involve access that mimics legitimate users.

For further information, please a see a white paper from IntruGuard on: 

Firewall Topology

Firewall should cover the use of a suitable firewall, firewall topology and firewall security policy

The use of a suitable firewall, firewall topology and security policy is critical in ensuring protection against network security threats. A secured firewall must be used to provide protection against threats from external public (un-trusted) networks, such as the Internet. Networks must be segmented if distinct security boundaries are to be enforced.

A firewall is a system than controls the flow of traffic between networks and provides a mechanism for protecting hosts against network based security threats. It should be noted that firewalls cannot control (and protect against) traffic that does not flow through the security gateway (eg. a dialup modem will bypass any firewall), nor can it protect against internal or authorized attacks. Firewalls are only as secure as the firewall system and the implemented security policy (firewall rule base). Due to the number and variety of developing threats and security vulnerabilities being easily distributed on the Internet firewalls can never provide 100% protection against all possible threats. A suitable firewall must be used to interconnect to any external, public or un-trusted network (i.e. the Internet). This is mandatory due to the security threats that exist and the sensitive nature of information located within the corporate. A DMZ (De-Militarized Zone) must be used to provide segmentation of the network when hosting public resources, such as Internet web servers.

External Firewall with DMZ

Multiple DMZ’s may be used if a requirement exists for multiple network segments with differing security policies (levels). This has applications for extranets, intranets, web hosting and remote access gateways (as shown below).

External Firewall with multiple DMZ

The use of internal firewalls within the corporate is not encouraged due to the complications associated with ensuring that corporate core services such as Active Directory and Exchange messaging are not affected. An internal firewall may inadvertently deny these core services which are critical to the operations of the corporate network.

If an internal firewall is to be used, it must be configured using an appropriate security policy (gateway rule base). This is a requirement to ensure that core services such as DNS, DHCP, Active Directory and Exchange messaging is globally available.

The minimum requirement with regards to “Firewall Topology” in the firewall security standards are:

1. A suitable firewall must be used for all external connections.

2. Networks with differing security requirements must be segmented and protected with a firewall (eg. Internal (trusted) vs. Internet (un-trusted)).

3. A DMZ is mandatory for systems (eg. web servers) that are accessible from any public (un-trusted) network. These externally accessed hosts must not be placed on the corporate internal (business) networks.

4. Multiple DMZ’s may be used to provide network segments with multiple security classifications (or zones).

5. All physical firewall connections must be secure and appropriately label. It is recommended to use a color coding scheme to differentiate between private, public or DMZ networks.

6. All Internet (external facing) firewalls must be configured to deny all traffic unless explicitly permitted.

A suitable firewall topology ensures the ability to identify security boundaries within the network and to apply a valid security policy (rule base) to the security gateway (firewall).

Another series of firewall security standards, you should read about firewall requirement.

http://www.computer-network.net/firewall-topology

The Many Faces of DDoS: Variations on a Theme or Two

When you look across the “class” of attacks used to perpetrate a denial of service attack you start seeing patterns. These patterns are important in determining what resources are being targeted because it provides the means to implement solutions that mitigate the consumption of those resources while under an attack. Once you recognize the underlying cause of a service outage due to an attack you can enact policies and solutions that mitigate that root cause, which better serves to protect against the entire class of attacks rather than employing individual solutions that focus on specific attack types. This is because attacks are constantly evolving, and the attacks solutions protect against today will certainly morph into a variation on that theme, and solutions that protect against specific attacks rather than addressing the root cause will not necessarily be capable of defending against those evolutions.
In general, there are two types of denial of service attacks: those that target the network layers and those that target the application layer. And of course as we’ve seen this past week or so, attackers are leveraging both types simultaneously to exhaust resources and affect outages across the globe.

NETWORK DoS ATTACKS

Network-focused DoS attacks often take advantage of the way network protocols work innately. There’s nothing wrong with the protocols, no security vulnerabilities, nada. It’s just the way they behave and the inherent trust placed in the communication that takes place using these protocols. Still others simply attempt to overwhelm a single host with so much traffic that it falls over. Sometimes successful, other times it turns out the infrastructure falls over before the individual host and results in more a disruption of service than a complete denial, but with similar impact to the organization and customers.

SYN FLOOD

A SYN flood is an attack against a system for the purpose of exhausting that system’s resources. An attacker launching a SYN flood against a target system attempts to occupy all available resources used to establish TCP connections by sending multiple SYN segments containing incorrect IP addresses. Note that the term SYN refers to a type of connection state that occurs during establishment of a TCP/IP connection. More specifically, a SYN flood is designed to fill up a SYN queue. A SYN queue is a set of connections stored in the connection table in the SYN-RECEIVED state, as part of the standard three-way TCP handshake. A SYN queue can hold a specified maximum number of connections in the SYN-RECEIVED state. Connections in the SYN-RECEIVED state are considered to be half-open and waiting for an acknowledgement from the client. When a SYN flood causes the maximum number of allowed connections in the SYN-RECEIVED state to be reached, the SYN queue is said to be full, thus preventing the target system from establishing other legitimate connections. A full SYN queue therefore results in partially-open TCP connections to IP addresses that either do not exist or are unreachable. In these cases, the connections must reach their timeout before the server can continue fulfilling other requests.

ICMP FLOOD (Smurf)

The ICMP flood, sometimes referred to as a Smurf attack, is an attack based on a method of making a remote network send ICMP Echo replies to a
single host. In this attack, a single packet from the attacker goes to an unprotected network’s broadcast address. Typically, this causes every
machine on that network to answer with a packet sent to the target.

UDP FLOOD

The UDP flood attack is most commonly a distributed denial-of-service attack (DDoS), where multiple remote systems are sending a large flood of UDP packets to the target.

UDP FRAGMENT

The UDP fragment attack is based on forcing the system to reassemble huge amounts of UDP data sent as fragmented packets. The goal of this attack is to consume system resources to the point where the system fails.

PING of DEATH

The Ping of Death attack is an attack with ICMP echo packets that are larger than 65535 bytes. Since this is the maximum allowed ICMP packet size, this can crash systems that attempt to reassemble the packet.

NETWORK ATTACK THEME: FLOOD

The theme with network-based attacks is “flooding”. A target is flooded with some kind of traffic, forcing the victim to expend all its resources on processing that traffic and, ultimately, becoming completely unresponsive. This is the traditional denial of service attack that has grown into distributed denial of service attacks primarily because of the steady evolution of web sites and applications to handle higher and higher volumes of traffic. These are also the types of attacks with which most network and application components have had long years of experience with and are thus well-versed in mitigating.

APPLICATION DoS ATTACKS

Application DoS attacks are becoming the norm primarily because we’ve had years of experience with network-based DoS attacks and infrastructure has come a long way in being able to repel such attacks. That and Moore’s Law, anyway. Application DoS attacks are likely more insidious simply because like their network-based counterparts they take advantage of application protocol behaviors but unlike their network-based counterparts it requires far fewer clients to overwhelm a host. This is part of the reason application-based DoS attacks are so hard to detect – because there are fewer clients necessary (owing to the large chunks of resources consumed by a single client) they don’t fit the “blast” pattern that is so typical of a network-based DoS. It can take literally millions of ICMP requests to saturate a host and its network, but it requires only tens of thousands of requests to consume the resources of an application host such that it becomes unreliable and unavailable. And given the ubiquitous nature of HTTP – over which most of these attacks are perpetrated – and the relative ease with which it is possible to hijack unsuspecting browsers and force their participation in such an attack – an attack can be in progress and look like nothing more than a “flash crowd” – a perfectly acceptable and in many industries desirable event.
A common method of attack involves saturating the target (victim) machine with external communications requests, so that the target system cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable. In general terms, DoS attacks are implemented by forcing the targeted computer to reset, or by consuming its resources so that it can no longer provide its intended service, or by obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.

HTTP GET FLOOD

An HTTP GET flood is as exactly as it sounds: it’s a massive influx of legitimate HTTP GET requests that come from large numbers of users, usually connection-oriented bots. These requests mimic legitimate users and are nearly impossible for applications and even harder for traditional security components to detect. This result of this attack is similar to the <choose your popular aggregator> effect: server errors, increasingly degraded performance, and resource exhaustion. This attack is particularly dangerous to applications deployed in cloud-based environments (public or private) that are enabled with auto-scaling policies, as the system will respond to the attack by launching more and more instances of the application. Limits must be imposed on auto-scaling policies to ensure the financial impact of an HTTP GET flood does not become overwhelming.

SLOW LORIS

Slowloris consumes resources by “holding” connections open by sending partial HTTP requests. It subsequently sends headers at regular intervals to keep the connections from timing out or being closed due to lack of activity. This causes resources on the web /application servers to remain dedicated to the clients attacking and keeps them unavailable for fulfilling legitimate requests.

SLOW HTTP POST

A slow HTTP Post is a twist on Slow Loris in which the client sends POST headers with a legitimate content-length. After the headers are sent the message body is transmitted at slow speed, thus tying up the connection (server resources) for long periods of time. A relatively small number of clients performing this attack can effectively consume all resources on the web / application server and render it useless to legitimate users.

APPLICATION ATTACK THEME: SLOW

Notice a theme, here? That’s because clients can purposefully (and sometimes inadvertently) affect a DoS on a service simply by filling its send/receive queues slowly. The reason this works is similar to the theory behind SYN flood attacks, where all available queues are filled and thus render the server incapable of accepting/responding until the queues have been emptied. Slow pulls or pushes of content keep data in the web/application server queue and thus “tie up” the resources (RAM) associated with that queue. A web/application server has only so much RAM available to commit to queues, and thus a DoS can be affected simply by using a small number of v e r y  slow clients that do little other than tie up resources with what are otherwise legitimate interactions.
While the HTTP GET flood (page flood) is still common (and works well) the “slow” variations are becoming more popular because they require fewer clients to be successful. Fewer clients makes it harder for infrastructure to determine an attack is in progress because historically flooding using high volumes of traffic is more typical of an attack and solutions are designed to recognize such events. They are not, however, generally designed to recognize what appears to be a somewhat higher volume of very slow clients as an attack.

THEMES HELP POINT to a SOLUTION

Recognizing the common themes underlying modern attacks are helpful in detecting the attack and subsequently determining what type of solution is necessary to mitigate such an attack. In the case of flooding, high-performance security infrastructure and policies regarding transaction rates coupled with rate shaping based on protocols can mitigate attacks. In the case of slow consumption of resources, it is generally necessary to leverage a high-capacity intermediary that essentially shields the web/application servers from the impact of such requests, coupled with emerging technology that enables a context-aware solution better detect such attacks and then act upon that knowledge to reject them.
When faced with a new attack type, it is useful to try to determine the technique behind the attack – regardless of implementation – as it can provide the clues necessary to implement a solution and address the attack before it can impact the availability and performance of web applications. It is important to recognize that solutions onlymitigate denial of service attacks. They cannot prevent them from occurring.

http://devcentral.f5.com/weblogs/macvittie/archive/2010/12/16/the-many-faces-of-ddos-variations-on-a-theme-or.aspx

Distributed Denial of Service Attacks - A Primer

This primer on DDoS attacks is for network, security and business managers. Existing information on DDoS attacks is outdated and has not kept up with current state of the art in attack tools and attack mitigation techniques. The scope of this tutorial is limited to internet data centers, webhosts and is not relevant to very large ISPs with several routers and several Internet links.

Defining DDoS Attacks

Denial of service (DoS) attacks are attacks that are deliberate attacks on your network properties to deny service to legitimate users. When these attacks seemingly come from distributed sources, they become distributed denial of service (DDoS) attacks.

 

Few years back, it was common to use spoofing techniques where a hacker would actually use very few machines (or just one machine) and spoof mutliple IP addresses. To the attacked destination it would seem that the attack is coming from multiple IP addresses. However in the recent times, with the advent of infected PCs, increasing number of smart mobile phones, many botnets are available around the world, which can be used to launch a real DDoS attack.

 

Scenarios Under Attack

 

• Under attack, your team does not know details of the attack. They understand the symptoms, but they can’t figure out the cause and the solution.
• Your routers and switches are overloaded and they don’t have the capability to stop such attacks. Firewalls simply allow these packets. IPS appliances (if you have them), don’t have the rules to block such attacks. Your equipment doesn’t match up in performance that’s required.
• May be, you have multiple links to the Internet. The attackers are attacking from different links.
• The attack is seemingly coming from all over the world. You cannot simply identify a Net-block to deny so that the attack can be stopped !! And you cannot simply block everyone !!
• The attack is no different from legitimate users accessing your web pages from the point of your edge equipment.
• Your team is unable to figure out the solutions quickly when the attackers are constantly changing the tactics.
• You have too much collateral damage. When attack happens on one part of the network, the others bleed too.
• Software solutions such as mod_evasive, iptables, Apache / LiteSpeed tuning, kernel tuning, not capable of handling the load.
• You are not as rich as others to over-provision your bandwidth and to buy high-bandwidth gear.
• The only tool your service provider has is Null Routing your IP address!!

 

Causes of Attacks

• Sometimes script kiddies’ youthful exuberance gets transformed to rivalry and they try to prove their might and you just get involved in their cross fire. Sometimes it may simply be your own rivals who are getting at you.
• In some cases, some script kiddies may have recently learnt the tricks of the trade. They may be doing this for sheer personal pleasure. They are randomly choosing targets and you just happened to be on their radar by mistake. They may incrementally advance to more sophisticated attacks as they learn the tricks.
•  For some attackers it is prestigious to attack you and bring you down despite all your attack defenses. Some times, a software bug on your server may be causing too many users to come to your site again and again. Your servers can’t handle the load and they keep trying. It’s like an avalanche.
•  Sometimes, someone wants you to pay or else they will break your site. May be there is a reason you are not reporting this to authorities – or may be authorities/ISPs don’t help and don’t know how to help.

Motivation Behind Attacks

There can be many reasons why DDoS attacks are launched.

 

• Some attacks are principle driven attacks. The attackers desire to silence you since your values are different from theirs. E.g. you own porn sites and they are web-vigilante. Sometimes your rival religious sects may be flooding if you own a religious site. Your web properties may be site capitalistic and the attackers may be anti-capitalism. You may be American and the attackers could be anti-American. You may be managing debt and the attackers may have sympathy with poor or those in debt. Such principle driven attacks are very common and are difficult to solve on the principle grounds. May be you have a gay/lesbian site and someone doesn’t agree with you.
• Sometimes attacks have a business reason. You may be in the way of someone else’s business growth. They will then hire a botmaster who will then launch an attack on your properties. Sometimes the attackers may have ethical objection to your business.
• Angry customers are another cause of the attacks. If you host IRC servers, gambling - especially offshore, or porn sites and you have some angry customers, they may come back to extract revenge. If you have recently banned someone from your servers or if someone has lost a lot of money on your site, they may be behind the attacks.
• Another type of attacks we have seen are related to social networking. If you are a social networking site and one of the users has written a page against a foreign government. That government may now be after you. Until you remove that page, you will be attacked.

Virus Infections, Botnets and Distributed Attack Tools

Millions of new users join the Internet daily. These are in the far-flung corners of the world. If you are reading this primer, you are savvy - but they are not. If they get an enticing email from someone, they open it and their machine now has bot code which can be remotely controlled by botmasters. Millions of such machines around the world are under control of bot-herds who buy, sell and rent them for monetary gains. Some foreign governments are also known to control them for possible cyber-warfare.

  

Fig. 1 A botnet control panel showing how easy it is to launch a DDoS attack

The above pictures shows a bot-controller that can be easily used to launch a DDoS attack sitting somewhere using bots around the world. The renter uses this software after paying the rent. She can simply enter the URL of the target site to be attacked and choose the type of the attack and launch the attacks including a blended attack. This program controls the bots on the Internet.

 

Following is another example of another bot controller panel. As you can see the panel consists of a display of available bots in different countries and ability to launch different tasks through the bots.

 

Fig. 2 A botnet control panel example also showing status of available bots

 

Another picture below shows ability of the bot-master to upload new functionality into the botnet and update the bots remotely and have an ability to remotely see the status of the bots.

 

Fig. 3 Another botnet control panel example showing ability to update bots remotely

Most Common Current Generation DDoS Attacks

Therea are many kinds of legacy and current generation attacks that are prevalent today. SYN flood and HTTP GET floods being the most common.

 

• SYN Flood

  Spoofed SYN Packets fill the connection table of servers, and all other devices in your network path. Low volume SYN flood can be easily stopped by software firewalls. High bandwidth SYN floods needs specialized equipment with SYN proxy capability.

 

• Zombie Flood

  In zombie or botnet floods, non-spoofed connections overload the services. The attacking IPs are able to do three way handshakes. These are difficult to stop unless you have behavioral mitigation. High bandwidth zombie floods needs specialized logic for discriminating legitimate traffic within zombie flood.

 

• ICMP Flood

  In these floods, ICMP packets, such as those used for ping, overload the servers and the network pipe. Low volume ICMP flood can be easily stopped by ACLs on routers and switches. High bandwidth ICMP floods needs specialized equipment.

 

• TCP/UDP Port Flood

  In these floods, TCP/UDP packets overload the servers and the pipe on ports not being used for service, e.g. TCP port 81.  Low volume port floods on non-service ports are easily stopped by ACLs. Higher volume need specialized equipment for automatic detection and mitigation unless you have totally blocked all non-service ports by default. Sites that use services such as FTP or IRC that use dynamic ports need to be careful with the stateful traffic on the dynamic ports. Most large attacks that are greater than 1 Gbps involve UDP floods because they are easy to generate by spoofing IPs.
  
  When packets overload the servers and the pipe on service ports, e.g. TCP port 80. Firewall, switches, routers, IPS appliances cannot stop these attacks. In these cases, you need specialized equipment for discrimination.

 

• Fragment Flood

  In these flood, fragmented packets overload the servers. Many firewalls, switches, routers cannot stop these attacks unless they have rulesets for dropping fragmented packets. Sometimes you may need specialized equipment.

 

• Anomalous Packet Flood

  Hackers create most floods with scripts. Sometimes deliberately and sometimes due to errors in scripts, packets are anomalous. These anomalies may be headers at layer 3, 4 or 7. They may be in TCP or UDP states or protocols. These packets overload the CPU of the servers and other networking equipment on the way. Some firewalls, and IPS appliances can stop these attacks. Specialized equipment for DDoS easily stop these attacks.

 

• HTTP GET Flood

  These attacks involved connection-oriented bots overload the servers and the pipe on service ports, e.g. on HTTP, mimicking legitimate users.  Since firewalls, switches, routers, IPS appliances don't have behavioral anomaly prevention, they cannot stop these attacks. Therefore you need specialized equipment to stop these attacks.

 

• Blended Attacks

  When multiple types of above attacks are blended on the server, they confuse the conventional equipment further. Firewall, switches, routers, IPS appliances cannot stop these attacks. You need specialized equipment to stop these attacks

 

• Floods from Unwanted Geographical Areas

  These are very common. For example, you have most of your customers in China and you are getting too many packets from Russia. Such floods are easy to stop with simple access control lists in Anti-DDoS equipment or in switches or routers before the network.

 

Myths and Realities about DDoS Attacks

 

• Most Network and Security Operations engineers only hear about DDoS attacks happening to others.  They think that they don’t have enemies. In reality, their perceptions of risk factors and suscpetability is most often misplaced. If you have a web presence, you can be attacked easily – sometimes even by mistake.
•  Many engineers think that they can custom compile kernel, set some options in Apache, install mod_dosevasive and DDoS attacks can be taken care of. In Reality, most servers do not have the capacity to handle DDoS attacks. Under most average sized DDoS attacks, your server CPUs will be too overloaded to give Apache modules a chance.
•  Another myth that exists is that simple iptables commands can block DDoS attacks. In reality, NetFilter/iptables can block very tiny attacks and tiny percentage of DDoS attacks. Real DDoS attacks require specialized equipment because the CPU running iptables will be too busy handling attack packets.
•  Many Network and Security Operations engineers think that their webhosts will take care of DDoS attacks. Many webhosts are happy to just null-route an attacked IP domain unless they have specialized equipment. Many webhosts do not have the skills to manually isolate issues - unless they specially advertise such capability.
• Some think that their ISPs, to whom their webhosting data center is connected to, cooperate under attack and they can find the source of the attack. Most ISPs are too busy. They have strict and bureaucratic processes to reach each other. Typical response time for ISPs are in days if not in hours – whereas you want the solution NOW !!
•  It is also easy to think that under attack, we can report to law enforcement to solve the problem. In reality, most law enforcement departments will not bother about needle in hay-stack attacks – for them that’s what most attacks are. Unless you are important and the attacks are in multiple 10s of Gigabits per second, don’t waste their time and yours.
• You may also think that you can determine that ACLs for your routers and switches to block the attacks. DDoS attacks are moving targets. The hackers are smart, their tools are smarter and techniques are sophisticated.
• Another myth that surrounds DDoS attacks are filled pipes. Many wonder if there is any point in buying any specialized Anti-DDoS equipment. In reality, 90% of the attacks are sub-1Gbps today and if you have that much pipe, you will be better off having a DDoS mitigation solution than not having one at all. Pain from the most complex attacks can be reduced with specialized equipment. Without the DDoS mitigation equipment, your servers will be thoroughly exposed to even the most ordinary attacks. Take the first step. DDoS mitigation eqauipment is not as expensive as you may think. DDoS mitigation costs are proportional to number of links, bandwidth, complexity of policies and type of attacks.  If you have a reasonable sized business, it should not cost you an arm and a leg. There are cost-effective solutions available that are effective.

 

Home Remedies For Simple and Small DDoS Attacks

• Update kernel to the latest release
• Install all security updates
• Disable unused and insecure services
• Remove unused packages
• Memory resources can be exhausted by filling up various kernel tables that are not tuned to be sufficiently large. Ensure that you understand various kernel tables.
• Network card is gateway to the packets.  Better network card means better handling of large number of packets. Better network card driver means better performance.
• Choose a vendor such as Intel and model which is proven and a driver that’s already hardened.
• Use NetFilter/iptables firewall to deny bad packets
• Use Hashlimit module to identify IPs that are consuming resources
• Use ipset module to block-lists of up to IP addresses that can be queried, loaded and unloaded from user-space.
• Use command : netstat -plan|grep :80 |awk '{print $5}' |cut -d: -f1 |sort |uniq -c |sort -n to find out if port 80 is being attacked by too many IPs.
• Use modules such as mod_evasive, mod_limitipconn to limit attacks from limited number of IPs.
• Try mod_qos to improve quality of service.
• Apache has its limits. You can try LiteSpeed.

Anti-DDoS Appliances

There are primarily following categories of appliances in the market for DDoS mitigation:

 

1. Carrier DDoS mitigation solutions
   • These solutions are useful for global networks and carriers and ISPs.
   • They employ IP flow-based and deep packet inspection technologies, and protect entire networks consisting of multiple routers and switches and services behind them.
   • Example of such solutions are Arbor Networks.
   • These solutions are too expensive for individual IDCs, webhosts or web properties.
   • These solutions have been designed around early 2000 and therefore are not keeping up with the current generation of DDoS attacks which involve botnets that mimic legitimate clients.
   • These solutions work very well at global level and the residual attacks from such solutions may be too much for an individual web property which in turn may have to employ a solution such as 2 below.
2. Custom Logic (FPGA or ASIC) based Internet Data Center (IDC), Web hosting and Web Property DDoS Mitigation Solutions
   • These solutions are useful for large IDCs, large web hosts and large web properties.
   • They work to protect one or several Internet links.
   • The behavioral solutions are implemented in custom hardware logic and provide line rate performance for large attacks.
   • IntruGuard has one such solution.
   • These solutions are cost-effective and effective for IDCs, webhosts and web properties.
3. Software based Web Property DDoS Mitigation Solutions
   • These solutions are useful for smaller web properties with very minimal traffic.
   • The behavioral solutions are implemented in off-the-shelf CPUs and have issues at large attack traffic volumes in terms of keeping up.
   • Some appliances have IPS functionality implemented in hardware but have their DDoS mitigation logic in software and suffer from the same issues.

  

Few Things to Look for in Anti-DDoS Equipment

• Latest Technology

  The hackers are pretty up-to-date on techniques. If your DDoS mitigation appliance is built around technology that was developed in early 2000s, it won't help you much as most of the current generation attacks would pass through.

• Centralized monitoring

  Look for appliances that allow you to centrally monitor all DDoS events and traffic in your network.  You can use SNMP, Cacti, MRTG to monitor traffic and attack levels and attack events. You can configure Syslog to get all attack events on a centralized server as well.

 

• Visibility into normal network traffic patterns

  Look for appliances that allow you to get extremely granular visibility into your network traffic. Typically you should look for a 12 month round robin view of what normal traffic looks like and incorporate this information into a correlation engine for threat detection, alerts, and reporting.

 

• Alerting Mechanisms

  Look for appliances that give you a threshold based alerting mechanism for DDoS specific events. You can set threshold for different people to get alerts depending on the quantum of attack. You should be able to query a database for Top Attacks, Top Attackers, Top Attacked Destination, etc. You should be able to create custom queries in your custom applications/reports.

 

• Filtering Mechanisms to Reduce False Positives

  Look for appliances that filter traffic in different network layers as they inspect incoming packets using dynamic profiling (based on monitoring and analysis of normal behavior), anti-spoofing algorithms, and other technology to progressively filter harmful traffic upstream of the network.

 

• Low Latency

  Latency, in this context, is the amount of time it takes a packet to go through an appliance. Look for appliances that don't affect your mission critical traffic by adding additional significant latency. Most switches and routers have low latency in the range of a < 50 microseconds. The anti-DDoS equipment should maintain similar latency levels. This latency should be maintained even during attacks.

 

• Hardware Logic for Anti-DDoS

  These days it is common for a $100 home router to claim that it has DDoS attack mitigation capability. Such claims have to withstand third party tests and real life. It is also easy to build Intel CPU based appliance running Linux with some behavioral capability built-in to claim anti-DDoS features. Many IPS appliances have IPS in hardware logic but anti-DDoS capability in software. Such appliances cannot handle attacks beyond a certain Mbps.
  
  Look for custom DDoS mitigation logic implemented in hardware as that alone can withstand large DDoS attacks. A granular approach to DDoS mitigation selectively mitigate attacks at highest possible layer so that attacks are stopped at most specific layer. This reduces the false positives.
  
  Ability to monitor a large number of ports, sources, destinations, connections etc. helps in proper identification of attacks and attackers.

 

• Bypass and Redundancy

  Look for internal or external bypass capability that ensures that your network traffic continues even if the appliance fails. For multiple links, look for ability to cross conect appliances in a fail-over configuration. In addition, look for asymmetric traffic support because you may have traffic coming from one link and going through another.

 

• Extensible Architecture

  Anti-DDoS equipment must grow with your business. Look for appliances that have such capability to grow through licenses.

• Third Party Validation

  Look for third party validation for a solution you choose. That will mitigate some risks of your inability to actually do a test in your own labs.

 

Conclusion

DDoS attacks are on the rise. The potential threats and volumes are increasing as more machines including mobile devices join the Internet. If you have a web property, the likelihood of your getting attacked is on the rise. Script kiddies are moving from fame to fortune. It is prudent to plan protection of the infrastructure rather than wait for the attacks to strike. 

http://knol.google.com/k/distributed-denial-of-service-attacks-a-primer#

Deep Packet Inspection vs. Granular Packet Inspection for DDoS Mitigation

Introduction

Deep Packet Inspection (DPI) is a capability to look within the application payload of a packet or traffic stream and make decisions based on the content of that data, in the network. This is achieved using signature-matching technology. Known attack signatures are used to determine future attacks.
Distributed Denial-of-service attacks overwhelm critical resources with a flood of attack traffic. To accomplish this, an attacker must be able to generate high-rate packet floods; this is usually done by recruiting a large number of machines through a remote compromise and instructing them to flood the target. Early DDoS attacks employed small number of compromised machines that generated large UDP or ICMP packets at a maximum rate, aiming to overwhelm a target’s bandwidth.  These limited number of sources used spoofing techniques to appear as a larger number of IP addresses. Recent attacks are more sophisticated. The attack traffic today is usually legitimate service request traffic (such as HTTP requests), and is sent from tens of thousands of compromised BotNet machines.
Because the traffic appears legitimate and is critical to business operation, it is very difficult to detect and filter attack packets while allowing access to legitimate user traffic. Further, since each attack machine sends traffic at a low rate, its behavior is not suspicious and therefore it is difficult to identify and blacklist such machines. DDoS attacks are a realistic threat to businesses, regardless of their size.
It is therefore necessary to inspect the intent of the attack rather than the content.
While most IPS appliances work on content inspection or deep packet inspection, for DDoS, using content inspection is futile.

Granular Packet Inspection (GPI) and Why Is It Important for DDoS Mitigation

If BotNets mimic legitimate users using scripts and content inspection cannot be used for discrimination between real traffic and attack traffic then what can be used. The answer lies in the methods the attackers use to launch such attacks.
To understand intent under a flood, one has to understand behavioral anomalies at micro and macro levels. Behavioral anomalies represent deviation from the past behavior. It is therefore important to gather information over past behavior and store it so that one can predict what the future behavior should be. This requires understanding the average, trends and seasonality of the traffic in a very granular way.
To achieve attack mitigation using behavioral anomaly, you must first understand the attack types used by BotNets. They can be broadly categorized in two kinds:
·          Non-Service attacks:

These are attacks that happen on ports, protocols or other network parameters not primarily used by the network. E.g. attacks such as SQL-slammer overloaded a rarely-used port.

 

·          Service attacks: 

These are attacks that are actually trying to mimic the legitimate users. E.g. if a website uses HTTP protocol, the attacks would target the open TCP port 80 and valid URLs.

 

 

First kind of attacks can be simply blocked by behaviorally blocking non-service ports/protocols etc. E.g. if your network rarely sees fragmented traffic and you suddenly get an overload of fragments, you can rate limit the fragmented packets to a rate that you had seen in the past. Same can be done for non-service protocols such as ICMP, UDP etc. and non-service ports. They may even be blocked for the duration of attacks at the perimeter to avoid collateral damage. Granular thresholds help here. Directionality helps here.  E.g. if you get x Mbps inbound traffic normally and y Mbps outbound, the rate-limiting can be different in two directions. Partitioning of network helps here to isolate issues. E.g. one of your subnets sees SSL traffic while the other does not, you can have different thresholds for rates of SSL traffic.
Second kind of attacks is tricky to stop using simple granular threshold on ports or protocols etc. You need more behavioral techniques.
BotNets attacks are primarily scripted attacks – that means they are bot-programs which are launching attacks. The behavior of these scripts is very different from a human clicking links on browsers or typing URL names. The rates are unusual. The rate of connection establishment for a single IP address is much higher for a scripted attack. Similarly one or more of the following behavioral rates are abnormal during such attacks:

• Total number of concurrent connections/destination IP address
•  Total number of concurrent connections/source IP address
•  Total number of SYN packets/second per partitioned network
•  Rate of packets/second/source
•  Rate of packets/second/destination
• Rate of TCP connection establishment

Such behavioral anomalies can be caught using granular inspection which monitors individual IP addresses, protocols, ports, etc. Baseline thresholds adjusted over time for seasonality for such granular characteristics can be used to block abnormal behavior.

Granular Inspection Technology

Custom hardware design can monitor thresholds for all traffic it sees on Layers 2, 3, 4 and 7 and measure packet rates, state transitions, fragments, checksum, flags, new connections, and address pairs, etc. Thresholds can be set on any of these network parameters to rate limit traffic for particular systems or applications.

First Level of Granularity: Compartmentalization of Business/Network

To partition networks logically, DDoS mitigation device provide support for partitioning the network. Through the use of Virtual Identifiers (VID), the appliances can segment the traffic into up to eight zones. These zones can each be a server, subnet or network, whether on-site or remote. This allows one gateway to secure eight network segments and thus leverage the cost over a large infrastructure. When the gateway is placed in front of a router and firewall this can substantially reduce duplicated these other network elements. VLAN tags, IP, or MAC addresses identify zones.
The logical portioning allows these VID zones to have their own set of parameters and policies. Each of the 200,000 plus parameters and their corresponding thresholds are automatically monitored to spot malicious traffic. As different zones should be expected to have unique traffic patterns, the use of VIDs improves accuracy and prevents false positives.

Second Level of Granularity: Directionality

Traffic in network has directionality and each direction has different behavior. DDoS Mitigation appliances allow you to set independent parameters in two dirctions. E.g. incoming rate of packets on port 80 and outgoing rate are usually different and should be controlled differently.

Third Level of Granularity: Time

Traffic in network has seasonality and growth over time. DDoS mitigation appliances allow you to set threshold once and they adjust the thresholds adaptively and continuously based on the time of the day and week.

Fourth Level of Granularity: Granular Packet Rate Thresholds

DDoS mitigation appliances monitor network parameters to analyze subtle changes in the behavior of network traffic rate to recognize and prevent attack and be able to differentiate between attack traffic and legitimate traffic and maintain service during denial of service attacks and respond like a circuit-breaker within 2 seconds.
DDoS mitigation appliances build a baseline model of legitimate network traffic at levels 2, 3, 4 and  7, measuring byte and packet counts, state transitions, fragments, flag distribution, IP address distribution, new connection establishment rate, and numerous other parameters. Counters for each parameter are implemented on chip – thus the measurement occurs at the packet forwarding rate of 200Mbps/2Gbps., Such design introduces no monitoring overhead, no filtering bottleneck, and high-granularity counters are supported. For example, traffic to one Million source IP and one Million destination IP addresses can be traced, as well as for any of 65536 ports on source or destination hosts, and for any of 256 possible protocol numbers.

Layer 2 Granularity	ARP, RARP, Multicast, Broadcast, VLAN, Double Encapsulated VLAN floods
Layer 3 Granularity	Protocol Flood (all 256), Options Flood (32), Fragment Flood, Source Flood, Destination Flood, TOS (all 256),  Network Scan, Dark Address Scan
Layer 4 Granularity	TCP Ports  (all 64K), UDP Ports (all 64K), ICMP Type/Codes (all 64K),. TCP Options (32),  Port Scan, Connection Flood, SYN Flood, Excessive SYNs/Source/Second, Excessive Connections Establishment/second, Zombie Flood, Excessive Connection/Source flood, Excessive Connections/Destination flood, TCP state violation floods

Layer 7     Granularity

URLs, User-Agent, Host, Referer, Cookie etc. (Translates into excessive URL accesses/second, URL access/source/second etc.)

This granularity is important because it supports building of a complex and detailed legitimate traffic model facilitating detection of sophisticated attacks that attempt to mimic legitimate traffic. Since the attacker cannot learn or infer the baseline model, the generated attack will inevitably breach some of the fine thresholds, regardless of attack sophistication. At the same time, fine granularity supports precise traffic filtering, minimizing collateral damage to legitimate traffic during an attack

A network administrator can set up thresholds on individual monitored parameters or their combinations, to describe allowed fluctuations in network traffic.  
Attacks that generate traffic floods are by comparing the current traffic measurements with a predicted trend for each monitored parameter. The predicted trend is derived from the baseline, taking into account a historical weighted average of the packet and byte counts with a certain parameter value (thus later measurements carry more importance), the traffic trend (dynamics of the parameter change) and the traffic seasonality. If a measured value exceeds the predicted value by more than the threshold set for this parameter, an attack will be detected. When a traffic parameter exceeds its minimum threshold, the smaller of the estimated and maximum thresholds will be used for filtering. An administrator can control the extent to which an estimated threshold may exceed the baseline by setting one of the five threat levels – higher threat levels lead to a tighter threshold setup.

Additional Prevention Mechanisms

 In addition to deploying a behavior modeling approach for attack detection, a DDoS mitigation appliance can detect anomalous traffic at the packet and the connection level. These techniques include:

• SYN Proxy
• Connection Limiting
• Aggressive Aging
• Source Rate Limiting
• Dynamic Filtering
• Active Verification through Legitimate IP Address Matching
• Anomaly Recognition
• Protocol Analysis
• Rate Limiting
• White-list, Black-list, Non-tracked sources
• State Anomaly Recognition
• Stealth Attack filtering
• Dark address scan prevention

Conclusion

While deep packet inspection (DPI) is useful for secure perimeters, it is not sufficient to handle DDoS attacks. Granular Packet Inspection (GPI) done in silicon combined with behavioral modeling can provide the network security administrator with the right tools to thwart new generation of attacks.

http://knol.google.com/k/deep-packet-inspection-vs-granular-packet-inspection-for-ddos-mitigation 

How To Test a DDoS Mitigation System

Knowledge of DDoS attacks is mostly through hearsay. Most people purchasing DDoS mitigation systems do not know how to decide one system from the other. This knol discusses a minimum feature set that you must test and benchmark to see the functionality and performance of a given DDoS mitigation system.

Introduction

Distributed Denial of Service (DDoS) attacks are becoming common now with the proliferation of botnets. Network managers and security managers are deploying DDoS mitigation systems. Since most DDoS mitigation systems are fewer than 5 year old today, there is a trust issue with them.  Those that have been tested by third parties such as Tolly Group are fewer. Most people would rather test them in their own lab before deploying them.

There are well know criteria for testing firewalls and Intrusion Prevention Systems (IPS). For DDoS mitigation systems, there is a need for a comprehensive test conditions.

This knol therefore focuses on idenifying different kind of floods that can be tested using DDoS mitigation systems.

The reader is expected to create test-benches and test scripts to create these tests.

 

Typical Test Benches

Following diagram shows a simple test bed. The appliances SmartBits and Avalanche are packet generator. Smartbits is used for creating session-less attack packets and Avalanche is used for creating sessions or attack sessions. Client PCs (PC1, PC2) and Server PCs (PC3 etc.) are used to seeing the results of mitigation.SmartBits and Avalanche here can be replaced with PCs runnig Linux/Windows with attack scripts.

Following diagram shows a more complex test bed. The appliances SmartBits and Avalanche are packet generators. Such setups are typically used for third-party performance tests.

DDoS Attack Types - A Broad Classification

DDoS attacks can be broadly classified into following categories:

• Spoofed floods vs. Non-spoofed floods
  • A spoofed flood sends packets that seem to come from an IP that either does not exist or did not actually send the packet.
  • A non-spoofed flood on the other hand comes from real IP addresses. Due to proliferation of botnets, it is quite common these days to see non-spoofed attacks coming from a large number of sources.

Anomalous header floods

• These are packets which are typically generated by scripts. Scripts simple use loops to increment certain header parameters. Since many of these header parameter values may not be valid from standards perspective, they are anomalous. Examples of these attacks are packets with invalid TCP flag combinations. If a packet has flags such as RST, FIN, SYN, and ACK set simultaneously, it is anomalous.

Anomalous state floods

• Protocols such as TCP are stateful. They follow predefined state transition rules. When scripted bots generate attacks, they violate many of these rules. Examples of such attacks are ACK packets coming without connection establishment, out of TCP window packets etc.

Limited sources vs. Large number of sources Floods

• Some DDoS attacks are launched using very limited numer of sources while some others are launched with a very large number of sources. It is easy to launch a spoofed attack with a seemingly large number of sources. To launch a non-spoofed large number source attack, you need a control over  a large botnet.

Layer 2, 3, 4 or 7 DDoS attack

• It is possible to launch DDoS attacks on different network layers.
• Within a LAN, it easy to launch a layer 2 DDoS attack. Examples could be a brodcast flood, ARP flood, RARP flood etc.
• Over the Internet, one can launch Layer 3, 4 or 7 attacks.
• Example of Layer 3 attacks are protcol floods such as ICMP floods, TCP floods, fragment floods. These are created using a variation in the layer 3 headers.
• Example of layer 4 floods are port floods (TCP or UDP). In these attacks, a single port is continuously attacked. ICMP echo flood are also of this kind.
• Example of layer 7 floods are URL floods. In this attack, a single URL is continuously attacked from mutliple sources.

Random header parameter attack

• It is easy to create DDoS attacks in which some specific header parameter is continuously varying. Examples are TCP random flag flooding, IP option flooding, TCP option flooding etc.

Blended attack

• It is easy to create DDoS attacks in which many attacks are combined to further confuse the destination. Examples are port floods on TCP and UDP simultaneously, .

Attacks To Test Functionality and Performance 

• Spoofed Syn Flood Attack
  • This is a layer 4 spoofed flood in which the attacker sends TCP SYN packets in which the IP addresses are continuously changing.
• Spoofed UDP Attack
  • This is a spoofed flood in which the protocol is UDP and source address keeps changing.
• Spoofed ICMP Attack
  • This is a spoofed flood in which the protocol is ICMP and source address keeps changing.
• Spoofed TCP SYN-ACK Attack
  • This is a spoofed TCP flood in which SYN-ACK packets are sent in an anomalous state manner. Connections are not established prior to this through a SYN packet.
• Spoofed TCP FIN-Ack Attack
  • This is a spoofed TCP flood in which FIN-ACK packets are sent in an anomalous state manner. Connections are not established prior to this through a SYN packet.
• Spoofed IP Attack
  • This is a spoofed IP protocol flood. Packets may not necessarily be TCP, UDP or ICMP and can be any protocol.
• Spoofed IP Fragments Attack
  • This is a spoofed IP flood in which packets are fragmented - the fragment bit is set in the layer-3 IP header.
• IP-UDP Fragments Attack
  • This is a IP flood in which packets are fragmented - the fragment bit is set in the layer-3 IP header and packets belong to protocol 17 (UDP).
• IP-ICMP Fragments Attack
  • This is a IP flood in which packets are fragmented - the fragment bit is set in the layer-3 IP header and packets belong to protocol 1 (ICMP).
• TCP/UDP Destination Port Attack
  • This is a layer 4 flood in which packets attack either a TCP or UDP destination port.
• Spoofed TCP-SYN / UDP / ICMP Blended Attack
  • This is a blended attack in which source IP addresses are spoofed and at the same time, the protocol keeps changing as TCP, UDP and ICMP. The TCP packets are SYN packets.
• Non-Spoofed TCP SYN-ACK
  • This is a limited source layer 4 flood in which TCP SYN-ACK packets are sent continuously without a formal connection establishment.
• Non-Spoofed TCP SYN Attack
  • This is a limited source layer 4 flood in which TCP SYN packets are sent continuously without further sending more packets within the connection. The connections will stay on the server until they timeout from the SYN-state.
• Non-Spoofed TCP FIN-ACK Attack
  • This is a limited source layer 4 flood in which TCP FIN-ACK packets are continuously sent without establishing formal connections.
• Non-Spoofed TCP ACK Attack
  • This is a limited source layer 4 flood in which TCP ACK packets are continuously sent without establishing formal connections.
• HTTP Half-Connection Attack
  • Half-connections or embryonic connections are connections that have not completed. When such a SYN flood occurs on HTTP port (80), it is called HTTP half-connection attack. This is obviously a spoofed layer 4 attack.
• Non-Spoofed UDP Attack
  • This is a limited source layer 3 protocol flood in which the sources send IP protocol 17 - UDP packets. Remember that this would be a layer 4 flood if the UDP port is fixed in all the packets.
• Non-Spoofed DNS Attack
  • This is a limited source layer 4 flood in which the sources send UDP packets with destination port set to 53 which corresponds to DNS protocol.
• Non-Spoofed ICMP Attack
  • This is a limited source layer 3 protocol flood in which the sources send IP protocol 1 which corresponds to ICMP. Remember that this would be a layer 4 ICMP type and code flood, if a specific ICMP type and code is used in the attack packets.
• Non-spoofed TCP ACK Flood
  • This is a limited source layer 4 flood in which TCP ACK packets are continuously sent without establishing formal connections.
• Spoofed TCP ACK Flood
  • This is a spoofed layer 4 flood in which TCP ACK packets are continuously sent without establishing formal connections.
• Non-spoofed TCP NULL Flood
  • This is a limited source layer 4 flood in which TCP packets are continuously sent without establishing formal connections. These packets don't have any flags set in them and therefore have a header anomaly in layer 4 header.
• Spoofed TCP NULL Flood
  • This is a spoofed layer 4 flood in which TCP packets are continuously sent without establishing formal connections. These packets don't have any flags set in them and therefore have a header anomaly in layer 4 header.
• Non-spoofed TCP Random flag Flood
  • This is a limited source layer 4 flood in which TCP packets are continuously sent with randomly changing TCP flags. Due to the randomization, there may be a header anomaly in layer 4 header. Some flag combinations are illegal. Example of legal combinations are SYN-ACK, FIN-ACK. Examples of illegal flag combinations are SYN-FIN-RST-ACK, SYN-RST etc.
• Spoofed TCP Random flag Flood
  • This is a spoofed layer 4 flood in which TCP packets are continuously sent with randomly changing TCP flags. Due to the randomization, there may be a header anomaly in layer 4 header. Some flag combinations are illegal. Example of legal combinations are SYN-ACK, FIN-ACK. Examples of illegal flag combinations are SYN-FIN-RST-ACK, SYN-RST etc.
• TCP random sequence, ackknowledgement numbers
  • TCP is a connection-based stateful protocol to complete datagram oriented IP protocol which it uses as an underlying protocol. It uses sequence numbers and acknowledgement numbers to ensure proper windowing and end-to-end ordered delivery. Normally sequence numbers are randomly chosen in a given connection. Once chosen, they follow a discipline. In a random sequence or acknowledgement number attack, these numbers are randomly chosen and varied. It can confuse the receiving end-point stack.
• TCP Random window size
  • TCP is a connection-based stateful protocol to complete datagram oriented IP protocol which it uses as an underlying protocol. It uses windowing to break large application packets to ensure proper end-to-end ordered delivery. The window size determines the number of bytes of data that can be sent before an acknowledgement from the receiver is necessary. In a random window size attack, the window sizes are randomly chosen and varied. It can confuse the receiving end-point stack.
• TCP random option value
  • The TCP Options are located at the end of the TCP Header. These options have been used to enhance TCP protocol. TCP options include Maximum Segment Size (MSS), Window Scaling, Selective Acknowledgement (SACK), etc. In a random option value flood, the option values are changed randomly. Some of the combinations may be anomalous while some values may be anomalous too as they may be unassigned values.
• TCP random data length
  •  The length of TCP payload is dependent on the MTU (Maximum Transmission Unit) supported by the network, for normal ethernet the MTU  is 1500. This is the maximum amount of data available to IP, TCP, and the application, it excludes the bytes for the ethernet header and  trailer. From this 1500 you need to subtract bytes for the IP and TCP  headers (normally 20 bytes each) leaving 1460 bytes available to the  application. If the RFC1323 Timestamp option is used (fairly common  nowadays) it extends the TCP header by 12 bytes leaving 1448 bytes. In a random data length attack, the payload size is randomly chosen.
• TCP checksum error flood
  • TCP checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header.  This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. In a TCP checksum error flood, TCP segments with bad checksums are sent to overload the checksum validation logic.
• IP Random Identification flood
  • The IP-Identification (IP-ID) field value in the IP header is used to uniquely identify the fragments of  a particular datagram. Fragments of a particular datagram are assembled if  they have the same source, destination, protocol, and Identifier. The IP identifier field can have 65,536 different values. It is  important  for an operating system to have some sort of a mechanism in order to control  the identification numbers correctly. In this flood, the IP-ID file is randomly varied.
• IP Random fragment flag, offset flood
  
  • IP-V4 header has a field called Flags related to fragmentation. This 3-bit flag has a reserved bit followed by Don't Fragment (DF) and More Fragment (MF) bits. A flood that continuously varies the above bits can confuse network devices. Just after the flags, there is a 13-bit fragment offset field. A flood that continously varies this field can also cause confusion.
• IP Random TTL flood
  • 
    

    IPV4 header has an eight-bit time-to-live (TTL) field that helps prevent datagrams from going in circles on the Internet. Each packet intermediate network appliance that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and is discarded. This flood sends packets with random TTL values.




• IP random protocol
  

  • IPV4 protocol supports up to 256 protocol types. In this flood, the protocol field value is randomly changed while (may be) keeping rest of the packet header values similar.




• UDP checksum error
  • UDP header has a checksum field. By sending a wrongly computed checksum value, packets with anomalous header can be flooded on the network.



• Non-spoofed ICMP echo reply flood
  • ICMP echo request is typically used to identify the presence of a machine on the network. The machine responds with a ICMP echo reply. This flood that continuously sends ICMP echo replies to an IP address. The sources are non-spoofed.



• Spoofed ICMP Echo Reply
  • Unlike above, this flood uses spoofed IP addresses to send ICMP echo replies. 



• Un-spoofed ICMP Type/Code Flooding
  • ICMP allows 65535 combinations of type/codes. This is an un-spoofed flood from limited number of sources that randomly send a type/code flood.



• Spoofed ICMP Random Type/Code Flooding
  • This is a spoofed flood where a single but random ICMP type/code is flooded. Rest of the packet header may be similar in the packets.



• Non-IP Flooding
  • Ethernet header allows different protocols. IP version 4 or version 6 are just two of them. There are other protocols too. In a non-IP flood, un-common values of the protocol values are used.

  Conclusion

  There are many ways to test DDoS mitigation equipment. Conditions given above are just some examples. DDoS mitigation is a police and thief game. The hackers come up with new techniques and therefore the testers and equipment makers have to come up new techniques to test and benchmark the equipment. 

http://knol.google.com/k/how-to-test-a-ddos-mitigation-system