SIPp-DD: SIP DDoS Flood-Attack Simulation Tool

SIPp-DD: SIP DDoS Flood-Attack Simulation Tool Jan Stanek, Lukas Kencl Research & Development Center for Mobile Applications (RDC) Czech Technical University in Prague Technicka 2, 166 27 Prague 6, Czech Republic {jan.stanek, lukas.kencl}@rdc.cz, Abstract With the growing popularity of Voice-over-IP communication and of the SIP protocol, mobile networks including, denial-of-service attacks against the signaling are an increasingly menacing threat. We present SIPp-DD, a tool for generating reallike SIP DDoS flood attacks. SIPp-DD modifies the popular SIPp call generator and offers the option to spoof source IP addresses and ports of the generated messages. For flexibility, any set of source IP addresses and ports can be input, using a text file. To create real-like attacks, we analyze some of the publicly available DDoS flood attacks, derive typical distributions of address and packet populations and employ those in attack generation. We compare the generator outputs with the real analyzed DDoS floods and demonstrate the tool applicability by performing a DDoS attack within a real SIP-server testbed. I. INTRODUCTION Popularity of the Voice over IP (VoIP) technology has grown rapidly in recent years. VoIP replaces the classic Public Switched Telephone Network (PSTN) because it is generally cheaper and the user can control its usage and deployment better. Using classic data network as the transfer medium, VoIP can be deployed almost anywhere, whether using the private network inside a company or the public Internet. This also adds some new security weaknesses, perhaps the biggest being non-guaranteed bandwidth for the call. If the network is overloaded, for example by some kind of flood attack (see Section III), then the quality of the call will be very low and it might even result in an unexpected end of the call. Thanks to extensive research done in the field of flood attacks in the last years, this weakness can be perceptibly limited using some of the known countermeasures. Still, flood attacks remain a big threat to VoIP telephony because one does not need to produce a very large general flood to congest the entire network, as it is much easier to target the key component of the VoIP infrastructure, the Session Initiation Protocol (SIP) server. SIP is the most widely used signaling protocol in VoIP telephony nowadays. It is simple and relatively easy to implement and therefore became quite popular and many implementations of it exist in forms of free or paid SIP servers (SIP server is used as a term for an application covering all the necessary functionality e.g. it usually incorporates the functionalities of SIP proxy server, registrar server and redirect server). Different SIP-server implementations have different weaknesses but it is always much easier to use a flood attack against the SIP server itself then against the entire network. For example the popular Asterisk [25] software can be congested using an attack composed of about 500 appropriately chosen SIP messages per second, instead of hundreds of thousand of packets necessary to congest even a low-dimensioned computer network. There has been a lot of research done upon SIP flooding in the last few years (see Section II). Stopping a DoS flood attack against a SIP server is generally easy it suffices to determine and block the IP address of the attacker. The situation is much more complicated with the distributed (DDoS) flooding attacks since there are many originators that need to be blocked. Even more difficult is the situation when the source addresses in the SIP messages are spoofed. To develop viable countermeasures, it is vital to simulate and inspect such attacks in a SIP testbed and measure the impact on the VoIP service. However currently there is a distinct lack of tools able to simulate a semi-realistic SIP DDoS flood attack. We address this shortcoming by presenting a tool with the ability to easily generate attacks of highly similar patterns to typical DDoS attacks in terms of address or flow popularity distributions, as gathered and studied from multiple public sources of information. This therefore allows to replicate such attacks or their variations and thus to test countermeasures focused on particular properties of real DDoS attacks. The main contributions of this work are: an analysis of the publicly available DDoS attack information, deducing typical address and packet distributions; a prototype SIP DDoS flood generator, SIPp-DD, based on the modified SIPp call generator [22], able to incorporate a list of spoofed source IP addresses used in the generated SIP messages; a spoofed address list that respects the observed typical distributions in DDoS attacks; early performance evaluation of the tool in a SIP testbed; The paper is organized as follows: in Section II, related work is surveyed. Section III describes the basics of flood attacks. Section IV presents the generator of IP addresses, along with the background analysis. Section V introduces the mechanisms to generate a DDoS flood attack and Section VI describes the SIPp-DD DDoS generation tool, its design and usage. In section VII we evaluate SIPp-DD-generated floodattack tests. Section VIII sketches possibilities of usage of SIPp-DD in mobile and wireless networks. The paper concludes in Section IX, including suggestions for future work. II. RELATED WORK VoIP security is an area of extensive research. The Voice over IP Security Alliance (VOIPSA) publication [1] summa- 978-1-4577-0636-3 /11/$26.00 2011 IEEE

DoS attacks can be found in [6], [8] and [16]. Some defense mechanisms against both DoS and DDoS SIP attacks were described and tested in [10], [11], [14] and [15]. SIPp-DD is capable of testing any proposed mechanism and generating the expected attack signature. Fig. 1. Hilbert map of Internet malicious activity created by Team Cymru, 2010 [20]. The map shows the entire Internet address space, each pixel representing a block of 4096 IP addresses. Pixel color represents level of malicious activity produced by machines with IP addresses from the corresponding block (heatmap scheme: black = none, white = highest). rized the general area of VoIP security, including the known threats against a VoIP environment, and established the ground for many other research works. Kang et al. [12] analyze VoIP traffic behavior, providing good insight into distinguishing anomalies in VoIP traffic. Blake published a short guide [9] containing the most important differences between VoIP and PSTN and also provided some best practices for deploying a VoIP solution. Chavhan and Chhabria [13] provided multiple design guidelines for use in VoIP security. Al-Allouni et al. [2] discuss classification, implementation and evaluation of some of the DoS attacks. Sisalem et al. published a very detailed paper about attack scenarios targeting SIP servers [8]. Deng and Shore proposed an advanced flooding attack on a SIP server in [4]. Luo et al. implemented and tested a CPU-based DoS attack on a SIP server in [5]. Liu and Lo simulated a DDoS attack against a SIP server and measured its impact when using different types of queues for storing the communication in [17]. SIPp-DD is capable of reproducing all of the attacks described. DDoS traffic has been analyzed widely. The basis for our generator of source IP addresses is the Hilbert map of malicious Internet activity [20], see Fig. 1. Zulkerine and Haque [19] describe various approaches for detecting DDoS flood attacks. Khazan and Azgomi [18] used the SimEvents software to simulate DDoS attacks and evaluate its security impacts. Mirza et al. used a modeling approach to create random flows and simulate a DDoS attack in [21]. Defense mechanisms against DoS and DDoS attacks have been studied widely. Mirkovic et al. [3] propose metrics to measure DoS attack impact. Various defense approaches to SIP III. FLOOD ATTACKS The flood attacks (floods) aim at the disruption of service using a high number of messages repeatedly sent to the server, resulting in its congestion and inability to process legitimate requests. Floods can be composed of any protocol messages (for example the well-known ICMP protocol is often used for flooding). These attacks are extremely severe in SIP environments, since SIP servers are not optimized to process high numbers of requests. It is generally simple to detect that a flood is being deployed against the server (the traffic is noticeably higher than usual). It is also easy to protect the server against the non-distributed versions of a flood, because once the attack is detected (using typically limits on allowed message rate per time period), it suffices to block its source (the IP address corresponding to the attacker machine). Such defense mechanism may be implemented using a common firewall, even though more sophisticated solutions might be necessary in complex environments (see for example deep packet inspection used in the SNOCER project [28]). Much more menacing are the so-called distributed DoS (DDoS) attacks, using either spoofed (fake) IP addresses or a high number of computers (called bots if under malicious attacker s control). It is highly complicated to defend against a distributed version of a flood due to the many origins of the attack the source limiting approach is unusable in this case. There are some known methods of defense against such attacks, e.g. acknowledgment of messages against spoofedbased attacks, self-learning statistical filters against attacks with typical pattern and others, but there is no generally usable defense approach yet. IV. DDOS FLOOD ATTACKS ANALYSIS To generate attacks similar to real DDoS flood attacks, we have performed an analysis of the few publicly available DDoS attack traces. We did not have any traces of DDoS floods against SIP servers but we have acquired three different sources of information: a rather large set of traces of three different flood DDoSes provided by the USC/LANDER project [23]; the Hilbert map of malicious Internet activity [20]; and the aggregate information about a DDoS flood targeting an HTTP server, provided by Moore et al. [24]. A. DDoS traces The first source is composed of three different traces of similar DDoS floods targeting an unknown server. The information is stored as complete traffic log within the network containing the server targeted during the attack. Unfortunately the IP addresses were anonymized so we have not gathered information about concrete sources, but still it provided very useful information about the division of load between the

B. Hilbert map Fig. 2. Loglog scale of DDoS attack load distribution between the attackers for two ICMP flood attacks. different attacking computers (supposedly remotely controlled bots). We have split the huge data-files into smaller parts and analyzed these parts using the Wireshark packet analyzer [26]. The date needed to be split because Wireshark cannot process such huge data files (the capture filesize is between 500MB and 2.7GB). The splitting has uncovered similar per-attacker load patterns across the trace and indicated that the attack process is not changing significantly over time. For specifications of all the analyzed attack traces please see Table I. The first attack (Attack A) was an ICMP flood. All the attackers started and ended their attack almost simultaneously. Attack B was a flood using malformed IP packets. The first attacker has sent 21478845 packets during the attack which is more than 95% of the whole attack load. The two remaining attackers have sent 596539 and 527941 packets which is about 2.64% and 2.34% of the whole attack load. All the attackers started their attack almost simultaneously, the leading attacker ended his attack about 20s before the other two attackers. Attack C was an ICMP flood. All the attackers started their attack almost simultaneously and ended the same way. The distribution of sent packets between the individual attackers for Attacks A and C can be seen in Fig. 2. From these results we observe that attack load is typically distributed among the attackers into groups of near-identical attack rate possibly a result of identical connection constraints. There is a leading group (or a single attacker) with a very high attack rate and then there are other attackers that usually form a few groups with similar rates. Occasionally, there are also some freelancers, flows with attack rate different from all others. We have not observed many different starting points the attackers usually start at the same time and maintain their attack rate constant throughout the attack. We have used the Hilbert map of malicious Internet activity [20] to derive a model probability distribution function of attacker source IP address values used by SIPp-DD. Unfortunately, the base information used for creating the Hilbert map is not publicly available we therefore had to extract useful data about IP addresses directly from the map itself using Matlab. Although the map does not allow extracting information about individual IP addresses (one pixel represents a block of 4096 IP addresses), we have been able to extract information about the first two bytes of the IP address and generated the last two bytes of the IP address randomly. The extraction process of the first byte was done as follows: We unwrapped the Hilbert line from the square to obtain a straight line of smaller squares, each containing pixels corresponding to one /8 subnetwork. The squares were then sorted in the line from 0 to 255 so we just had to count the number of differently colored pixels in each square. As the colors were taken from the whole color palette, we assigned every individual pixel a weight computed according to its color (eg. black=0, blue=1, purple=2, green=3, yellow=4, orange=5, red=6 and white=7). The final weight, computed as a sum of all pixels weighted colors in the square was assigned as a weight to each of the 256 squares. Finally the weights were normalized over the sum of all weights to derive the probability distribution function. The resulting cumulative distribution function can be seen in Fig. 3. To extract the necessary information about the second byte for each of the 256 first bytes we had to divide the smaller squares forming the previously unwrapped Hilbert line into 256 parts. As every square was formed by 63x63 pixels (62x62 for the squares at the map edge), we have used interpolation from the nearest pixels to create a borderline to complete the desired 64x64 square. Each square was then converted to a 16x16 square (every 16 pixels forming a small square were aggregated into one with weight equal to the sum of its weights). Because every resulting square again represented 256 bytes ordered in a Hilbert curve style, it was necessary to unwrap each to obtain a straight line from 0 to 255. Finally the weights were normalized as in the previous part. TABLE I DATA GATHERED IN ANALYSIS OF THE DDOS TRACES. number of packets number of IP addresses duration Attack A 1043222 145 251s Attack B 22603325 3 816s Attack C 195021 28 40s Fig. 3. Cumulative distribution function of the aggregate level of malicious activity computed for /8 network blocks.

C. Aggregate data of a specific DDoS flood The third source of information was a list containing recorded aggregate data about a real DDoS flood attack against an HTTP server [24]. It includes IP addresses of the bots that participated in the attack, along with the number of packets originating from them during the attack. We have used this trace to verify the attack properties observed in sections IV-A and IV-B. We have checked whether the distribution of the first byte of source IP addresses in this real attack corresponds to the distribution we extracted from the Hilbert map and whether the load of the attack distributed among the different sources corresponds to the model of attack load distribution. To compare the distributions of the first byte of IP addresses we have computed the correlation coefficient between the distribution we obtained from the Hilbert map analysis and the distribution from the real attack. The coefficient was 0.354. This can be interpreted as that there is a relation between the two distributions, although not very strong. Considering that the real attacker machines were chosen from only a portion of the address space (probably botnets controlled by the attacker), we may interpret this result as positive. Distribution of the attack load is quite different from the distributions we have plotted for our previously analyzed attacks. This is probably due to the fact that there were 4217 machines involved, many more than in the previously analyzed attacks. The numbers of sent packets were higher too. We have identified the typical groups with similar attack rates, but differences between the rates in a group were higher (a few hundred packets) and there were definitely more freelancers. To prove the grouping hypothesis, more real attacks need to be analyzed in the future. For now, we take it as a possibility for our IP address generator. V. DDOS FLOOD GENERATION PRINCIPLES There are two main methods of generating a distributed attack using a botnet (network of computers under attackers control) or using the IP spoofing mechanism. We use the IP spoofing mechanism because it is more flexible and more easily usable in a simulation environment. A spoofing mechanism sends IP packets with forged information in the source-address field of the IP header (pretending the packets originate from a different address than they actually do). It can be implemented by misuse of the IP protocol, or rather of the TCP/IP stack, by using the RAW socket instead of the classic TCP or UDP socket for network communication. The RAW socket is a lightweight version of a socket that leaves all the header-creation work to the programmer. This introduces additional overhead, because the programmer has to create otherwise automatically created headers, but it leaves him or her the opportunity to change the individual parts of the headers (including the IP source address field) in any manner. The biggest advantage of this approach is that one needs only one machine to simulate a distributed flood attack by simply changing the values of the source IP address in the messages that form the attack. We have used this mechanism in our SIPp-DD attack simulation tool described in Section VI. Fig. 4. Architecture of the attack creation process. The list of IP addresses may be reused or re-generated for each attack. VI. SIP DDOS ATTACK TOOL SIPp-DD is a modification of SIPp [22] an open source software traffic generator for the SIP protocol, which offers the functionality to simulate almost any SIP communication. One can easily generate a DoS flood attack using SIPp without modifications by creating an XML scenario with the chosen SIP message (or messages), transmitting to the SIP server in every call, and setting the call rate high the server will be flooded with requests. This simple DoS attack can be used to stress-test the SIP server and make assumptions about its processing capacity but it is not useful for security testing since a simple DoS attack is easy to detect and block. Therefore we have modified SIPp to be able to spoof source IP addresses and simulate a DDoS flood attack. For architectural overview of attack generation using SIPp-DD see Fig. 4. It would be hard to modify SIPp to enable address spoofing for all the three transport modes (UDP, TCP and TLS) due to protocol complexity, but it is feasible for UDP, used for majority of SIP communication anyway. We have modified SIPp to use a RAW socket next to the classic TCP and UDP sockets and created a new option spoof ip which can be set in the XML scenario file. When spoof ip is set then the modified SIPp uses RAW socket and is able to inject any source IP address and source port into the packet sent to the SIP server. To maintain SIPp-DD as configurable as possible, the source IP addresses and ports are not generated by an integrated generator but instead we have implemented reading of the addresses and ports from an external file. Because SIPp itself provides the functionality to load additional information from a text file into the XML scenario, we have modified this process to load the information about ports and addresses too. As SIPp may read the text file in random mode, one does not need to specifically order the addresses in the source file and may use the implemented pseudo-random strategy. We have designed an IP address generator in the form of a Matlab function. The function takes two arguments: number of packets and number of IP addresses to be used in one iteration. Based on the analysis of DDoS attacks in Section IV, the generator creates four groups with similar attack rates. The IP

(a) Attack A (b) Attack C Fig. 5. Loglog scale of comparison of packet load distribution in an original ICMP attack and in a simulation. address and flow population distribution is a very coarse-grain approximation of those measured in Section IV. To create the set of IP addresses for various combinations of configurable numbers of packets and addresses for attack generation but also to suit the needs of SIP flooding (which is effective for low numbers of messages hundreds or at most thousands per second), the generator divides the IP addresses into four groups. The first group contains 30% of IP addresses, the second 50% of IP addresses, the third 20% of IP addresses minus r (where r is a random integer between 1 and 5, but never higher than 10% of IP addresses) and the fourth r addresses (these are the checkers, flows with low packet rate, which are often used by an attacker to check the behavior of the attacked target). The total number of packets is divided between the four groups such that the first group takes 40% of the load, the second takes 50%, the third takes 9.9% and the fourth takes 0,1%. The particular IP addresses for the groups are generated as follows: the random generator for the first two bytes uses the appropriate distributions computed in the analysis phase from the Hilbert map (see Section IV). The last two bytes are generated pseudo-randomly using the uniform distribution. The output is a text file with one IP address per line. The packet rates in the output file are represented by address repeats (e.g. if address A has packet rate 15 packets per second then address A is repeated 15 times). VII. PERFORMANCE EVALUATION A. IP address distribution in an attack To test the generator from Section VI we use two criteria: first, the existence of groups with similar attack rate (which is expected since the generator is designed to produce isolated groups) and, second, a comparison of distribution of the first byte in the IP addresses produced by the generator and the distribution derived from the Hilbert map analysis. As the generator produces the specified number of isolated groups every time, for evaluating the first criterion we have used the setup of the attacks analyzed in Section IV. The comparison of load distribution among individual attackers in attacks A and C and in their simulations can be seen in Fig. 5 (we do not include attack B since there were only 3 attackers present which makes the comparison uninteresting). To compare the distributions of the first bytes of the IP addresses we use the correlation coefficient. Because the generator output highly depends on the pseudo-random numbers generated during its computation phase we have repeated the run of the generator 100 times for every measured setup and computed an average correlation coefficient as an arithmetical mean over the 100 measurements. The results for various setups of the generator can be seen in Table II. The correlation coefficient depends significantly on the number of IP addresses and much less on the number of packets. Higher number of IP addresses used results in a higher correlation. Because the output of the generator will be used for SIP DDoS attack simulations where we expect a few thousand packets per second and a few dozens or hundreds of source IP addresses, we find the results for both criteria satisfactory. If we take the values of 5000 packets per second and 100 IP addresses as a model situation, the existence of isolated groups with the same attack rate is obvious and the value of correlation coefficient (see Table II) is higher than the one measured in the real HTTP flood attack (0.354, see Section IV-C for details). TABLE II AVERAGE CORRELATION COEFFICIENTS FOR THE DISTRIBUTIONS OF THE FIRST IP ADDRESS BYTE, PER DIFFERENT GENERATOR SETUPS. Number of IP addresses Number of packets Correlation coefficient 15 500 0.2289 15 5000 0.2232 30 500 0.3084 50 500 0.3598 100 500 0.4673 100 5000 0.4644 1000 5000 0.6725 4000 20000 0.7042

(a) DoS attack, defense off (b) DoS attack, defense on (c) DDoS attack, defense on or off Fig. 6. Comparison of CPU utilization during DoS (SIPp) and DDoS (SIPp- DD) attacks. (a) DoS attack exhausts CPU capacity when no defense is active. (b) CPU utilization during a DoS attack may be reduced highly by employing a simple firewall. (c) Firewall has no influence on DDoS-flood. B. Comparison of DoS and DDoS floods To compare the impact of an attack generated by SIPp-DD to a simple DoS-attack generated by SIPp, we have simulated the attacks in a real testbed. It is composed of three computers with Intel Xeon 2.5Ghz CPUs, connected through one 100 Mbps switch, all running Linux CentOS 5.4 and fully isolated from other networks. The first computer was running Asterisk 1.6.0.21 [25], a widely used open-source PBX, as the test SIP server. The second computer was used as a simulated attacker and was running SIPp (version 3.1-TLS) or SIPp-DD, according to the test setup. The third computer was running SIPp and was used to simulate valid REGISTER and INVITE messages, to check whether the SIP server is able to process legitimate requests during the tests. The simulated legitimate traffic was set to keep the Asterisk-server CPU utilization fluctuating around 5%. Asterisk CPU exhaustion can easily be accomplished using a DoS-flood attack composed of identical SIP messages. We have tested all the basic SIP message types and the best suited for a flood attack are REGISTER, INVITE and OPTIONS, due to their processing complexity. About 500 requests per second will flood Asterisk in our testbed within less than 15 seconds, making it unable to process any further SIP traffic. First we compare the situation when the server is flooded by a single attacker machine (each request having the same source IP address and port) and by many attacker machines. For the first case we have used the non-patched SIPp, for the second SIPp-DD. The scenario for both attacks is the same sending the same SIP requests (REGISTER, INVITE or OPTIONS), using the attack rate 500 requests per second and limiting to 10000 requests in total, creating a 20s attack. We have run a monitoring program on the Asterisk server, logging CPU utilization every second. The output was used to generate all the graphs in Fig. 6. The monitoring program starts 5 seconds before the actual attack, so the attack can be seen in the graphs from the 6th second onwards. Under the DoS flood attack, unprotected Asterisk was flooded (the legitimate traffic requests did not receive the expected response and started being retransmitted) within 6s when using the INVITE and within 7s when using the REGISTER and OPTIONS messages (CPU utilization history is presented in Fig. 6(a)). Behavior under the DDoS flood ((we have used a set of 1000 different IP addresses as spoofed sources, Fig. 6(c)) was very similar. We have repeated both simulations 10 times with similar results. For the setup used, there appears no significant difference between the impact of DoS and DDoS floods. Request processing inside Asterisk is not influenced by the source address or port much, these are just stored as variables. Most of the CPU is consumed by processing of the request itself. In a changed test setup, a simple firewall was deployed on the Asterisk server, blocking potential SIP floods using a rate-limiting approach. When more than 300 SIP packets from a single source IP address arrive at the standard 5060 SIP port over a period of 30s, the firewall drops packets from that address for another 30s. When repeating the attack simulations, the impact of DDoS flood did not change but the impact of DoS-flood was practically eliminated (see Fig. 6(b)). Legitimate traffic during the DoS attack was not affected at all (all requests were processed on time). The previous simulation shows the main benefit of SIPp- DD: it is a useful testing tool for SIP defense mechanisms. Although we have shown only penetration of a naive defense solution, using SIPp-DD for security testing of SIP defense mechanisms might reveal potential weaknesses that would be hard to find without considering SIP DDoS flood attacks.

VIII. SIPP-DD IN MOBILE AND WIRELESS NETWORKS SIPp-DD was designed as a testing tool for SIP environments and is not usable for e.g. generating DDoS floods targeting band-exhaustion in mobile networks. However, thanks to the popularity of SIP, there are situations where SIPp-DD can be very useful in mobile and wireless networks. Lately, the problem of mobility in heterogeneous networks has been widely discussed, with SIP proposed as possible auxiliary [29], or even a replacement, of mobile IP. A solution based solely upon SIP can be seen in work of Zhang et al. [30]. Even though the work focuses on security aspects of the proposed solution, it does not take into account the SIP DDoS flood attacks that are a major threat for this protocol. Generally, any solution based on SIP that is using a central SIP component is prone to SIP DDoS flood attack and SIPp-DD may be used to test its resistance. Moreover, the mobility-providing solutions often use some kind of IP address-translation mechanisms that can be thoroughly tested using the spoofing ability of SIPp-DD. SIPp-DD may also be employed in testing smartphone SIP clients. SIP clients for smartphones are increasingly popular since they can be much cheaper than using the operator provided voice-call, especially for overseas calls. These clients aim to be easily usable and multi-platform (see [31]) and do not possess strong security protection. Another area where SIPp-DD can be useful is testing of internal security in private wireless networks. Many companies use a SIP server for internal communication and do not consider it necessary to protect it since it is located within the private network. However, often wireless access is provided to guests in their offices and it can be quite easily compromised. SIPp-DD is an ideal tool to test the capabilities of a SIP server inside a private network thanks to the possibility to use any list of source IP addresses for the test scenario. IX. CONCLUSION We have presented a highly flexible tool for a simulated SIP DDoS flood attack generation. Going the way of modification of a popular SIPp call generator, it offers the possibility to generate almost any SIP traffic to be used in the attack. Using a raw socket instead of UDP provides the functionality of spoofing IP addresses and ports in the generated communication and therefore one machine may be employed to simulate the entire DDoS attack. The main contribution of the tool is the demonstrated ability to generate attacks similar to typical DDoS attack patterns in terms of address or flow population distributions, as gathered from multiple sources of information. This allows to replicate such attacks or their variations and thus to test countermeasures focused on particular properties of real DDoS attacks. By performing a simulation of such attacks in a real testbed we have further demonstrated the the tool s usability. As for future work, we intend to collect and analyze more data from real attacks to enhance real-attack similarity as well as introduce variability with respect to the type of attack used. Furthermore, analysis of attack inter-packet timing patterns is needed to likewise generate realistic packet arrival times. The ultimate goal is to improve techniques of detection and mitigation of SIP DDoS flood attacks, by tests employing SIPp-DD, and eventually employing techniques detecting and nullifying the effects of the described attack patterns within real network traffic. Our goal is to make SIPp-DD available to the research community in the near future, to enable further testing and extensions. REFERENCES [1] J. Zar et al., VOIPSA VoIP Security and Privacy Threat Taxonomy. www.voipsa.org/activities/voipsa Threat Taxonomy 0.1.pdf, 2005. [2] H. Al-Allouni, A. E. Rohiem, M. El-moghazy, A. Ahmed, VoIP Denial of Service Attacks Classification and Implementation. 26th NRSC, 2009. [3] J. Mirkovic, P. Reiher, A. Hussain, S. Fahmy, S. Schwab, R. Thomas, C. Ko, Measuring Denial Of Service. QoP, October 2006. [4] X. Deng and M. Shore, Advanced Flooding Attack on a SIP Server. International Conference on Availability, Reliability and Security, 2009. [5] Ming Luo, Tao Peng, C. Leckie, CPU-based DoS Attacks Against SIP Servers. NOMS, 2008. [6] G. Zhang, S. Ehlert, T. Magedanz, D. Sisalem, Denial of service attack and prevention on SIP VoIP Insfrastructures Using DNS Flooding. IPTCOMM, 2007. [7] E.Y.Chen,Detecting DoS Attacks on SIP Systems. VoIP MaSe, 2006. [8] D. Sisalem, J. Kuthan, S. Ehlert, Denial of Service Attacks Targeting a SIP VoIP Infrastructure: Attack Scenarios and Prevention Mechanisms. MNET, September/October 2006. [9] E. A. Blake, Network Security: VoIP Security on Data Network-A Guide. In Information Security Curriculum Development Conference, 2007. [10] M. Nassar, S. Nicollini, R. State, T. Ewald, Holistic VoIP Intrusion Detection and Prevention System. IPTCOMM, 2007. [11] J. Fiedler, T. Kupka, S. Ehlert, T. Magedanz, D. Sisalem, VoIP Defender: Highly Scalable SIP-based Security Architecture. IPTCOMM, 2007. [12] Hun Jeong Kang and Zhi-Li Zhang, SIP-based VoIP Trafc Behavior Proling and Its Applications. MineNet, June 2007. [13] N. A. Chavhan and S. A. Chhabria, Multiple Design Patterns for Voice over IP Security. ICAC3, 2009. [14] D. Y. Ha et al., Design and Implementation of SIP-aware DDoS Attack Detection System. ICIS, 2009. [15] M. A. Akbar and M. Farooq, Application of Evolutionary Algorithms in Detection of SIP based Flooding Attacks. GECCO, July 2009. [16] C. Zhou, C. Leckie, K. Ramamohanarao, Protecting SIP Server from CPU-Based DoS Attacks using History-Based IP Filtering. LCOMM, 2009. [17] Chung-Hsin Liu and Chun-Lin Lo, The Simulation for the SIP DDoS Attack. NCM, 2009. [18] M. A. Khazan and G. Azgomi, A distributed attack simulation for quantitative security evaluation using SimEvents. AICCSA, 2009. [19] Yonghua You Zulkernine and M. Haque, Detecting Flooding-Based DDoS Attacks. ICC, 2007. [20] Team Cymru reasearch NFP, Hilbert map of Internet malicious activity. http://www.team-cymru.org/monitoring/malevolence/maps.html, 2010. [21] J. Mirza, M. Shu, J. Yoedhana, C. Gerla, M. S. Lu, Random flow network modeling and simulations for DDoS attack mitigation. ICC, 2003. [22] SIPp - test tool for the SIP protocol. http://sipp.sourceforge.net/, 2009. [23] USC/LANDER Project. LANDER: Los Angeles Network Data Exchange and Repository. http://www.isi.edu/ant/lander/, 2005. [24] H. D. Moore et al. Source list of attackers targetting metasploit.com. http://digitaloffense.net/tools/ddos sources 02.09.txt, 2009. [25] Asterisk Private Branch exchange, http://www.asterisk.org/. [26] Wireshark network protocol analyzer, http://www.wireshark.org/. [27] SIP: Session Initiation Protocol, http://www.ietf.org/rfc/rfc3261.txt. [28] SNOCER project. Low Cost Tools for Secure and Highly Available VoIP Communication Services. http://www.snocer.org [29] M. Boutabia, E. Abd-Elrahman, H. E. Afifi, A hybrid mobility mechanism for heterogeneous networks in IMS. ICME, 2010. [30] L. Zhang, H. Miyajima, H. Hayashi, An Effective SIP Security Solution for Heterogeneous Mobile Networks. ICC, 2009. [31] H. Wook, S. Kang, Design and implementation of SIP-based mobile VoIP application for multiple smartphone OS. ICTC, 2010.