Detection and Reaction against DDoS Attacks in

Telecommunications Engineers Option

Network Engineering

END OF STUDIES PROJECT REPORT

Theme

Detection and Reaction against DDoS Attacks in Cellular Networks By

Alaaedine Chouchane

Supervised by

Prof. Noureddine Boudriga

Work elaborated in The Communication Networks and Security Research Laboratory

Academic year: 2006/2007

To whom I’m eternally indebted, To my loving parents Ali and Zineb, I dedicate this work.

Acknowlegements

I am deeply grateful to my advisor, Professor Noureddine Boudriga, who has been such an amazing mentor. Enticing but not pushing, flexible but not lenient, he generously provided his time, effort and knowledgeable advice at all times. He possesses a rare talent to organize and steer students with advice rather than commands. I also would like to thank all members of the CN&S Research Laboratory for making me feel so at home. My thanks go especially to Dr. Slim Rekhis for reviewing the present report. I am eternally indebted to my loving parents. They readily and selflessly tried to provide the best conditions so to let me go ahead with my dream. I also want to thank my brother whose encouragement was one of the reasons of my success. And finally, I am grateful to my sister and I want to thank her for being my guide through my entire modest career.

Abstract

The scarcity of resources in wireless communications in addition to attackers’ experience in Internet denial of service make DDoS a challenging issue in cellular networks. In spite of the seriousness of the problem, research works in this issue are immature. CODERA (COoperative DEtection and Reaction Architecture) is our proposed architecture that aims to detect and react against DDoS and save network’s availability to legitimate users. This report depicts CODERA’s components and operations, specifies steps taken in updating the novel architecture and analyses its performance. Key words: Distributed Denial of Service (DDoS), Cellular Networks, CODERA.

Table of contents

Introduction…………………………………...………………………………......………...…1 Chapter 1: Distributed Denial of Service in Cellular Networks….……………….….……..4 I. Introduction............................................................................................................................... 5 II. DDoS in Internet: Principle, taxonomy and defense approaches ............................................ 5 II.1. Denial of Service (DoS) ................................................................................................... 5 II.1.1 Principle...................................................................................................................... 5 II.1.2 Types of DoS .............................................................................................................. 6 II.2. Distributed Denial of Service (DDoS).............................................................................. 7 II.2.1 Definition.................................................................................................................... 7 II.2.2 Principle of the attack ................................................................................................. 7 II.2.3 DDoS defense methods .............................................................................................. 8 III. DDoS attacks in cellular networks ....................................................................................... 10 III.1 DDoS attacks in 2G networks ........................................................................................ 11 III.1.1 Camping in false BTS ............................................................................................. 11 III.1.2 De-registration attack .............................................................................................. 12 III.1.3 Location-update request spoofing ........................................................................... 13 III.2 DDoS attacks in 2.5G networks: Internet SYN flood attack.......................................... 13 III.3 DDoS attack in 3G networks.......................................................................................... 15 III.3.1. Public servers’ abuse.............................................................................................. 15 III.3.2 Radio resources consumption.................................................................................. 17 III.3.3 Bandwidth attacks ................................................................................................... 19 IV. Conclusion ........................................................................................................................... 23 Chapter 2: CODERA: A COoperative DEtection and Reaction Architecture against DDoS in cellular networks….………………………………………………………………….…….24 I. Introduction............................................................................................................................. 25 II. Objectives of CODERA ........................................................................................................ 25 III. Architecture.......................................................................................................................... 26 IV. Detection and reaction to diverse types of DDoS ................................................................ 28 IV.1 Detecting 2G cellular DDoS attack: Camping in false BTS .......................................... 28 IV.2 Fighting a 2.5G attack: TCP SYN flooding attack ........................................................ 28 IV.3 Fighting 3G DDoS attacks ............................................................................................. 29 IV.3.1 Public servers’ abuse............................................................................................... 29 IV.3.2 Blocking radio channels.......................................................................................... 34 IV.3.3 Bandwidth attacks ................................................................................................... 36 V. Threshold-based and none-threshold-based defenses ........................................................... 41 VI Conclusion ............................................................................................................................ 42 Chapter 3: CODERA’s Extensibility………………………………………………………...43 I Introduction.............................................................................................................................. 44 II A unique definition for DDoS in the cellular concept............................................................ 44 II.1 Most common definitions of DDoS................................................................................. 44 II.2. Unique definition for DDoS ........................................................................................... 45 II.3 Taxonomy of DDoS attacks in cellular networks............................................................ 46

II.3.1. Consuming rare resources in cellular networks....................................................... 46 II.3.2 Disturbing public servers.......................................................................................... 48 III. Fighting all DDoS attacks in cellular networks ................................................................... 48 III. 1 A unique defensive model for DDoS attacks ................................................................ 48 III. 2 Defense operation in each kind of attack ...................................................................... 50 III.2.1 Resource consumption attacks ................................................................................ 50 III.2.2 Attacks aiming to disturb public servers ................................................................. 52 III.3 Learning a new defense.................................................................................................. 54 IV. Implementing the proposed model in CODERA ................................................................. 54 IV.1. Learning each class of attacks DDoS............................................................................ 54 IV.2. Implementation steps of a new defense ........................................................................ 55 IV.3 Example of integration of new defense.......................................................................... 57 V Conclusion.............................................................................................................................. 58 Chapter 4: Evaluation of CODERA’s Performance ……………………………………….59 I. Introduction............................................................................................................................. 60 II. CODERA’s performance....................................................................................................... 60 II.1. CODERA’s efficiency.................................................................................................... 60 II.1.1 Completely stopped attacks ...................................................................................... 60 II.1.2 Mitigated attacks....................................................................................................... 62 II.1.3 False reports.............................................................................................................. 63 II.2. Can CODERA induce network’s overload? ................................................................... 63 II.2.1 DefCOM defense against flooding attacks............................................................... 63 II.2.2 Defense against abusing telephonic server............................................................... 64 II.3 Security schemes of CODERA........................................................................................ 65 III. Simulation ............................................................................................................................ 66 III.1 Features of CODERA Simulator.................................................................................... 67 III.1.1 Simulated network................................................................................................... 67 III.1.2 Traffic generation.................................................................................................... 68 III.1.3 Input/output of Codera simulator ............................................................................ 70 III. 2 Simulation results.......................................................................................................... 73 III.2.1 Consuming radio channels ...................................................................................... 73 III.2.2 Abusing telephonic server....................................................................................... 75 III.2.3 Bandwidth attacks ................................................................................................... 78 III.2.4 TCP SYN flood attack............................................................................................. 80 IV. Conclusion ........................................................................................................................... 81 Conclusion……………………………………………..………………………………………82 Bibliography…………………………………………………………………………….…......84

Table of figures Figure 1.1: DDoS attack..................................................................................................................... 8 Figure 1.2: Camping in a false BTS................................................................................................. 12 Figure 1.3: Opening of TCP connection .......................................................................................... 13 Figure 1.4: Half open connection..................................................................................................... 14 Figure 1.5: Abuse of telephonic server ............................................................................................ 15 Figure 1.6: Call setup steps in UMTS .............................................................................................. 17 Figure 1.7: DDoS attack by radio resources consumption............................................................... 18 Figure 1.8: The UDP flooding is initiated by a single packet .......................................................... 20 Figure 1.9: Distributed UDP-flooding attack................................................................................... 21 Figure 2.1: Deployment of CODERA in the case of UMTS network ............................................. 27 Figure 2.2: The SYN-Proxy method against TCP SYN flood ......................................................... 29 Figure 2.3: Nodes involved in defense operations ........................................................................... 30 Figure 2.4: Algorithm implemented in the RIDS level.................................................................... 31 Figure 2.5: Algorithm deployed in the analysis server .................................................................... 33 Figure 2.6: Detection algorithm of resource starvation attack ......................................................... 35 Figure 2.7: Illustration of DefCOM operation ................................................................................. 38 Figure 2.8: Deployment of DefCOM in CODERA.......................................................................... 39 Figure 2.9: Our algorithm implemented in alert generators............................................................. 40 Figure 3.1: Generic model for defense operation............................................................................. 49 Figure 3.2: Generic algorithm for DDoS attacks that are based on consuming radio links............. 51 Figure 3.3: Generic algorithm for DDoS attacks that aim to disturb telephonic servers ................. 53 Figure 3.4 Implementation steps in each class of cellular DDoS..................................................... 56 Figure 3.5: Flooding the Iu interface................................................................................................ 58 Figure 4.1: Impact of partial deployment on the defense against telephonic server abuse.............. 61 Figure 4.2: Countering replay attacks using sequence numbers ...................................................... 66 Figure 4.3: Modeling circuit switched traffic with traffic vector..................................................... 68 Figure 4.4: Example of traffic vectors generated by Gaussian distributions ................................... 69 Figure 4.5: State transition diagram of a SGSN............................................................................... 70 Figure 4.6: Input/Output of CODERA Simulator............................................................................. 71 Figure 4.7: Evolution of the number of occupied channels through time........................................ 73 Figure 4.8: Impact of CODERA’s reaction in the availability of radio channels ............................ 73 Figure 4.9: Impact of the variation of calls rate threshold on the speed of the reaction .................. 74 Figure 4.10: Variable parameters is simulating abusing telephonic server...................................... 76 Figure 4.11: Number of calls handled by a telephonic server with capacity of 100 calls................ 76 Figure 4.12: Impact of tuning the calls rate threshold on the speed of the reaction......................... 77 Figure 4.13: Impact of tuning the number of attackers’ threshold on the speed of the reaction...... 78 Figure 4.15: Impact of the variation of the threshold on the number of reported attackers............. 80 Figure 4.16: Variation of the amount of memory occupation of the targeted server ....................... 81

Introduction

1. Wireless security and the problem of DoS: an overview With the growth of open and distributed mobile networks, security is becoming an extremely crucial issue. In fact, the widespread of cellular networks and their connectivity to Internet began to create untold numbers of security risks. Thus, security of mobile networks, especially cellular networks, is having day after day more interest by researchers and network operators. Through the evolution of mobile communication we distinguish different generations of wireless systems such as 1G, 2G, 3G and 4G. Every new generation offers more sophisticated services but also brings new vulnerabilities. In other words, the evolution of communication systems goes in parallel with the sophistication of attack tools and methods. Among the most critical security services that are targeted we find availability. In fact, keeping network services available for all subscribers is a primordial goal for operators. Denial of service attacks aim to deny network services for legitimate users. These attacks are among the most difficult to prevent, detect or defend against. Furthermore, the availability of attack tools is making the task easier for attackers. In spite of the gravity of the problem, no solution was proposed to fight DDoS in cellular networks. This can be explained by two factors. First, the problem is relatively recent with cellular networks, since the access to them was quite restricted in the second generation. But, with the openness of 2.5G and 3G networks to Internet the problem became more serious. In contrast, DoS and DDoS (Distributed DoS) in Internet is an ancient problem. Hence, numerous solutions were proposed to fight DDoS in computer networks. Second, the number of recorded attacks is still small. In fact, denial of service is more efficient in 3G networks, and, nowadays, deployed cellular networks are mainly 2G networks.

Introduction

2

Nevertheless, the migration to 3G networks makes the conception and implementation of a defense architecture a critical need. The aim of this work is to conceive a defense architecture called CODERA (COperative DEtection and Reaction Architecture) that can detect DDoS attacks and react against them. 2. Approach pursued in conceiving CODERA It is obvious that a cooperative architecture is strongly needed in protecting cellular networks from DDoS attacks which are growing day after day. From this perspective, we try in this work to conceive and simulate a complete architecture composed by defense nodes that are able to mitigate and stop, in some cases, the effect of DDoS. CODERA operations are divided into three classes. First, monitoring functions are continuously performed. Second, aggregation functions correlate different monitoring reports. Finally, depending on the judgment of the aggregation function, the suitable reaction is performed. Building CODERA passed by three steps. The first step is the theoretical study of vulnerability of cellular networks to denial of service. It includes the study of different attacks that occurred and those which are expected to happen in future. This study will be useful in further steps, since it gives an idea about network weaknesses and vulnerabilities. The next step is the choice of components that will be part of CODERA. This choice will be based on the topology of the network and the algorithm that will be implemented. Communication between different components will also be specified depending on the suitable defense. The last step is making CODERA extensible. In other words, we will propose a unique defense model for all attacks. This model will facilitate the update of CODERA in order to make it able to counter new attacks. 3. Outline of the report This report is organized in four chapters as follows: The first chapter illustrates the first step described above which consists in studying several characteristics of the problem of DDoS in the cellular concept. We start by describing the state of the art of the problem of DoS and DDoS in computer networks. Then, in the second part, we

Introduction

3

present different DDoS attacks related to cellular networks. The panorama of these attacks is organized into three classes according to the type of the targeted network (2G, 2.5G or 3G). The second chapter proposes a novel cooperative architecture able to detect and react against DDoS attacks in cellular networks that we called CODERA. First, it specifies the objectives of the proposed architecture. Then, it describes different components used in CODERA and their roles. Finally, the CODERA’s defense operations are detailed for each attack. In the third chapter, we illustrate the third step of the design of CODERA which is the extensibility of the new architecture. This chapter is organized into three sections. The first section will give a unique definition of DDoS. The second one will propose a defensive model that is applicable to any DDoS attack. In the third section we will apply this model in CODERA by giving several steps of the integration of a new defense. The fourth chapter studies the performance of the novel architecture. The evaluation includes two main sections. The first section addresses some performance properties of the architecture. In other terms, it analyzes performance schemes of CODERA which are efficiency, overload and security. In the second section, we present CODERA Simulator which is the simulator that we developed and we used to test CODERA’s efficiency.

CHAPTER 1

Distributed Denial of Service in Cellular Networks

Chapter 1: Distributed Denial of Service in Cellular Networks

5

I. Introduction Availability is one of the most important security services in fixed and wireless networks. For that reason, network operators and service providers are facing a real challenge given the strength and the sophistication of new generation of network attacks attempting to break availability. In addition, an increasing number of services and applications rely on the third generation of mobile networks today, not only for simple tasks but also for complex and critical ones. Along with this increasing reliance on them, new problems have appeared. DDoS attacks are famous attacks that first appeared with Internet. Then, with the increasing interest on mobile networks, there was a convergence toward networks that can offer mobility in addition to voice and data services. The immediate consequence of this progress is the inheritance of new generation networks of DDoS threats from Internet. In addition, attacks which are intrinsic to cellular networks create new security challenges. In this chapter, first we study the problem of DDoS as it first appeared in computer networks. Then we highlight the most dangerous DDoS attacks that threaten cellular networks. II. DDoS in Internet: Principle, taxonomy and defense approaches Distributed denial of service attacks are widely regarded as a major threat to the Internet. They have adversely affected service to individual machines, major Internet commerce sites, and even core Internet infrastructure services. In this section, first, we define Denial of Service (DoS) and Distributed Denial of Service (DDoS). Then, we describe techniques usually used to perform DoS and DDoS attacks. Finally, the last part depicts different approaches used in countering DDoS. II.1. Denial of Service (DoS) II.1.1 Principle Denial of service (DoS), as defined in [2], is an incident in which a user or an organization is deprived of the services of a resource they would normally expect to have. Typically, the loss


6

of service is the inability of a particular network service, such as e-mail, to be available or the temporary loss of all network connectivity and services. In the worst cases, for example, a Web site accessed by millions of people can occasionally be forced to temporarily cease operation. A denial of service attack can also destroy programming and files in a computer system. It is a type of security breach to a computer system that does not usually result in the theft of information or other security loss. However, these attacks can cost the target person or company a great deal of time and money. Because of the closed context of the original ARPANET, no consideration was given to denial of service attacks in the original Internet architecture. As a result, almost all Internet services are vulnerable to DoS attacks of sufficient scale. In most cases, sufficient scale can be achieved by compromising enough end-hosts (typically using a virus or worm) or routers, and using those compromised hosts to perpetrate the attack.

Such an attack is known as a

Distributed Denial of service (DDoS) attack. However, there are also many cases where a single well-connected end-system can perpetrate a successful DoS attack. II.1.2 Types of DoS As we have seen previously DoS attacks are one of the most serious problems in network security since attacks are easy to generate with automatic methods. These attacks can be classified according to the exploited weakness into four classes. •

Bandwidth consumption: In these attacks the attacker aims to deprive legitimate users from one of the most critical resources which is bandwidth. Even if the attacker has no access to a large bandwidth, he can amplify his attack by a distributed approach in order to overwhelm the victim network.

•

System resource starvation: These attacks focus on consuming system resources such as CPU time and memory. By consuming these resources in an excessive manner, they are deprived for legitimate system and user needs.

•

Exploitation of exceptional condition: These attacks exploit design and programming flaws that result in the failure of an application, operating system, or hardware device to


7

handle certain exceptional conditions. By inducing such conditions, the attack may slow down or disable the affected system. Some of the well-known attack techniques in this category involve sending malformed network packets to cause system crashes. •

Routing and Domain Name Service (DNS) manipulation: Routing-based DoS attacks involve malicious manipulation of routing table entries, causing network traffic to be improperly routed through the Internet. Attacks on DNS servers involve inducing these servers to cache bogus address information so that legitimate traffic is directed to the wrong IP addresses. Either kind of attack may prevent the victim from properly sending or receiving network packets, or cause the victim to be flooded with packets misdirected to its network [4].

II.2. Distributed Denial of Service (DDoS) II.2.1 Definition Aiming to deny services to legitimate users, DDoS have the same objective as DoS. But in this case the attack is stronger and more sufficient. We are talking about DDoS when the attack is generated by a huge number of terminals in order to improve the effectiveness of the attack. DDoS attacks are becoming one of the most dangerous threats in the Internet since they are too difficult to prevent, to detect and to react against. II.2.2 Principle of the attack In a DDoS attack, an attacker breaks into several machines, or coordinates with several entities, to launch an attack against a target machine or network at the same time. As shown in Figure 1.1, an attacker starts by breaking into weakly secured computers, using well known defects in standard network service programs and common weak configurations in operating systems. A cautious intruder will begin by breaking into just a few sites, then using them to break into some more, and repeating this cycle for several steps, to reduce the chance of being caught during this, the riskiest part of the operation. At the time of the attack, the attacker runs a single command, which sends command packets to all the captured machines,


8

instructing them to launch a particular attack against a specific victim. When the attacker decides to stop the attack, he sends another single command [3].

Figure 1.1: DDoS attack Because these attacks are coming from a wide range of IP addresses, it is much more difficult to block and detect because a small number of packets from each machine might escape from the IDS. If a single IP address is attacking a company, the company can block that address at its firewall. If it is 100 machine attacks, the problem becomes extremely difficult to alleviate [3]. II.2.3 DDoS defense methods Approaches to DDoS protection can be classified as network-based, source-based, or endpoint-based, according to where the defenses are deployed. In this section, we describe these general classes and provide examples of defenses in each class that are currently in use or


9

under investigation. Effective comprehensive DDoS defense will probably require implementing a combination of these methods. II.2.3.1 Network Based Defense The goal is to protect as much of the network infrastructure as possible, by reducing congestion in communication links caused by attack traffic flows. These flows start as large numbers of relatively small flows from individual flooding agents. The small flows successively join into larger and larger flows as they approach the intended victim and in many cases overwhelm the capacities of one or more links along the way to the victim. Intermediaries in the network, such as routers, switches, and firewalls can be used to monitor network conditions as well as take defensive action when necessary. A complete network based approach to DDoS prevention will require network operators and ISPs to have a thorough understanding of end-to-end network congestion and choke points, and to make a coordinated response to a DDoS attack. The ideal response will be to block traffic as close to the attackers as possible. Thus, the ability to locate the sources of attack traffic is a crucial component of effective network based defense. Network based solutions to DDoS prevention are most effective against bandwidth consumption and possibly network wide routing attacks. The problem of coordination among independent administrative domains presents a significant obstacle to comprehensive network-based defense today. Some limited, and not entirely effective, forms of network based DDoS defense are in use today. Rate limiting and quality of service mechanisms are used to limit the bandwidth allocated to certain classes of traffic, such as the ICMP and UDP messages used in some DDoS attacks, at the expense of dropping some legitimate messages. Ingress filtering, in which any packet whose source addresses does not fit the network address of the interface it arrived on, can provide partial protection from some forms of source address spoofing [4]. II.2.3.2 Source Based Defense Source based DDoS defense approaches attempt to prevent attack traffic at or near its source, before it enters the Internet core. In many cases, it is easier to identify attack traffic near the


10

source; for example, spoofed packet source addresses are easier to detect within the originating network since the range of legitimate addresses for outgoing traffic is known there. The most widely deployed form of source based defense today is egress filtering, in which an organization blocks any outgoing traffic from its network whose source address does not match the organization’s assigned address range. This is accomplished with access router and firewall filters. When deployed close to an attacker, this can greatly restrict the degree of source address spoofing that is possible. Most security-conscious network operators do use egress filtering; unfortunately, most network operators today are not security-conscious. Since egress filtering is far from universal, attackers can selectively deploy their agents on the many networks known to have no egress filtering. Furthermore, in large networks, this filtering must be deployed at many points within the network to be most effective, and this imposes additional administrative costs. II.2.3.3 End Point Based Defense End point based solutions look at DDoS prevention primarily from the perspective of the end-points (servers) that need protection. The approach here is to pursue localized protection on the server itself, or at potential choke points (bottlenecks) in front of servers, without any network-wide or systemic collaboration. End point based DDoS solutions can be effective against localized bandwidth consumption attacks, as well as against attacks based on system resource starvation and exceptional condition exploitation of individual systems. III. DDoS attacks in cellular networks Denial of Service (DoS) attacks are now a prominent issue due to their ability to disrupt services and communication infrastructure. With the appearance of new network architectures and services the problem of denial of service becomes more general. In fact, telecommunication service providers are not only providing connectivity but also mobility. One of the most popular mobile networks are cellular networks. As we will see in this section, DoS and DDoS present a serious threat to cellular networks throughout their three generations. Over


11

the last few years, DoS attacks have evolved from a nuisance to a real and constant threat. In order to enhance the efficiency of DoS attack, attackers generally use distributed mechanism. It is obvious that DDoS can be a real threat in cellular networks given the increasing computational power and network bandwidth. Two significant events have already occurred. First, in the summer of 2000, the first preliminary virus against mobile phones appeared [5]. The second event was the emergence of the first DDoS attack tool toward mobile phones, known as the SMSflooder [6]. It tries to use the wired Internet to attack a wireless victim. The two events mentioned above show that the DDoS attack directed towards the mobile networks is not only a theoretical possibility, but also a real and evolving threat. However, research in this issue is still immature. In addition, the problem of DDoS existed since the second generation of cellular networks and it grows with 2.5G and 3G networks. Hence, this section details the main DDoS attacks in 2G, 2.5G and 3G. III.1 DDoS attacks in 2G networks Security designers of 2G networks did not foresee the problem of denial of service. Indeed, 2G security mechanisms were mainly consecrated to preserve secrecy and authentication. Although, DoS and DDoS present a real threat to the availability of these networks. In this subsection we describe denial of service attacks specific to 2G cellular networks. III.1.1 Camping in false BTS The GSM standard has encryption as an option only. This flaw is not dangerous by itself, but because a MS does not authenticate the BTS, it can be used for eavesdropping. An attacker can purchase base station equipment and set up a BTS of his own with encryption turned off. MS will connect to attackers BTS, if it has the characteristics of the operator and a better signal than the best of "real" base stations. The spoofed station sits between MS and BTS forwarding (and intercepting) all traffic between them without either one knowing that it is there. The attacker could send a "busy" signal to the MS each time it wanted to place a call and "forget" to forward any calls to the MS. Also, it is possible for the BTS to respond to a service


12

request on the RACH with a message forbidding the mobile station to access the channel within a specified time. This attack can be considered as denial of service since it denies legitimate users from using the network.

Figure 1.2: Camping in a false BTS

III.1.2 De-registration attack This attack exploits the weakness that the network cannot authenticate the messages it receives over the radio interface. When a legitimate user wants to detach his mobile from the network, he can simply turn off his phone or remove his SIM card. Then the MS sends an “IMSI detach” message to the networks. The problem consists on the fact that the network cannot authenticate this message. In other words, an intruder gain access to the network and cause user de-registration. The network deregisters the user from the visited location area and instructs the HLR to do the same. The user is subsequently unreachable for mobile terminated services.


13

III.1.3 Location-update request spoofing This attack requires a modified MS and exploits the weakness that the network cannot authenticate the messages it receives over the radio interface. Instead of the de-registration request, the user spoofs a location update request in a different location area from the one in which the user is roaming. The network registers in the new location area the target user which will be paged in that new area. The user is subsequently unreachable for mobile terminated services. III.2 DDoS attacks in 2.5G networks: Internet SYN flood attack One of the most famous DDoS attacks is SYN flood attack. Besides, the 2.5G networks architectures such as GPRS are designed to accommodate some Internet services, including informative service, job dispatching, messaging services, etc. The principle of the SYN flood attack and the damage that can cause are depicted in this section.

Figure 1.3: Opening of TCP connection An attacker takes advantage of vulnerability in the TCP protocol design to perform a TCP SYN flooding attack. A TCP session starts with negotiation of session parameters between a requesting party (a client) and a server. The client sends a TCP SYN packet to the server,


14

requesting some service. In the SYN packet header, the client provides his initial sequence number, a unique per-connection number that will be used to keep count of data sent to the server (so the server can recognize and handle missing, reordered or repeated data).

Figure 1.4: Half open connection During a TCP SYN flooding attack, attackers generate a multitude of half-open connections. These requests quickly exhaust the server’s connection buffer space, and the server can accept no more incoming connection requests. Established TCP connections usually experience no degradation in service. In rare cases, the server machine crashes, exhausts its memory or is otherwise rendered inoperative. In order to keep buffer space occupied for the desired time, the attacker needs to generate a steady stream of SYN packets toward the victim (to reserve again those resources that have been freed by timeouts). No simple filtering rule can handle the TCP SYN flooding attack because legitimate traffic will suffer collateral damage.


15

III.3 DDoS attack in 3G networks III.3.1. Public servers’ abuse III.3.1.1 Vulnerability of mobile handsets to viruses and worms As more consumers begin surfing the Web and sending e-mail messages on cellphone and hand-held devices, along comes a new worry: worms and viruses spread via Internet-enabled handsets.

Figure 1.5: Abuse of telephonic server The problem is still small, with only a few cases reported globally [1]. But as operating systems in cellphones become standardized, hackers will probably begin focusing on vulnerabilities in those systems as they have with personal computers. And as cellphones and


16

personal digital assistants (PDAs) connect to the Internet at ever faster speeds, more users will be able to download files with attachments some of which may be infected. "The danger to mobile phone networks is probably five times bigger than with personal computers because very few people are focused on this problem now," said Andrew Cole, consultant specializing in telecommunications issues [1]. III.3.1.2 Principle of the attack The main purpose of a DDoS attack is making a public server enable to provide services to legitimate users. A telephonic server can be a typical target of such a DDoS attack. Among aimed servers we find emergency numbers. As we have seen, the threat of viruses and worms concerns not only computer networks but also cellular networks. So, the intruder can make a large number of cellphones simultaneously call a voice server or a highly solicited number such us companies numbers. The principle of this attack is similar to traditional DDoS and is illustrated in the Figure 1.5. First, the attacker, who can be an Internet user, breaks into weakly secured cellphones by means of warms and viruses. Then, he sends command packets to all the captured handsets, instructing them to dial the number of the targeted server. As telephonic servers have limited capacities, with a sufficient number of manipulated handsets, the target will be immediately blocked. In 2001, a malware delivered by e-mail spread among Japanese mobiles. As the e-mail was read by the user, the malware dialed the police emergency number and forced the national emergency hotline to shutdown [1]. The effect of this attack relies on the capacity of the targeted server, the number of zombies and the duration of the attack. If the server can treat N simultaneous calls, an attack performed by the aid of N or more zombies can completely shutdown the victim throughout the time of the attack. An attacker must manipulate a sufficient number of weakly secured phones in order to perform an efficient attack.


17

III.3.2 Radio resources consumption In wireless communications, the radio interface is shared between all users. Because of shared radio spectrum, communication can be interfered by competing users or other equipments. Consequently, communication links in wireless networks are scarce resources. Since a DDoS attack aims to deny the availability of network resources and radio links are among the most critical resources, availability of these links can be targeted. First, we will describe the typical scenario for the preliminary part of a mobile originated call in UMTS. Then, we will precise how the attacker can exploit the scarcity of radio resources to generate a DDoS attack. Different steps of call setup originated from the user equipment (UE) are as follow: First, the User Equipment (UE) is continually listening to the BCCH channel in order to get system information.

UE

Node B

MSC/VLR

RNC

System Information (BCCH) Connection Request (CCCH) Radio Link Setup Request Radio Link Setup Response Connection Setup (CCCH) Connection Managment Service Request

CM Service Request

CM Service Response Authenticaton messages Radio Bearer Setup

Figure 1.6: Call setup steps in UMTS


18

When the user desires to make a call, a connection request message is sent to the RNC via the Node B in the CCCH channel. Then, a radio link is set up by the Node B. After that, the connection management setup is performed. Next, after the authentication procedure and the radio bearer setup, the communication takes place. The taxation begins when the called user picks up. A DDoS attack that is based on consumption of radio resources is performed as follows: The attacker, which can be a mobile phone or a computer, breaks into weakly secured mobile phones using diffusion messages. The intruder will begin by breaking into just a few sites, then using them to break into some more, and repeating this cycle for several steps, to reduce the chance to be caught during this, the riskiest part of the operation.

Figure 1.7: DDoS attack by radio resources consumption At the time of the attack the attacker runs a single command, which sends command packets to all the captured User Equipments that are called “zombies”. Then all zombies begin, at the


19

same time, the call setup procedure of Figure 1.6. All steps are executed normally until the allocation of a radio link. After that, each zombie stops the communication. This procedure is repeated during a long period of time. Consequently, with sufficient number of zombies in each cell the network can be broken down for a long period since all radio links are continuously consumed by zombies. Sufficient number of manipulated phones is required in order to ensure the efficiency of the attack. Let N the number of simultaneous calls that the Node B can manage. N depends on the extent of the cell and the capacity of the Node B. Let Nm the mean number of carried calls. By breaking into at least (N - Nm) zombies in the same cell, the attacker can completely block the access in this cell. III.3.3 Bandwidth attacks In a bandwidth consumption attack, an intruder directs a large number of packets towards the network, thereby consuming all the available bandwidth and stopping legitimate packets from accessing the congested network link. There are two major impacts of bandwidth attacks. The first is the consumption of the host's resources. Generally, the victim could be a web server or a proxy connected to the Internet. The victim has limited resources to process the incoming packets. When the traffic load becomes high, the victim will drop packets to inform senders, which consist of both legitimate users and attack sources, to reduce their sending rates. Legitimate users will slow down their sending rates while the attack sources will maintain or increase their sending rates. Eventually, the victim's resources, such as CPU and memory, will be used up and the victim will be unable to service legitimate traffic. The second impact is consumption of the network bandwidth, which is more threatening than the first. If the malicious flows are able to dominate the communication links that lead to the victim, then the legitimate flows will be blocked. Therefore, not only the intended victim of the attack is disabled, but also any system which relies on the communication links of the attack path. Although a congested router can control the traffic flow by dropping packets, legitimate traffic will also be discarded if there is no clear mechanism to differentiate legitimate traffic from attack traffic.


20

Since third generation mobile networks allow packet switched communications, various types of DDoS attacks are inherited from the Internet network. In addition, bandwidth is very limited in a mobile network, so cellular networks inherited, from Internet, many DDoS attacks which basically affect bandwidth. In this section we detail the principle of two types of DDoS attacks that target bandwidth and are inherited by 3G networks. The first attack exploits the weakness of the UDP protocol and the absence of flow control. The second is based on the ICMP protocol. III.3.3.1 UDP flood The User Datagram Protocol (UDP) is a connectionless protocol that does not have flow control mechanisms, i.e., there is no built-in mechanism for the sender and receiver to be synchronized to adapt to changing network conditions. The UDP flood is a type of bandwidth attack that uses UDP packets.

Figure 1.8: The UDP flooding is initiated by a single packet


21

Since UDP does not have flow control mechanisms, when traffic congestion happens, both legitimate and attack flows will not reduce their sending rates. Hence, the victim is unable to decide whether a source is an attack source or legitimate source by just checking the source's sending rate. Moreover, unlike TCP, UDP does not have a negotiation mechanism before setting up a connection. Therefore, it is easier to spoof UDP traffic without being noticed by the victim. Figure 1.8 gives an example of how a single spoofed UDP packet can initiate a never-ending attack stream. The attacker sends a UDP packet to victim 1, claiming to be from victim 2, requesting the echo service. Since victim 1 does not know this is a spoofed packet, it echoes a UDP packet to victim 2 at port 7 (echo service). Then victim 2 does exactly the same as victim 1 and the loop of sending echo requests will never end unless it is stopped by the external source. This attack can be performed in a distributed manner when the objective is denying the access to a public server. Used with sufficient number of zombies, this attack can completely make the targeted public server break down. Attacker

Victim 1.1

Victim 1.2

Victim 1.3

Victim 1.4

Spoofed UDP packet with src@=victim2 Victim 2

Figure 1.9: Distributed UDP-flooding attack

Never-ending stream of UDP packets


22

III.3.3.2 ICMP Flood The Internet Control Message Protocol (ICMP) is based on the IP protocol and is used to diagnose network status. An ICMP flood is a type of bandwidth attack that uses ICMP packets. On IP networks, a packet can be directed to an individual machine or broadcast to an entire network. When a packet is sent to an IP broadcast address from a machine on the local network, that packet is delivered to all machines on that network. When a packet is sent to that IP broadcast address from a machine outside the local network, it is broadcast to all machines on the target network (as long as routers are configured to pass along that traffic). IP broadcast addresses are usually network addresses with the host portion of the address having all one bits. For example, the IP broadcast address for the network 10.*.*.* is 10.255.255.255, and for the network 10.50.*.* is 10.50.255.255. Network addresses with all zeros in the host portion, such as 10.50.0.0, can also produce a broadcast response. The smurf attack is a type of ICMP flood, where attackers use ICMP echo request packets directed to IP broadcast addresses from remote locations to generate denial of service attacks. There are three parties in these attacks: the attacker, the intermediary, and the victim (note that the intermediary can also be a victim). First, the attacker sends one ICMP echo request packet with a spoofed address (which is the address of the victim) to the network broadcast address and the request is forwarded to all the hosts within the intermediary network. Second, all of the hosts within the intermediary network send the ICMP echo replies to flood the victim. Solutions to the smurf attack are discussed in [8], which include disabling the IP-directed broadcast service at the intermediary network. The aforementioned protocol bandwidth attacks utilize TCP, UDP, and ICMP traffic respectively, which are commonly observed in the Internet. All these attacks are based on the spoofed IP addresses and take advantage of the vulnerabilities of the Internet protocols. Actually, many 3G operators allow the use of diagnostic protocols like ICMP. Whereas, it is obvious that these protocols have their vulnerabilities that can lead to dangerous DDoS attacks and cause meaningful damages. In fact, cellular networks interfaces have limited bandwidth if we compare it to Internet. Thus, targeting 3G network by ICMP flood is an easier task. Consequently, a defensive mechanism must be implemented in order to counter these attacks.


23

IV. Conclusion Most of definitions of DDoS treat the issue as a problem linked to computer networks. Nevertheless, the problem is becoming more general as it touches telecommunication networks. In fact, cellular networks inherited many vulnerabilities from Internet. In addition, there are new weaknesses linked to wireless medium. For that reason, we started in this chapter by studying denial of service in Internet. Then, we described different attacks that can target cellular networks. In the next chapter, we will propose a novel architecture that is composed by various defense components in order to mitigate and, in some cases, stop the effect of DDoS attacks.

CHAPTER 2

CODERA: A COoperative DEtection and Reaction Architecture against DDoS in Cellular Networks

Chapter 2: CODERA: A COoperative DEtection and Reaction Architecture against DDoS in cellular networks

25

I. Introduction DDoS attacks are a virulent type of Internet attacks; they have targeted some biggest web sites on the world - owned by the most famous E-Commerce companies such as Yahoo, eBay, Amazon – which became inaccessible to customers, partners, and users. The financial losses are very huge. It didn’t stop there. The hazard of DDoS is now threatening cellular networks more aggressively since resources are scarcer in these networks. For Internet, many defense approaches were proposed and commercialized. Nevertheless, since the problem is relatively recent for cellular networks there is a lack in research propositions. Spread of 3G mobile networks and absence of suitable solutions make the problem more critical day after day. In this chapter, we will present a novel COoperative DEtection and Reaction Architecture in order to fight DDoS attacks in cellular networks. II. Objectives of CODERA Securing cellular networks from DDoS becomes a challenging issue. Indeed, the problem will be more critical with next generation networks. Yet, to date there is no developed mechanism that can detect and react against DDoS in cellular networks. As we have shown, there is a critical need to such a mechanism since cellular networks are gaining an exponential spread all over the world. That is why, we suggest an architecture called CODERA. Its goals are: •

Detecting DDoS attacks generated by mobile equipments regardless if they attack the access network or the core network.

•

Detecting attack floods that come from Internet

•

As soon as detection nodes detect an attack, the reaction should be so rapid that the effect becomes insignificant.

•

After the reaction, CODERA should take suitable preventions that allow the attack not to succeed thereafter.

In addition, in order to obtain a good defensive mechanism it must fulfill some specifications. First, CODERA must have the security features that allow it to be secured from attacks that


26

attempt its normal functioning. Secondly, this architecture should be light. In other words, traffic generated by CODERA entities should not overload the network. Finally, this solution should be robust. That means that it works properly even in abnormal conditions like congestion of the network or deterioration of propagation conditions. To conclude, the proposed solution must be light, fast and efficient. III. Architecture CODERA is a defense architecture that utilizes diverse algorithms so as to fight diverse types of DDoS attacks. The architecture of CODERA is depicted in Figure 2.1 and consists of: • Radio Intrusion Detection Systems (RIDS) that are implemented in the Node B level. These IDSs have a real-time monitoring of the radio interface. That’s why we have called them “Radio IDSs” or RIDSs. They are able to analyze all the traffic carried in signaling channels and traffic channels. A RIDS can operate either as an autonomous system or as a participant in a distributed defense system. In autonomous operation, it detects attacks and responds to them without communication with any other entity. In distributed cooperative operation, the RIDS enhances its detection by receiving attack alerts from other participants. •

Analysis servers: These nodes are deployed in the RNC level. They have two major roles. The first is to monitor all traffic that pass through the RNC and the second is to aggregate detection reports that are collected from correspondent RIDSs. Analysis servers are the heart of the detection operation in Distributed IDSs they receive reports from detection agents in order to decide on the existence of the attack. In fact, the advantage of DIDS is the ability to detect attack patterns across an entire corporate network, with different locations. This could allow for the early detection of a well-planned and coordinated attack against the organization in question.

•

Rate limiters: there are reactive nodes able to reduce the aggressiveness of packets that pass through. As we will see later, rate limiters are useful when countering attacks based on overwhelming the victim by useless packets.


•

27

Classifier nodes that perform selective rate-limiting. They differentiate between legitimate and attack packets, dedicate their available bandwidth to legitimate traffic and cooperate with other defense nodes to ensure good service for the legitimate clients. Note that classifier functionality encompasses rate limiter functionality. Also note that the traffic differentiation does not need to be perfect. As long as the classifier node respects its rate limit, it can choose to send any traffic it deems important for its users.

VLR

RNC

RNC

RNC MSC

MSC

VLR

SGSN

SGSN SGSN

SGSN

GGSN GGSN

RIDS Rate limiter Classifier Analysis server

Figure 2.1: Deployment of CODERA in the case of UMTS network


28

Since not every component in the network will be a defense node, CODERA is designed to be effective in partial deployment. The system provides a significant level of defense for potential targets with only a few defense nodes deployed, and becomes more effective as more defense nodes are added, protecting a larger community. So the question here is how these components can detect and react to the widely different types of DDoS. The answer to this question is the subject of the next section. IV. Detection and reaction to diverse types of DDoS Since DDoS attacks that threaten cellular networks have diverse kinds, different algorithms must be deployed in CODERA nodes. In order to make CODERA able to counter attacks of different types, we propose several algorithms that can perform detection and suitable reaction. In addition, we take some algorithms developed to counter some DDoS attacks in Internet. IV.1 Detecting 2G cellular DDoS attack: Camping in false BTS As we have seen in the last chapter, the scenario of this attack requires a malicious BTS that is able to transmit signals with high power. The objective of this operation is to attract maximum of mobile phones to the false BTS. Since RIDSs are intrusion detection systems that can monitor all radio signals in the radio interface, they will capture powerful signals that come from a malevolent BTS. When such a signal is detected, the cell where the malicious operates is naturally known. Finally, security managers can perform transmitter’s localization to localize the false BTS. IV.2 Fighting a 2.5G attack: TCP SYN flooding attack In SYN Flood attacks, attackers send so many connection requests to one server so that end users cannot connect to it. Because attackers can easily put servers into a denial of service state this way, it is reported that about 90% of all DDoS attacks are SYN Flood attacks in the case of Internet network [7]. And now the danger passes to cellular networks. So CODERA must be equipped with a defensive mechanism that can insure immunity of the network against these attacks.


29

Figure 2.2: The SYN-Proxy method against TCP SYN flood Since the problem is not new in computer networks there are many proposed solutions. These mechanisms are candidate solutions to be introduced in CODERA. One simple method to tackle SYN-Flood attacks is called SYN-Proxy. It was proposed by authors of [7]. We propose to introduce the SYN-Proxy in the RIDS level. This node has a list of secured servers. Its role is to respond to the acknowledgements of SYN packets on behalf of secured servers, and to pass SYN packets only when the proxy receives the third packet in the TCP handshake. Consequently, attack packets are automatically dropped. If the server do not answer by a SYN/ACK, the RIDS will send a RST message that will cancel the connection. IV.3 Fighting 3G DDoS attacks IV.3.1 Public servers’ abuse As we showed in the previous chapter, this attack is based on overwhelming the targeted telephonic server by a huge number of simultaneous calls. Since the capacity of a telephonic sever is limited, with an efficient number of zombies, the attacker can totally block the access to this server.


30

Only RIDSs and analysis servers are involved in this case as shown in Figure 2.3.

RIDS

RNC

Analysis server

Figure 2.3: Nodes involved in defense operations IV.3.1.1 Main idea In the case of servers’ abuse, RIDSs are the nearest nodes to attackers. In addition, sourceend defense provides two very important features. First, it places the response close to the sources, thus relieving targets from the attack as soon as possible. Moreover, it provides a selective response, minimizing collateral damage to legitimate traffic. Both of these features make source-end defense highly attractive for integration in CODERA response to servers’ abuse. Then again, RIDSs cannot take the decision on the existence of the attack, since it is often distributed in different cells. The basic idea of detection in this case lies in continuously monitoring all users. Monitoring function is achieved by RIDSs; they perform a real-time computing of the rate of calls generated by every mobile equipment to each secured telephonic server. If there is a sufficient number of attackers in the same cell, that means that their rates exceed a threshold, a report is sent to the analysis server of Figure 2.3. Then, the analysis server aggregates different reports and cooperates with other servers to decide on the existence of the attack and then choose the suitable reaction. The detection and reaction operations are depicted with details in the next sections.


31

Call Attempt From i to j

Drop i from La

Compute Rij

False

Rij > RTh True

Add i to La

False

Nj > NTh True

Send a report to the Analysis Server

i ∈ users in the current cell j ∈ servers to be secured Rij : Calls rate from i to j RTh : Threshold rate La : List of probable attackers Nj : Number of attackers aiming the victim j NTh : Number threshold

Figure 2.4: Algorithm implemented in the RIDS level IV.3.1.2 Detection operation As we depicted previously, in each cell there is a RIDS who controls the behavior of clients. In addition, the RIDS disposes of two lists. The first is a static list L1 that contains numbers of telephonic servers that must be secured from probable attacks. The second is a dynamic list L2


32

that enclose identifiers of users located in the actual cell of the RIDS. As well, each RIDS have a counter CAij for each pair of cell phone and secured server where i ∈ L2 and j ∈ L1. At a given time t, CAij is the number of calls originated from i toward j. The time t counter is set to zero every T1 seconds and incremented in each call attempt from i to j. So the calls rate of i toward j is Rij = CAij / t computed in calls per minute every new call attempt. After that, if Rij is greater than a threshold RTh, the user i is added to an attackers list denoted by La. In the opposite case, the user i is retrieved from the list La. Then the number of attackers for each target is checked. If there is a sufficient number of attackers who aim the same victim, a report is sent to the analysis server. The idea here is that the attack would be insignificant when performed by few attackers. In other terms, if there is no sufficient number of mobiles that want to call the server simultaneously we can not judge on the existence of the attack. This algorithm is depicted in Figure 2.4. In the RNC level, the analysis server is in charge of collecting different reports from RIDSs. Using a specific algorithm, the analysis sever can judge on the existence of a server’s abuse attack. We define our algorithm detailed in Figure 2.5. The idea of the algorithm consists in using two thresholds (Th1 >Th2) for the value of the number of collected reports in a given period T2. If the number of reports gathered in the current period exceeds Th1, it is enough for the analysis server to assume the existence of the attack. Yet, if the number of reports is between Th1 and Th2, it will check other analysis servers and ask them about the number of reports collected in the current period. Then, the sum of all reports is computed. If it exceeds the threshold Th1, CODERA presumes that involved users are performing the attack in question and passes to the reaction phase. To conclude, the detection is performed by the analysis server with the cooperation of different RIDSs. The decision may even require the resort to adjacent analysis server. It depends on the degree of distribution of the attack. In other words, when the server collects a sufficient number of reports concerning a targeted victim, it will consider that the number of attackers will suffice to organize a significant attack. In this case the attack is not very distributed. The other scenario consists in a number of reports that is not enough to pass to the reaction phase. Thus, CODERA will realize that the attack could be well distributed.


33

Receive a detection report

Increment Nj’

Nj’ >Th1

True

False

False

Nj’ > Th2 True Consult other servers and compute Nj’’

Nj’’ > Th1

True

False Assume the absence of an attack

Reaction phase

j ∈ servers to be secured Nj’ : Number of reports considering the server j ( set to zero every T seconds) Nj’’: Sum of reports collected by all analysis servers Th1, Th2: Thresholds

Figure 2.5: Algorithm deployed in the analysis server Then the analysis server will ask other servers about the number of collected reports considering the victim in question. Finally the decision will be taken depending on the total number of reports.


34

IV.3.1.3 Reaction phase As soon as the attack is detected, involved attackers will be immediately detached from the network in order to stop the effect of the attack. The analysis server sends the list of attackers to the Home Location Register (HLR). Then, the HLR mark them as infected and detach them. As detailed in the last chapter this attack is generally deployed using a worm or a virus. The objective is to manipulate a maximum number of vulnerable mobile terminals in order to perform a strong distributed attack. So the most efficient reaction of defensive mechanism is to secure vulnerable mobiles that participated in the attack by providing the appropriate patch. IV.3.2 Blocking radio channels The principle of this attack was detailed in the previous chapter. It aims to consume one of the most critical resources in a cellular network which is radio links. As shown in the last chapter, this attack is basically performed with the aid of viruses in order to insure a heavy effect on radio resources. So the typical defense against this attack is to prevent the spread of such viruses. The task is impossible since the network is opened to various types of networks. Consequently, a defending mechanism is requisite. In addition, our proposed architecture is supposed to defend cellular networks from various natures of DDoS. So we tried to implement a defending mechanism in order to make CODERA able to counter this attack. Since the attack takes effect in only the current cell of the manipulated attacker, the detection operation should be performed locally in this cell. Consequently, only the correspondent RIDS is involved in this case. IV.3.2.1 Main idea A Radio Intrusion Detection System aims, as any ordinary IDS, to find signs of intrusion and then to generate suitable reaction. But, its distinctive characteristic is its position close to mobile users. This feature allows RIDS to be the most suitable defense node in the case of radio resources starvation since it have a direct access to the radio interface. It was shown previously that this attack is based on flooding the base station by uncompleted communications. The effect of this behavior will be significant when performed by a large number of mobile terminals in the same cell.


35

Call Attempt From i

Uncompleted

False

True Increment Ci

Compute Ri

False Ri > RTh True Add i to attackers’ list False N > Th True Reaction phase

i ∈ users in the current cell Ci: Counter of incomplete calls Ri : Incomplete calls rate originating from i RTh : Threshold rate N: Number of attackers in the list Th: Threshold

Ri = Ci /t

Figure 2.6: Detection algorithm of resource starvation attack Our novel approach is to carry a counter for each user in order to detect any abnormal behavior that can lead to radio starvation. This counter presents the number of incomplete call attempts.


36

IV.3.2.2 Detection operation In order to detect this type of attacks the Radio IDS must have a continuous observation of all radio channels. The detection algorithm is very simple and efficient. In each RIDS we implement the algorithm of figure 2.6. The RIDS holds a counter Ci for each user of his cell. This counter presents the number of uncompleted call attempts generated by the user i. This counter is set to zero every T seconds. The detection of abnormal behavior of the user i is timebased. In other words, the RIDS compute the rate of unfinished call attempts Ri=Ci\t where t is the time and is set to zero every T seconds. The anomaly is detected when the rate Ri exceeds a threshold Rth. Users with abnormal behavior are noticed in a list. When the number of attacker is sufficient to block the access in the current cell (N>Th), the attack is detected. IV.3.2.3 Reaction When the RIDS detects the attack, the response must be so rapid that the attack becomes insignificant in a short time so as to preserve good services to legitimate users. The reaction here is similar to the case of public servers’ abuse attack. The RIDS, detaches automatically the attacker from the network by sending a message to the HLR. To conclude, in this case the detection is performed by a simple algorithm based on call attempts rates. And, the reaction is so rapid and efficient that the effect of the attack vanishes in few seconds and may be countered before it has any consequence. The performance of CODERA will be discussed with details by simulation results. IV.3.3 Bandwidth attacks As shown in the previous chapter, the attacker in a bandwidth consumption attack directs a huge number of packets toward the victim. Many solutions were proposed to counter this type of attacks in Internet network. So our strategy is to choose one of defense mechanisms that exist in the literature and try to adapt it to the cellular concept. IV.3.3.1 Main idea A resource starvation attack can be performed using any kind of available techniques. In last chapter, we spoke about UDP-flood and TCP-flood attacks. Whereas, these attacks are based


37

on the same strategy: flooding the victim by huge streams of useless packets. In addition, other techniques are used to target bandwidth, and, surely there are others that will appear. Consequently, it will not be practical to perform a defensive mechanism to each attack. Our approach is to propose a generic detection and reaction mechanism that can counter and mitigate various types of attacks which target networks bandwidth. Since the problem of DDoS is relatively old in Internet, many mechanisms were developed in order to trace and limit the effect of such attacks. We find two major types of defenses: (1) simple defense which performs a simple protection node which is generally a router or a firewall and (2) distributed defenses which uses a network of protection nodes that cooperate in order to detect and drop attack packets. Experiments proved that cooperative defense offers better results [8]. IV.3.3.2 DefCOM: a defensive mechanism against bandwidth consumption attacks One of the most efficient defending mechanisms is the DefCOM solution (Defensive Cooperative Overlay Mesh) which is detailed in [8]. DefCOM is based on an overlay network composed by three types of nodes: (1) Alert generators which detect the attack and send alert messages to other nodes, (2) Rate limiters and (3) Classifiers which distinguish legitimate packets from malicious ones. When the alert generator AG detects the attack it floods the rest of the overlay network by ALARM messages containing the victim’s address. Then, a traffic tree that contains nodes of the overlay network that observes traffic to the victim is built. Each classifier of the traffic tree stamps every packet. Two stamps can be used to mark packets: HIGH stamp and LOW stamp [9]. As detailed in [9], each rate limiter first reclassifies each incoming packet based on its current stamp and the aggressiveness of the node that forwarded this packet. Then, resource allocation and rate-limiting are performed in order to allocate most bandwidth to HIGH stamped packets. The remaining bandwidth will first be offered to the LOW stamped traffic, and any leftovers will be used to forward unstamped traffic. The overall effect of packet stamping is the differentiation between three traffic classes and the service offered to those classes. Whereas, DefCOM does not specify a method for the detection of the attack [8]. It simply uses an alert


38

generator near the victim but authors of [8] do not mention how can this node detect the attack. It is basically a reactive solution.

Overlay Network

Legitimate 1

Attacker 1 Victim

Legitimate 2 Alert Generator Rate Limiter

Legitimate 3 Attacker 2

Classifier

Figure 2.7: Illustration of DefCOM operation [8]

Thus, in order to obtain a complete solution we propose our algorithm that should be implemented in the Analysis Server level and makes it able to detect attack floods. IV.3.3.3 Implementation of DefCOM in CODERA Since 3G cellular networks have packet switched backbone, packet flooding attacks are not only a theoretical danger but they present a real hazard to these networks. Also, one of the main goals of CODERA is to counter flooding attacks. As we have seen, many solutions were proposed in computer networks. In fact, there are many candidate technologies that can be introduced to our solution. We chose DefCOM because it offers a generic solution to various types of flooding attacks. As depicted in the last section, alert generators must be introduced near threatened networks or severs. Yet, in a cellular network the most vulnerable components are interfaces between the


39

RNC and the Node B. Using sufficiently large streams of packets adequately targeting this interface the “community” of attackers can completely deny Internet services to all users camped in besieged cells.

VLR

RNC

RNC

RNC MSC

MSC

VLR

SGSN

SGSN SGSN

SGSN

Rate limiter

GGSN GGSN

Classifier Alert Generator

Figure 2.8: Deployment of DefCOM in CODERA So, alert generators should be introduced in the RNC level. That is why we suggest that Analysis servers play the role of alert generators in the operation of detection of flooding attacks. In addition, we notice in the DefCOM solution that rate limiters have a partial deployment in the backbone of the Internet network (Routers). Besides, the backbone of the cellular network is composed by SGSNs. Hence, the suitable site to introduce rate limiters is SGSNs. Finally, the principle source of packet floods is Internet since attack tools are more


40

sophisticated and available in computer networks. So classifiers must be introduced in Internet gateways (GGSNs).

III.3.3.4 Detection and reaction steps Detection operation DefCOM presents a good cooperative mechanism to fight flooding attacks. Yet, this solution is short of the detection mechanism that allows the alert generator to take the decision [8]. So, we propose our algorithm that allows it to do so.

Packet issued from i

t=n*T Empty the list

True

Check the list of senders

i ∈ SL False Add i to the list with Ci=0

Increment Ci

(a) Filling senders’ list

False N>Th True Pass to the reaction phase

(b) Detection of aggressive floods

SL: Senders’ list Ci: counter of packets originating from i N: number of users whose the Ci exceeds Cth Th: Threshold

Figure 2.9: Our algorithm implemented in alert generators


41

The alert generator must continuously monitor the behavior of senders of all packets that pass through it. Since the attack packets are more aggressive than legitimate ones, we choose to perform a rate-based mechanism. In other words the anomaly is detected when there are many senders that target the local RNC by a packet rate greater than a fixed threshold. The proposed algorithm is depicted in Figure 2.9. First, the alert generator must hold a counter for each source of sent packets during the current period T. As depicted in the part (a), the alert generator uses a list that contains IP addresses of senders and the correspondent number CPi of packets originating from i. In every instant t=n*T, all values of CPi are compared to a threshold CPth. If there is a sufficient number of senders whose counter exceeds the threshold, the attack is detected. And the alert generator passes to the reaction phase. This operation is shown by the part (b) of figure 2.9. Reaction operation After the attack is detected, the analysis server will issue an attack alarm message containing his identifier and send it to all rate limiters and classifiers. The rest of the operation is exactly the same as DefCOM in Internet network. A traffic tree is built. It contains nodes which relay packets to the alert generator that detected the attack. Then, rate limiting is performed as depicted in VI.3.3.2. V. Threshold-based and none-threshold-based defenses The majority of detection mechanisms used in CODERA are threshold-based. That is, user’s behavior is quantified by a metric such as the number of calls per minute or the number of generated packets. In this case, when the metric exceeds the threshold set by the administrator, the user is considered as an attacker. However, in some cases, no thresholds are needed in the defense operation. For example, with the TCP SYN flood attack, the defense is preventive: it is not founded on the detection of abnormal behaviors. So it is classified as none-threshold-based defense. Besides, with the false BTS attack, the defense is based on a continuous monitoring of the radio interface. When a malicious signal is detected, the reaction is immediately performed.


42

To conclude, CODERA’s defense mechanisms are not only threshold-based. Defense algorithms are quite various and it use deferent methods to detect attackers and preserve network’s availability. VI Conclusion In this chapter, we proposed a novel protective architecture for cellular networks. The novel architecture’s role, members and algorithms are demarcated with a description of its different components. This architecture includes many algorithms that allow it to perform cooperative detection and reaction against diverse types of DDoS. With attacks that are inherited from Internet we tried to adapt existent solutions to the cellular concept. Yet, for intrinsic vulnerabilities we proposed our own solutions.

CHAPTER 3

CODERA’s Extensibility

Chapter 3: CODERA’s Extensibility

44

I Introduction Fighting DDoS is a real challenge in computer networks since these attacks have extremely various natures. With the convergence of telecommunication and computer networks the problem becomes more delicate with cellular networks. In the first chapter, we have depicted existing DDoS attacks that threaten cellular networks. Then, in the second chapter, we proposed a novel architecture called CODERA that is able to detected and react to these attacks. From the operator’s point of view, there is a need to a generic solution that can counter various types of DDoS. This solution must embody different defense algorithms and be easily updated to counter new types of DDoS. In this chapter, our objective is to make CODERA able to learn future DDoS attacks that can threaten cellular networks. To this end, we first depict a unique definition that is valid for all kinds of DDoS. Then we try to give taxonomy for various attacks. After that, in section three, we define a generic model for defense against DDoS in a cellular concept. Finally, we adapt this model to CODERA in order to guarantee its ability to learn future attacks. Roughly speaking, this chapter proposes an enhancement to CODERA’s functionalities making it able to adapt new attacks. II A unique definition for DDoS in the cellular concept While members of research community have long been aware of existence of Distributed Denial of Services DDoS, there is no unique definition for the problem. Indeed, no explicit definition of DDoS seems to exist in the cellular concept. Different authors, either in presenting possible attacks or examining real ones have identified a number of different methods of denying service across the network. In this section we try to depict the most common definitions of DDoS. II.1 Most common definitions of DDoS Each published view of cellular denial of service is somewhat different. Some authors view the problem in terms of resource consumption and locate it in end systems rather than in network devices. Others examine the effects of propagation of malicious information or routing updates.


45

Nevertheless, the problem in computer networks is relatively old. That is why, numerous researchers tried to understand different aspects of DDoS in Internet network. Besides, the problem of DDoS seems to have the same philosophy with cellular networks. Hence, we try to study various definitions of DDoS given by organisms and researchers. One definition given by the CERT (Computer Emergency Response Team) is:” A denial of service attack is characterized by an explicit attempt by attackers to prevent legitimate users of a service from using that service.”[11] This definition depicts the objective of such attacks regardless the manner by which the attack is generated. However, we need a precision in defining the problem with its different aspects such as utilized techniques and attack strategies. An other definition which is specified by the US-CERT (United States Computer Emergency Readiness Team) describes DDoS as “An attack that successfully prevents or impairs the normal authorized functionality of networks, systems or applications by exhausting resources. This activity includes being the victim or participating in the DoS.”[12] This definition touches only the problem of resources consumption, while DDoS is a widely larger problem. In addition to definitions given by organisms, research community offers various definitions to DDoS. One definition, given by authors of [13] gives a more technical view to the problem “In an Internet DDoS attack, compromised hosts of security unaware users are usually remotely controlled and organized by an attacker into a so called amplifying network of masters and agents. They are then misused to carry out attacks on few or just a single host. Such attacks can also be targeted at core Internet infrastructure components such as routers, central services (e.g. domain name system) or low to medium bandwidth links.” This definition treats specific DDoS aspects, and, it is not valid for all DDoS attacks. Ultimately, we found in research literature and organisms documents a variety of descriptions of DDoS attacks. Although, no definition fit exactly to the cellular concept, since vulnerabilities are quite different. II.2. Unique definition for DDoS To summarize all proposed definitions, we propose the following definition for Internet DDoS attacks: “A DDoS attack is a cooperative operation performed by a set of user


46

terminals in order to deny legitimate users from using network services. As well, attackers can be unaware of the operation when they are manipulated by one or more attackers.” This definition is as general as it can touch different attack manners, techniques and targets. Indeed, it is also suitable to cellular networks. Since the network architecture is quite different with mobile cellular networks, the problem has its specific features. First, user terminals are not the same with cellular 2G or 3G networks. A user equipment has clearly less sophisticated computing and storage capacity. So, organizing a DDoS attack requires more effort with cellular networks, since more compromised “zombies” are needed. Secondly, even legitimate users have the same weakness. They are easily deprived of network resources. Finally, the last key word of the definition proposed above is network services. We notice that network services are different in fixed and wireless networks. Even, the same services are provided by different techniques. To recapitulate, we can give the following definition that better fits the cellular network: A DDoS attack is a malicious operation generated by a set of mobile terminals in order to deny legitimate mobile users from using network services. This can be performed by consuming cellular scarce resources or exploiting protocols’ and architecture’s vulnerabilities. Taxonomy for cellular DDoS attacks will be the subject of the next section. II.3 Taxonomy of DDoS attacks in cellular networks The definition given above is sufficient to make a taxonomy of cellular DDoS attacks. As shown in Table1, two major types of DDoS can be used. First, we find attacks that are based on consuming network’s resources. Second we find attacks that exploit protocols’ vulnerabilities in order to disturb network’s normal working. II.3.1. Consuming rare resources in cellular networks Cellular network’s architecture is quite different from computer networks. In addition, the cellular concept is strongly linked to wireless communications. These two facts make cellular networks extremely dependent to the needed resources. Radio links The limited availability of radio spectrum is always the bottleneck in a wireless network.


47

Even if license-free RF bands are used and micro-cell and pico-cell technologies are employed to expand transmission rates, it is still a scarce resource as the number of users and the demand for bandwidth increase. Technological research on wireless bandwidth allocation and admission control relies on stochastic theories, assuming that users will not use their devices all at the same time. With cellular networks, this resource is scarcer, since frequency band is standardized. That’s why, radio links are becoming typical targets to DDoS attacks.

Scarce resource consumption

Disturbing public servers’ functioning

Consuming radio links

Abusing telephonic servers

Consuming bandwidth

Abusing computer servers

Table 1: Taxonomy of cellular DDoS attacks Bandwidth Another aspect in connection with resource starvation attacks is targeting data bandwidth. Tens of millions of cellular phones, laptops and PDAs are expected to use wireless connections to access the Internet in the near future. Although transmission rates in wireless networks are much lower than those in wired networks, potential DDoS attacks are still feasible if large population of mobile units are involved. Thus, wireless data packet traffic is a potential avenue for DDoS attacks. Indeed, in the packet switched part of the network, the scarcest resource is bandwidth since links have their limited capacity to handle data packets. Examples of attacks that aim this weakness are flooding attacks. In such attacks, interfaces with limited capacity are targeted by huge floods of packets maliciously generated by attackers.


48

II.3.2 Disturbing public servers Telephonic servers Since telephonic servers are reachable by mobile terminals they become targeted by DDoS attacks. One of the famous attacks that aimed a telephonic server is the DDoS attack described in the last chapter. This attack was generated by infected mobile terminals and succeeded to flood the emergency number in Japan. Computer servers In the vein of Internet DDoS, computer servers that provide services to mobile clients can be targeted by the same attacks seen in the Internet case. So, the danger of these attacks is clearly virulent especially when we take a look in the history of Internet DDoS and the damage that it caused. III. Fighting all DDoS attacks in cellular networks In order to facilitate CODERA’s updates, we present a unified defense approach that is applicable for all types of DDoS. First, we define a unique model to DDoS defense mechanisms. Then, we depict how could this model trace back the attack and perform the suitable reaction. Finally, we implement this model to CODERA. III. 1 A unique defensive model for DDoS attacks As we have shown in the introduction of this chapter, our objective is to make CODERA able to counter future DDoS attacks with minimum updates. Our strategy is to comprehend the phenomenon of DDoS as a general issue regardless of specific used techniques. To this end, we defined in the previous section the problem of DDoS. In this section, we define methods that are useful to defend cellular networks from DDoS. Once, a DDoS attack is always coupled with an abnormal behavior of users or data flows. As a result, the monitoring function will be handled in all cases. In fact, monitoring users’ behavior is a key strategy in capturing attack attempts. Whereas, monitoring in the end user side is not sufficient in packet switched attacks. Consequently, the monitoring function must be implemented in the access network and core network. Secondly, since DDoS attacks gain their efficiency from their distributed aspect, defense mechanism must also be performed in a


49

distributed manner. For that reason, sensors must be distributed through different parts of the network. In some attacks, one sensor can take the decision and pass to the reaction phase. In other cases, the output of a set of sensors must be aggregated in order to judge on the existence of the attack. To summarize, the defensive mechanism must embody three major functions: the monitoring function, the aggregation function and the reaction function.

Monitoring functions

Aggregation functions

Reaction functions

Figure 3.1: Generic model for defense operation Monitoring function In a DDoS attack detection, the shutter release of the operation is the observation of abnormal behavior or irregular traffic flow. Hence there is a vital need to monitoring functions in order to trace all malicious behaviors. This function consists in continually surveying users’ behavior and data flows. The detection of attackers can be taken at this stage, when no aggregation is needed. Aggregation function In most DDoS attacks, results of traffic and users’ behavior must be collected and studied as an aggregate in order to decide if the attack exists really. That is why the aggregation function is strongly needed. In other words, components that are equipped with this function will be able to decide on the existence of a DDoS attack due to the output of monitors.


50

Definitely, this function is needed in both cases of resource consumption and servers’ abuse attacks. Reaction function Once the detection is completed, the defensive mechanism must immediately react in order to counter the attack as fast as possible. The reaction can have different forms depending on the type of the attack. III. 2 Defense operation in each kind of attack The proposed model is supposed to be useful in defending all existent and future DDoS attacks. Hence, this section discusses each class of DDoS attacks of Table 1, and how could the proposed model fit to these attacks. III.2.1 Resource consumption attacks Consuming radio links As shown in the section II.3.1, these attacks aim to consume scarce radio links and deny legitimate users from accessing to the network. The detection operation in this case is performed as follow: Components of defense architecture, that are endowed with monitoring functions, are continuously supervising the radio interface. They insure the control of all users’ behavior. An abnormal behavior is detected referring to a specific criterion. It depends on the technique used to generate the attack. Each user with abnormal behavior is marked as probable attacker. Then, the aggregation function play its role by taking a decision based on the number of attackers involved in the operation and eventually other parameters. After that, if all required conditions are filled, the reaction phase is performed. In the reaction operation, all involved attackers are detached from the network. The algorithm given in Figure 3.2 presents a generic defense operation that is valid to all radio resources consumption attacks. Each stage of the algorithm must be parameterized with the specific technique used in the attack. Again, parts of the proposed model are shown in the algorithm.


51

Consuming bandwidth Since bandwidth is a critical resource in packet switched services, consuming available bandwidth in network’s links will immediately deprive legitimate users from accessing to packet switched networks like Internet. Our proposed defensive model responds to these attacks using its three previously described parts with the three operations listed below. First, monitoring functions will not survey users’ behaviors but it will analyze streams of data packets. Diverse criteria could be used to detect malicious traffic that aims to block network’s data links. It depends on the type of the attack. Yet the most common criterion is traffic aggressiveness (i.e. packets’ rate).

Monitoring users’ behavior False

Monitoring functions

Abnormal behavior True Mark the user as a probable attacker Aggregate monitoring results

Aggregation functions Sufficient number of attackers

Reaction functions

False

True Reaction phase

Figure 3.2: Generic algorithm for DDoS attacks that are based on consuming radio links


52

After that, aggregation operation is performed. It’s typically based on collecting information reported from diverse sensors distributed through the network. Yet, in this type of attack this step can be optional if the anomaly is detected near the flooded link. Finally, the reaction phase is performed in order to mitigate the effect of the attack and alleviate the pressure on the attacked link. Details will be shown in the last section of this chapter when implementing the learning model in CODERA. Since this type of attacks can be performed using various techniques, no unique algorithm can be defined. III.2.2 Attacks aiming to disturb public servers Telephonic servers’ abuse Telephonic servers appeared with fixed telephonic networks before the emergence of mobile networks. So, no security dangers were noticed until the connection of PSTNs with mobile networks. Since the first attack mentioned against these servers [Chapter 2], securing emergency numbers and other public servers were became a critical issue in network’s security. In fact, attackers’ abilities are growing day after day. Hence, with sophisticated attack methods telephonic services can be abused and denied to legitimate users for long periods. For that reason our solution must not be limited to the attack mentioned in the previous chapter. We try to give a generic defensive algorithm that is applicable to all techniques that could exist. As depicted in Figure 3.3, the defensive algorithm is based on the model of Figure 3.1. First the monitoring function is continually performed. Since our solution is implemented in the cellular network and the detection is naturally faster near the source, monitoring functions will be implemented the nearest possible to the source of the attack (i.e. mobile terminals). As well, in some cases aggregation function is not needed to judge on the existence of the attack. Hence, correlation is optional for some attacks. In the algorithm shown in Figure 3.3, two steps are obligatory, and one step is optional. First, monitoring modules perform continues observation of all calls generated toward servers to be secured. Then, calls characteristics (such as rate, duration etc) are compared to the profile of attack calls. If the test is positive, the next step is dependent on details of the attack that we do not specify. If the monitor’s result are sufficient to be sure of the existence of the attack no


53

aggregation will be needed. Finally, the suitable reaction will be performed in order to lighten the effect of the attack.

Monitoring calls toward telephonic servers False Calls match with Attack’s profile True False

Aggregation Is needed True Aggregate monitoring results True False

Collective behavior matches with attack’s profile

True Reaction phase

Figure 3.3: Generic algorithm for DDoS attacks that aim to disturb telephonic servers Abusing computer servers In this attack, computer servers are the principle aim. Since attacks in this case are extremely various, there is no unique defense to DDoS that aim a computer server. Nevertheless, we specify the main strategy in defending against this attack. First monitoring functions will be performed near the target since attackers are from quite various sides. Secondly, aggregation functions will be done using messages between several actors. Finally, reaction is performed by the component that detected the attack (Dropping some packets, limiting packets’ rate…).


54

III.3 Learning a new defense As we said previously, the objective of this chapter is to enhance CODERA’s ability to counter various types of attacks. Our strategy here is to make it able to learn new attacks with minimum human intervention. In order to reach this aim we specify the learning operation step by step. First, security managers must be aware of new DDoS attacks that threaten their network. When they learn about a new attack, they must: 1. Classify the attack and assign it to one of the four classes listed above. 2. Choose the components of the reaction architecture that will be involved and assign each one to the appropriate part of defense model depicted in Figure 3.1. 3. Implement the suitable parameters in each level so as to make monitoring, correlation and reaction mechanisms up to date with the new attack. IV. Implementing the proposed model in CODERA In the previous chapter, we showed the reaction of CODERA to specific DDoS attacks. Our purpose now is to make it extensible for new DDoS attacks. That is why; we first define DDoS as a general issue. Then we proposed a taxonomy for DDoS attacks in the cellular concept. After that, we specified a general model of defense against cellular DDoS. And, we depicted, the defense operation for each type of attack. In this section we implement the proposed model in CODERA in order to make it easily updated. First, we precise learning operation of each class of attacks with CODERA. Secondly, we depict details of implementation of a new defense with a network that already deploy CODERA’s defenses. Finally, we treat an example of how to update CODERA with a defense against a new attack. IV.1. Learning each class of attacks DDoS Since DDoS attacks can be launched by various techniques, we tried to classify them into four major classes. So we define here the learning operation of each class of DDoS attacks. We don’t specify the exact operation but we try to simplify the update as much as possible. Consuming radio resources We proposed in section II.2.2.1 a generic algorithm useful in countering radio resource consumption attacks this type of attacks. So we specify here how CODERA components can integrate this algorithm.


55

Since, in CODERA’s architecture, RIDSs are close to the radio interface (in the BTS level), they are the typical components of the architecture that can perform monitoring function in the case of countering radio consumption attack. Thus, in the algorithm of Figure 3.2 the three first steps, are hold by RIDSs. Secondly, every set of RIDSs is connected to one analysis server. So this server will be in charge of the aggregation function. Again, the decision on the existence of an attack can be taken by one analysis server or with collaboration of other analysis servers. Finally, the component which detects the attacks will immediately detach the attackers from the network. Consuming bandwidth In this type of attacks, bandwidth is the typical target, since networks interfaces are capacity-limited in terms of bandwidth. Thus, sensors will analyze data traffic. In our architecture (CODERA), components involved in the monitoring operation against these attacks are analysis servers and classifiers. These actors are in charge of surveying traffics behavior. Also, the anomaly is detected when one of the characteristics of data streams satisfies a specific criterion such as data rate or content. Nevertheless, the decision can require the aggregation of collective information from different sensors. It depends on the technique of the attack. Then rate limiters and classifiers will perform the reaction function. Abusing telephonic server In the case of telephonic servers’ abuse, the circuit switched part of the network is touched. So, the attack will not come from the Internet side. Like depicted in section II.2.1, monitoring functions will be more efficient when performed near the attacker. A RIDS is close to mobile users so monitoring functions will be integrated in the Radio Intrusion Detection System. In addition, it can take the decision and pass to the reaction phase. But, in some cases aggregation is needed. Since analysis servers can correlate reports collected from different RIDSs, they will be in charge of the aggregation function. Finally, the component of CODERA that detects the attack will perform the suitable reaction. IV.2. Implementation steps of a new defense When a new DDoS attack appears, security managers must immediately update CODERA’s complements in order to counter this attack. This chapter aims to make the


56

update as simple as possible without any change in CODERA’s architecture. In this section we specify different steps that must be taken in order to integrate the new defense. When a new DDoS attack appears, the first step is to classify it in one of the four classes described in section II.3. After that, the correspondent defense mechanism is performed. When we are talking about consuming radio resources, the algorithm of Figure 3.2 is needed. New attack Classify the attack

Radio resources consumption

Bandwidth consumption

Telephonic server’s abuse

Computer server’s abuse

Implement calls monitoring in each RIDS

Allow analysis servers or rate limiters to monitor data traffic

Allow monitoring calls toward public servers

Introduce new monitoring rules in the RIDS level

Integrate aggregation functions in Analysis severs if needed

Precise messages useful in correlating monitoring results

Integrate aggregation functions in Analysis severs if needed

Specify messages to be exchanged to perform reports’ correlation if necessary

Allow the component that detects the attack to detach attackers from the network

Release classifying functions and rate limiting operations

Detach involved users from the network

Perform rate limiting or other reaction operation

Figure 3.4 Implementation steps in each class of cellular DDoS So we should describe the behavior of an attacker in order to make RIDSs able to detect abnormal behavior. In other words, criteria of detection must be specified. Then we must know if the aggregation is needed. If it is the case, the update will touch the analysis sever and the exact threshold will be set. In this case, the immediate reaction is detaching attackers from the network.


57

Nevertheless, in the case of consuming bandwidth parameters to be adjusted are somewhat different. First, according to the technique of the attack, new monitoring functions should be set in analysis servers or classifiers. After that, if the attack is well distributed, decision will be taken by aggregation. So, messages that must be transmitted must be specified. Finally, the right reaction must be configured in the rate limiter and classifier level. When the attack is classified as a telephonic server’s abuse attack, security administrators must set the monitoring criterion that enables RIDSs to differentiate legitimate from malicious calls. Lastly, in computer server’s abuse the monitoring function will be implemented in the RIDS level. Also, if the correlation is needed, we must specify messages to be exchanged between several analysis servers. Then the reaction operation will be setup in rate limiters or analysis servers, it depend on the attack. All of these steps are depicted in the diagram of Figure 3.4. IV.3 Example of integration of new defense In order to materialize the procedure of implementing new defense we considered a new DDoS attack that was not stated in the last chapter. And, we integrate it in CODERA using the procedure described above. This attack aims to break down capacity limited UMTS interfaces. In other words, since bandwidth is quite limited in UMTS interfaces, a huge number of attackers try to exploit this scarcity by generating floods of attack streams toward the Iu interface between he the RNC and the SGSN. The integration in this case will be as fellows: 1. This attack is clearly a bandwidth attack. 2. Rate limiters integrated in SGSN level will be in charge of the monitoring functions. When a congestion is detected in one of the Iu interfaces the rate limiter will work as an intrusion detection systems. More precisely, it will monitor all packets toward the congested Iu interface and detect aggressive users. The detection does not need an aggregation since it is performed near the victim. When a sufficient number of aggressive sources is detected (i.e. sources with packet rate that exceed a threshold) rate limiter assume the existence of the attack. 3. As soon as the attack is detected the rate limiter will perform a packet filtering that drops all packets coming from attackers.


58

Figure 3.5: Flooding the Iu interface V Conclusion In this chapter our aim was to standardize defense integration in CODERA so as to make it easy to update. We proposed a unique defense model. After that, we specified how can we apply this model to all cellular DDoS attacks in order to conceive generic defense operation to every class of attack. Then, we described implementation of these defenses in CODERA. And lastly, we took a new DDoS attack and we tried to update CODERA with the new defense using the proposed model. In the next chapter, we will study the performance of the novel architecture.

CHAPTER 4

Evaluation of CODERA’s Performance

Chapter 4: Evaluation of CODERA’s Performance

60

I. Introduction CODERA is a novel defense architecture that aims to tackle DDoS attacks in cellular networks. It’s a new problem that is associated to the meet of scarcity in wireless resources and ancient denial of service problems of Internet. CODERA uses various components in order to counter actually existent attacks with different natures. Again, we proposed generic defense model that facilitates CODERA’s updates with minimum human intervention and without any change in the architecture. In this chapter, we treat CODERA’s performance. First, we give answers to these questions:

•

What is the security degree that CODERA offers?

•

In which case can CODERA take bad decisions?

•

Can it overload the network?

In the second part of this chapter, we present a concrete analysis of CODERA with simulation results. II. CODERA’s performance II.1. CODERA’s efficiency The objective of our novel defensive solution is to prevent network services for legitimate users and to deny it for attackers. This section discusses CODERA’s ability to reach its principle objective that is countering DDoS. Since these attacks are quite various, some of them can be completely stopped and others are mitigated. Indeed, attacks can be completely stopped if the monitoring functions are performed near the attackers. In the opposite case, the effect of the DDoS attack is only mitigated. II.1.1 Completely stopped attacks In some attacks, after the attack is detected, CODERA can completely eliminate attackers and save networks normal working. We depict two of these attacks.


61

Abusing telephonic servers The principle of this attack is depicted in the first chapter. It aims to flood a telephonic server by a huge number of simultaneous calls in order to keep it busy for a long period. The defense is performed near the attacker and is based on detecting abnormal calling behaviors of a set of users.

Secured Zone RNC

RNC

SGSN

RNC

RNC

MSC

SGSN

Unsecured Zone VLR

GGSN VLR

MSC

GMSC

RIDS Analysis server

PSTN

Targeted server

Figure 4.1: Impact of partial deployment on the defense against telephonic server abuse With a full deployment, there is no chance of such an attack to escape from CODERA’s monitoring and aggregation functions.


62

In a full deployment of CODERA, RIDSs are implemented in all BTSs and analysis servers exist in all RNCs. In the opposite case, if the defense architecture is not fully implemented, there is a chance for an attack to succeed. To clarify this issue we trait the architecture of Figure 4.1. Let C the capacity of the targeted server. And, let Nu the number of attackers in the unsecured zone and Ns is the number of attackers in the secured zone. In addition we suppose N the mean number of calls treated by the server during the attack attempt. The attack succeeds only if Ns do not exceed the threshold Th2 of the algorithm of Figure 2.4 and the sum N+Ns+Nu exceeds the capacity C. This scenario is not probable for two reasons. First it demands an attack that is well distributed in order to make the number of attackers in each cell do not exceed the first threshold. Secondly, it also requires a maximum number of attackers in the unsecured zone. Blocking radio channels As described in the first chapter, this attack is based on consuming available radio resources in order to block the access for legitimate users in the same cell. The algorithm shown in Figure 2.6 proposes a defense based on capturing call rates that exceeds some threshold. Cells that contain a Radio IDS installed in their Node B are perfectly secured from this attack. The reaction in this case is extremely severe with the immediate elimination of attackers after the detection. That is why this attack is classified as completely stopped attack. II.1.2 Mitigated attacks In other cases, when the danger comes from other networks (i.e. Internet), monitoring functions can not be performed near the source of the attack. Consequently, the aim of CODERA’s defense is to alleviate the effect of the attack on the network. Some of these attacks are flooding attacks. In all scenarios of flooding attacks the objective is to overwhelm the target by a huge number of packet streams. The defense of CODERA is based on the DefCOM solution [8]. In fact, CODERA performs a selective rate limiting in order to drop malicious packets. Whereas, packets can escape from being stamped since no explicit criterion can permit a reliable judgment of the legitimacy of a packet.


63

II.1.3 False reports One of the most important issues to discuss in CODERA’s efficiency is the possibility of taking bad decisions. As shown in the second chapter CODERA’s reaction is quite severe. It can detach users from the network and drop data packets. In fact, CODERA can take bad decisions when it assumes the existence unreal attacks. This problem can occur only in one case: When thresholds are not well chosen. For example in the attack based on consuming radio links the RIDS counts call attempts of every user. If thresholds are very low CODERA can perform severe reaction without the existence of the attack. Consequently, the choice of thresholds is very important in order to preserve CODERA’s efficiency. This point will be clarified in the analysis of simulation results. II.2. Can CODERA induce network’s overload? All CODERA’s defenses that use correlation functions requires data exchange between different actors in order to take cooperative decision on the existence of the attack. We study here the amount of data exchanged between CODERA’s components in each defense. It’s obvious that defenses that don’t require an aggregation don’t utilize data exchange. For that reason, we talk only about defenses with correlation functions. II.2.1 DefCOM defense against flooding attacks In the case of flooding attacks, cooperation is strongly needed and messages exchange is vital in detecting and reacting against DDoS. In this section we study different messages exchanged between CODERA’s nodes when performing DefCOM defense. Alert message In the DefCOM’s defense against flooding attacks, alert messages are defused to all rate limiters and classifiers in the network. An alert message contains IP address of the target. An IP packet will largely suffice to contain this message. The number of packet generated after the discovery of the attack is equal to the number of rate limiters and classifiers directly linked to the alert generator that detected the attack. Every point that receives an alarm message will forward it to other points in the network.


64

It is clear that one packet per link will not overload the network. That is why, alerting operation could not induce networks saturation. Stamping Since the backbone of the packet switched network is based on the IPv4 protocol, we should exploit header fields in the IP packet. As described in [8] the stamp is placed in the ID field of the IPv4 header, which is normally used for fragmented packet identification, and fragmented traffic going to the victim during an attack is dropped. We believe that the damage to fragmented traffic will be minimal because: fragmented traffic makes a very small portion (0.25%) of the Internet’s traffic [8], and CODERA only marks traffic going to the victim during the attack, so the fragmented traffic loss is limited. Stamping operation cannot, in any case, cause networks overload since it does not add any data to be transmitted through the network. II.2.2 Defense against abusing telephonic server In this case aggregation functions are strongly needed and cooperation between several CODERA’s actors is necessary. For that reason the problem of overload that may be created during the correlation operation must be discussed. The algorithm of this defense is detailed in Figures 2.3 and 2.4. It requires transmission of reports from the RIDS to the analysis server. One report contains the list of attackers. Each mobile terminal is identified by its International Mobile Subscribers Identifier whose size is less than 15 digits. Consequently, the size of a detection report is equal to 15*N; where N is the number of attackers. It’s clear that such a message can not overload the network, since only one message will be sent when the number of users with abnormal behavior exceeds the threshold. The same thing with messages exchanged between analysis servers. The number of messages is very low when compared to the amount of exchanged traffic. As a result, there is no danger that can be caused by CODERA’s information exchange when defending against telephonic server abuse.


65

II.3 Security schemes of CODERA Security of CODERA against several attacks is a very important issue since its role is critical in securing the cellular networks from one of the most virulent attacks. In fact, normal functioning of CODERA’s operation can be altered by different kinds of attacks. Masquerade It takes place when one malicious entity pretends to be one of CODERA’s actors in order to gain access to the architecture. This attack can be extremely dangerous since a malicious node can perturb defense operation by sending false reports or taking bad decisions. For example, when one attacker succeeds to convince CODERA’s nodes that he is an analysis server, he can gain many privileges. He can receive detection reports, send false reports to other analysis servers and even detach users from the network. Thus, CODERA must be secured from these attacks. In fact, the evident solution to this problem is making CODERA’s membership static. In other words, defense nodes are set from the beginning and every node is able to authenticate other nodes of the architecture. So, no new nodes will join CODERA without the intervention of security managers. Replay This attack occurs when the attacker captures one of CODERA’s messages and reuses it in order to alter the normal functioning. This attack can be very hazardous when performed with high coordination between deferent attackers. For example one attacker can capture the alert message even if it is authenticated. Then he can resend it when the there is no attack. This can induce CODERA’s reaction against an attack that doesn’t exist and release rate limiting operation. The typical solution to this attack is adding a sequence number to every message. This means that one node will increment the sequence number with every new message. If the attack succeeds to capture one message and resend it to the destination, it will not be considered. In addition, attacker can not deduce the sequence number since all messages are encrypted.


66

t = t1 {M,SN} pubB

Node A

Node B

t = t2 > t1 Node A

{M,SN+1}pubB {M,SN} pubB

accepted

Node B denied

Attacker

Figure 4.2: Countering replay attacks using sequence numbers Modification One intruder can modify messages when he gains access to the network. This modification can lead to disastrous results if the attack is well planed. In order to preserve data integrity, digital signature can be used. In other words, every encrypted message should be sent with the signature of the sender. By verifying the signature the receiving node can be sure of the identity of the sender and the integrity of the message. III. Simulation In order to study CODERA’s performance we will analyze simulation results. We have chosen to develop our own simulator that we have called CODERA Simulator. The role of this simulator is to feign DDoS attacks scenarios in the cellular environment and depict attacks impact on network’s performance and CODERA’s effectiveness. The choice of developing our own simulator will give the possibility to the network operator to test the product. More than that, it will permit to experiment any change in CODERA’s operation before the real implementation.


67

In other words, it will give to the operator the possibility of testing new defensives mechanisms and selecting the right ones depending on deferent criteria. The first section of this part will present CODERA Simulator. Then the second will study CODERA’s effectiveness by analyzing simulation results. III.1 Features of CODERA Simulator III.1.1 Simulated network CODERA is a defending architecture that can be implemented in any cellular network. For that reason we will not simulate a specific network (i.e. UMTS, GSM…). In addition, the simulation will not include all messages and network’s components. Although, only facts that affect attack’s impact on the network and CODERA’s response will be simulated. For that reasons, many parameters are variable in simulation scenarios the most common ones are the number of cell, the number of users, the number of attackers and their amount. a. Number of cells The number of cells in the simulated network is a key parameter in the evaluation of CODERA. By increasing the number of cells we can exploit the impact of widely distributed attacks. In addition, simulating large scale attacks can depict the scalability of CODERA. In other words we will depict the influence of large scale attacks and CODERA’s response against them. Thus, the number of cells is adjusted with each scenario, which gives a larger view of CODERA’s performance. b. The number of users As depicted in the first chapter, the number of users in the mobile network has a clear impact on its immunity against DDoS attacks. When users are numerous, the network is more sensitive to a denial of service attack since resources become scarcer. Hence, one of the key variables in the simulated network is the weight and the kind of users. In fact, we distinguish between three types of users in a given instant, users who generate voice calling traffic, users who are linked to Internet and use the packet switched part and users who are attached to the network without generating any traffic.


68

c. The number and proportion of attackers This parameter defines the second actor in the simulation which is the attack. Many variables linked to the attack can modify simulation results. First, by tuning the number of attackers we can test CODERA’s performance in different levels of attack strength. Second, the degree of distribution of attackers is a key parameter in the simulation. III.1.2 Traffic generation In order to make the simulation as close as possible to the reality, CODERA Simulator encloses traffic generation functionalities. For that reason we give models of both types of traffic (i.e. circuit switched and packet switched). III.1.2.1 Circuit switched traffic Modeling Circuit switched traffic is calls handled by the circuit switched part of the network. In order to model this traffic we distinguish three possible states for a user: A state 0 when no call is handled by the user, a state 1 during a call setup and a state 2 during the call. In the simulated period, every user has a traffic vector that depicts its state variation as shown in Figure 4.3. In order to obtain a traffic vector for one user, the simulated period is divided into intervals of two seconds. 0

0

0 0 Idle state

1

1

1

2

2

2

2

Call setup

2

2

2

2

0

0

0

0

Calling

Figure 4.3: Modeling circuit switched traffic with traffic vector Traffic generation Traffic generation is equivalent to the generation of traffic vectors described above. It’s obvious that a traffic vector is well defined by the length of each state of Figure 4.3. Thus, generating a


69

traffic vector is based on defining the duration of successive states. For instance with the vector of Figure 4.3 a first state 0 has the duration of four intervals. Then a state 1 lasts for three periods. Next, a new call (state 2) lasts for eight intervals. Finally, a second state 0 lasts four periods. The choice of the duration of each state must not be the same for each user and each simulation. That is why we chose to model the three variables (i.e. call duration, setup duration and intercalls time) by a Gaussian distribution for each one. The choice of the mean value and the variance will be performed by the user when generating the traffic since it depends on many factors and it could not be fixed. Thus, a traffic vector is constructed by generating a Gaussian distribution for each state in every new simulation. We treat the example of a simulated network that have the following features:

•

Call durations have a mean value of two minutes (i.e. 60 periods of 2 seconds) and a variance of one minute(.i.e. 30 periods)

•

Inter-calls time has a mean value of four hours and a variance of one hour.

•

Call set up time has a mean of 6 seconds and a variance of 2 seconds.

When using these distributions we obtain traffic vectors of Figure 4.4. 0

0

0 0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0 0

1

1

1

1

2

2

2

2

2

2

2

2

2

2

2

1

1

2 2

2

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0 0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

2

2

2 2

0

0

0

0

0

0

0

0

1

1

1

1

0

0

0

0

0

0 0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0 0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

Simulated period = 19*unit time Figure 4.4: Example of traffic vectors generated by Gaussian distributions


70

III.1.2.2 Packet switched traffic Many DDoS attacks aim the packet switched part of the network. So it is essential for CODERA Simulator to simulate data traffic in addition to voice. In order to simplifier the task we propose a static architecture for the packet switched part of the network. Each node of the network is modeled as a FIFO queue. The inter-packets time is exponentially distributed with the rate λ. The rate of service is equal to μ. λ 0

λ 1

μ

λ .....

2

n

n-1

μ

μ

Figure 4.5: State transition diagram of a SGSN The arrival of packets is modeled by a Poisson process whose probability density function has the following expression, f p ( x) =

e−a a x x!

where a is the mean value. To conclude the network is simulated by a queue network with an arrival process that follows a Poisson law. So, a SGSN is modeled as a queue, a packet as client, waiting time as the time spent by the packet in node’s memory and saturation of the node as the number of waiting clients that exceeds queue’s capacity. III.1.3 Input/output of Codera simulator III.1.3.1 Input We mean by simulator’s input different parameters that must be adjusted before the running of the simulation. These parameters are divided into three classes according to the state in which they can be included. We distinguish between three major classes.


Inputs

71

Outputs Usual QoS parameters

Legitimate Traffic

CODERA Simulator

Attacks CODERA’s Defense

QoS parameters under the effect of the attack QoS parameters after CODERA’s reaction

Figure 4.6: Input/Output of CODERA Simulator a. Parameters linked to the normal functioning of the network These parameters do not refer to any type of attack. They specify the behavior of legitimate users in the simulated period and the impact of this behavior on network’s state. One of these inputs is voice traffic measured in Erlangs. We already quantified the traffic by vectors of Figure 4.3. From the user’s point of view parameters to adjust are the mean values and the variances of intercall time, call duration and call setup duration distributions. Furthermore, in the case of Internet traffic parameters that must be adjusted are the architecture of the packet switched network in addition to traffic schemes like packets arrival rate. b. Parameters linked to the attack A DDoS attack can be extremely virulent when performed with sufficient number of attackers and a good degree of synchronization between them. In the opposite case, one attack that has not an important weight and sufficient synchronization will not present a serious danger to network. As a result, it will be very important to specify attack’s schemes that depict its presence in the network. Examples of these schemes are the time of the release of the attack, the degree of synchronization between attackers and the weight of the attack. For instance, in the case of consuming radio channels, the number of attackers, the moment of the generation of attack floods, and the aggressiveness of the attack are the key characteristics of


72

one attack. We mean by attack’s aggressiveness the number of call attempts generated by every attacker during the attack. In addition, when all attackers are synchronized (i.e. well manipulated by the master) the generation of attack call attempts would be simultaneous and the impact would be immediate on radio resources availability. In the case of flooding attacks, the number of packets per second that arrive to the node (SGSN or GGSN) and the source of these packets are key parameters of the attack that are the input of CODERA Simulator. c. Parameters linked to CODERA’s defense These parameters are static and we implement them without giving the user the possibility of changing them. They are the key elements that allow the simulator to perform CODERA’s operation against various attacks in different defense stages: Monitoring, detection and reaction. Among the most important elements that are considered as linked to CODERA we find defense algorithms that must be implemented in the simulator. Since the operator should update CODERA with new defensive, our simulator should also give possibilities to simulate new kinds of scenarios. That is why; the source code must be updated with every new attack. III.1.3.2 Output The objective of simulation is to depict CODERA’s ability to fight DDoS attacks and its impact on Quality of Services (QoS). Consequently, our simulator’s outputs have three classes. Due to the input of traffic in the absence of an attack many sorts of outputs can show Quality of Service that the network offers to users. One of these outputs is the blocking rate in different cells. Another QoS parameter is the number of occupied channels through time (Figure 4.7). CODERA simulator gives the possibility to follow channels occupation in three cases: In the absence of an attack, under the effect of the attack and after CODERA’s reaction. In the case of Internet traffic, the main output is the dropping rate of packets. To conclude, in the three levels of attack’s evolution, parameters of Quality of Service are depicted by CODERA Simulator.


73

Figure 4.7: Evolution of the number of occupied channels through time III. 2 Simulation results The object of this section is to analyze simulation outputs in order to concretize the study of CODERA’s features. Outputs are the set of curves that result from simulation scenarios. We will treat different outputs attack by attack. III.2.1 Consuming radio channels The key parameter in this case is the number of occupied channels through time, since attackers aim to consume all available radio spectrum channels. In the simulation the output is the curve that depicts the variation of this number through time.

Figure 4.8: Impact of CODERA’s reaction in the availability of radio channels


74

In order to test CODERA’s ability to tackle this attack we simulated three scenarios: The first traces the variation of occupied channels in the absence of attackers. The second shows the impact by an attack generated by twenty attackers at the same time and the last show the state of consumed resources under the effect of the same attack with CODERA activated.

Figure 4.9: Impact of the variation of calls rate threshold on the speed of the reaction As shows the Figure 4.8, the beginning of the attack rises the curve to higher levels of resource consumption. More than that, with the stronger attack available channels become completely consumed and the communication in this cell are no more possible. In the Figure 4.8 we depict the impact of CODERA’s reaction with the blue curve. We observe that the number of consumed channels returns to its usual values after about eight seconds. In fact the time of reaction is dependent to the threshold value. In other words, if the threshold is quite small, the reaction is extremely rapid. Although, in this case, the probability of detaching legitimate users would increase, especially for those who generate many calls in a short period. In the Figure 4.9, we notice that when CODERA is deployed with a small threshold Rth=3, the reaction is relatively fast. However, with a larger threshold (Rth=4 and Rth=5) the response takes more time. This difference can be explained by the tolerance given by CODERA when we increase the threshold. In other words, with Rth=5, an attacker is detected when he generates


75

more than five calls per minute. Yet, with a small threshold an attacker is rapidly detected and detached. III.2.2 Abusing telephonic server This attack is described in the second chapter. It consists on flooding an important telephonic server, such as emergency number, by numerous calls in the same time. The immediate result is the total congestion of the server. In addition, the impact of the attack is still during the generation of call floods by several manipulated attackers. CODERA gives a novel defending methods useful in tackling this attack. In order to test the efficiency of this defense, we analyze the curve that depicts the variation of the number of calls handled by the server through time. III.2.2.1 Variable parameters As shows the Figure 4.10, many parameters are variable and it can be adjusted by the user. (a) Number of RNCs Since CODERA’s defense in this case requires the cooperation of several components, we must specify the architecture of the simulated part of the network. One of the key parameters is the number of RNCs. This specification permits to test the efficiency of the defense in different scales of the attack. (b) Number of cells per RNC Another important parameter is the number of cells per RNC. This option gives the user the possibility to scale his network with more details. (c) Number of attackers Testing CODERA’s efficiency in different cases of attacks’ strength is one of the major objectives of the simulation. So, it’s necessary to make the number of attackers one of simulation variables. (d) CODERA’s parameters CODERA’s defense can be extremely efficient when thresholds are strictly chosen. However, legitimate users can be penalized. In the opposite case, if thresholds are tolerant several attackers


76

can escape from the defense. This compromise is very important while choosing thresholds. For that reasons we gave the user the possibility to adjust thresholds.

Figure 4.10: Variable parameters is simulating abusing telephonic server

Figure 4.11: Number of calls handled by a telephonic server with capacity of 100 calls


77

III.2.2.2 Efficiency of CODERA The defense algorithm is detailed in the second chapter. It consists on monitoring functions performed by Radio Intrusion Detection Systems and correlation functionalities performed by analysis servers. In order to test CODERA's efficiency in this case CODERA Simulator depicts the curve that shows the number of calls handled by one telephonic server. It is obvious in Figure 4.11 that CODERA can completely stop attacks effect by detaching all attackers from the network. The green curve shows the decrease of the occupation of the targeted server due to CODERA’s defense. III.2.2.3. Impact of the choice of thresholds Choosing good thresholds is an important step to ensure the best usage of CODERA. Thus, the simulator that we propose as a complement to the architecture will aid security manager to choose suitable thresholds. There is obviously a compromise between severe reaction against attackers and the worry of detaching legitimate users. In this section, we analyze the impact of the choice of thresholds.

Figure 4.12: Impact of tuning the calls rate threshold on the speed of the reaction Threshold of calls rate toward the server This parameter shows the degree of aggressiveness of one user that allows CODERA to consider


78

him as an attacker. This parameter should be carefully chosen since it defines CODERA’s tolerance or strictness. The Figure 4.12 depicts the impact of tuning this threshold.

Figure 4.13: Impact of tuning the number of attackers’ threshold on the speed of the reaction

Threshold of the total number of simultaneous attackers The principal role of an analysis server is to correlate different reports originating from RIDSs. The decision taken by the analysis server is mainly linked to the total number of attackers and the threshold already set up by security administrators. The figure above depicts the impact of tuning the number of attackers’ threshold on the speed of the reaction. III.2.3 Bandwidth attacks These attacks are linked to the third generation of cellular networks. Indeed, they are similar to Internet denial of service that overwhelms networks nodes and links to shutdown it. We proposed in this defense to integrate the DefCOM solution in order to make CODERA able to react against this attack. The efficiency of DefCOM reaction is proved in [9]. Simulation results found in [9] shows the decrease of the load in the targeted server after the use of DefCOM.


79

Consequently, CODERA Simulator will not be interested to the reaction phase. Nevertheless, the detection phase is not specified in DefCOM. Authors of [8] and [9] do not precise how can alert generators detect aggressive users. That is why, we proposed the algorithm described in the second chapter in order to make CODERA able to detect and react against these attacks. As a result, simulating the detection phase is necessary. III.2.3.1 Variable parameters Variable parameters in this simulation are divided into three types: legitimate traffic parameters, attack traffic parameters and defense parameters. The first class encloses the main value of the number of legitimate users who generate packets that passes through the node in question. The second class includes the number of attackers and their main aggressiveness. The last kind of parameters is linked to CODERA’s detection mechanism and its thresholds. The variation of these parameters can also aid security manager in choosing the right threshold depending on his network’s characteristics. III.2.3.2 Simulation results During this simulation, we first study the efficiency of the proposed detection algorithm. We simulated an attack with forty attackers who generate ten packets per second each one. As shows Figure 4.14, eight seconds are sufficient to completely detect all attackers. Then, we tried to depict the impact of the choice of the threshold on he performance of the detection function. In order to test CODERA’s efficiency in detecting aggressive floods of packets, we simulated three scenarios. In the first scenario, we generated a legitimate traffic with a mean rate of RL=4 packets/s and an attack traffic with a mean of rate RA=20 packets/s and 20 attackers. We fixed a threshold of 10 packets per second. As shows the Figure 4.15, the 20 attackers are detected in four seconds. So, in this case the threshold is well chosen. In the second scenario, we tried to make the threshold close to the normal rate of legitimate packets. We obtained the green curve of Figure 4.15. We observe that CODERA reported about 41 attackers. Nevertheless, there are 20 attackers in reality. We


80

conclude that when the threshold is not sufficiently greater than the rate of legitimate traffic, false reports will be generated. In the third scenario, the threshold is chosen so as to make the detection very tolerant. Only attackers with the rate greater than 19 packets per second are detected. As a result, this tolerance induced the escape of some attackers from being detected as depicts the blue curve of Figure 4.15.

Figure 4.15: Impact of the variation of the threshold on the number of reported attackers In conclusion, the proposed algorithm can be extremely efficient in the case of a good choose of the threshold. In the opposite case, if the threshold is very tolerant attackers can escape from the detection. And, if the threshold is very severe, some legitimate users will be penalized. III.2.4 TCP SYN flood attack In this attack targeted components are usually web servers. Consequently, the impact of the attack appears in the consumption of the server’s resources. More precisely, a TCP SYN flood attack consumes the available memory of a server. By this simulation, we try to show the impact of this attack on the availability of server’s memory in the presence and the absence of CODERA’s defense. Variable parameters in this simulation are divided into three types. The first variable characterizes the occupation of the server in normal conditions (i.e. in the absence of the attack).


81

The second parameter is linked to the strength of the attack. And the third specifies if CODERA’s defense is enabled.

Figure 4.16: Variation of the amount of memory occupation of the targeted server Figure 4.16 illustrates the variation of the amount of consumed memory of the targeted server through the simulated period. When CODERA Proxy is disabled we observe a sudden rise of the occupation amount. The server can be totally blocked if the attack is sufficiently strong; such is the case of Figure 4.16. While when CODERA Proxy is activated the variation continues having the same mean. That is, there is no sudden rise as it is the case in the absence of the defense. IV. Conclusion To summarize, CODERA is an efficient, light and robust defense architecture. It can detect and stop a large number of attacks. Simulations proved the ability of the novel solution to counter various DDoS attacks in 2G, 2.5G and 3G cellular networks. Nevertheless, CODERA can be used in many ways. Explicitly, adjusting thresholds is a sensitive task that requires a good knowledge of the network and the risk of each attack. In fact, bad thresholds can lead to the aggravation of the problem. It can even create new problems. CODERA Simulator is a good tool that helps security manager to chose the right thresholds.

Conclusion Many operators are turning their attention to device security as handsets begin to provide more data functions. They will need to keep a close eye on their networks, too, as bandwidth and always-on services continue to rise. More precisely, cellular network security against denial of service is becoming more imperative as data services increase. Our contributions Distributed denial of service is a serious problem that requires a complex solution. This report has presented CODERA, a cooperative defense architecture that successfully handles a broad range of DDoS attacks. CODERA achieves excellent performance with a modest set of models and per packet overhead. It provides good service to legitimate traffic during the attack, which is the ultimate goal of DDoS defense. In addition, CODERA is a flexible and extensible solution. First, it counters traditional DDoS attacks. Second, its update becomes easier with the model given in the third chapter. We introduced three main contributions: First we proposed the defense architecture. We specified its components, the role of each one and the set of algorithms that allow them to detect and stop the attack. We treated actual DDoS attacks one by one and we described how the defense is performed in each case. Second, we made CODERA able to be easily updated. Given the evolution of attack tools and the appearance of new attacks so regularly, a static architecture will be superseded very soon. From this perspective, we considered as primordial to give several steps of the implementation of new defense. Third, we proposed CODERA Simulator: an additional tool that has two main functions. It helps security managers to choose suitable thresholds that fit with their network. As we have seen in the last chapter, when thresholds are wrongly chosen, CODERA may aggravate the problem.

Conclusion

83

Thus, simulating the attack and the defense is a crucial step before the choice of different parameters. In addition, before the integration of a new defense CODERA Simulator is useful in testing the efficiency of the new algorithm. When security managers decide to add a new defense, they should follow several steps explained in the third chapter. After that, they need to be sure of the efficiency, robustness and reliability of the modification. So they can test it using CODERA Simulator. Future work Our work opens new field of research showing problems that remain still unsolved and which can be addressed in future works. New perspectives can be related to two main axes. The first axis addresses CODERA’s weaknesses. The second axis concerns new denial of service problems linked to heterogeneous networks’ interconnection. As proven by simulations, CODERA is an efficient solution to traditional denial of service. Nevertheless, it presents some weaknesses that can be addressed in future works. First, CODERA do not consider mobility of users. That is, one subscriber is modeled as a user camped in one cell. For example, in the monitoring function, every RIDS is in charge of surveying the behavior of users attached in his cell. An attacker can escape from being detected by moving from one cell to other. CODERA’s detection mechanisms can be enhanced by taking users’ mobility in consideration. The second weakness of the novel architecture is that it does not allow operators to cooperate in order to efficiently detect attacks. In fact, in many cases, attackers who are subscribers of one operator can launch an attack against other operator’s network. In this case, cooperation is needed. Indeed, operators’ awareness that DDoS is becoming a more significant consideration that will make inter-operator cooperation a possible approach. So, one of the possible enhancements of CODERA would be benefiting from the cooperation between operators. Future works can also address new security challenges. For example, security of inter-provider handover is becoming a challenging issue. In fact, as more and more roaming procedures between different providers and wireless network technologies evolve, handover procedures of a mobile device from a foreign network to another network become of greater interest. Indeed, security weaknesses of handover and roaming procedures may induce hazardous denial of service attacks.

Bibliography

[1] Ken Belson, “Beware the Worm in Your Handset”, New York -Times, Nov. 2003 [2] Internet Security Systems, Denial of Service FAQ, http://www.iss.net/news/denialfaq.php December 2006 [3] Bennett Todd, “Distributed Denial of Service Attacks”, February 2000 [4] Snoeren, A., Partridge, C., Sanchez, L., Jones, C., Tchakountio, F., Kent S., and Strayer, W., "Hash-Based IP Traceback," SIGCOMM 01, August 27-31, 2001, San Diego, California, USA. [5] S. Dennis, “Mobile phones emerge as new virus target Kaspersky” January 2007, Newsbytes.com, http://www.newsbytes.com/news/00/153195.html [6] L. Sheriff, “Virus launches DDoS for mobile phones”, http://www.theregister.co.uk/ content/1/12394.html [7] Yuichi Ohsita, Shingo Ata, Masayuki Murata “Deployable Overlay Network for Defense against Distributed SYN Flood Attacks” [8] George Oikonomou, Jelena Mirkovic, Peter Reiher, Max Robinson “Distributed Defense Against DDoS Attacks” University of Delaware Technical Report 2005-02 [9] George Oikonomou, Peter Reiher, Max Robinson, and Jelena Mirkovic, “A Framework for A Collaborative DDoS Defense” 2006 Annual Computer Security Applications Conference (ACSAC 22), December 2006. [10] D. Moore, G. M. Voelker, and S. Savage, “Inferring Internet Denial of Service activity,” in Proceedings of the 2001 USENIX Security Symposium, pp. 9–22, Aug. 2001. [11] CERT Coordination Center. Denial of Service Attacks. February 2007 http://www.cert.org/tech_tips/denial_of_service.html [12]

US-CERT,

Federal

Incident

Reporting

Guidelines

available

in

http://www.uscert.gov/federal/reportingRequirements.html [13] Thomas Dubendorfer, Matthias Bossardt, Bernhard Plattner “Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation”

Fiche de renseignements

Abstract The scarcity of resources in wireless communications in addition to attackers’ experience in Internet denial of service make DDoS a challenging issue in cellular networks. In spite of the seriousness of the problem, research works in this issue are immature. CODERA (COoperative DEtection and Reaction Architecture) is our proposed architecture that aims to detect and react against DDoS and save network’s availability to legitimate users. This report depicts CODERA’s components and operations, specifies steps taken in updating the novel architecture and analyses its performance.

Key words: Distributed Denial of Service (DDoS), Cellular Networks, CODERA.