Flash Crowds

In this section, we explain how flash crowds are similar to DDoS in terms of the impact of congestion on a server but differ in their non-malicious intentions, as flash traffic consists of real legitimate requests. A Flash crowd is an unanticipated, massive and rapid increase in the popularity of a resource, such as a web page, that lasts for a short time. Flash crowd events such as popular webcasts like the Olympics, can be anticipated in advance and precautions can be taken (e.g. in the form of increasing resources for support). However, some flash crowds have no advance warning, such as the September 2001 terrorist attack in the United States, which saw popular news sites, for example the CNN, receiving a dramatic increase in the number of requests.

[62] studied the differences in the characteristics of flash events and DDoS attacks. In flash crowds, the client distribution is expected to follow the population distribution among ISPs and networks, and there is a significant overlap between the clusters of IP addresses a site sees before and during a flash crowd event. As a server gets slower during a flash crowd event, the per-client request rate is lower than usual. This indicates that legitimate clients are responsive to the performance of a server unlike DDoS attackers who generate requests without regards to the server’s load. In DDoS attacks, the client distribution across ISPs and networks does not follow the population distribution. The cluster overlap is also very small. In some DDoS attacks, they involve a few clients emitting very high request rates while some involve a large number of clients generating a low request rate, but in both cases, the per-client request rate is stable during the attacks and significantly deviates from

2. DDOS ATTACKS AND DEFENCES

There are several approaches to remedy the flash crowd problem. A straightforward but costly approach is to provide accessibility based on the peak demand. Another approach is the use of Content Distribution Networks (CDNs) [63-65] which are commercial solutions to help offload the request volume on Web servers by serving a subset of resources on behalf of a set of origin servers via an overlay network. Besides being used to improve routine access to Web sites, CDNs can also serve as insurance protection against flash crowd events so that Web sites can continue to function normally.

For sites such as non-profit organizations, the costly solutions stated above are not justifiable. These sites can then make use of publicly available and Internet-wide infrastructure supports such as widely distributed hierarchical Web proxies, caching networks [66], or peer caching via peer-to-peer overlays [67-69].

2.2

DDoS Defences

There are three categories of DDoS defences, namely prevention, detection and reaction/responses. Attack prevention measures attempt to protect a network or node from damage caused by an attack. Attack detection mechanisms attempt to determine the existence of an ongoing attack with low false positive and low false negative, and provide alerting signals to the response mechanisms. Response mechanisms act during an attack to mitigate it or trace down the attacker (possibly after an attack too) so as to reduce the impact of damage and to institute accountability. In the following subsections, we discuss the existing defence mechanisms. In addition, we introduce DDoS mitigation frameworks, which both detect and automatically respond to various forms of attacks.

2.2.1 Attack Prevention

Egress filtering [32] is a form of attack prevention measure. It performs filtering on outbound traffic and only allows packets with valid source addresses out from the network and into the Internet. This attempts to ensure that networks implementing egress filtering could not be exploited to being a participant in a DDoS attack. Widespread deployment will result in reduction of DDoS attack incidents where spoofed IP addresses are used. However, a way to bypass egress filtering would be to generate attack packets with spoofed IP addresses within the source network address range. D-WARD

2.2 DDoS Defences

[70] detects outgoing attacks and stops them by controlling outgoing traffic to the victim. The installation is done at the source router that serves as the gateway between the deploying network and the rest of the Internet. This router is configured with the set of valid local (source) addresses to perform egress filtering on outgoing traffic. The network flows and connections are also monitored over time to detect anomalies. A non-responsive foreign host may be an indication that it is overwhelmed by an attack, while an aggressive sending rate indicates that local hosts are likely participants in the attack. In [71], detection of DDoS attacks is performed at the source routers. Queries are sent to the destinations of outgoing packets and the response time is used to determine if an attack is on-going. Outgoing packets are then preferentially dropped for high-rate outgoing flows at the sources. However, with the high number of distributed zombies in a botnet [72, 73], a small amount of traffic generated by each of them would result in a successful attack while bypassing the detections. The motivation to deploy the schemes described above is not very high as it does not protect the networks themselves from becoming a victim of DDoS attacks, but instead they have to bear the cost of preventing their networks from carrying out attacks.

Ingress filtering [74], on the other hand, filters incoming traffic with invalid source IP addresses. These invalid source addresses include any internal IP addresses coming from external networks and any private or reserved IP addresses (for example, 192.168.*.*) [75]. This takes minimal effort to deploy and is a sensible way of blocking certain spoofed IP addresses with absolute confidence. However, the range of addresses that could be used by attackers for spoofing is still very wide. Therefore, even after removing the above-mentioned attack traffic, this scheme would still not be able to effectively prevent DDoS attacks. A feature module employing ingress filtering, developed by Cisco, works by modifying the Unicast Reverse Path Forwarding (URPF) [76]. When URPF checks the source address to ensure that the prefix exists in the router’s table, it also checks if the reverse route is on a real interface. If it’s not, the packet is dropped. The requirement is that URPF must be configured on the ingress interface of the perimeter router.

In the Source Address Validity Enforcement (SAVE) protocol [77], routers are being updated with the valid source addresses allowed to pass through their links. While a typical forwarding table specifies the outgoing interface for a given destination address space, a SAVE incoming table is built by specifying the valid incoming interface for a given source address space. Similar to existing routing protocols, SAVE constantly propagates messages containing valid source address information from the sources to the destinations. An incoming table is maintained for each interface on the router. This table associates the sets of valid incoming source addresses with each interface. SAVE shares the same

2. DDOS ATTACKS AND DEFENCES

idea as ingress filtering. However, it outperforms ingress filtering since it allows not only the filtering of the set of spoofed addresses in ingress filtering, it also learns from the periodic SAVE messages what are the additional spoofed addresses (that is, not in the list of valid addresses). The disadvantages of SAVE are the requirement for wide-spread deployment to be effective, as well as the modification to the routing protocols, which involves standardization issues which would take a long time to accomplish.

In StackPi [78], the complete Path Identifier (Pi) is encoded in each packet’s 16-bit Identification field while enroute to its destination. The 16-bit Identification field is divided to 8 sections. A 2-bit hash of each traversed router is computed and placed in the (Time-To-Live mod 8)th section of the Identification field. The victim stores the correct path indentifiers for particular source addresses and the information is used to detect and mitigate IP spoofing. However, fragmentation uses the ID field and it raises compatibility issues. If only non-fragmented packets are marked as suggested in [78], attackers could use fragmented packets to launch DDoS attacks. Due to the short length of the hash value, collisions would result in false negatives.

[79, 80] are attack prevention schemes. In Port Hopping [79], the server’s port numbers are changed dynamically as a function of time. Time is divided into discrete slots (for example, 0.5 sec was used as the slot size in the paper) and during different slots, different port numbers are used for the same service. When a client needs to communicate with the server, it will determine the server’s current port number using their shared secret and time slot number. When the server receives packets that have invalid port numbers, the packets can be quickly and easily filtered off during an attack (without the need to examine the contents of the packets). However, a shared secret would need to be established beforehand in the server and client pairs. In [80], randomization on TCP Retransmission Timeout (RTO) was proposed to counter low-rate TCP-targeted DoS attacks. As most operating systems in use today have a common base TCP RTO of 1 sec, attackers can inject periodic bursts of packets to fill the queue and force TCP connections to timeout. Therefore, with the randomization scheme, the attackers would not be able to perform the prediction of the next TCP timeout and carry out the attacks. This scheme however only caters for low-rate TCP attacks.

2.2.2 Attack Detection

TCP SYN flood detection [81] is a mechanism proposed to monitor the protocol behavior of the TCP SYN-FIN (RST) pairs. If the difference between the number of SYN and FIN (RST) packets

2.2 DDoS Defences

increases abruptly and exceeds a threshold, a DDoS attack is detected to be taking place. This mechanism is simple and robust as it is not necessary to maintain the state of each TCP connection (as maintaining state would degrade end-to-end TCP performance and subject the defence mechanism to DDoS attack). However, a way the attacker can defeat this scheme would be to send a mixture of TCP SYN and FIN packets to the victim.

MULTOPS [82] detects DDoS attacks by monitoring the packet rate on both the up and down links. The assumption is that the traffic in both directions should be similar during normal operations. Detection of a significant disproportionate difference would be a strong indication of an ongoing attack. However, traffic in both directions might not always be proportional. In certain applications such as video streaming or file downloading, one direction of the traffic is always much higher than the other. There is also a way the attacker could bypass the detection, and that is to launch attacks with spoofed addresses in one direction (towards the victim) and perform legitimate file transfer from the other to balance the traffic load in both directions.

It has been observed in [83] that by monitoring the number of arriving packets and representing it as a signal, the power spectral density of the signal for a normal TCP flow exhibits strong periodicity around its round-trip time in both directions, whereas DDoS attack traffic flows are not regulated in such a way. Therefore, spectral analysis could be used to identify DDoS attack traffic flows. However, this spectral analysis is only valid for TCP flows and not for connectionless protocols such as UDP and ICMP. The attackers could also “generate” reverse traffic as in the former case in MULTOPS detection, to bypass the detection.

DDoS attacks typically generate a large number of similar packets (for example, destination address, protocol type, packet’s data contents). Therefore, there is a great deal of similarity in the attack traffic pattern. Legitimate traffic flows, on the other hand, have many different and random traffic types, and are not highly correlated. Relying on these assumptions, an algorithm [84] based on the concept of Kolmogorov complexity, that states that the joint complexity measure of random strings is lower than the sum of complexities of the individual strings if the strings exhibit some correlation, was proposed to exploit the feature of DDoS attack traffic flows to perform detection. The strength of the scheme is that any type of DDoS attacks can be detected by agents using the same attack tool, which is typically the case. However, the attacker could bypass this scheme by breaking the correlation. This could be achieved for example by adding into agent code the functionality to randomly generate attack packets’ contents.

2. DDOS ATTACKS AND DEFENCES

Based on the strong correlation between traffic behavior at the victim and that at the attack source, a scheme [85] was proposed to proactively detect DDoS attacks using time series analysis. Firstly, the key variables are extracted from the victim (for example, number of ICMP Echo packets for ICMP flooding attack). Statistical tools such as the AutoRegressive model are then used to find the variables, which are highly related to the key variables, from potential attackers. A normal profile is then built of such variables found. Any deviation from the profile is a strong indication of an attack. A disadvantage of the scheme is that the detection is based on the features of known attacks. For DDoS bandwidth depletion attacks, it is not necessary for attackers to restrict the attack traffic type or packets’ contents. The attackers could also devise new types of attacks which would not be able to be detected by the scheme.

Based on the concept of human immunology, a Network Intrusion Detection System based on the architecture of an Artificial Immune System (ARTIS) was proposed [86]. The system named “Lightweight Intrusion Detection System” (LISYS) firstly forms an identity string from the IP packet (based on its contents). During the training period, all packets that occur frequently are considered as self (that is, normal). Detector strings are created based on self such that they do not match any self strings. Incoming packets are monitored and if the number of them matching the detector strings exceeds a threshold, it is an indication of an attack. However, as with all anomaly based detection schemes, it is not possible to capture all normal traffic behavior during the training phase. Legitimate traffic could therefore be classified as attack traffic, resulting in false positive.

2.2.3 Attack Responses

In this section, we discuss the DDoS attack response mechanisms classified into the following categories. - Traceback - Containment - Reconfiguration - Redirection - Filtering - Ratelimiting - Resource replication

2.2 DDoS Defences

- Legitimacy testing

- Attackers’ resource consumption

2.2.3.1 Traceback

An IP packet contains two addresses: source and destination. The destination address is used by the routing architecture to deliver the packet. The IP network routing infrastructure does not verify the authenticity of the source address carried in IP packets. The source address is used by the destination host to determine the source for a message reply. In general, no entity is responsible for the correctness of the source address. The scenario is the same as sending a letter using the postal service; the postal service does not care about the correctness or authenticity of the source address, it merely makes sure that the letter is delivered to the correct destination. Consequently, the design of the IP protocol and forwarding mechanism makes it difficult to identify the real origin of a packet. This characteristic of the Internet is exploited by DDoS attackers to hide their source and identity, using spoofed source IP addresses. Traceback mechanisms have been proposed to trace the true source of the attackers to institute accountability. Another need for traceback is to stop the attack at the point nearest to its source.

There are two main approaches to perform traceback: infrastructure schemes and end-host schemes. In the first approach, infrastructure scheme, the network is responsible for maintaining the traceback state information necessary for the victim and the network to construct the attack graph. The IP logging scheme belongs to this category. In the end-host scheme, the end hosts, which are the potential victims, maintain the traceback state information. IP marking and ICMP Traceback belong to this category.

In the IP logging scheme, the network routers log the passage of all IP packets. The key challenge here lies in the potential huge amount of information storage requirement. For example, if a router is to log all the packets in its entirety, each OC-192 link at 1.25 GB/s at the router requires 75 GB of storage for a 1-minute query buffer. The storage requirement quickly becomes prohibitive as the number of router links increases. One solution, SPIE (Source Path Isolation Engine) [87], has been proposed for IPv4. The mechanism is designed to identify the true source of a particular IP packet given a copy of the packet to be traced and an approximate time of receipt. In order to take care of the transformation of packets as they are routed from source to destination, the mechanism identified the

2. DDOS ATTACKS AND DEFENCES

(Type of Service), TTL (Time to Live), Checksum and Options field. The logging is based on the invariant portion of the IP header and the first 8 bytes of payload. Based on the statistics collected, the 28-byte prefix described above results in a rate of collision of approximately 0.00092% in a WAN environment and 0.139% in a LAN environment. To further reduce the storage requirement, instead of storing the entire 28-byte prefix, hashing is performed on it, followed by Bloom filter processing [88]. The scheme reduces the memory storage requirement in the router to 0.5% of link bandwidth per unit time.

In IP marking [89], the intermediate routers mark the IP packets with additional information so that the victim can use them to determine the attack path. Approaches proposed include node append, node sampling and edge sampling. The node append mechanism is similar to the IP Record Route Option [90], in that the addresses of successive routers traversed by an IP packet are appended to the packets. The victim can thus easily traceback the source of such attack packets. However, this method introduces very high overhead in terms of router processing and packet space. The node sampling approach reduces such overheads by the probabilistic marking of IP packets. The edge sampling approach, as its name implies, marks an edge of the network topology, traversed by the IP packets, instead of just the node. Most algorithms propose to put the marking information in the Identification field of the IP header. This type of mechanism has an inherent disadvantage in that it affects the format of IP packets, for example, the Identification field is used for fragmentation purposes. The standardization of the format for IP marking also becomes an issue.

In the ICMP Traceback mechanism [91], a new ICMP message type, ICMP Traceback (ITrace), is designed to carry information on routes that an IP packet has taken. As the IP Marking requires