Detection of denial of service attacks

l4ppe j J UNIVE LAPPEENRANTA UNIVERSITY OF TECHNOLOGY Lappeenranta University of Technology Faculty of Technology Management Department of Information Technology Detection of denial of service attacks The subject of the thesis has been approved by the department council of the Department of Information Technology on 16.01.2008 Examiners: Professor Esa Kerttula Senior assistant Pekka Jappinen Supervisor: M.Sc Oleg Chistokhvalov Lappeenranta 27.01.2008 Dmitrii Karasev Karankokatu A 53810 Lappeenranta Finland Abstract Lappeenranta University of Technology Department of Information Technology Dmitrii Karasev Detection of denial of service attacks Thesis for the degree of Master of Science in Technology 2007 57 pages, 22 figures and appendices Examiners: Professor Esa Kerttula Senior assistant Pekka Jappinen Keywords: denial of service, distributed denial of service attack, detection, CUSUM algorithm, ns-2 network simulator This thesis studies techniques used for detection of distributed denial of service attacks which during last decade became one of the most serious network security threats To evaluate different detection algorithms and further improve them we need to test their performance under conditions as close to real-life situations as possible Currently the only feasible solution for large-scale tests is the simulated environment The thesis describes implementation of recursive non-parametric CUSUM algorithm for detection of distributed denial of service attacks in ns-2 network simulator - a standard de-facto for network simulation Table of contents Terms and abbreviations DoS - Denial of Service DDoS - Distributed Denial of Service Ns-2 - Network simulator CUSUM - Cumulative Sum SYN - TCP synchronization message FIN - TCP closing connection message SYN+ACK - TCP acknowledgement and synchronization message ACK - TCP acknowledgement message PUSH+ACK - TCP acknowledgement and forced data delivery message AS - Autonomous System ISP - Internet Service Provider IDS - Intrusion Detection System IPS - Intrusion Prevention System TTL - Time -To-Live D-WARD - DDoS Network Attack Recognition and Defense NOMAD - Traffic-based network-monitoring framework for anomaly detection MULTOPS - MUlti-Level Tree for Online Packet Statistics OTcl - Object-oriented Tcl Introduction Nowadays businesses rely more and more in their practices/business models on their online presence Some of the companies have proceeds from the online store as their one and only revenue source, for others “being on the Net” is still just a means to provide no more than technical support and feedback for their customers and to advertize their products Nevertheless of the degree they depend on their online divisions it is still very frustrating and in most cases costly (especially for web-driven enterprises) to have online services disrupted It could happen for a number of reasons, just to name a few: hardware or software failure, virus infiltration, insider abuse and especially denial of service (DoS) attacks The latter term covers numerous techniques which deny the legitimate user access to the online service Among them currently the utmost importance is given to distributed denial of service (DDoS) attacks DDoS attacks came to the attention of the research community about nine years ago [1], when in August of 1999 a DDoS tool called Trinoo was spread across at least 227 systems and as a result of their activities a single University of Minnesota host was unavailable for two days From that moment on DDoS attacks became quite commonplace occurrence Soon they changed their status from being just a nuisance to a serious threat, both in terms of direct financial losses from disruption of services to legitimate clients in the event of an attack and associated expenditures needed to maintain the infrastructure to prevent, detect and mitigate attacks Widely publicized events of February 2000 proved the seriousness of this threat On February 7, 2000 Yahoo web site became a target for the DDoS attack - for hours the portal was unavailable Next day, February 8, Amazon, Buy.com, CNN and eBay were also targeted, which either shut them down completely or considerably slowed their operations On February it was a turn for ZDNet and E*Trade During an attack Buy.com could only provide to its clients 9.4 percent availability as opposed to usual 100 percent, and for CNN’s customers this number dropped to percent, while ZDNet and E*Trade sites went practically offline [2] Even today, almost years later, this attack still remains probably most singularly costly event in the history of denial of service attacks - “according to the Yankee Group, a Boston consulting firm, the DDoS attack in February cost approximately $1.2 billion” [3] A key problem when trying to solve DDoS attacks is attack detection which importance cannot be overstated We need to detect an attack in progress as soon as possible for a number of reasons First of all, the sooner the attack is detected prior to inflicting any real damage, the more time the system under the attack has to implement some defense measures Second, detection of the attack usually ascertains also the identity of those systems which participate in it This data is potentially useful for taking the legal action and prosecuting the guilty party Third, if the attack can be detected close to its sources, corresponding filtering mechanism can be turned on, dropping attack flows and preventing the bandwidth waste Of course, all those opportunities are available only if a given detection mechanism is really doing what it is supposed to do, if it is really effective In this regard, it becomes crucial to be able to test different detection approaches not only on the basis of their theoretical performance but also under conditions as close to different real situations as possible Considering available options, we have three venues to pursue First, we can run detection scenarios on test beds, which are usually of limited size and thus any results are of limited credibility Second, we can use collected network traces and run our tested detection engines against them Of course, there are almost no publicly available network traces, so we have to collect them by ourselves - a rather time consuming and tedious process Then we have to take into account the place where the network trace is going to be collected - it is one thing to collect statistics on a number of backbone nodes and completely another if we are limited only to our own local network traffic Consider also that during time the nature of traffic changes For example, during late 80s and early 90s majority of the Internet traffic was either FTP or e-mail During late 90s it was all about Web traffic Nowadays a substantial amount of traffic is due to peer-to- peer applications Third, we can use network simulators which allow verification of scenarios to be run and are easily scalable to hundreds and possibly thousands of nodes, allowing us to test complex topologies with different kinds of traffic flows The last option is probably the only solution if we are aiming our research to be independently verified and consequently accepted by academic community As a standard defacto in network simulation is ns-2 network simulator [4], we are obviously interested in implementing any detection mechanisms in ns-2 Currently, though, there is no publicly available code, neither in main ns-2 distribution, nor in code contributed by users, which performs any detection of denial of service attacks The detection mechanism which in my view merits foremost the outright implementation in the code for ns-2 simulator is non-parametric Cumulative Sum (CUSUM) algorithm, which is simple and efficient The CUSUM algorithm was shown to be optimal in terms of detection accuracy for parametric model and has good performance for nonparametric model [5] The efficiency of such an algorithm was evaluated and validated on the sets of collected network traces [6-10] As such implementation of CUSUM algorithm in the ns-2 would be of some value for researchers interested in detection of DDoS attacks in a simulated networking environment The CUSUM algorithm due to its low computational overhead is also a good candidate for implementation at routers of Internet Service Providers (ISP) as it allows real-time attack detection Prior to deployment of CUSUM algorithm in real life environment it would be beneficial to run the ns-2 simulation with the use of CUSUM detection algorithm to allow for tweaking of the algorithm parameters (to incorporate some of the real-life onsite conditions) - so the ISP operators can also benefit from the use of proposed ns-2 code My contribution in this paper is the actual code implementation of recursive nonparametric CUSUM algorithm for the ns-2 simulator which uses as its statistic measure the number of new network addresses, detected at a leaf router, where this mechanism is implemented/installed The justification for the validity of the choice of the statistic used is the observation in [11], where it was shown that during DDoS attacks most source IP addresses are new to a victim The rest of the paper is organized as follows Chapter introduces main concepts used in denial of service research, such as terminology used, accepted taxonomy and typical ways in which denial of service attacks are launched The impact of denial of service attacks on businesses is also briefly considered Chapter presents some known countermeasures against DDoS attacks They can be put into three separate groups, like attack prevention and preemption, attack detection and filtering, attack source traceback and identification Some of the examples from each of those groups are given Chapter presents CUSUM algorithm, used in our implementation and discusses its realization in the ns-2 network simulator Chapter offers conclusions we were able to gather from the network simulations using CUSUM algorithm Denial of service attacks 2.1 Terminology The denial of service (DoS) attacks can be divided into two groups: vulnerability attacks and flooding attacks First one, as the name suggests, is based on exploiting the vulnerabilities of a target machine/host or target application These vulnerabilities are typically either a software bug in the implementation or a bug in the configuration of a service The attacker sends to the target host a few messages in specific format which uses this given vulnerability As a programmer did not foresee the used particular input, then the application either considerably slows down or goes into infinite loop or freezes or completely crashes the whole system One of the classical examples of such an attack is a “ping-of-death” also known as “long ICMP” attack, which gained popularity in 1996 - 1997 [12] The ping request usually consists of 64 bytes (84 bytes including IP header) As most systems cannot handle an IP packet with size more than its allowed maximum size of 65,536 bytes, then upon receiving a packet of a size more than that a buffer overflow could happen, which quite often leads to a system crash Eventually, such a bug was fixed (it was done in late 1997 by issuing corresponding patches for different operating systems), and now “ping-of-death” is no more than the historical curiosity Obviously, this kind of attacks depends heavily on previously undiscovered weaknesses in network protocols/services and their implementations in software As soon as such a weakness is found, the system which runs corresponding application is open to the attack That’s why vulnerability attacks are hard to predict, as we not know what can go wrong Second group, flooding attacks (known also as saturation attacks) are designed to exhaust some of the key resources at the target, like bandwidth, CPU time, memory, etc For example, complex messages need more CPU cycles to process, lengthy messages take up bandwidth and messages/requests for new connections use up buffer memory As soon as all the resources are tied up, the legitimate users cannot access the service, i.e they are denied it The key here is that flooding attacks rely not on content but particularly on volume As we as an attacker start with only one host generating numerous requests to the target host, executing an attack, this situation is described as DoS - denial of service attack To bring down the target we would need to generate hundreds and thousands of packets per second to saturate the resource As such, this attack is easily identified and dealt with So instead we launch our attack from numerous hosts (preferably servers), distributing the generation of packets to the target host, thus the name DDoS - distributed denial of service attack Every packet stream from one of those hosts is aggregated at the target so we have an amplification of traffic Apart from a greater amplification factor there are other advantages to DDoS attacks, at least from the point a view of an attacker Usually a server machine has more processing power, memory and especially bandwidth than a client machine (a workstation) So using server machines the attacker has better chances of saturating a target Then there is a matter of stopping the attack If the attack comes from one single source and it is possible to trace it back, then in most cases it will be possible to stop it only if a source system owner/administrator manually does the action If we have 1000 attack sources, then we would need to contact 1000 different system administrators to stop them And getting thousands of people to something is an overwhelming challenge In order to perform DDoS attack from numerous hosts first we need to gain access to them As such those compromised hosts are often called the “secondary victims/targets” and the host/system/network under attack itself is called the “primary victim/target” The use of secondary targets allows attackers to use much larger base of packet generating hosts while providing higher degree of anonymity as real flooding attack is performed by secondary sources so tracking down a real attacker becomes a formidable task Another benefit for the attacker, as was mentioned earlier, is that the aggregation of attack traffic is done only at the target so we can restrict our packet generation rates to much lower values and it becomes very hard to distinguish this kind of traffic at the source networks and intermediate nodes on the way to the target As DDoS attacks are much more disruptive, currently the majority of research on denial of service attacks is done with emphasis on distributed systems The Figure provides an illustration on how the denial of service attack is performed [13] To some extent the modus operandi of an attacker can be compared to the way a military strategist plans a campaign First off we need to establish a base of operations We start from an attacker’s computer usually referred to as a client - a system from which we communicate with the rest of the DDoS attack system Then we begin scanning the Internet in search of hosts with vulnerabilities we can explore, i e hosts with nonexistent or weak security When such a host is found we install on this system a handler - software package which is used to further control DDoS attack system On other compromised hosts we install agents - somewhat simpler software packages which are going to be used to carry out an attack against a target Agents are also alternatively referred to as zombies Handlers are used to identify which agents are active, when to launch the attack, when to update agents and so on, basically performing control functions Agents, though, are responsible only for actual attack traffic generation Figure Distributed denial of service attack [13] handier Typically the owners of Mack is launch ad from the handler A Cnee the attack, has been launched, the handler can be taken offline (i.e if it’s detected) with the agents able to independent!/ continje with the attack Attack preparation: as much systems as passible are compromised with classic system penetration techniques, and then DDoS agents are installed compromised systems have no knowledge of the presence of agents Those agents can be configured to be in connection either with a single handler or numerous ones And finally, we launch an attack from agents, flooding the target system, thus using greater amplification factor of DDoS Once the attack is in progress we can take the handler offline, to make it impossible to trace the attack back to us To make it harder to distinguish attack traffic from legitimate communications, handlers are installed at routers or network servers with high volume of traffic thus masking messages between the client and the handler, and between the handler and agents This scenario is usually referred to as “agent-handler model” Its variation is “IRCbased model” where instead of using handlers the communication between an attacker and agents is done using IRC (Internet Relay Chat) channel [14] To summarize, it can be noted that the choice of P influences our detection sensitivity the larger P we have (the bigger offset in negatives of a sequence zn) - the less likely a value will appear in zn that is going to be more than zero In its turn, it is less likely that the test statistic will accumulate enough to merit the attack flag being set “up” The larger the threshold N, the more time delay before detecting an attack Set threshold too high, and an attack with sufficiently low intensity will not be detected at all Conclusion As a result of my work on the thesis, the recursive non-parametric CUSUM algorithm for detection of DDoS attacks was successfully implemented in ns-2 simulator The analysis of its operation confirms its efficiency and robustness The use of the developed code allows us to test numerous distributed denial of service attack scenarios in regard to the ability of the CUSUM algorithm to detect them A possibility to use network simulation instead of relying on real-life network traces should be beneficial for further testing and development of detection techniques At the same time it is necessary to note, that CUSUM algorithm which uses the number of new source network addresses as its statistic, though very effective and computationally simple, is still vulnerable to DDoS attacks It is especially true when an attacker is aware of the presence of CUSUM detection mechanism at the target’s network For example, an attacker can direct his agents to visit target’s host some time before a real attack As these low-intensity visits usually will look like legitimate requests, the source addresses of agents will be entered into address database, i.e considered legitimate So as the real attack commences, the detection engine will not recognize attackers as being ones To provide defense against this kind of a hack, we can check whether or not any source address has abnormally high traffic flow, as DDoS attacks rely not only on high number of agents but also on the high number of messages generated by every agent Figure 20 yn vs time Threshold N = 0.3, P = 0.1 Observation time interval is seconds The possible future goal in continuation of the work done in my view would be to provide a working code optimized for the use as either an integral part of ns-2 distribution package or as third-party contributed module/code In this regard we could try to implement CUSUM algorithm not only to DropTail queuing but also to other kinds of queuing mechanisms, available in ns-2 Also some kind of algorithm optimization is necessary For example, to use the hash table for keeping record on the number of new addresses instead of using simple arrays and thus to optimize algorithm’s performance in database lookup, speeding up its execution Finally, having shown that CUSUM algorithm is quite efficient for detecting DDoS attacks in simulated networking environment, the real proof of its practical validity is going to be its implementation in the real situation For example, as Lappeenranta University of Technology possesses a sophisticated networking environment, it would be very interesting to deploy CUSUM detection mechanism at some of its leaf routers, which connect university’s network to the rest of the Internet Certainly kernel network stack of some of the Linux based machines can be modified to include this detection engine This would allow us to test algorithm’s performance and sensitivity under real-life conditions References Gary C Kessler Defenses Against Distributed Denial of Service Attacks November 2000 [cited 2007 23 November]; Available from: http://www.garykessler.net/library/ddos.html Computer Security Handbook, ed S Bosworth, M E Kabay 2002: Wiley p 1224 X Genf, Andrew B Whinston Defeating distributed denial of service attacks IT Professional, 2000 2(4): p 36-42 User information - Nsnam [cited 2007 23 November]; Available from: http://nsnam.isi.edu/nsnam/index.php/User Information B E Brodsky and B S Darkhovsky Nonparametric Methods in Change- Point Problems 1993: Dordrecht, The Netherlands: Kluwer Figure 20 yn vs time Threshold N = 0.3, P = 0.1 Observation time interval is seconds Hellinton H Takada, Ulrich Hofmann Application and Analyses of Cumulative Sum to Detect Highly Distributed Denial of Service Attacks using Different Attack Traffic Patterns [cited 15 November 2007]; Available from: http://www.istintermon.org/dissemination/newsletter7.pdf H Wang, D Zhang, and Kang G Shin Change-Point Monitoring for the Detection of DoS Attacks IEEE Trans Dependable Secur Comput., 2004 1(4): p 193-208 T Peng, C Leckie, K Ramamohanarao Detecting Distributed Denial of Service Attacks Using Source IP Address Monitoring [cited 15 December 2007]; Available from: http://www.cs.mu.oz.au/~tpeng/mudguard/research/detection.pdf 10 H Wang, D Zhang, Kang G Shin Detecting SYN Flooding Attacks in INFOCOM 2002 Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies IEEE 23-27 June 2002 pp 15301539 11 H Wang, D Zhang, Kang G Shin SYN-dog: Sniffing SYN Flooding Sources in Proceedings of the 22nd International Conference on Distributed Computing Systems (ICDCS'02) 2002 p 421 12 J Jung, B Krishnamurthy, and M Rabinovich Flash crowds and denial of service attacks: characterization and implications for CDNs and web sites, in Proceedings of the 11th international conference on World Wide Web 2002: Honolulu, Hawaii, USA 13 Ping of death [cited 2007 30 November]; Available from: http://en.wikipedia.org/wiki/Ping of death 14 P Rotondo Denial of service attacks and countermeasures [cited 2007 23 November]; Available from: http://www.dsi.uniroma1.it/Sicurezza/doc/dosAttacks.pdf 15 Stephen M Specht and Ruby B Lee Distributed Denial of Service: Taxonomies of Attacks, Tools, and Countermeasures, in Proceedings of 17th International Conference on Parallel and Distributed Computing Systems, 2004 International Workshop on Security in Parallel and Distributed Systems September 2004 Figure 20 yn vs time Threshold N = 0.3, P = 0.1 Observation time interval is seconds 4 16 S Specht and R.Lee Taxonomies of Distributed Denial of Service Networks, Attacks, Tools, and Countermeasures 2003, Department of Electrical Engineering Princeton Architecture Laboratory for Multimedia and Security, Technical report CE-L2003-03 17 J Mirkovic, J Martin, and P Reiher A Taxonomy of DDoS Attacks and DDoS Defense Mechanisms 2001, University of California: Los Angeles Technical report #020018 18 A Hussain, J Heidemann, and C Papadopoulos A framework for classifying denial of service attacks, in Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications 2003: Karlsruhe, Germany 19 Smurf attack [cited 2007 20 November]; Available from: http://en.wikipedia.org/wiki/Smurf attack 20 Possible DoS (fraggle) Problem [cited 2007 November]; Available from: http://www-arc.com/sara/cve/Possible DoS problem.html 21 SYN flood [cited 2007 25 November]; Available from: http://en.wikipedia.org/wiki/SYN flood 22 Morris worm [cited 2007 November]; Available from: http://en.wikipedia.org/wiki/Morris Worm 23 Computer History Museum - Exhibits - Internet History - 1980's [cited 2007 15 November]; Available from: http://www.computerhistory.org/internet history/internet history 80s.shtml 24 ISC Domain Survey: Number of Internet Hosts [cited 2007 20 December]; Available from: http://www.isc.org/index.pl7/ops/ds/host-count-history.php 25 CSISurvey 2007 [cited 2007 December]; Available from: http://www.gocsi.com/ Figure 20 yn vs time Threshold N = 0.3, P = 0.1 Observation time interval is seconds 26 D Moore, C Shannon, Douglas J Brown, Geoffrey M Voelker, and S Savage Inferring Internet Denial-of-Service Activity ACM Transactions on Computer Systems, 2006 May 24(2): p 115-139 27 Distributed Denial of Service (DDoS) Attacks/tools [cited 2007 December]; Available from: http://staff.washington.edu/dittrich/misc/ddos/ 28 Rocky K.C Chang Defending against flooding-based distributed denial-of- service attacks: a tutorial IEEE Communications Magazine 2002 40(10) p 42-51 29 P.Ferguson, D.Senie Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing 2001, RFC 2827 30.Help Defeat Distributed Denial of Service Attacks: Step-by-Step [cited 2007 23 November]; Available from: http://www.sans.org/dosstep/ 31 K.Park, H.Lee On the Effectiveness of Route-Based Packet Filtering for Distributed DoS Attack Prevention in Power-Law Internets in ACM SIGC0MM'01 Applications, technologies, architectures, and protocols for computer communications 2001 New York: ACM Press 32 T Peng, C Leckie, and K Ramamohanarao Protection from Distributed Denial of Service Attack Using History-based IP Filtering in IEEE International Conference on Communications (ICC 2003) 2003 Anchorage, Alaska 33 Hopper, D.I Denial of service hackers take on new targets [cited 15 November 2007]; Available from: http://archives.cnn.com/2000/TECH/computing/02/09/denial.of.service/ 34 IBM Proventia Network Intrusion Prevention System (IPS ) [cited December 2007 ]; Available from: http://iss.net/products/Proventia Network Intrusion Prevention System/prod uct main page.html 35 Snort - the de-facto standard for intrusion detection/prevention [cited 2007 December]; Available from: http://www.snort.org/ Figure 20 yn vs time Threshold N = 0.3, P = 0.1 Observation time interval is seconds 36 R R Talpade, G Kim, S Khurana Nomad: Traffic-based Network Monitoring Framework for Anomaly Detection in Fourth IEEE Symposium on Computers and Communications 1998, pp 442-451 37 J.B.D Cabrera, L Lewis, X Qin, W Lee, R.K Prasanth, B Ravichandran, and R.K Mehra Proactive detection of distributed denial of service attacks usingMIB traffic variables-a feasibility study in Integrated Network Management, 2001 IEEE/IFIP International Symposium 2001 Seattle, WA pp 609 - 622 38 M Basseville and I V Nikiforov Detection of Abrupt Changes: Theory and Applications 1993: Englewood Cliffs, NJ: Prentice-Hall 39 J Mirkovic, P Reiher D-WARD: a source-end defense against flooding denial-ofservice attacks Dependable and Secure Computing, IEEE Transactions on, JulySeptember 2005 2(3): p 216 - 232 40 Thomer M Gil and M Poletto MULTOPS: a data-structure for bandwidth attack detection in 10th Usenix Security Symposium 2001 Washington, DC 41 S Bellovin 2000 ICMP Traceback Messages, Network Working Group, Internet Draft 42 A Mankin, D Massey, C L Wu, S F Wu and L Zhang On Design and Evaluation of IntensionDriven ICMP Traceback in 10th International Conference on Computer Communications and Networks 2001 Arizona 43 S Savage, D Wetherall, T Anderson, A Karlin Network support for IP traceback IEEE/ACM Transactions on Networking, 2001 9(3): p 226-237 44 J Ioannidis, S M Bellovin Implementing Pushback: Router-Based Defense Against DDoS Attacks in Network and Distributed System Security Symposium 6-8 February 2002 San Diego, California Figure 20 yn vs time Threshold N = 0.3, P = 0.1 Observation time interval is seconds 45 Vasilios A Siris and Fotini Papagalou Application of Anomaly Detection Algorithms for Detecting SYN Flooding Attacks Computer Communications, 2006 29: p 14331442 46 NS by Example - Network Components [cited 2007 14 December]; Available from: http://nile.wpi.edu/NS/ Appendix A Below follows source code of the header file drop-tail-ddos.h describing the CUSUM algorithm implementation in C++ * * * * * * * * * * * * * * * * * * * /* -*- Mode:C++; c-basic-offset:8; tab-width:8; indent-tabs-mode:t -*- */ /* Copyright (c) 1994 Regents of the University of California All rights reserved * Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the Computer Systems Engineering Group at Lawrence Berkeley Laboratory Neither the name of the University nor of the Laboratory may be used to endorse or promote products derived from this software without specific prior written permission * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ''AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR *PURPOSE ARE DISCLAIMED IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR *CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * *INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER *IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR *OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF *ADVISED OF THE POSSIBILITY OF SUCH DAMAGE Figure 20 yn vs time Threshold N = 0.3, P = 0.1 Observation time interval is seconds * * @(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/queue/drop-tail.h,v 1.17 2002/01/01 04:26:10 sfloyd Exp $ (LBL) */ #ifndef ns_drop_tail_h #define ns_drop_tail_h #include #include "queue.h" #include "config.h" * /* A bounded, drop-tail queue */ class DropTailDDoS : public Queue { public: DropTailDDoS() { q_ = new PacketQueue; pq_ = q_; bind_bool(" drop_front_", &drop_front_); bind_bool("summarystats_", &summarystats); bind_bool("queue_in_bytes_", &qib_); // boolean: q in bytes? bind("mean_pktsize_", &mean_pktsize_); // _RENAMED("drop-front_", "drop_front_"); } ~DropTailDDoS() { delete q_; } protected: /*struct address_database { nsaddr_t node_address; double arrival_time; };*/ //static address_database database; static nsaddr_t database_a[100]; static double database_t[100]; static nsaddr_t database_a_last[100]; static double database_t_last[100]; static nsaddr_t database_filtered[100]; static double database_filtered_t[100]; static int attackDetected; static double attackThreshold; static double statistic; static int nodeColor; void databaseUpdate(nsaddr_t address_, double time_); void database_last_Print(); void database_current_Print(); void databaseCheck(); void databaseFilteredAdd(nsaddr_t address, double tiime); void databaseLastAdd(); void reset(); void changeColor(int color); int command(int argc, const char*const* argv); void enque(Packet*); Packet* deque(); PacketQueue *q_; /* underlying FIFO queue */ int drop_front_; /* drop-from-front (rather than from tail) */ int summarystats; //void print_summarystats(); int qib_; /* bool: queue measured in bytes? */ int mean_pktsize_; /* configured mean packet size in bytes */ }; #endif Figure 20 yn vs time Threshold N = 0.3, P = 0.1 Observation time interval is seconds Appendix B Below follows the source code of the file drop-tail-ddos.cc which is the implementation of CUSUM algorithm written in C++ on the basis of DropTail queuing class * * * * * * * * * * * * * * * * * * * * * /* -*- Mode:C++; c-basic-offset:8; tab-width:8; indent-tabs-mode:t -*- */ /* Copyright (c) 1994 Regents of the University of California All rights reserved * Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the Computer Systems Engineering Group at Lawrence Berkeley Laboratory Neither the name of the University nor of the Laboratory may be used to endorse or promote products derived from this software without specific prior written permission * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ''AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE */ #ifndef lint static const char rcsid[] = "@(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/queue/drop-tail.cc,v 1.15 2003/01/16 19:02:54 sfloyd Exp $ (LBL)"; #endif #include "drop-tail-ddos.h" nsaddr_t DropTailDDoS::database_a[100] = {0,0}; double DropTailDDoS::database_t[100] = {0,0}; nsaddr_t DropTailDDoS::database_a_last[100] = {0,0}; double DropTailDDoS::database_t_last[100] = {0,0}; nsaddr_t DropTailDDoS::database_filtered[100] = {0,0}; double DropTailDDoS::database_filtered_t[100] = {0,0}; int DropTailDDoS::attackDetected = 0; double DropTailDDoS::attackThreshold = 0.3; double DropTailDDoS::statistic = 0; int DropTailDDoS::nodeColor = 0; static class DropTailDDoSClass : public TclClass { public: DropTailDDoSClass() : TclClass("Queue/DropTailDDoS") {} TclObject* create(int, const char*const*) { return (new DropTailDDoS); } } class_drop_tail_ddos; void DropTailDDoS::reset() { Queue: :reset(); } int DropTailDDoS::command(int argc, const char*const* argv) { if (argc==2) { if (strcmp(argv[1], "databaseCheck") == 0) { databaseCheck(); return (TCL_OK); } } if (argc == 3) { if (!strcmp(argv[1], "packetqueue-attach")) { delete q_; if (!(q_ = (PacketQueue*) TclObject::lookup(argv[2]))) return (TCL_ERROR); else { pq_ = q_; return (TCL_OK); } } } return Queue: :command(argc, argv); } * /* drop-tail */ void DropTailDDoS::enque(Packet* p) {int iii,count = 0; if (summarystats) { Queue::updateStats(qib_?q_->byteLength():q_->length()); } int qlimBytes = qlim_ * mean_pktsize_; hdr_ip *ipheader = hdr_ip::access(p); nsaddr_t node_number = ipheader->saddr(); double current_time = NOW; //printf("packet arrived from node %d at time %f\n", node_number,current_time); databaseUpdate(node_number,current_time); //databasePrint(); //Find out if the source address of this particular incoming packet is one of those //new source addresses Done by comparing the address with a database of new addresses //We this checkup only when the node is under DDoS attack as indicated by the variable } //attackDetected, which should hold true, i.e.to be equal to if (attackDetected == 1) {for(iii=0;iiilength() + 1) >= qlim_) || (qib_ && (q_->byteLength() + hdr_cmn::access(p)->size()) >= qlimBytes)){ // if the queue would overflow if we added this packet if (drop_front_) { /* remove from head of queue */ q_>enque(p); Packet *pp = q_->deque(); drop(pp); } else { drop(p); } } else { q_->enque(p); } } Packet* DropTailDDoS::deque() { } if (summarystats && &Scheduler::instance() != NULL) { Queue::updateStats(qib_?q_->byteLength():q_->length()); } return q_->deque(); /*void DropTailDDoS::print_summarystats() { } //double now = Scheduler::instance().clock(); printf("True average queue: %5.3f', true_ave_); if (qib_) printf(" (in bytes)"); printf(" time: %5.3f\n", total_time_); */ void DropTailDDoS::databaseUpdate(nsaddr_t address_, double time_) {int i; for(i=0;i