Simulation-based study of botnets and defense mechanisms against them

ISSN 1064�2307, Journal of Computer and Systems Sciences International, 2013, Vol. 52, No. 1, pp. 43–65. © Pleiades Publishing, Ltd., 2013.Original Russian Text © A.M. Konovalov, I.V. Kotenko, A.V. Shorov, 2013, published in Izvestiya Akademii Nauk. Teoriya i Sistemy Upravleniya, 2013, No. 1, pp. 45–68.

43

INTRODUCTION

Botnets allow intruders control millions of infected computers simultaneously, which helps constantlyincrease the number of cyber crimes. There examples of large�scale successful attacks performed usingbotnets. For example, as the result of the DDoS (Distributed Denial of Service) attacks aimed at govern�ment sites of Estonia in 2007 and Georgia in 2008, these sites were practically inaccessible for several days.In 2009, the Stuxnet botnet was discovered that affected SCADA systems and stole corporate intellectualproperty. On the FBI evidence as of October 2009, the losses due to botnets were as high as 100 milliondollars. The intensity of DDoS attacks, which is one of the most dangerous types of attacks using botnets,is increasing. According to the Worldwide Infrastructure Security Report published by Arbor Networks in2010, the total intensity of DDoS attacks in 2010 exceeded 100 Gb/s. It was mentioned that the intensityof DDoS attacks more than doubled compared with 2009 and increased more than tenfold comparedwith 2005.

Presently, increased competition in the market of botnets is observed. At the end of 2009 and in thebeginning of 2010, a number of new programs for implementing botnets appeared, such as Filon, Clod,Buga, Spy Eye, and others. It is clear that the number and power of botnets is going to grow; therefore,taking into account the fact that they are dangerous, botnets and the adequate defense methods should bestudied. one of the method allowing one to analyze the operation of botnets and the correspondingdefense mechanisms is based on simulation.

This paper is devoted to the study of botnets propagating using computer worms and used to executeDDoS attacks; the study uses simulation techniques. The paper is based on earlier publications of theauthors [1–7]; however, in distinction from those papers, it contains a description of the architecture ofthe implemented software environment and a description of the series of experiments aimed at the simu�lation of bonnets and defense mechanisms against them. The architecture of the software environmentwas considerably revised and the models of attacks and defense mechanisms were improved; a compo�nent�oriented approach for the representation of architecture is used. Many new experiments were added,their representation and analysis methods were improved. This enabled us to compare the capabilities ofthe defense methods against botnets in the course of their development.

1. RELATED STUDIES

We mainly used the results obtained in three directions of research—analysis of botnets as an Internetphenomenon [8–14] including studies on measuring parameters of botnets, development and improve�ment of methods of defense against modern botnets, and investigation of simulation of modern botnetsand defense mechanisms.

COMPUTER METHODS

Simulation�Based Study of Botnets and Defense Mechanisms against Them

A. M. Konovalov, I. V. Kotenko, and A. V. ShorovSt. Petersburg Institute for Informatics and Automation, Russian Academy of Sciences, St. Petersburg, Russia

e�mail: [email protected] October 20, 2011; in final form, May 11, 2012

Abstract—To defend oneself against botnet attacks, one must have tools that make it possible to inves�tigate the processes occurring on all stages of the lifecycle of botnets (propagation, control, attack) andpossess defense mechanisms that can counteract botnets. A simulation�based approach to the investi�gation of botnets and the corresponding defense mechanisms is proposed. The simulation is per�formed using a special software environment developed by the authors. The architecture of this envi�ronment and the libraries needed to create models of botnets and defense mechanisms are described.Experimental data demonstrating the capabilities of the simulation environment for studying various stagesof the botnet lifecycle and the efficiency of the corresponding defense mechanisms are discussed.

DOI: 10.1134/S1064230712060044

44

JOURNAL OF COMPUTER AND SYSTEMS SCIENCES INTERNATIONAL Vol. 52 No. 1 2013

KONOVALOV et al.

In the studies on the analysis of botnets, the definition of their lifecycle is given [10, 13, 14]. It consistsof the phases (or stages) of primary infection, propagation, control, and attack. The roles of the partici�pants of botnets are considered [13], features of the botnets with centralized [10, 14] and decentralized[8, 9, 13, 15] architecture are analyzed, and various types of attack executed using botnets are described.In [16], the efficiency criteria of botnet operation are discussed.

Publications describing defense methods against botnets can be divided into two groups: (1) signature�based methods [17] and (2) based on the search of local and network anomalies [18–22]. The advantagesof the first group of methods are the relative simplicity of implementation, which is often reduced to com�paring the observed stream of bytes with a set of signatures [27], and the low level of errors of the first andsecond kind. On the other hand, a significant drawback of signature�based methods is their inability todetect unknown types of botnets and the necessity to regularly update the base of signatures. The mainadvantage of the methods based on detecting anomalies over the signature�based methods is their abilityto automatically detect unknown types of botnets without knowing the details of their implementation [23];on the other hand, the methods of this group are more difficult to implement, and they are prone to errorsof the first and second kind.

Due to considerable differences in the course of botnet lifecycles phases, combined defense methodsare used that take into account the specific features of each phase operation. To defend oneself from a bot�net propagation by means of computer worms, the techniques based on virus throttling (VT) [24] andfailed connection (FT) [25] are used. VT is based on limiting the number of new connections from aunique IP address to other IP addresses in a given interval of time. The FC approach is based on the anal�ysis of TCP connections from a unique IP address. Packets in which the flags TCP RST and TCP SYN areset are tracked. If a host breaks connections in a certain time more frequently than a predefine threshold,then new requests for connection from this IP address are limited. Other approaches, such as ThresholdRandom Walk [26] or Credit Base�based Rate Limiting were also proposed.

In this paper, we describe botnets whose primary aim is to organize DDoS attacks. Methods used atdifferent phases of defense against DDoS attacks are considered. The Ingress/Egress Filtering [27] andSource Address Validity Enforcement (SAVE) protocol [28] approaches are considered as mechanisms forattack prevention; these mechanisms are used to filter the traffic for which the sender IP address is substi�tuted. Such attack detection methods as Source IP Address Monitoring (SIM) [29], Hop�Count Filtering(HCF) [30], Detecting SYN Flooding [31], and others are analyzed.

We also examine the defense method aimed at detecting botnets of various architectures. The botnetarchitecture is determined based on the control protocol used in this botnet. Presently, IRC, HTTP andP2P oriented botnet architectures are distinguished [14]. IRC�oriented botnets use IRC [32] as the com�munication protocol. They are classified as botnets with centralized architecture. In the greater part ofapproaches used to detect botnets of this type, packets on the network or application level are analyzed todetect known signatures or detect network anomalies [11, 18, 33, 34]. As a result of the traffic analysis ini�tiated by the suspected participants of the botnet, the subset of command center nodes is localized andneutralized; thus, the botnet is weakened. A considerable drawback of the botnet detection methods basedon the analysis of application�level protocols is that they cannot operate if the IRC packets are encrypted.To eliminate this drawback, some authors proposed methods that analyze exclusively the network�levelpacket flows to detect correlation between flows of packets outgoing from different nodes [21, 34].

HTTP�based botnets use the HTTP infrastructure as the communication environment. These botnets(see [5]) use the HTTP protocol as a carrier for intercommunications, which is performed using domainnames [36] of dedicated Web servers. The use of the HTTP protocol makes it impossible to apply themethods based on the analysis of data packet contents that were designed for IRC�oriented botnets.To detect botnets of this group, methods based on the detection of anomalies in the operation of domainname services (DNS) are used (e.g., see [37–39]).

P2P�oriented botnets have a decentralized architecture. In such botnets, an implementation of theP2P protocol (e.g., Chord [40] or Kademlia [41]) is used as the communication protocol. In the generalcase, the detection and neutralization of such a botnet is much more difficult than in the case of central�ized botnets. However, some authors propose methods for detecting P2P botnets; for example, epidemi�ological methods for detecting segments of botnets are proposed in [42]; namely, chains of nodes aretraced that form connections to a node that is known to belong to the botnet. In [43], anomalies aredetected using metrics obtained by processing the entropy of data flows by the nonparametric cumulativesums technique (NP�CUSUM).

The publications devoted to botnet simulation describe a wide range of methods and approaches.A large group of publications is devoted to the investigation of botnets using analytic models. For example,[44] describes a stochastic model of a decentralized botnet propagation; in this model, the botnet states


SIMULATION�BASED STUDY OF BOTNETS 45

and transitions between them are represented by a graph. The analytic model proposed in [45] demon�strates the dependence of the activity of potential botnet nodes on the time zone they are located in.

Another group of works uses simulation of botnets and computer networks as a whole as the main inves�tigation tool. These publications mainly rely on the methods for discrete event simulation of processes innetwork structures [46] and on trace�driven models that use traces of events registered in real�life com�puter networks [47]. In [48], a specially developed simulation system is used to experiment with wormpropagation. In [49], the simulation tool GTNetS was used to create a model of a computer worm. In [50],a model based on the Wormulator simulation tool [51] was constructed to simulate the propagation of theSlammer worm. In [52], a simulator is developed and a botnet propagation is simulated on the model con�sisting of 250 thousands of nodes. Mechanisms of defense against botnet propagation are also simulated.In [53], the distributed technique for detecting DDoS attacks called Distack is simulated using the simu�lator OMNeT++. Distack is based on the library ReaSE designed for constructing models of real�life net�work topologies and real�life traffic patterns of legitimate network applications. In [28], a specially devel�oped simulation environment and test benches were used to evaluate the efficiency, scalability, and cost ofthe implementation of the SAVE defense technique against DDoS attacks.

In this paper, we describe an approach to discrete event simulation at the packet level. Initially, thisapproach was designed for the simulation of network attacks and defense mechanisms. The operation ofa botnet is investigated, including the propagation, control, and attack phases, and defense mechanismsagainst the botnet at each phase of its lifecycle are studied.

2. ARCHITECTURE OF THE SIMULATION ENVIRONMENT

2.1. General Architecture of the Simulation Environment

The proposed simulation environment implements a set of models called BOTNET; in this set, antag�onistic processes of confrontation between attack and defense networks are simulated. As the contextunder consideration is specified, this set of models can be represented as a sequence of internal abstractionlevels: a model of discrete network events, a model of the computer network with packet switching, amodel of the network of network services, a model of attack network, and a defense network model.

Each next level is a refinement (subset) of the preceding level. The refinement is achieved by the defi�nition of new entities in the abstract model of the preceding level. Semantically, the BOTNET model canbe interpreted as a multilevel sequence of generalizations of various levels of abstraction. The variant ofthe semantic decomposition of BOTNET used in this paper is illustrated in Fig. 1. This decompositioncorresponds to the multilevel architecture of modern computer networks, and it allows one to design anddevelop a complete model step by step.

The hierarchy of representations is reflected in the structure of the set of implemented components.Being C++ classes, the components at each level are combined into libraries of components thus imple�menting the modularity property in the implementation of the BOTNET model and the principle of codereuse. This simulation environment is based on the library created by the authors of this paper and a num�ber of third�party libraries. The purpose of each library completely corresponds to the semantics of the

Level 4

Level 3

Level 2

Level 1

Мodelof the attack

Мodelof the defense

Мodel of the networkand network service

Мodel of the computer networkwith packet switching

Мodel of discrete eventson network structures

Specific

Sp

ace

of

con

cep

ts

Abstract

network network

Fig. 1. The hierarchy of representations used in the BOTNET model.

46


KONOVALOV et al.

same level. The level corresponding to the botnet and attack models is implemented by the authors of thepresent paper. The simulation system is implemented in C++, which is used in the components of all thelevels including the basic level that provides a universal platform for more specific upper level models.

The diagram illustrating the relationships between the semantic levels and implementation levels(libraries) is shown in Fig. 2. Each library joins the components determining a semantic level. Similarly tothe hierarchy of semantic representations, the library implementing a semantic level provides objects andcomponents for the implementation of the next semantic level; at the same time, it depends on the libraryimplementing the preceding level of the semantic hierarchy. Thus, the relationships between the librariescopy the relationships between the semantic representations (Fig. 2).

The first level is created using a general purpose discrete event simulation system; more specifically, thisis OMNeT++ [54]. It provides capabilities for the simulation of network structures of various topologiesand for the simulation of message propagation mechanisms in these structures. To model computer net�works based on network packet switching, the library of component INET Framework [55] is used. Thesecomponents are implemented in the discrete event simulation system OMNeT++; it contains a large setof components for modeling network devices, network protocols, components for their automatic config�uration, and models of elements of wired and wireless networks.

Realistic computer networks are simulated using the library ReaSE [56], which is an extension ofINET Framework. It provides tools for creating network topologies that are statistically identical to thetopologies of real�life computer networks; it is based on the papers [57, 58]; it includes models of realisticnetwork traffic simulated on the packet level. The network traffic models are implemented using themethod described in [59], which is based on the traffic generation that is statistically equivalent to the traf�fic observed in real�life computer networks. The subject area is simulated using the set of componentsdeveloped by the authors of this paper. These components are joined in the library called BOTNET Foun�dation Classes; they include models of applications related to botnets of various types.

According to the fourth level of the BOTNET model representation, the set of components is dividedinto two groups—components of the attack network and components of the defense network. The firstgroup includes the following components: those responsible for the propagation of the attack network inthe vulnerable network, for maintaining the controllability of the attack network, for the counteraction todetection and suppression of the attack network, and the components implementing models of DDoSattacks of various types. The second group includes the following components: those responsible for thedetection and suppression of the attack network at different phases of its lifecycle, for the effective con�trollability of the defense network, and for its connectivity (the latter components are models of the pro�tocols organizing centralized and decentralized networks).

The description of the BOTNET model in the form of a scenario tree is its sequential semantic decom�position. In the general case, the implementation of each scenario assumes that a subset of network nodes

Omnet++

C++Standard library

INET Framework classes

Rease classes

BOTNET Foundation Classes

Discrete event�based networksimulation

IP Network

Realistic computer network

Botnets, Defencing networks

Semantic levels Implementation levels(libraries)

Fig. 2. Relationship between the semantic and implementation levels.



is involved in the activity determined by the scenario purpose. Each node can participate in several sce�narios. Ultimately, the collective behavior of the set of participants is determined by the set of algorithmsof the individual behavior of the nodes included in the scenario. Various aspects of the node behavior areimplemented by the corresponding intermediate models.

In the general case, the model of an individual node can be represented by a set of intermediate modelsthat are connected by communication channels and interact with one another by exchanging messages.Each message received by a network node from the outside is first processed by the component that imple�ments the model of the hardware network interface via which the node is included in the network. Thenetwork interface model is a base in the model of the stack of OSI protocols implemented in the node.Next, the message is sequentially translated to the upper level of the stack of protocols until it reaches tomodel of an application. Semantically, the model of the application is semantically an extension of themodel of the stack of protocols; it is an implementation of the models of the corresponding applicationprotocols. The network applications are controlled by the user model that encapsulates the business logicof an end user or a bot simulating his or her behavior. According to the structure of scenarios, the behaviorof the BOTNET model is determined by the set of conditionally independent network processes. Themodel of legitimate traffic is based on the approach described in [59]; it is implemented using the compo�nents included in the library ReaSE [56].

The model of the attack network specifies a set of processes generated by the attack network. In thispaper, the model of the attack network is implemented in three relatively independent models: (1) modelof the attack network propagation, (2) model of the attack network organization, and (3) model of theattack per se. For each original process of the attack network, the defense network implements a reverseprocess whose aim is to counteract the attack. The defense network is implemented in three models:(1) model of counteraction to the attack network propagation, (2) model of counteraction to the attacknetwork organization, and (3) model of counteraction to the attack per se. In addition to the actions aimedat the counteraction to the actions of the attack network, the model of the defense network includes self�organization processes.

2.2. Models of the Attack Network

The model of the attack network propagation implements the scenario of the attack network spread�outin the space of the computer network. The purpose of this scenario is to add new nodes to the attack net�work. In this paper, it is represented by the model of propagation of a bot agent using the techniques forpropagating computer worms of various types. The participants of the botnet propagation are the compo�nents IP Worm and Vulnerable App, which are models of the network client and network server, respec�tively (see Fig. 3).

IP Worm is the client network application that broadcasts a viral network packet over the computer net�work. Here are the parameters of this type of application: the method used to select a victim node, themethod used to substitute the sender’s IP address, and interval of the viral packet broadcast. The data fieldof the viral packet contains addresses of the URL servers that are command centers used to first involvethe nodes to be infected in the attack network. The component Vulnerable App is a model of the serverapplication containing a vulnerability that manifests itself when a viral packet is received. The diagram ofinteraction between components is shown in Fig. 4.

Models of network applications interact by exchanging messages that simulate interprocess communi�cations within a node using the component Worm Activity Director. When a network node receives a viralpacket, the vulnerable application model installed on this node notifies the component Worm ActivityDirector. Then, this component retrieves the addresses of the command centers and forms a commandmessage for the Worm App application; the retrieved addresses are included as the parameters of this mes�sage. The command thus formed is passed to Worm App and is interpreted as a signal to start the propa�gation of the computer worm from this node. In the model described in this paper, models of computerworms and vulnerable applications based on the TCP and UDP protocols are implemented.

The model of attack network control implements a scenario of the attack network control. The aim ofthis scenario is to ensure the connectivity of the attack network and realize the control of the attack net�work nodes by the master node. The model of the attack network described in this paper implements twotypes of architectures. The first type is the attack network based on the IRC protocol [60]. It is a classicalimplementation of a centralized network [61]. The second type of the attack network is based on an imple�mentation of the P2P protocol that belongs to the group of decentralized networks [15]. The libraryBOTNET Foundation Classes includes components that are common for both types of architectures and

48


KONOVALOV et al.

components that are specific for each of them. The static diagram of the components involved in the sce�nario is shown in Fig. 5.

The main components that directly ensure the connectivity of the network nodes are the models of net�work applications that implement the corresponding network protocols. In the case of a centralized net�work, a group of nodes—command centers controlling the other participants of the network—are distin�guished. The model of the network application corresponding to the command center is represented by

Network ServerApplication

+ configuration

Network ClientApplication

+ configuration

IRC Client App

Application

+ configuration

P2P Agent App IRC Server App

Network AppGeneric

BotMaster Zombie

User models

IOverlayNetworkIOverlayNetwork

Application models

Fig. 5. Static diagram of the components participating in the botnet control scenario.

Network ServerApplication

+ configuration

Vulnerable App

+ is_vulnerable

Network ClientApplication

+ configuration

IP Worm App

+ scan type+ send freq+ spoon type

Worm Activity

Director

TCP Worm UDP Worm VulnerableTCP App

VulnerableUDP App

Fig. 3. Static diagram of components participating in the botnet propagation scenario.

Worm Activity

Network

Network

Director Worm AppVulnerable App

Falformed PackedRcvd

Innitiate WormSpreading

Innitiate WormSpreading

Close VulnerablePort

Send malformed packet




Fig. 4. Diagram of interaction between the components participating in the botnet propagation scenario.



the component IRC Server App. This component is an implementation of the generalized server networkapplication; it provides a partial implementation of the IRC protocol on the server side that is sufficientfor reproducing the essential aspects of the network behavior in the model. The components IRC ClientApp that implement the IRC protocol on the client side are clients of the command center node. Thesecomponents provide an implementation of the model of generalized network client.

The model of control of a decentralized network is provided by the component P2P Agent App, whichis an implementation of the client of the P2P protocol. Due to the features of the class of P2P protocols[62], this component is an implementation of the class of server network application and the class of clientnetwork application simultaneously. It is important that the components IRC Client App and P2P ClientApp are models of the client network applications implementing the corresponding protocols of the appli�cation level. These applications are controlled based on the user model. The common features inherent inthe components of client network applications make it possible to distinguish an invariant interface for thecontrol of these models from the user side. This interface allows one to separate the operation logic of anarbitrary distributed network application from the component implementing the protocol used for theinternal communication in the network. Thus, there is a possibility to reuse the components IRC ClientApp and P2P Client App in various distributed systems.

The components implementing models of users are implementations of the generalized user modelNetwork App Generic, which is an abstract model that exchanges data in the network via an applicationlevel protocol. The user model interacts with the protocol using the IOverlayNetwork interface. Specificimplementations of the generalized user model directly specify the network activity logic. In the modeldescribed here, two types of specific user models are implemented in the control phase—the model of themaster node of the attack network (BotMaster) and the bot agent, which resides on zombie nodes andmakes it possible to control those nodes from the attack network (Zombie).

Model of the attack phase. In this paper, we simulate DDoS attacks. The attack is started on commandfrom the master node of the botnet. In this paper, we use implementations of the attacks TCP Flood andUDP Flood. These components are directly related to the component that represents the network levelprotocols in the node model. Figure 6 shows the block diagram of the components implementing thephase of attack of the type TCP Flood; the structure of the node operating in the centralized attack net�work is also shown.

The model of a zombie node hosts the models of IRC client, which is responsible for the communica�tion between this node and the other part of the network, the model of the zombie agent, which imple�ments the communication protocol between the zombie node and the master node of the botnet, and themodel of the TCP Flood component, which is used to execute the TCP Flood attack. The componentresponsible for the implementation of the TCP Flood attack and the network client use the services pro�vided by the module that implements the network level protocols (TCP, IP, UDP). The diagram illustrat�ing the interaction between the components participating in the attack phase are shown in Fig. 7.

The master node of the botnet initiates an attack command, accompanies it with additional informa�tion (address of the victim node), and broadcasts it to all the participants of the botnet. Then, the messagecarrying this command is delivered to a zombie node via network protocols. At the zombie node, the orig�inal message containing the command code and additional data is reconstructed, and the message is

Zombie

BotMasterSYN FlooderIRC Client App

IOverlayNetwork

attack

IRCZombie

ITCPProtocol

Netrwork Layer

Fig. 6. Block diagram of the components participating in the attack.

50


KONOVALOV et al.

passed to the component Zombie for processing according to the logic of the control protocol. The com�ponent Zombie identifies the command, retrieves the address of the victim node from the additional datain the message, and instructs the component IP Flood to switch the victim node specified by the givenaddress to the attack mode. The time when the component IP Flood stops the attack is determined by thelogic of its implementation; it is a part of the complete logic of the attack network operation.

2.3. Models of the Defense Network

The general model of the defense network includes the models of counteraction to the attack networkat each phase and the models implementing the self�organization scenario. In the simple case, the defensenetwork does not include cooperation mechanisms and is a set of isolated autonomous components thatcannot interact with each other. This approach is implemented in the current version. The further devel�opment of the defense network architecture is aimed at the use of network organization scenarios that aresimilar to the scenarios used in the organization of botnets. It is intended to use centralized and decentral�ized network organization protocols in defense networks.

The components implementing the defense network scenarios can be conditionally subdivided intothree categories: (1) those that monitor the traffic at the specified level of the stack of protocols of the OSInetwork model without modifying this stack; (2) scenarios that filter traffic at the specified level of thestack of protocols of the OSI network model by a certain rule; (3) scenarios that do not interact with thetarget traffic. The main module the filters traffic is Filtering router, which is a model of an IP router thatcan selectively transmits packets of the passing traffic. The filtering rule is specified by registering a call�back function, which is called each time an IP packet passes through this router. The passing packet ispassed for the analysis to the registered function as a parameter. The function returns a Boolean variablethat instructs the router to pass or to filter out the packet. Filtering router is the main component used tocollect information about the traffic circulating in the network; also, it is a traffic filtering tool.

The proposed architecture of the defense network components assumes the direct implementation ofdefense scenarios designed to counteract the main attack network scenarios. Thus, according to the con�tents of the scenario tree, the following scenarios (and the corresponding models in the defense network)are implemented in the framework of the defense network: (1) defense against the attack network propa�gation; (2) suppression of the attack network organization; (3) counteraction to the attack scenario.

In distinction from the attack network scenarios, the defense network scenarios are always active. Eachdefense scenario can be conditionally subdivided into two intermediate scenarios: (1) detection of the cor�responding attack network scenario and (2) counteraction to the detected attack network scenario.

Scenario of Defense against Botnet Propagation is implemented using methods suppressing the propa�gation of computer worms. One of the components developed in this work for making decisions about thetraffic filtering is the component Virus Throttling Filter. It is the component Filter router that uses an algo�rithm based on the VT approach [24]. This defense technique restricts the number of new connectionsfrom a unique IP address to destination IP addresses in a given time interval. A limited range of destinationIP addresses for the sent packets is specified. If a request for the new connection arrives and its destinationaddress is in the range, then the connection is allowed. If the destination address is not in the range butthere is place for its address in the allocated stack of addresses, then the connection is allowed, and the IP

Zombie

MASTER

Network

Syn�FlooderIRC Client AppAttack Command

Packet

Command + Data





Reseived

Start Flloding

Fig. 7. Diagram of interaction between the components participating in the attack.



address of the destination computer is stored. If the destination address is not in the range and the addressstack is full, then the packet is rejected.

The second implemented component that suppresses the propagation of the attack network is the com�ponent Failed Connection filter. It also is an implementation of the filter component, and it uses an algo�rithm based on the FC approach [25] as the filtering rule. Packets in which the flags TCP RST and TCPSYN are set are tracked. If a host breaks connections in a certain time more frequently than a predefinethreshold, then new requests for connection from this IP address are limited. In the model of the defensenetwork described in this paper, different methods that are simultaneously used in the network may becombined; this is a direction of future research.

Defense Scenario at the Phase of Botnet Control is implemented by monitoring the passing IRC trafficand detecting anomalies. In this work, we use the approach based on the evaluation of metrics of cooper�ation between agents in the IRC network [33]; then, anomalous values are detected. We developed thecomponent IRC Monitor for the monitoring and filtering of the passing IRC traffic. This is an extensionof the Filtering router component by adding a parser of the passing IRC packets and an evaluator of IRCtraffic metrics. Using this component, we implemented components for filtering the traffic by the rela�tionship and synchronization metrics [33].

Defense Scenario at the Attack Phase is mainly implemented using methods similar to those used forsuppressing the computer worms. In this paper, we consider the defense techniques based on theapproaches HCF, SIM, and SAVE.

The SIM�based defense technique [29] can operate in two modes—learning and detection. In thelearning mode, the list of trusted IP addresses is collected. New IP addresses are retrieved from the passingtraffic, and it is checked how many packets were received from this client. If the number of packets isgreater than a predefined value (e.g., three), then this IP address is added to the trusted list; otherwise, thisIP address is rejected. It is also checked how much the number of new packets increased in a time unit. If

Table 1. Modules of the Library BOTNET foundation classes

Botnet Foundation Classes Description

Botnet Master Model of the botnet master

Components of the compromise model

Worm Computer worm model

Vulnerable Application Vulnerable application model

Components of the control model

IRC client Model of an IRC client

IRC Server Model of an IRC server

P2P Agent Model of a decentralized overlay network client

BotNet Client Model of a botnet client

Components of the attack model

UDP Flooder Model implementing a UDP flood attack

SYN Flooder Model implementing a SYN flood attack

Components of the defense model

Filtering router Model of a router able to filter the passing traffic

Failed Connection filter Model of the Failed Connection method

Worm Throttling filter Model of the Virus Throttling method

HIPC filter Model of the Source IP Counting method

IRC Monitor Model of an IRC traffic analyzer

IRC Relationship filter Model of the IRC traffic filter based on the monitoring of the Relationship metric [33]

IRC Synchronization filter Model of the IRC traffic filter based on the monitoring of the Synchronization metric [33]

Hop�Count filter Model of an IP filter based the Hop�Count Filtering method

SIM filter Model of an IP filter based the Source IP Address Filtering method

SAVE filter Model of an IP filter based the Source Address Validity Enforcement Protocol.

52


KONOVALOV et al.

a predefine threshold is exceeded, the beginning of a DDoS attack may be suspected; in this case, thelearning mode is suspended. Due to the fact that IP addresses can be retrieved from the packets passingthrough the SIM mechanism, the packets arriving form the addresses not included in the trusted list arefiltered out.

In the learning mode, the HCF�based technique [30] forms a database of the correspondence betweenIP addresses and the difference between an initial value of the TTL (time to live) and the value of the TTLof the arriving packet. In the normal operation mode, the arriving packet is checked for the correspon�dence of the difference of its TTL to the value of the stored TTL for the host that sent this packet.

The SAVE�based technique [28] allows routers in the local network to detect packets with the substi�tuted address and filter them out. As a packet from the internal network is received, the router checkswhether the sender address is in the internal network address range. If the address is not found, the packetis rejected. Thus, the penetration of malicious packets from the internal network into the external networkis prevented.

The components implementing methods of the attack and defense networks are shown in Table 1.

3. EXPERIMENTATION PLAN AND PARAMETERS

An example of the model representation in the course of experiments is shown in Fig. 8. In the leftupper corner, there is the main panel, which shows the components that are a part of the general model,and controls enabling the user to interact with these components. The main panel also includes controlsfor managing the model time (e.g., one can perform the simulation step�by�step or in express mode).There are also controls for searching the entity of interest for editing its state.

Figure 8 shows a fragment of the model network, where the models of routers are depicted by cylinderswith arrows and the models of hosts are depicted by computer pictograms. By way of example, this figurealso includes the window representing one of the hosts (in the right top part), the window for editing

Fig. 8. Model representation in the course of experiments.



parameters of a bot client (in the right bottom part), and a plot illustrating the experimental results for oneof the parameters.

Before describing the experimental results, we discuss the main parameters of the modeling environ�ment configuration; these parameters specify the topology and configuration of the network and theexperimentation plan. The topology and configuration of the network is modeled at two levels of detail.

At the first level, the network topology is modeled at the level of autonomous systems (AS). To generatethe network topology at the AS level, we use the positive feedback preference (PFP) method [58]. Wemodeled networks consisting of 30 ASs. For the generation of the AS�level graph, the following parame�ters were used: threshold for assigning AS nodes to the transit group (Transit Node Threshold = 20), thenumber of links for new nodes (P = 0.4), and the assortativity level of the generated network, which char�acterizes the degree of preference of the nodes depending on their connectivity when a new node is addedto the network (Delta = 0.04) [58]. Transit ASs are connected by a communication channel with the speeddr = 10000 Mbit/s and the delay d = 50 µs; connections of stub ASs are connected by channels with dr =5000 Mbit/s and d = 20 µs.

At the second level, the internal (route level) topology is modeled for each AS. In this work, we use theHOT (Heuristically Optimal Topology) model [57] with the following parameters: the number of routersis in the range from 5 to 20, the percentage of the core routers in the total number of routers is 1%, thenumber of hosts per router is in the range from five to twelve, and the connectedness level of the core rout�ers is 0.2. The core routers are connected by communication channels with the speed 2500 Mbit/s and thedelay 1 µs. The gateways are connected with the core routers at the speed dr = 1000 Mbit/s and the delay1 µs, gateways are connected with edge routers at the speed dr = 155 Mbit/s and the delay 1 µs, edge rout�ers are connected with servers at the speed dr = 10 Mbit/s and the delay 5 µs, and edge routers are con�nected with ordinary nodes at the speed dr = 0.768 Mbit/s and the delay 5 µs for download and dr =0.128 Mbit/s and the delay 5 µs for upload.

Using these parameters, a network consisting of 3652 nodes was generated among which ten nodes areservers; they include one DNS server, three Web servers, and six mail servers. About 30% of all the nodesare vulnerable. A master node is specified in the network, which is the source of the primary propagationof the worm and the originator of the botnet control commands. All the nodes in subnets are connectedby edge routers. In each subnet, a core router used to connect subnets one with another. User models areinstalled on client nodes to simulate access to servers thus creating legitimate traffic. At each node, amodel of the standard stack of protocols (which includes the protocols PPP, LCP, IP, TCP, ICMP, ARP,and UDP) is installed. Depending on the functional role of the node, models of the network componentsimplementing the corresponding functionality may be additionally installed. The experimentation planincludes the investigation of the botnet actions and the counteracting defense mechanisms at the phasesof the botnet propagation, control (reconfiguration and preparation for attack), and attack execution.

Below, we consider the simulation features for each phase and the corresponding parameters of the bot�nets and defense mechanisms.

3.1. Simulation of Botnet Propagation

To propagate the botnet, a model of a computer worm is used. According to the scenario, a part of thenodes in the local network have a vulnerability that can be exploited by the worm. The computer worm hasthe following parameters: the connection type is TCP, the scanning speed in different experiments was 6,20, or 30 packets/s, the network port from which the packets was sent was 8080, the destination port was8080, scanning was performed randomly in a given range of IP addresses, and the number of attempts toestablish a connection was 30, 60, or 100 in different experiments. At this stage, the total number of nodesin the network and the number of vulnerable nodes was registered.

3.2. Simulation of Defense against Botnet Propagation

To counteract the worm propagation, the defense models based on the FC [25] and VT [24] approachesare used. The defense modules are installed on the core router or on all the routers in the network.

The defense mechanism based on Failed Connection has the following parameters: the buffer for thesender IP addresses is 400 long; the threshold value for the number of RST packets for each sender IPaddress was 1, 3, or 6 in different experiments; each 5 s, it is allowed to reduce the number of received RSTpackets relative to the threshold value and if the IP address is blocked, it is allowed to exit from the list ofblocked IP addresses.

54


KONOVALOV et al.

The defense mechanism based on Virus Throttling is characterized by the following values: the buffercan contain up to 300 sender IP addresses; for each sender IP address, a buffer for five allowed destinationIP addresses is allocated; if this buffer is full, it is allowed to free one slot every 5 s and connect to anotherremote node.

Experiments were performed for the following cases: no defense tools are installed on the routers; 30,50, or 100% of random routers use a defense method. All the “protected” routers use the same defensemethod. As a result of the simulation of the botnet propagation, the following characteristics are deter�mined: the number of filtered malicious packets (true positive, TP), the number of filtered legitimatepackets (false positive, FP), the number of passed malicious packets (false negative, FN), the number ofinfected nodes, and the ratio of the filtered legitimate packets to the total amount of legitimate traffic.

3.3. Simulation of the Botnet Control Mechanism

A centralized botnet with a single control center is simulated. The botnet nodes communicate one withanother using a model of the IRC protocol. In addition, communication between legitimate IRC users issimulated. The legitimate IRC communication is simulated by creating IRC channels with a small num�ber of participants (from five to ten) that exchange broadcast messages. At the same time, the clients ofbotnets mainly exchange private IRC messages with the master node of the botnet.

For the legitimate communication scenario, the following parameters are determined: the maximaladmissible number of IRC channels on the IRC server and the maximal number of participants in a legit�imate IRC channel (this parameter practically does not affect the simulation of the defense method in thebotnet control scenario). As a result of the simulation, the number of nodes participating in the maliciousand legitimate IRC communication is registered.

3.4. Simulation of the Defense Mechanism against Botnet at the Phase of Control

The defense method at the phase of control is based on the approach proposed in [33]. This methodinvolves monitoring of the IRC traffic passing through an observer node, the subsequent evaluation of therelationship and synchronization metrics based on the contents of the network packet data field. The rela�tionship metric is a characteristic of the distribution of the number of clients of the IRC channel. Too highvalues of this metric are considered to be anomalous. The value of 30, 100, or 200 participants per channelis set as a threshold for this metric. If this threshold is exceeded, the method filters out the passing packetsrelated to this IRC channel.

Experiments were performed for the following cases: no defense tools are installed on the routers; 30,50, or 100% of random routers use a defense method. In all the cases, no defense tools were installed inthe subnet in which the master node resides. After the phase of communication, information about thenumber of nodes that received the instruction to start the attack is collected, and plots of the traffic levelfor the observed IRC channels and charts illustrating the distribution of participants between the IRCchannels are constructed.

3.5. Simulation of Botnet Attack

DDoS attacks are simulated. The DDoS attack module has the following parameters: type of attack isSYN flooding; the frequency of packet generation is 10, 30, or 60 packets/s; the number of packets to besent is 1000; the attack on a given Web server goes through port 80; in some experiments, the substitutionof the sender’s IP address is used. The IP addresses used for substitution are in the range from the first IPaddress in the first subnet to the last IP address in the last subnet using the mask 255.0.0.0. The number ofhosts participating in the DDoS attack is calculated upon the execution of the preceding phases of the bot�net operation, and it depends on the efficiency of individual defense mechanisms, their combination, andother factors.

3.6. Simulation of Defense against DDoS Attacks

Several methods for detecting DDoS attacks and defense against them are simulated. These are SAVE,HCF, and SIM. To prevent attacks, the defense mechanism based on the SAVE approach [28] is used. Thismethod allows routers in the local network to detect packets with the substituted address and filter themout. First, the mechanism gets information about the interfaces connected to the router and determinesthe IP addresses of the clients connected to it from the internal network. Then, the mechanism passes intothe external network only the packets sent by computers with the IP addresses from the internal network.



In our experiments, the defense mechanism was installed on 30, 50, or 100% of random routers. In someexperiments, no defense mechanism was used.

The method HCF [30] detects the substitution of IP addresses of incoming packets by analyzing theirTTL field. This mechanism is installed on victim nodes. The method SIM [29] can operate in twomodes—learning and protection. In the first mode, a base of trusted IP addresses is used. It is checkedhow much the number of new clients per unit time has increased. If this number exceeds a given threshold,one can suspect the beginning of a DDoS attack. If the number of new addresses registered in a secondexceeds a certain threshold, then the mechanism goes to the protection mode. In this mode, it passes onlythe packets from the IP addresses registered in the base of legitimate IP addresses. This mechanism isinstalled on victim nodes.

Upon DDoS attack simulation, the following data are collected: the number of true positives, falsepositives, false negatives, total traffic without defense and with defense in the immediate vicinity of theattack goal, and the ratio of false positives to the total legitimate traffic.

4. ANALYSIS OF EXPERIMENTAL RESULTS

A great number of experiments were performed in the framework of this study. We describe the resultsof some of them.

4.1. Botnet Propagation and Defense against Its Propagation

At the 100th second of the model time, the master node begins to scan the network to detect vulnerablenodes and connects to an IRC channel through which it intends to send commands to the “commandcenter” for their further transmission to zombie nodes. In this experiment, the network is scanned at therate of 6 packets/s using random scanning in the range of known addresses. Upon infection, the zombienode becomes a source of propagation; for this purpose, it makes 30 attempts to establish a connection,connects to an IRC channel, and waits for further instructions.

To counteract the propagation, a VT�based defense mechanism was used. It has the following features.It has a buffer for 300 addresses of traffic sources; this is a FIFO buffer. For each source address, a bufferfor five allowed IP destination addresses is allocated. As soon as this buffer is full, it is allowed to free onebuffer slot (this is a FIFO buffer) every five seconds and connect to a new remote node. This defensemechanism is installed on routers. Several experiments were performed, and plots illustrating the depen�dence of the number of infected nodes on the botnet propagation time were constructed. Figure 9 showsthe dependence of the number of infected nodes on the botnet propagation time for unprotected networksand with the defense installed on 30, 50, and 100% of routers.

In the experiments, we obtained the number of false positives, false negatives, and true positivesdepending on the botnet propagation time in the case when the network packets were processes by the VTdefense mechanism. It was shown that if the number of protected routers is small (30%) and the buffer is

Unprotected

048 55 62 69 76 83 90 97 10

411

111

812

513

213

914

615

316

016

717

418

118

883

200

400

600

800

1000

1200Infected nodes

30%

50%

100%

Time, s

Fig. 9. Dependence of the number of infected nodes on the botnet propagation time when the VT defense mechanism is used.

195

56


KONOVALOV et al.

048 55 62 69 76 83 90 97 10

411

111

812

513

213

914

615

316

016

717

418

118

819

5

5000

10000

15000

20000

25000

Packets/s30000

All

Filtered

FP

FN

(a)

0

48 55 62 69 76 83 90 97 104

111

118

125

132

139

146

153

160

167

174

181

188

195

5000

10000

15000

20000

25000

30000All

Filtered

FP

FN

(b)

0

48 55 62 69 76 83 90 97 104

111

118

125

132

139

146

153

160

167

174

181

188

195

5000

10000

15000

20000

25000

Time, s

30000(c)

All

Filtered

FP

FN

Fig. 10. Dependence of the amount of total traffic, filtered traffic, FP and FN on the botnet propagation time when theVT defense mechanism is used.

300 source addresses long, the numbers of FPs and FNs are close to each other. This is because the VTmechanism passes packets from infected nodes whose addresses were earlier included in the prohibitionlist but were later overwritten by new source addresses. When the percentage of protected routersincreases, the number of FNs is considerably lower.

Figure 10 illustrates the dependence of the total amount of traffic, filtered traffic, and the number oferrors of the first and second kind on the botnet propagation time when the VT�based defense was installedon 30 (Fig. 10a), 50 (Fig. 10b), and 100% (Fig. 10c) routers, respectively.

By the start of the attack at the 400th second, 1147 nodes were infected when no defense was used atall, 1147 nodes were infected when the defense was installed on 30% of routers, 1142 nodes were infectedwhen the defense was installed on 50% of routers, and 867 nodes were infected when the defense wasinstalled on all the routers. Figure 11 illustrate the dependence of the amount of rejected traffic relative to



the total legitimate traffic (on a percentage basis) on the botnet propagation time when the VT�baseddefense was installed 30, 50, and 100% of routers.

We also experimented with the FC�based mechanism for the defense against botnet propagation. Sev�eral experiments were conducted, and the number of infected nodes depending on the botnet propagationtime was plotted. A relatively high level of TP in all the plots indicates that the defense mechanism makesit possible to filter a large number of packets. However, with the current values of the experimental param�eters, the defense mechanism does not significantly restrain the botnet propagation. The ratio of the num�ber of vulnerable nodes to the number of legitimate nodes, the method of scanning of vulnerable nodes,and the threshold value significantly affect the quality of the defense. By the start of the attack at the400th second, 1147 nodes were infected when no defense was used at all, 1147 nodes were infected whenthe defense was installed on 30% of routers, 1147 nodes were infected when the defense was installed on50% of routers, and 957 nodes were infected when the defense was installed on all the routers.

Figure 12 illustrates the dependence of the amount of rejected legitimate traffic relative to the totallegitimate traffic (on a percentage basis) on the botnet propagation time when the FC defense mechanismwas installed on 30, 50, and 100% of routers. This defense method shows a high level of filtering the legit�imate traffic compared with VT; however, it is worth noting that it mostly filters the legitimate traffic orig�

048 54

5

10

15

20

25

30Legitimate traffic, %

30%

50%

100%

Time, s60 66 72 78 84 90 96 10

210

811

412

012

613

213

814

415

015

616

216

817

418

018

619

219

8

Fig. 11. Dependence of the amount of rejected legitimate traffic relative to the total legitimate traffic on the botnet prop�agation time when the VT defense mechanism is used.

0

48 54

10

20

30

40

50

60Legitimate traffic, %

30%

50%

100%

Time, s

60 66 72 78 84 90 96 102

108

114

120

126

132

138

144

150

156

162

168

174

180

186

192

198

Fig. 12. Dependence of the amount of rejected legitimate traffic relative to the total legitimate traffic on the botnet prop�agation time when the FC defense mechanism is used.

58


KONOVALOV et al.

inated at the infected nodes, while VT rejected approximately the same number of packets originated atinfected and uninfected nodes.

4.2. Botnet Control and Defense against Botnet at the Control Phase

Monitoring of IRC traffic at various points in the network and evaluation of the relationship metric.Using the “observer” components installed on core routers of large network segments, the IRC traffic ismonitored. Based on the analysis of IRC packets, data concerning the IRC channel and its participantsare determined. Next, these data are used to evaluate the relationship metrics of the channels under obser�vation. It is assumed that the data obtained from the observer components strongly depend on the locationof the observer in the network relative to the main IRC flows, which converge in the vicinity of the networksegment containing the IRC server.

Table 2 shows a fragment of the set of values of the observed relationship metric relative to the actualrelationship of the corresponding IRC channel. Data for the botnet control channel (Irc�bot) and for twochannels of the legitimate IRC communication (Irc�1 and Irc�2) are shown. The number of clients in theIrc�1 channel is ten, while the number of clients in Irc�2 is nine. For the legitimate channels, either all theparticipants are detected or none of the participants are detected. This is because the legitimate IRC com�munication is performed by exchanging broadcast messages; therefore, if an observer resides on the wayof the IRC traffic, it detects all the clients of the corresponding channel.

A graphical representation of the relationship metric for the control channel Irc�bot is shown in Fig. 13.

For the control channel Irc�bot, there is significant differentiation of the observed metric dependingon the observer location in the network. This is due to the features of botnet client communication in thecontrolling IRC channels. Rather than broadcasting messages to all the channel participants, the botnetnodes exchange information only with a small number of nodes belonging to the set of master nodes. It isseen from Table 2 and Fig. 13 that there are two routers on which the botnet control channel was detectedalmost completely. The analysis of the network topology showed that the IRC server was located in the seg�ment sas17, while the segment tas0, which was in the close vicinity of sas17, operates as a transit segmentbetween the IRC server and the greater part of the bot clients.

Thus, we may assume based on the acquired data that the defense mechanism executed on a smallnumber of routers that are transit routers for the main IRC traffic can be as efficient as the defense mech�anism installed on a greater number of routers. We may also assume that the defense mechanism with alow coverage of the network under protection is generally ineffective because the overwhelming majorityof routers pass only a small part of the IRC control traffic.

Monitoring IRC traffic at various points of the network and evaluation of the synchronization metric.The traffic is monitored at various points of the network. Based on the acquired data, the synchronizationmetric is evaluated by monitoring the traffic through the core router of the network segment tas0 (Fig. 14).

Table 2. Observed relationship metric of IRC channels at various points in the computer network

SensorIrc�bot Irc�1 Irc�2

%

sas17 97.91 100 100

tas0 95.82 100 100

tas4 26.82 100 100

tas2 26.00 100 100

sas1 15.00 100 100

sas18 7.27 0 0

sas26 5.45 100 0

sas11 5.45 0 0

tas8 5.27 100 0

tas5 5.27 0 0

sas20 5.09 100 0

sas13 5.00 0 0



Beginning from the 200th second, sharp surges in the traffic level pertaining to the botnet control IRCchannel are observed once in 100 seconds. They are caused by messages from the zombie nodes inresponse to requests of the botnet master node. The network segment tas0 is located in the close vicinityof the network segment that includes the IRC server. Thus, a significant part of the control IRC trafficpasses through tas0. For this reason, surges in the control channel traffic are pronounced relative to thelegitimate communication traffic. To estimate the influence of the closeness of the observation point tothe IRC server on the intensity of the control traffic surges (and thus on the discernibility of the controlchannel synchronization metric), the model traffic in the router of the network segment sas13 was mea�sured (Fig. 15).

The traffic measurements showed the overall reduction of the traffic at the observation point sas13 andgood discernibility of the control traffic surges on the core router of this network segment. Therefore, weconclude that the synchronization metric can be used to detect the control IRC traffic in the network.

Filtration of IRC traffic in the IRC channel based on the relationship metric. This filtration method isbased on the assumption that the IRC channels with a very large number of participants are anomalous.We performed filtration based on the relationship metric for various configurations of filter componentlocation and for various values of the parameter determining the critical level of the relationship metric.The results of filtering the IRC channels with the relationship metric greater than 100 nodes evaluated foreach router are shown in Table 3.

0

600

400

800

1000

1200

Packets/s

200

30 60 90 120

150

180

210

240

270

300

330

360

390

420

450

480

510

540

570

Irc�bot Irc�1 Irc�2

Time, s

Fig. 14. Value of the synchronization metric determined for the core router of the tas0 segment.

0

senso

r_sa

s17

40

60

80

100%

20

senso

r_ta

s4

senso

r_sa

s1

senso

r_sa

s26

senso

r_ta

s8

senso

r_sa

s20

senso

r_sa

s6

senso

r_ta

s24

senso

r_sa

s16

senso

r_sa

s27

senso

r_sa

s12

senso

r_sa

s28

senso

r_sa

s25

senso

r_sa

s10

senso

r_sa

s22

Fig. 13. Value of the relationship metric for the Irc�bot control channel.

60


KONOVALOV et al.

The results of filtering IRC channels with the relationship metric greater than 50 nodes evaluated foreach router are shown in Table 4.

Thus, the effectiveness of the IRC traffic detection and filtration system based on the relationship met�ric considerably increases with the coverage of the core routers of the control IRC traffic by filtration com�ponents. It is also worth noting that the method is correct with respect to false negatives, which is achievedby setting a sufficiently high critical relationship level.

Filtration of IRC traffic in the IRC channel based on the synchronization metric. This filtration methodis based on the assumption that the short�time synchronous exchange of messages within the same IRCchannel is anomalous. The observed value of the synchronization metric was evaluated as the number ofIRC packets passing through the observation point during a fixed time interval. Based on this metric, thereal�time analysis aimed at detecting a local well pronounced maximum is performed. In this work, thefivefold increase in the traffic in 20 s with the subsequent return to the initial value was used as the filtercriterion. The results of the IRC channel filtration based on the synchronization metric are presentedin Table 5.

0

30

20

40

50

70

Packets/s

1020

5

Irc�bot Irc�1 Irc�2

Time, s

235

265

295

325

355

385

415

445

475

505

535

565

595

625

655

685

715

745

775

60

Fig. 15. Value of the synchronization metric determined for the core router of the sas13 segment.

Table 3. Results of IRC channels filtration with the relationship metric greater than 100 nodes evaluated for each router

Experiment Filtered, % FP, %

Filtration on four routers with the greatest relationship metric (i.e., on the first four routers from Table 2)

98 0

Filtration on 16 routers with the lowest relationship metri 68 0

Table 4. Results of IRC channels filtration with the relationship metric greater than 50 nodes evaluated for each router



98 0

Filtration on 16 routers with the lowest relationship metric 63 0

Table 5. Results of IRC channels filtration based on the synchronization metric



98 5

Filtration on 16 routers with the lowest relationship metric 71 8



The experimental results indicate that the method performance is insufficient in the current configu�ration because the level of the first kind errors is high.

4.3. Execution of DDoS Attacks and Defense against Them

At the 400th second of the experiment, the master node issues a command to start the DDoS attack ona remote Web server. The master sends a message indicating the attack goal to the command centerthrough an IRC channel; the command center broadcasts this message to zombie nodes also through anIRC channel. Having received this message, a zombie node retrieves information about the attack goalfrom this message and immediately joins in the DDoS attack. In our experiments, the module performingDDoS attacks had the following parameters: the attack type was SYN�flooding, the frequency of packetgeneration was 100 packets/s, the number of sent packets was 1000, the substitution of IP address was on,and the attack at the Web server was through port 80. To defend against DDoS attacks, the SAVE andSIM methods were used.

0

982000

4000

6000

8000

100000

120000

Packets/s

30%

50%

100%

Time, s

122

146

170

194

218

242

266

290

314

338

362

386

410

434

458

482

506

530

554

578

Unprotected

Fig. 16. Dependence of the number of packets arriving at the server under attack on model time when the SAVE defensemechanism is used.

98 123

148

173

198

223

248

273

298

323

348

373

398

423

448

473

498

523

548

573

0

2000

4000

6000

8000

100000

120000

Packets/s

Time, s

All

Filtered

FP

FN

Fig. 17. Dependence of the amount of total traffic, filtered traffic, FP and FN on the model time when the SIM defensemechanism is used.

62


KONOVALOV et al.

Figure 16 illustrates the dependence of the number of packets arriving at the server being attacked afterprocessing the traffic using the SAVE defense mechanism on the experimental model time. The data arepresented for the cases when 30, 50, and 100% of routers.

Figure 17 illustrates the dependence of the number of first and second kind errors and the cases of cor�rect detection on the experimental model time; these data were obtained when the network packets wereprocessed by the SIM defense mechanism. The packets arriving at the Web server were not filtered by otherdefense mechanisms.

It is seen from Fig. 18 that the number of rejected legitimate packets increases after the defense modeis switched on.

Figure 19 illustrates (on a percentage basis) the dependence of the amount of rejected legitimate trafficrelative to the entire legitimate traffic passing through the SIM defense mechanism (upon the filtration ofthe attacking traffic by the SAVE mechanism and filtration at the phase of control) on the model experi�mental time. The data are presented for the cases when 30, 50, and 100% of routers.

In all the cases, the SIM defense mechanism demonstrates a high level of true positives and a very lowlevel of false negatives (Fig. 17); a small surge in the false negative packets is registered only at the start ofthe attack (Fig. 18). However, due to the fact that this mechanism rejects packets with unknown IPaddresses after the start of the DDoS attack, the level of false positives gradually increases and the percent�age of the rejected legitimate packets can be as high as 30–40% of the legitimate traffic (Fig. 19).

In our experiments, the HCF method installed on the node being attacked showed very low effective�ness even though the IP address substitution for the malicious traffic was on and the range of IP addressesincluded the IP addresses of the subnets that connected to the server under attack as legitimate clients.It seems that, for the effective operation, this mechanism requires long time to form the database of legit�imate IP addresses and related TTLs. In any case, the malefactor can use for substitution the range of IP

00

10

Number of FP and FN

Time, s200 210 220 230 240 250 260 270 280

20

30

40

50

FP FN

Fig. 18. Dependence of the first and second kind errors on model time when network packets are processed by the SIMmechanism.

22

0

25

3035

40

45Amount of legitimate traffic, %

Time, s

30%

20

15

10

5

50%

100%

45 68 91 114

137

160

183

206

229

252

275

298

321

344

367

390

413

436

459

482

505

528

551

574

Fig. 19. Dependence of the amount of rejected legitimate traffic relative to the total legitimate traffic (on a percentagebasis) on model time when the SIM defense mechanism is used after the SAVE mechanism and filtration at the controlphase.



addresses that have never connected to the node under attack; for that reason, the HCF mechanism willnot be able to detect the substitution of the IP address. To eliminate this drawback, one can maintain, forexample, a database of pairs IP address–TTL and reject the unknown IP addresses and packets classifiedas substituted ones. However, this variant better suits for defending internal servers in corporate networks.

CONCLUSIONS

In this paper, a general method for investigating botnets and defense mechanisms against them basedon the use of simulation was proposed. The general architecture of the environment for the simulation ofbotnets and defense mechanisms against them was presented. This architecture was implemented on thebasis of the discrete events simulation system OMNeT++, a library of components INET Frameworkimplementing network protocols, the library ReaSE designed for the simulation of realistic computer net�works, and the library BOTNET Foundation Classes containing models of network applications pertain�ing to the operation of botnets and counteraction mechanisms.

Experiments were performed that demonstrate the behavior of botnets and counteraction mechanismsat the phases of propagation, control, and attack. The defense at the phase of botnet propagation was orga�nized based on the VT and FC approaches. Methods of detection of IRC�oriented botnets based on therelationship metric of individual IRC channels, distribution of the response time to broadcast messages,and the synchronization metric of the group behavior of botnets were investigated as defense mechanismsagainst botnets at the phase of control. At the attack phase, models based on the SAVE, SIM, and HCFapproaches were used as counteraction methods.

The experiments confirmed the practical usefulness of the proposed approach for the simulation ofcomplex botnets and the analysis of security of network segments. This approach can be used to study theoperation of various kinds of botnets, search for optimal configuration of defense mechanisms against bot�nets and against other types of attacks in computer networks, and to evaluate the performance of thosemechanisms. Further research will be devoted to the analysis of effectiveness of botnet operation anddefense mechanisms, development of novel defense mechanisms, and to the improvement of the simula�tion environment.

ACKNOWLEDGMENTS

This work was supported by the Russian Foundation for Basic Research (project no. 10�01�00826); theProgram of Basic Research of the Department for Nanotechnologies and Informational Technologies,Russian Academy of Sciences (project no. 3.2); State contract 11.519.4008; and the European Union asa part of the SecFutur and Massif projects.

REFERENCES

1. I. Kotenko and A. Ulanov, “Agent Teams in Cyberspace: Security Guards in the Global Internet,” in Proc. Int.Conf. on Cyberworlds (CW’2006) (IEEE Computer Society, Lausanne, 2006), pp. 133–140.

2. I. Kotenko and A. Ulanov, “Agent�Based Modeling and Simulation of Network Softbots’ Competition. Knowl�edge Based Software,” in Proc. of the Seventh Joint Conf. on Knowledge�Based Software Engineering, Frontiers inArtificial Intelligence and Applications, Ed. by E. Tyugu and T. Yamaguchi (IOS, Amsterdam, 2006), Vol. 140,pp. 139–146.

3. I. Kotenko and A. Ulanov, “Multi�Agent Framework for Simulation of Adaptive Cooperative Defense AgainstInternet Attacks,” in Int. Workshop on Autonomous Intelligent Systems: Agents and Data Mining (AIS�ADM�07)Lect. Notes in Artif. Intell. 4476, 212–228 (2007).

4. I. Kotenko, “Multi�agent Modeling and the Simulation of Computer Network Security Processes: A Game ofNetwork Cats and Mice,” in NATO Science for Peace and Security Series, D: Information and CommunicationSecurity. Vol. 17. Aspects of Network and Information Security, Ed. by E. Kranakis, E. Haroutunian, and E. Shah�bazian (IOS, Lansdale, 2008), pp. 56–73.

5. I. Kotenko, “Simulation of Agent Teams: the Application of Domain�Independent Framework to ComputerNetwork Security,” in Proc.of the 23rd European Conf. on Modelling and Simulation (ECMS’2009), Madrid,2009, pp. 137–143.

6. I. Kotenko, “Agent�Based Modelling and Simulation of Network Cyber�Attacks and Cooperative DefenceMechanisms,” in Discrete Event Simulations (Sciyo, Rijeka, Croatia, 2010), pp. 223–246.

7. I. Kotenko, A. Konovalov, and A. Shorov, “Agent�Based Modeling and Simulation of Botnets and BotnetDefense,” in Proc. of the Conf. on Cyber Conflict. (Tallinn, 2010), pp. 21–44.

64


KONOVALOV et al.

8. M. Bailey, E. Cooke, F. Jahanian, et al., “A Survey of Botnet Technology and Defenses,” in Proc. of the Cyber�security Applications Technology Conf. for Homeland Security (USA, Washington, 2009), pp. 299–304.

9. J. B. Grizzard, V. Sharma, C. Nunnery, et al., “Peer�to�Peer Botnets: Overview and Case Study,” in Proc. of theFirst Workshop on Hot Topics in Understanding Botnets, Berkeley, 2007, pp. 1–2.

10. J. Govil and G. Jivika, “Criminology of Botnets and Their Detection and Defense Methods,” in Proc. of theIEEE Int. Conf. on Electro�Information Technology, Chicago, 2007, pp. 215–220.

11. C. Mazzariello, “IRC Traffic Analysis for Botnet Detection,” in Proc. of the Fourth Int. Conf. on InformationAssurance and Security, Naples, 2008, pp. 318–323.

12. B. Botezatu, “Anatomy of a Botnet,” MalwareCity News, http://www.malwarecity.com/13. M. Feily, A. Shahrestani, and S. Ramadass, “A Survey of Botnet and Botnet Detection,” in Third Int. Conf. on

Emerging Security Information Systems and Technologies, Athens, 2009, pp. 268–273.14. F. Naseem, M. Shafqat, U. Sabir, et al., “A Survey of Botnet Technology and Detection,” Int. J. Video & Image

Proc. Network Security 10 (1), 13–17 (2010).15. P. Wang, S. Sparks, and C. C. Zou, “An Advanced Hybrid Peer�to�Peer Botnet,” in Proc. of the First Workshop

on Hot Topics in Understanding Botnets, Orlando, 2007, p. 2.16. D. Dagon, G. Gu, C. P. Lee, et al., “A Taxonomy of Botnet Structures,” in Twenty�Third Annual Computer Secu�

rity Applications Conf. (ACSAC’07), Florida, 2007, pp. 325–339.17. S. Sen, O. Spatscheck, and D. Wang, “Accurate, Scalable in Network Identification of P2P Traffic Using Appli�

cation Signatures,” in Proc. of the 13th Int. Conf. on World Wide Web (ACM, New York, 2004), pp. 512–521.18. J. R. Binkley and S. Singh, “An Algorithm for Anomaly�Based Botnet Detection,” in Proc. of the 2nd Conf. on

Steps to Reducing Unwanted Traffic on the Internet, Berkeley, 2006, Vol. 2, pp. 43–48.19. M. Mahoney and P. K. Chan, “An Analysis of the 1999 DARPA/Lincoln Laboratory Evaluation Data for Net�

work Anomaly Detection,” Florida Tech. Report CS�2003�02, 2003.20. C. Hyunsang, L. Hanwoo, L. Heejo, et al., “Botnet Detection by Monitoring Group Activities in DNS Traffic,”

in Proc. of tge 7th IEEE Int. Conf. on Computer and Information Technology (CIT), Fukushima, Japan, 2007,pp. 715–720.

21. C. Mao, Y. Chen, S. Huang, et al., “IRC�Botnet Network Behavior Detection in Command and Control PhaseBased on Sequential Temporal Analysis,” in Proc. of the 19th Cryptology and Information Security Conf.(CISC'2009), Taipei, Taiwan, 2009.

22. R. Villamarin�Salomon and J. C. Brustoloni, “Bayesian Bot Detection Based on DNS Traffic Similarity,” inProc. of the ACM Symp. on Applied Computing (SAC’09), New York, 2009, pp. 2035–2041.

23. Y. Kugisaki, Y. Kasahara, Y. Hori, et al., “Bot Detection Based on Traffic Analysis,” in Proc. Int. Conf. on Intel�ligent Pervasive Computing (IPC’07), Jeju Island, South Korea, 2007, pp. 303–306.

24. M. Williamson, “Throttling Viruses: Restricting Propagation to Defeat Malicious Mobile Code,” in Proc. of theACSAC Security Conf., Las Vegas, 2002, pp. 61–68.

25. S. Chen and Y. Tang, “Slowing down Internet Worms,” in Proc. of the 24th Int. Conf. on Distributed ComputingSystems (ICDCS’04) (IEEE Computer Society, New York, 2004).

26. V. Nagaonkar and J. Mchugh, “Detecting Stealthy Scans and Scanning Patterns Using Threshold RandomWalk” (Dalhousie University, Halifax, 2008).

27. P. Ferguson and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which Employ IPSource Address Spoofing,” Internet Engineering Task Force (IETF), RFC 2827, 2009.

28. J. Li, J. Mirkovic, M. Wang, et al., “Save: Source Address Validity Enforcement Protocol,” in Proc. IEEE INFOCOM,New York, 2002, pp. 1557–1566.

29. T. Peng, C. Leckie, and K. Ramamohanarao, “Proactively Detecting Distributed Denial of Service AttacksUsing Source IP Address Monitoring,” Lect. Notes Comput. Sci. 3042, 771–782 (2004).

30. C. Jin, H. Wang, and K. Shin, “Hop�Count Filtering: An Effective Defense Against Spoofed DDoS Traffic,” inProc. of the 10th ACM Conf. on Computer and Communications Security, New York, 2003, pp. 30–41.

31. H. Wang, D. Zhang, and K. Shin, “Detecting SYN Flooding Attacks,” in Proc. IEEE INFOCOM, New York,2002, pp. 1530–1539.

32. J. Oikarinen and D. Reed, RFC 1459: Internet Relay Chat Protocol (Network Working Group, 1993).33. M. Akiyama, T. Kawamoto, M. Shimamura, et al., “A Proposal of Metrics for Botnet Detection Based on Its

Cooperative Behavior,” in SAINT Workshops, Hiroshima, Japan, 2007, p. 82.34. W. Strayer, R. Walsh, C. Livadas, et al., “Detecting Botnets with Tight Command and Control,” in Proc. of the

31st Int. Conf. on Local Computer Networks (LCN), Tampa, USA, 2006, pp. 195–202.35. K. Chiang and L. Lloyd, “A Case Study of the Rustock Rootkit and Spam Bot,” in Proc. of the First Workshop

on Hot Topics in Understanding Botnets, Berkeley, 2007, p. 10.36. “SSAC Advisory on Fast Flux Hosting and DNS,” Technical Report of the ICANN Security and Stability Advi�

sory Committee, 2008: http://www.icann.org/en/committees/security/.



37. H. Tu, Z. T. Li, and B. Liu, “Detecting Botnets by Analyzing DNS Traffic,” in Proc. of the Pacific Asia Workshopon Intelligence and Security Informatics (PAISI), Berlin, 2007, pp. 323–324.

38. R. V. Salomon and J. C. Brustoloni, “Identifying Botnets Using Anomaly Detection Techniques Applied toDNS Traffic,” in Proc. of the 5th IEEE Consumer Communications and Networking Conf., Las Vegas, 2008,pp. 476–481.

39. B. Al�Duwairi and L. Al�Ebbini, “BotDigger: A Fuzzy Inference System for Botnet Detection,” in Proc. of the5th Int. Conf. on Monitoring and Protection (ICIMP’10), Barcelona, Spain, 2010, pp. 16–21.

40. I. Stoica, R. Morris, D. Karger, et al., “Chord: A Scalable Peer�to�Peer Lookup Service for Internet Applica�tions, in ACM SIGCOMM, New York, 2001, pp. 149–160.

41. P. Maymounkov and D. Mazieres, “Kademlia: A P2P Information System Based on the XOR Metric,” in Proc.of the Int. Workshop on Peer�to�Peer Systems, London, 2002, pp. 53–62.

42. Zh. Huang, X. Zeng, and Y. Liu, “Detecting and Blocking P2P Botnets through Contact Tracing Chains,” Int.J. Internet Protocol Technology Archive 5, 44–54 (2010).

43. J. Kang and J. Y. Zhang, “Application Entropy Theory To Detect New Peer�to�Peer Botnet with Multi�ChartCUSUM,” in Proc. of the 2nd Int. Symp. on Electronic Commerce and Security, Washington, 2009, Vol. 1,pp. 470–474.

44. E. V. Ruitenbeek and W. H. Sanders, “Modeling Peer�to�Peer Botnets,” in Proc. of the 5th Int. Conf. on Quan�titative Evaluation of Systems (QEST’08), St. Malo, France, 2008, pp. 307–316.

45. D. Dagon, C. C. Zou, and W. Lee, “Modeling Botnet Propagation Using Time Zones,” in Proc. of the13th Annual Network and Distributed System Security Symposium (NDSS’06), San Diego, 2006.

46. P. Owezarski and N. Larrieu, “A Trace Based Method for Realistic Simulation,” in Comm. of the IEEE Int. Conf.,Toulouse, 2004, pp. 2236–2239.

47. R. Simmonds, R. Bradford, and B. Unger, “Applying Parallel Discrete Event Simulation to Network Emula�tion,” in Proc. of the Fourteenth Workshop on Parallel and Distributed Simulation (PADS’00), Washington, 2000,pp. 15–22.

48. A. Wagner, T. Dubendorfer, B. Plattner, et al., “Experiences with Worm Propagation Simulations,” in Proc. ofthe ACM Workshop on Rapid Malcode, New York, 2003, pp. 34–41.

49. G. Riley, M. Sharif, and W. Lee, “Simulating Internet Worms,” in Proc. of the 12th Int. Workshop on Modeling,Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), Atlanta, 2004, pp. 268–274.

50. A. Suvatne, “Improved Worm Simulator and Simulations,” Master’s Projects (San Jose, USA 2010).

51. J. Krishnaswamy, “Wormulator: Simulator for Rapidly Spreading Malware,” Master’s Projects (San Jose, USA,2009).

52. M. Schuchard, A. Mohaisen, D. Kune, et al., “Loosing Control of the Internet: Using the Data Plane to Attackthe Control Plane,” in Proc. of the 17th ACM Conf. on Computer and Communication Security (CCS/10) (ACM,USA, 2010), pp. 726–728.

53. T. Gamer and C. Mayer, “Large�Scale Evaluation of Distributed Attack Detection,” in Proc. of the 2nd Int.Workshop on OMNeT++, Rome, 2009, pp. 1–8.

54. A. Varga and R. Hornig, “An Overview of the OMNeT++ Simulation Environment,” in Proc. of the Int. Conf.on Simulation Tools and Techniques for Communications, Networks and Systems & Workshops (Simutools’08),Brussels, 2008, pp. 1–10.

55. The INET Framework is an Open�Source Communication Networks Simulation Package for the OMNeT++Simulation Environment, http:// inet.omnetpp.org/

56. ReaSE—Realistic Simulation Environments for OMNeT++, https://i72projekte.tm.uka.de/trac/ReaSE/

57. L. Li, D. Alderson, W. Willinger, et al., “A First�Principles Approach to Understanding the Internet’S Router�Level Topology,” ACM SIGCOMM Computer Communication Review, 3–14 (2004).

58. S. Zhou, G. Zhang, G. Zhang, et al., “Towards a Precise and Complete Internet Topology Generator,” in Proc.of the Int. Conf. on Communications, Circuits and Systems (ICCCAS), Guilin, China, 2006, pp. 1830–1834.

59. K. V. Vishwanath and A. Vahdat, “Realistic and Responsive Network Traffic Generation,” in Proc. of the Conf.on Applications, Technologies, Architectures, and Protocols for Computer Communications, New York, 2006,pp. 111–122.

60. S. Jones, “Internet Relay Chat,” in Encyclopedia of New Media: An Essential Reference to Communication andTechnology (SAGE Publications, Thousand Oaks, California: 2002), pp. 256–257.

61. B. Saha and A. Gairola, “Botnet: An Overview,” CERT�In White Paper CIWP, 2005, http://www.mende�ley.com/research/bots�botnet�overview/

62. A. Oram, Peer to Peer: Harnessing the Power of Disruptive Technologies (O’Reilly Media, Sebastopol, 2001).

Documents

Simulation-based study of botnets and defense mechanisms against them