Keywords

1 Introduction

The main goal of DDoS attacks is to make a network resource unavailable to its users. Every year there is an increase in the number DDoS attacks, their power and complexity and hence the harm they can do. According to the report of the Arbor Network [1], more than 60 % of companies that have been questioned detected more than 10 DDoS attacks per month in 2014. By the year 2015 the main victims of such attacks are not only servers of different companies and Internet providers, but also their clients. New types of DDoS attacks appear and one of destroyable type of attacks is so called Reflection attacks. These attacks use servers to reflect and amplify the malicious traffic. Nowadays Network Time Protocol (NTP) Reflection attacks using NTP servers became very popular. This means that it is necessary to develop new efficient protection mechanisms against DDoS attacks. Development of new protection systems and testing of real networks for stability to DDoS attacks requires significant hardware, temporal, and financial costs. For this reason in order to perform such experiments we suggest using computer simulation techniques.

As against of our previous papers [2, 3] we would like to present the system, having included the possibility of using real nodes connected to a virtual network. Such an approach has made it possible to significantly increase the adequacy of DDoS attack simulation on transport and application levels. The system has been verified for a real network. The paper is devoted to the experiments for simulating different types of DDoS attacks in the developed environment. The authors have conducted the experiments of simulating DDoS attacks on transport and application levels. We have simulated the attacks using the protocols of TCP (for SYN-flooding) and UDP (for Chargen and Echo attacks). Attack simulation on an application level has been performed. Section 2 discusses related work. Section 3 specifies formal models of main components. In Sect. 4 we briefly represent the architecture and implementation. Sections 5 and 6 consider examples of experiments. Section 7 and Conclusion outline application of the developed system, main results and further research.

2 Relevant Works

Nowadays a large number of researches and companies are looking for the most efficient ways of service protection against DDoS attacks [3]. In [4] one can get acquainted with a system that uses Spirent Test Center [5] as a device generating traffic. This work contains templates for setting IP-address configurations and attack scenarios. In order to deal with similar tasks it is also possible to use the environment produced in 2014 by the company MazeBolt’s Team [6]. Using this environment we can generate different types of DDoS attacks of the power up to 20 000 Mbit/sec. [7] considers a system developed by Ixia [8]. The authors point out that the system makes it possible to provide protection against DDoS attacks of the power of 70 Gbits/sec. In real time. ViSe [9] is a system for simulating the main most widespread attacks (40 different scenarios). In [2] we can read about a DDoS attack simulation system, which allows us to simulate a network with different behavior of clients inside it.

The system introduced in our paper allows us to construct virtual networks with a high degree of adequacy. Furthermore, the system makes it possible to introduce any known protection mechanism or the one created by the user. Protection mechanisms can be architecture-dependent, which also allows us to conduct experiments in the way most close to a real network. An important advantage is the possibility of connecting real nodes to a virtual network, which will make it possible to improve the accuracy of the experiments and also to test various settings and types of servers.

3 Specification of Simulation Components

In order to understand the structure of the developed simulation components, it is necessary to specify the parameters of their models. The formal model of the network is defined as follows: \( Network\,\, = \,\,\left\langle {NetConf,\,\,Router_{1..q} ,\,\,Host_{1..n} ,\,\,Server_{1..m} \,\,} \right\rangle ,\,\, \) where NetConf — network configuration, Router — routers, Host — hosts, Server — servers.

Network configuration \( NetConf\, = \,\,\left\langle {IPStart,\,\,ExtIP,\,\,ServPath,\,\,NetPar} \right\rangle ,\, \) where IPStart — initial IP-address for assignment to hosts, for example, if IPStart = “1.0.0.1”, and a network consists of 20 hosts (personal computers (PCs), routers, servers), then the IP address of the last host is 1.0.0.20; ExtIP — IP address of the external server; ServPath — the path to the virtual server, which will be a plug (it reflects the position of the real server) for the virtual network; NetPar — on the basis of the above components each network host will receive its interface settings and routing tables.

Model of the router \( Router_{k} \,\, = \,\,\left\langle {NetPar,\,\,NPcap,\,\,Def_{0..n} ,\,\,ExtDevN_{0..q} ,\,\,DelConf} \right\rangle , \) where NetPar — router’s parameters obtained during initialization of Netconf; NPcap — the number of modules to account the traffic flow; Def — a protection algorithm running on the router, this algorithm is implemented in software, the router may use any number of algorithms; ExtDevN — the number of interfaces connected to the external network, required for routers which contain an external host in their local network; DelConf — configuration of packets delay, it is used that the virtual network would have the characteristics of the real network. Model of virtual clients \( Host_{k} = \left\langle {NetPar,\,\,DDoSApp_{0..1} } \right\rangle , \) where NetPar — client’s settings received under initialization of Netconf; DDoSApp — an application that will perform the attack for a given scenario. Model of attacks against the server includes the following options: \( DDoSApp\,\, = \,\,\langle VictimPath,\,\,AType,\,\,Lvl,\,\,Dport,\;DeltaT,\,\,AStart,\,AEnd,\,MaxP,\,SpecialP\rangle , \) where VictimPath — a path to the victim server (to empower attacks against several servers); Atype — type of the attack against the server: 1 — HTTP Flooding, 2–7 — different variants of TCP Flooding (SYN, SYN-ACK, RST, UDP, etc.); Lvl — the percent of clients involved in the attack;; Dport — destination port, it is defined in a random manner; DeltaT — the time between packets (in the case of HTTP Flooding it is the time between sessions); AStart, AEnd — start and end time of the attack; various conditions for this interval can be set; MaxP — the maximum number of packet sendings (in the case of HTTP attacks — sessions); SpecialP — specific attack parameters, i.e. for HTTP it is a string of the HTTP query, for TCP — the type of the sender’s IP address spoofing. The developed models allow connecting any number of external servers to the virtual network. In the router it is also possible to configure the attack scenarios and the DDoS protection methods.

4 Architecture and Implementation of a Simulation System

The architecture of the developed system can be represented as a set of several components (Fig. 1). On the first level of the component hierarchy we can find a discrete-event simulation system OMNeT++ [10]. The second level of hierarchy is represented by a model of a computer network. In order to adjust the network and set package switching the INET library is used [11]. The library ReaSE [12] has been completed for topology settings. The authors ceased to support it in 2011 and therefore it was renewed for working with the version OMNeT++4.5. The third level contains the models of hosts and routers that are included in the network. The server model is related to both this level and the next one. The fourth level contains the following models developed: an application for performing attacks according to the given scenario; traffic accounting modules; a container for protection algorithms, which can be installed at different network nodes. The models and architecture that have been created were used for developing a hybrid simulation system. In order to provide virtualization of operating systems and computational resources, VirtualBox и Vmware [13, 14] have been applied. The possibilities for risk analysis [15, 16] can be added.

Fig. 1.
figure 1

Common architecture of modeling system

Full size image

Examples of settings for created components are shown below. Figure 2 depicts an example of the topology which includes models Network, NetConf, NetPar. This topology contains a Web-server, routers, gateways and hosts. Every node can be configured by user any time. Example of settings for NetConf is shown in Fig. 3.

Fig. 2.
figure 2

Example of the created topology

Full size image
Fig. 3.
figure 3

An example of settings for the network configuration model

Full size image

It should be noted that the range of addresses, the real IP address of the server belongs to, must not overlap with IP addresses of virtual PC. This is to ensure that the server’s responses are forwarded to computer of the virtual network. For the experiments we used a computer with the following characteristics: processor is Intel Core i7-3770, 3,4 Ghz, 8 cores; RAM is 15, 6 GB DDR3 1600 MHz; Operating system is Ubuntu 14.04 64-bit. The developed system can also be deployed on the Windows computers. The system currently operates in a single-threaded simulation mode. More than 200 virtual desktops are used, they can attack with the delay of 10 ms. During attack simulations the capacity of the core is 50 %.

5 Experiments with Attacks on Transport Level

The authors have conducted a series of 10 experiments devoted to simulating an attack of the type SYN-Flooding In order to successfully perform a SYN-flooding attack, SYN cookies were switched off on a server. The attack involves 200 hosts generating packages with a frequency of 2 packages per second. 3 hosts are attacking throughout the whole experimental time; the rest are included in an attack in a distributed way from the 10th to the 35th second of the experiment and stop package generation in the interval from the 50th to the 70th seconds. Figure 4 shows SYN packages sent to a server from a virtual network; the line shows the mean value for 10 experiments and errors are also demonstrated. Server responses are represented in a similar way without repeated sending of SYN-ACK for semiopen connections that have already been established.

Fig. 4.
figure 4

Plot of the traffic log for SYN flooding against the server

Full size image

Only 3 clients applied to the server prior to the 10th second. At the beginning of an attack, on the 10th second, the number of server applications increases because more and more virtual clients are beginning to take part in the attack. Till the 14th second the server manages to process all messages and after that the TCP-stack is overfilled and the server is unable to deal with an increasing flow of applications. Then, beginning from the 50th second and ending with the 70th second virtual clients are leaving the attack. 3 clients are applying to the server again from the 70th on the 88th second. Simulation was stopped at the 88th second. In the period from the 14th second till the 68th second the server did not respond to SYN-packages.

The experiments devoted to attack simulation and based on the UDP-protocol used the network consisting of 100 computers. The attacking packages were sent at a rate of 2 packages per second. The nodes started generation of malicious packages from the 1st to the 20th seconds and terminated the attack from the 40th to the 60th seconds. The Chargen attack is performed by sending a large number of packages to the UDP-port of the 19th victim computer. This causes the server to generate responses consisting of a random set of symbols. Thus, it is possible to reboot the server and reduce its efficiency. The solid line in Fig. 5 shows malicious traffic arriving at an attacking server. Prior to the 20th second we can notice traffic rise, which remains invariable till the 40th second. Then, the number of malicious packages starts to decrease. The dashed line shows server responses (chargen). After sending some number of responses the server becomes inactive and instead of UDP-packages generates ICMP-messages about the server unavailability. ICMP-messages are shown in the plot by the dot-and-dash line. Traffic resending is reached when a server being attacked has to send return packages to the UDP-port of the 19th sender, which generates return chargen packages to the server.

Fig. 5.
figure 5

Server traffic for a chargen attack

Full size image

Figure 6 shows server traffic during an attack with resending. The solid line indicates incoming malicious packages coming from different UDP-ports except the 19th one. The dot line shows incoming UDP-packages sent from the 19th port of attacking nodes, i.e. obtained during resending. The dashed line (short dashes) shows chargen server responses. The curve of chargen responses almost completely coincides with the curve of resent packages. The line with long dashes shows ICMP-messages of the server telling us that the server is currently unavailable.

Fig. 6.
figure 6

Server traffic for a chargen attack with resending

Full size image

Attack Echo is carried out by sending a large number of packets on the UDP port 7 of a victim computer. This causes the server to generate responses that mimic the incoming packet. As Chargen, this attack leads to overload of the server, and reduces its productivity.

Figure 7 outlines by the solid line the malicious traffic directed to the target server. The traffic increases up to 20 s, then it remains unchanged up to 40 s, and further the number of malicious packets is reduced. The dashed line shows the server’s response (echo). After sending a certain number of responses the server becomes inactive and generates ICMP packets (instead of UDP ones) that the service is not available. The graph demonstrates the ICMP packets by the dotted line. Bounced traffic is generated when the attacked server needs to send response packets to the UDP port 7 of the sender, which in turn generates echo response packets to the server. However, the implementation of such an attack cannot achieve infinite loop, as the server, as in the previous case, at some time becomes inactive and does not respond to incoming traffic.

Fig. 7.
figure 7

Server traffic under an echo attack

Full size image

Figure 8 depicts by solid line the incoming UDP packets to the server, including bounced traffic. The dotted line shows Echo responses of the server. It can be seen that when the server responds to Echo requests the incoming traffic includes balanced Echo messages from attacking hosts. Dotted line represents the ICMP packets, indicating that the server is currently inactive.

Fig. 8.
figure 8

Server traffic under an echo attack with bounced traffic

Full size image

6 Experiments with Attacks on Application Level

An HTTP-Flooding attack is reached by sending a large number of GET queries to the port 80 and as a result the server becomes incapable of processing other queries. A series of 10 experiments has been conducted and 200 hosts are involved in the attack. Each host initiates a TCP-connection with an HTTP-query at a rate of 2 packages per second. The queries are processed by the server using the PHP script, which increases the server load. Due to increasing load the server response time increases with the increase of the number of hosts. The host studied is participating in the attack during the whole experiment; other hosts are included in the attack in a distributed way from the 10th to the 40th seconds and stop package generation from the 70th to the 90th second. The plot (Fig. 9) shows the dependence of session duration from its number. The line shows the mean value for 10 experiments and the errors are also indicated. As can be seen from the plot, the server load increases during an attack, which makes the query processing time longer.

Fig. 9.
figure 9

Traffic log plot for HTTP flooding against the server

Full size image

Next NTP Reflection Attack was simulated. It is based on an NTP vulnerability consisting in the fact that if the packet with the request on the latest hosts, which asked for his time, was sent, the NTP-server will send the list of these hosts.

Attack of the type NTP Reflection Attack is implemented the following way. The attacking nodes send the queries get_monlist to an NTP-server; at the same time the source address is replaced with the address of a victim computer. In response to this command the server sends a package containing 600 IP-addresses applying to it earlier. We can gain 500 times attack increase. Consider a scenario when 30 % of computers included in a network are participating in the attack (Fig. 10).

Fig. 10.
figure 10

Server traffic for an NTP-attack (30 % of network computers are in an attack)

Full size image

Each of the attacking nodes generated 2 packages per second. One of the packages was a legitimate query to an NTP-server, i.e. a query for time synchronization. Address substitution has not been used. The second package contained the command get_monlist, and the IP-address of the source was replaced with the IP-address of a server being attacked. The nodes started sending packages in a distributed way from the 1st to the 20th seconds and terminated the attack from the 40th to the 60th seconds. The plot (Fig. 10) shows time dependencies of the number of queries and responses. The curves of legitimate queries and NTP responses and also get_monlist queries coincide completely and are shown by the solid line. Server responses to the command get_monlist are shown by the dashed line.

7 Discussion

There are many systems that can simulate DDoS attacks [3–9, etc.], including systems that generate real traffic for malicious attacks against legitimate sites. But they all have drawbacks that make it difficult to use them. The system presented in [5] cannot be applied to create defense mechanisms. The systems [6, 8] can provide protection against the attacks with limited power; moreover, these systems are very expensive. ViSe [9] requires a lot of hard disc space as well as a rather large number of settings for starting and repeating the tests. Our system can be considered not only as a packets generator for various types of DDoS attacks, but also as a research laboratory to investigate existing DDoS attacks and methods of protection against them. The main advantage of the developed system is that it allows creating and testing new distributed architecture specific defense mechanisms against DDoS attacks. This is achieved by the fact that by using this laboratory it is possible to create a large-scale computer networks consisting of thousands of nodes, generating as attacks as well as the legitimate traffic. The ability to use real hosts allows to work not only with the web server, but with any network services without the need for simulation, for example, with cloud computing systems.

The ability to use not emulated, but real software is very important to simulate DDoS attacks with the highest power, as different software can react differently to events taking place in its environment. For example, if the attacked host is an actual web server, it can have different hardware configurations, settings, software installed on it, so that the reaction of one attacked host may differ significantly from others. The virtual (simulated) part of the system also gives the possibilities to configure parameters of network interfaces for clients and routers (connection speed, performance of routers, etc.). Experiments have shown that the developed system allows quite accurate simulation of the behavior of attacked web servers. For example, in the experiments on SYN Flooding the server stops processing all SYN packets from clients. This corresponds to the official CERT document describing SYN Flooding [17].

8 Conclusion

In the present paper we have introduced the experiments devoted to simulation of different types of DDoS-attacks. The experiments were conducted in the modeling environment developed by the authors with the possibility of connecting real nodes. In the paper we have provided the experiments for attack simulation at transport and application levels. The experiments have shown that the developed system performs adequate simulation of the processes occurring in computer networks. The behavior of a server being attacked when it is overloaded corresponds to a real server. All the results and plots obtained during simulation in the developed environment are almost identical to the results that could have been achieved in a real network. The developed system can be used in the field of computer security for creating and testing protection mechanisms against DDoS attacks. In future we plan to use this environment for developing new protection techniques against DDoS attacks.