Discover Top Posts Tagged with #ffsn

Detecting and Mitigating Fast-Flux Service Networks

Written as part of evaluation in IMT4561 Applied Information Security.

1. INTRODUCTION

The aim of this paper is to review state of the art techniques for detecting and mitigating Fast-Flux Service Networks. This will be done by reviewing recently published work on the topic. It is however important to not only understand these techniques, but also to have an understanding of context surrounding FFSN. The reason for this is that to understand how something is used, one needs to understand why it emerged. Because of this to is also the goal of this paper to provide an introduction to some of the topics closely related to FFSN, This includes proxy servers, Content Distribution Networks (CDN), spoofing Domain Name System (DNS) servers and how services can be taken down by force.

Over the last couple of years, there has been written numerous articles regarding FFSN and how they can be detected. Techniques for mitigating FF service networks seems to have received less attention, probably due to the fact that many of the techniques are common to botnets in general.

Much of the published provide excellent descriptions of their respective topics, but it is my opinion that they do not to fully provide the reader with an overview of FFSN. This involves combining what FFSN are, why it have emerged, and why they can be difficult to detect. What follows is a brief overview of previous work worth mentioning in regard to this article. They are also the main sources of information gathered for this paper.

1.1. Related work

The Honeynet Project’s article from 2007[3] is hard to miss when searching for information about FFSN. It is cited by almost any publication on the topic to date and gives an excellent introduction to how these networks operates.

[6] and [1] gives a further description of the attributes of known FFSNs, having focus on the lifespan and size, i.e., the number of compromised machines, of botnets utilizing FFSN. Extensive work has been put into finding a method to quickly and accurately decide whether a given domain belongs to a FFSN. [7] and [8] describes how a domain can be classified as part of a FFSN by regularly polling the DNS server to examine how a domains records change over time. [4] goes even further by gathering data from active and passive sensors in order to identify FFSN within minutes. These articles provide a good foundation for how FFSNs can be distinguished from the benign Content Distribution Network (CDN) and Open CDN.

The Internet Corporation for Assigned Names and Numbers (ICANN) published a warn- ing concerning FFSNs as early as 2008[17]. The article defines some of the terminology concerning FFSN, as well as a introduction to the anatomy and workings of FFSNs in general.

Finally, on how botnets can be mitigated, [10] gives a good and thorough description on the specific case of peer-to-peer botnets.

1.2. Outline

Section 2 provides the background of botnets, FFSN and other concepts closely related to the topic. This include Open Content-Distribution Networks, which without the proper tools will be easy to confuse with FFSN. It also review common applications for FFSN and some of the mitigating techniques which applies to botnets in general.

Section 3 gives an presents existing techniques for detecting FFSN. It will review FFSN measurement with both active sensors, i.e., polling a DNS server, and passive sensors, i.e., listening to data traffic. The section will also review some of the techniques which can be applied to evade those kinds of measurement.

In Section 4 some of the techniques for mitigating FFSNs are presented. It will present a technique for locating the server hidden behind the proxies, popularly called the mothership. It also describe an interesting technique for avoiding being located.

Discussions, suggestions for further work and conclusions are presented in section 5.

2. BACKGROUND

Fast-Flux service networks is a technique for using compromised computers in a botnet to hide a servers location[4]. Comprised computers, or agents, who is part of a FFSN serve as proxy which relays the request from the client to the hidden server, and the response back to the client. There are essentially three ways to achieve this. The first is to point the Domain Name System (DNS) A records for a domain to the Internet Protocol (IP) addresses of compromised computers. This is usually referred to as Single-Flux service networks. Note that when a client requests an available IP for a given domain, multiple of these A records may be returned. When a client wants to load contents from e.g., www.example.org, it first finds the reference to the nameserver which stores the A records. Fluxing (i.e., regularly changing) this or these IP’s is called Double-Flux service networks. The third method defined is simply Single-Flux and Double-Flux combined[4]. The difference between Single-Flux service networks and Double-Flux networks can be observed in figures presented in[3]. In the remainder of this paper, there will not be much focus on the differences between Single- Flux and Double-Flux Service Networks.

In order to have a FFSN, the adversary has to obtain a botnet. Getting hold of a botnet can be quite easy, and you can rent a large botnets tailored for your needs if you know where to look. A botnet consists mainly of two parts. First the adversary needs a mechanism to compromise computers. This is usually done by developing a trojan horse, which masquer- ades as a legit application, but in fact gives the advisory more or less complete control of the system. Next, the user needs a mechanism to communicate with the compromised comput- ers, issue commands and updating the malware. This is usually referred to as the botnet’s Command and Control mechanism (C&C). Traditionally, the chat protocol Internet Relay Chat (IRC) has been extensively used as a C&C platform. FFSN can be used with every protocol which uses DNS, but HTTP seems to be the most popular protocol for this use[4].

Compromised computers has the habit of being shut down from time to time. This forces the FFSN owner to change the A records regularly in order to prevent that all A records point to unavailable computers. Each A record has a property that tells the client how long a given A record is valid. This property is called Time-To-Live (TTL) and is for regulardomains the value is recommended to be set to several days.[4]. For FFSNs however, this value is usually much lower, and TTL’s on less that 15 minutes is not uncommon[3][4].

While it is easy to detect Fluxing and low TTL’s, other benign network types share the same properties. Such networks range from the simple load-balancing Round-Robin DNS algorithm, to advanced high-availability network architectures such has content distribution networks[12]. When using the Round-Robin method, the user defines multiple A records for a given domain. When a client request the IP of the domain, the first A record is returned. On a second request, the next A record is returned. This method enables load-balancing of request to a number of different hosts or servers. It is important to note that the A records in Round-Robin DNS generally do not change, and that the IP’s is usually in the same subnet. This makes quite easy to distinguish Round-Robin from FFSN.

Round-Robin DNS (RRDNS) do provide some load-balancing, however it is quite in- effective on a larger scale. Advanced archtectures has been developed for ensuring high availability and load-balancing of web-services on a large scale. One of these archtectures is called Content Distribution Network (CDN). The aim of CDN is to move the content closer to client. This can be done by replicating the service over several servers spread around the world. When a client then requests available IP addresses of the domain, the IP addresses to the servers closest to the client is returned[11]. This can reduce the average load time of the service, in addition to making the service more resilient to total unavailability[11]. If one of the servers in the CDN goes down there are others ready to take its place, and the service remains available. The reason why RRDNS an CDN is generally not used for hosting content is that they are too easy to trace and shut down[8].

There are two major similarities between CDN and its evil twin brother FFSN. First, as mentioned, the TTL of its A records are changed frequently. Second, the A records of a domain in these networks usually has a large IP geometry, i.e., the IP addresses for the domain are not in the same subnet[8]. Being able to identify the differences between FFSN and CDN has received a lot of attention over the last years, and should be considered the one of the key factors to enable reliable detection of FFSN. Some of the proposed methods for distinguishing FFSNs and CDNs will be reviewed later in this paper. It should be noted that CDNs and Round-Robin DNS are not suitable as alternatives to FFSN. This is due to the ease of identification and localization of servers that is part of these networks.

One of the main motivations for an adversary to use FFSNs is, as with CDN, to ensure high service availability. However, FFSNs are utilizing an additional quality which ensures this availability. This quality is that the server is actually hidden for the client by the compromised computers. This makes it more difficult for law enforcement to identify where the service originates, which in turn makes it harder to shut down the service by force. An alternative method for taking down these types of services is to make the Intenet Service Providers (ISP) block a specific domain which is known to be a part of the FFSN. This is discussed later in the paper. Another related feature that is appreciated by adversaries using FFSNs is that because it is not possible to contact the hidden server directly. For a client sending a request to a domain using FFSN, the compromised computer will appear as the final destination for the request. This makes it more difficult to identify the adversary behind the crime.

The most popular application of FFSNs seems to be hosting of illegal content. FFSN can however also be considered an application of botnets. Botnets can use FFSN to hide its C&C central, commonly referred to as the mothership. This makes it feasible to let the adversary remain hidden while the mothership issues commands to its compromised computers. The location of the mothership in a FFSN can however be estimated by utilizing a slightly modified version of method called Constraint-Based Geolocation (CBG)[14]. The idea of CBG is to send request to a server from multiple computers and measuring how long it takes to receive the response. All the computers used to send requests needs to have a known location. A network of such computers with known locations can be found atwww.planet-lab.org. It is possible to use this technique to locate the mothership behind a proxy. To do this, it has to be taken into account that the IP address where the request is sent, isn’t really the last stop. Though this fact adds uncertainty to the real response time, the large amount of proxy hosts makes it feasible to do some quite good estimations of the motherships location. This will be further reviewed later in the paper.

Now that a brief introduction to the nature of FFSNs has been given, it is time to study how these networks may be detected. The techniques and results reviewed in the following sections is extracted from published scientific articles.

3. DETECTING FAST-FLUX SERVICE NETWORKS

This section will review some of the proposed methods for detecting Fast-Flux Service Networks. To enable the detection of FFSNs, some metrics on the nature of FFSNs has to be defined. The most relevant background on the attributes of FFSN is Caglayan et al.[4][5][6], Holz et al.[12][1], Passerini et al.[7] and Campbell[8].

3.1. The observable attributes of Fast-Flux Service Networks

The works of Caglayan, Holz and Passerini does have many similarities when it comes to describing the observable attributes FFSNs. They do however have a somewhat different view on the attributes. There is also some attributes that to some extent are unique for the respective works. Next follows a review of which attributes that can be used to identify FFSNs.

Caglayan is putting emphasis on four different attributes possessed by FFSNs: (1) Time- To-Live (TTL) is how long each of the A records is set to be valid. (2) The Fast-Flux Activity Index is a measure of how fast the A records for a domain fluxes (i.e., changes IP). (3) The Footprint Index is a measure of how widely spread the IP addresses of a given domain is. (4) Guilt by association is used to identify IP addresses and nameservers which has been previously identified as part of a FFSN.

When wanting to identify FFSNs from other benign networks, it is observed that FFSN domains usually has a much lower TTLs than regular domains[6]. This is observation is though not enough due to the fact that CDN networks also usually have low TTLs on their domains[12]. The main reason for setting the TTL low is high availability.

High availability can be enforced with two components: (1) A nameserver which stores what IP addresses is valid for a given domain, and (2) a piece of software which is regularly polling the IP addresses valid for that domain. Imagine now that the owner of the domain example.com has two machines at her disposal: One powerful and expensive server, and one smaller and slower server. She wants to provide her users with the best possible experience, and sets the IP address of the powerful server as the only A record for the domain. At the same time a small program is running on the less powerful server. This software has two tasks: Every minute it send a request to the powerful server and uses the response to verify that it is available. If the server does not respond, it can be assumed that it is unavailable. This can be due to overcapacity, loss of power etc. Now knowing that the primary server is unavailable, the small server changes the A record of the domain to its own IP address. If the TTL of the A record was set to a high number, e.g., 6 hours, chances are that the calling client would keep attempting to reach the now unavailable IP address for quite some time. However if the TTL was low, e.g., 10 minutes, the service would become available on the less powerful server within reasonable time.

This is a very simple example with limited availability gain for the service owner, but the same concept applies to benign CDNs and malicious FFSNs. In FFSNs the unavailability of a given server is probably due to that the victim has powered of his laptop or desktop. On CDNs servers may become unavailable due to for example large amount of network traffic. These factors the owners of both FFSNs and CDNs to keep their TTLs relatively low. The Activity Index is a measure for how fast the IP addresses for a given domain is changing. This is related to the TTL, but addition to detect mere changes to the A records, the number of new, previously unknown IP addresses in the FFSN is also recorded. It is however not stated any claim as to how the Activity Index can be used other than to merely support whether a domain is used in a FFSN or not.

The Footprint Index is a measure for how spread the IP addresses for a domain are. Such spread can usually be determined by looking at the Internet Service Providers (ISP) for the IP addresses assigned to a given domain. Though both FFSNs and CDNs has low TTLs, the owners of CDNs usually have all their servers connected to the internet through the same, or a few ISPs[12]. Because the IP addresses in FFSNs are connected to the internet though a wide range of ISPs, the Footprint Index provides a quite good measure for detecting FFSNs[6]. A factor which is making the Footprint Index less useful is, as Caglayan states, that it requires the FFSN to monitored for a longer period of time in order to generate reliable results.

The work of Holz and Caglayan has many similarities, but they do have slightly different approaches on detecting FFSNs. As Caglayan, Holz et al. are defining a set of distinguishing parameters based on two known restrictions of FFSNs[12]: (1) IP diversity. This is somewhat similar to Caglayan’s Footprint Index, but Holz focuses on the fact that the attacker does not have control over which IP addresses is available for his domain. (2) No physical agent control. While owners of CDNs and other benign networks has control over the machines that is used to make the service available, the owners of FFSNs usually has no control over the availability of the compromised machines. This is quite related to the Activity Index and the issue of high availability and low TTL described in the previous section.

While these observations is quite similar to Caglayan, Holz are using them differently in order to create parameters which can distinguish FFSNs from other networks. Holz has defined three distinguishing attributes: (1) Caglayan used the restriction of no physical agent control to measure how fast the A records where changing (Activity Index). Holz, on the other hand, observes that the lack of control over the availability of the machines, usually results in that the owner creates many A records for the domain. The argument of the FFSN owner can therefore be: If there are many valid IP addresses, one of them is likely to be available. (2) The number of nameservers used for a domain, which relates to the detection of Double-Flux Service Networks, which is described earlier. (3) The number of Autonomous System Number (ASN), which is similar to the Footprint Index. The number of ASN indicates how many different origins the IP addresses for a domain has. This may for example be measured on the number of different ISPs represented among the IP addresses for the domain.

While the work of Passerini et al.[7] does include most of the attributes defined by Caglayan and Holz, they are organizing the are grouping the attributes in a different way. In addition Passerini gives more attention to attributes that may help decide that a network is benign, rather than looking solely for suspicious behavior. When identifying attributes, or features, which will be used for identifying FFSNs in their FluXOR application, Passerini et al. is dividing the attributes into three groups: (1) features characterizing of the domain name to which the suspicious hostname belongs to, (2) features characterising the degree of the availability of the network that is potentially associated with the suspicious hostname, and (3) features characterising the heterogeneity of the potential agents of the network. In the first group, Passerini puts the attributes domain registrar and domain age. These two attributes are not considered by other work reviewed in this paper. This may be called too opinion-specific, Passerini claims to have observed that some registrars are more commonly used than others in FFSNs, but does unfortunately not refer to any statistics backing up this claim. Passerini argues that the reason for that a few registrars is popular among FFSN owners is that they reside in countries with less strict laws against cyber crime. Concerning domain age, Passerini claim that benign domains usually gets much older that maliciousones. While this claim may be easy to agree upon, there is not referred to any statistics on the age of domains.

In the second group of factors for defining FFSNs attributes, Passerini puts the number of distinct A records associated with a domain and the TTL of these records. These attributes are closely related to the work of Caglayan and Holz. As mentioned earlier, the number of A records and TTL alone may not be sufficient to distinguish FFSNs from CDNs. The attributes in the third group enables the FluXOR application to detect FFSN behavior. These attributes are also closely related to the work of Caglayan and Holz and include: (1) The number of different subnets in the network. This relates to the Footprint Index defined by Cagalyan and IP diversity defined by Holz. (2) The number of different autonomous systems. An autonomous system is defined by Hawkinson as a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy[18]. This is somewhat to Footprint Index and IP diversity, but is not limited to different IP addresses being on the same subnet. (3) Number of distinct resolved qualified domain names. Even though the A records for a domain return multiple different IP addresses, the qualified domain name for these IP addresses can be identical for these IP addresses. Similar qualified domain names for the IP addresses, beyond the chance of luck, is assumed to be impossible for FFSNs. This attribute can therefore help to prove that a domain is benign. (4) Number of distinct assigned network names. This is the name given the network by the registration authority e.g., the ISP. As with the previous attribute, multiple IP addresses can share a network name, and similar network names can therefore be an indication of that a network is benign. (5) Number of distinct organisations. Organizations can also own multiple networks, such as those described in (4). So even though different IP addresses belong to different networks, they may still belong to the same organization. This may also add to the belief the domain pointing to these IP addresses, is benign.

In contrast to Passerini et al., Campbell et al. does not describe the details of FFSNs in such detail[8]. Campbell is simply monitoring the A records of a domain and compares new IP addresses with previously registered subnets for that domain. If a new IP address is not part of any existing subnets, a statistical method called Random Walk is used in order to estimate whether domain is performing Flux activity or not. Campbell is also utilizing dynamic black and white list in order to quickly label subnets with the same value as its related subnets. This technique is similar to the guilt by association technique described by Caglayan.

3.2. Fast-Flux behavior

When describing the behavior of FFSNs, Caglayan et al. creates four groups[6]: (1) Short term behavior, (2) long term behavior, (3) organizational behavior, and finally (4) op- erational behavior. When describing the short term behavior of a FFSN, the TTL and especially the Activity Index is taking into account. Questions one might ask concerning the short term behavior is therefor whether a given domain is performing Flux Activity, i.e., changing IP addresses or nameserver at a given time. While short term behavior focuses only on the individual actions in a FFSN, the long term behavior is more concerned with how FFSNs evolve over time. Key factors in long term behavior is the expected lifetime of a FFSN, and the number of IP addresses, nameservers and domains which is identified as part of the FFSN. Studies show that there is a strong relation between the number between the number of domains involved in a FFSN, and the expected lifetime of the network[6]. Note that the lifetime of a FFSN in a large degree depends of the type of illegal content which the FFSN is used to conceal[6].

Nazario and Holz has also monitored the long term behavior of FFSNs[1]. While Caglayn collected data on live FFSNs for a year[6], Nazario and Holz monitors their FFSNs for five months. In their work they use a tool called ATLAS to perform DNS mining, anddivide the long term behavior of FFSNs into five categories: (1) discovery, (2) lifetimes, (3) membership, (4) visibility, and (5) distinct botnets. Though not defined explicitly, the categories discovery and visibility is assumed to relate to the amount and intensity Fast- Flux activity, such as number of A records and the Fluxing of these. Nazario argues for how the use of so-called sleeper domains, which are domains that stays inactive for a longer period of time before it takes part of the FFSN. The lifetimes group relate to the lifetime of the monitored domains. Nazario define the active timeline as the time between data was first gathered on the domain, until the domain becomes inactive. The reason for a domain going inactive is usually that the domain has been taken down by forced by the ISP, or that the A records for the domain has been changed to point to servers controlled by the ISP. The latter is commonly referred to as parking. (3) Relates to how many botnets a given IP address is associated with. In their study the IP addresses associated with a botnet was on average also associated with 14 other FFSN domains[1, p. 5]. Finally, distinct botnets relate to the issue of mapping which domain belongs to which botnet.

An observation made by Campbell is that there is a different development in the number of subnets associated with FFSNs and CDNs. The number of observed subnets in CDN increases quite rapidly while the CDN is young, and seems to even out after a while, when all the IP addresses in the network has been observed. Because FFSNs does’t pay for its servers and IP addresses, it has a much larger pool of IP addresses. The number of subnets therefore usually continues to increase much longer than CDNs[8].

With the term organizational behavior, Caglayan is referring to how the FFSNs and the associated botnet is organized. This behavior can be related to the Command and Control (C&C) of the botnet. The organizational behavior also affects the social network of the FFSN and thereby affect the guilt by association attribute of the network. The social network of a FFSN can be viewed as a multigraph where the domains, nameservers and compromised hosts are nodes and the relation between them (e.g., IP addresses) are edges. Two nodes which is directly or indirectly connected to each other is said to be in the same cluster[6]. Relations between the nodes in the social network is detected by monitoring the suspected FFSN. The forces the adversary to choose a tactic in order by balance the need for availability and control of his botnet. Aggressive fluxing of domains, i.e., chaining the A records of the domains may provide higher availability than less frequent fluxing. A consequence of this, however, is that services monitoring the domains are able to create a larger social network over the botnet, and is thereby able to identify the malicious behavior faster.

The last group in Caglayan’s definition of behavior in FFSNs is the operational behavior. Operational behavior relates to where the agents, or compromised computers, reside. This may be the geographical location or in terms of Autonomous Systems Numbers (ASN) ASN is a unique number which identifies a Autonomous System, which is described earlier. In order to measure this operational behavior, Caglayan et al. looks at the relation between the number of domains and the number of countries or ASNs[6].

3.3. Analyzing FFSN attributes

Having reviewed attributes which can be used to identify FFSNs, it’s time to take look at how these attributes can be analyzed. The aim of this analyzation is to determine whether a domain is part on a FFSN not.

Holz et al. is dividing the total number of A records with the number of A records returned in a single lookup in order to determine the fluxiness of a domain. A low fluxiness score may be evidence of a traditional domain with a fixed set of IP addresses. A high fluxiness score may indicate the use of CDN or FFSN[12]. Holz is also assigning a flux-score to the domains. The flux-score is calculated with

f(x) = w1 ∗ nA + w2 ∗ nASN + w3 ∗ nNS

The w values represents different weights and nA is the total number of A records. nASN is the number of unique Autonomous System Numbers and nNS is the number of different nameservers. Holz use the bias value b to determine the threshold which the domain has to exceed in order to be classified as a FFSN. the w values should according to Holz be adjusted periodically in order to adjust to adversary mimicry. The reason for this is that FFSN owners can adapt his network to static values in order to disguise his domains among benign domains.

Caglayan et al. are using techniques from artificial intelligence when they are creating a Bayesian belief network This bayesian belief network is using the TTL, the Activity Index and the Footprint index to create a probabilistic assessment of whether a domain is associated with a FFSN or not[4].

When the FluXOR application by Passerini et al. is out detecting live FFSNs, it first analyses the attributes of the domains themselves. As mentioned earlier, these attributes is the domain age and the domain registrar. After a short time, FluXOR extracts the domains it considers suspicious and send them to further analysis[7]. During this analysis, the attributes mentioned earlier in this section is analyzed. Based on the values found in the analysis FluXOR determines if it thinks the domain is associated with a FFSN by using a Bayesian classifier[7].

While Campbell also is using a probabilistic model for determining whether a domain belongs to a FFSN or not, his approach is rather different from the work of Caglayan and Passerini. Each time there is detected a change in a monitored A record, its domain is checked for being associated with a FFSN. This is done by comparing the new A records /12 subnet (i.e., the first two numbers in an IPv4 address) to known subnets for that domain. If it is not, a statistical method is run based on the previous decisions for that domain. While the results of the previous random walks is an important part of the analysis, it is also recognized that given a change in an A record, there is a greater probability that the A record belongs to a FFSN domain[8]. Note that they in their experiments they tried at various sizes of such subnets, e.g., /8 and /16 subnets.

3.4. Gathering data on Fast-Flux Service Networks

Knowing what attributes to look for and how to analyze them in order to identify FFSNs, the focus now turns to how these data can be gathered. In their work, Caglayan et al. is describing two main types of sensors for gathering data: active and passive sensors[6]. Caglayan implements three active sensors. These can be considered the applications of the TTL, the Activity Index and the Footprint Index, which is reviewed earlier. The difference between the active and the passive sensors is that the active sensors are sending requests to the respective domains. The passive sensors merely intercepts requests initiated by other clients by using a technique called passive DNS replication[19]. When using passive sensors, the observer is not in control of the amount of data. This may result in an uneven distribution of data in the different intervals of the monitoring. Beyond this difference, the data from active and passive sensors are treated in the same manner.

When gathering data using passive sensors, the observer has to place the application intercepting the data a place on the network where the data is available. In organizations this would typically mean that the interceptor is connected to the router responsible for connecting the organization’s local interanet with the rest of the world. An other option is to intercept data packages transmitted between computers and the wireless router they are connected with, however this certainly raises some ethical and/or legal questions. While Campbell et al. was monitoring the network traffic of a laboratory during their experiments, Perdisci et al. where in their experiments allowed to set up their passive sensors in front of the DNS servers of a large american ISP[9]. Because such monitoring provides a more real- istic data, there might therefore be a problem with low amount of requests for A records[7]. Campbell et al. tries to mitigate this by multiplying each domain lookup request[8].

4. MITIGATING FAST-FLUX SERVICE NETWORKS

In the real world, there is usually not enough just detect the presence of a Fast-Flux service network. It is also desirable to be able to do something about. The techniques for taking down FFSNs are pretty much the same for taking down any type of botnet. There are however certain techniques that relates to the fact that FFSN is capable of concealing a server or a set of servers behind the compromised computers which makes the botnet. This section will review some of the techniques which can be utilized in mitigating FFSNs, i.e., stopping the malicious activity.

The problem of mitigating FFSNs has not received as much attention as the problem of detecting them. Much the of the reason for this may be that because FFSNs is a central part, or an application of botnets, they can be mitigated by mitigating the botnet. Holz et al has provided a short overview of the available methods for mitigating FFSNs in[13]. In these slides he is dividing the techniques into two main groups: (1) Domain blacklist, and (2) Identifying the control node. The first group mitigates the FFSN by disabling the domain, or domains, associated with the network. There are essentially two ways of disabling a domain. Technically, both of these methods pretty straight forward to implement, but it does require some special privileges. First, the domain can taken down by the registrar which is responsible for that domain. This, requires the cooperation of the registrar, which sometimes can be quite difficult to get. The lack of such cooperation can be caused by both diplomatic and legal factors. The other way of disabling a domain is by blocking user from accessing the domain. This is usually done by an ISP and is therefore under national control. There also exists international treaties where countries agree to cooperate on disabling domains serving illegal content. An example of such treaty is the Cybercrime Convention from 2001[20]. Disabling a FFSN domain may however not be an efficient way of taking down the whole network. A single FFSNs may be associated with several thousand domains[6], and there is estimated to be registered well over one hundred thousand new domains each day[21]. In addition SSAC has observed FFSNs exploiting a common practice among registrar called domain tasting, where the user can try the domain for a couple of days and then return it to the registrar without getting billed[17].

Clearly, there is a need for additional techniques. One efficient way of taking down an illegal service would be to confiscate the server providing the illegal content. Because there are generally much fewer content providing computers than compromised computers and domains, taking out these would do more damage on the illegal service. In addition, replacing such a computer is much more expensive than new domains or new compromised computers. The problem is that in order to take out this or these computer, physical access is needed. In order to get physical access you need to know where it is, in addition to a subpoena. Because the computer his hidden behind numerous of compromised host, locating these computers is not easy. There are mainly two different was in order to locate the hidden computers. The first is to detect a hidden computer’s IP address by monitoring going to and from one or several compromised hosts. This usually requires the cooperation of the ISPs of the compromised hosts. The second technique is to use a modified version of Constraint Based Geolocating (CBG) to provide an estimation of the hidden computer’s location. While using the modified CBG, the distance between the compromised host and the hidden computer is considered one extra hop. Though there may be several network nodes between the two, the number of compromised hosts combined provides a pretty good estimation. This is estimation will however not be enough alone in order to locating the exact position, but might help to identify which country or region the computer resides in[16]. This type of geolocation may also be made more difficult by utilizing techniques for evading the geolocation of an IP address. One way of doing this is by adding an extra delay to the responses. This may result in a more uncertain estimation of the hidden computer’s location, but more advanced implementations of the technique may actually fake another location[14][15].

5. DISCUSSION AND CONCLUSIONS

This article has reviewed some of the recently proposed techniques for detecting and miti- gating FFSNs. It has been reviewed how such identification can be performed by identifying and measuring the observable attributes of FFSN domains. It has also been discussed how these attributes can be analyzed in order to classify a domain as part of a FFSN or not. In the discussion it has been distinguished between the short-term and long-term behavior of FFSNs. Finally, some of the techniques which can be used for mitigating FFSNs and botnets in general where reviewed.

Based on the review done in this article, it may be concluded that there are three main techniques for classifying whether a domain is part of a FFSN or not. The first is to observe over a period of time how often the IP addresses for a domain changes. This may indicate the presence of a high-availability service which may be benign, so this technique is usually not enough by itself. The next technique is too observe who owns the IP addresses associated with a domain. If a domain changes its IP addresses often, and these addresses belongs to different internet service providers all over the world, it is a good indication of FFSN. The first two techniques combined may provide reliable and accurate in order to detect FFSNs, but because they have to observe each domain for a longer period of time, it may proved too slow detection. In order to speed up the detection we may use the third technique: domain blacklisting and whitelisting. When doing blacklisting we may utilize two facts: (1) An IP address associated with a FFSN domain is on average associated with several other FFSN domains. (2) Each FFSN domain is associated with a large number of IP addresses. These two facts may enable us to generate a social network of the domains and IP addresses. Doing analysis on this social network may help us classify domains as part FFSNs much faster. However, there is a higher probability of false positives while doing blacklisting and whitelisting alone. The technique should therefore be used together with the to first techniques. By whitelisting IP addresses and domains that we have confirmed as benign may also reduce the number of false positives. Whitelisting is limited by the amount of domains and IP addresses we are able to confirm, and also provides advisories an opportunity to remain undetected by being erroneously be put on the whitelist.

An efficient mitigation of FFSNs are largely dependent on legal international coopera- tion. Having directives which enables national law enforcement to cooperate with foreign colleagues is crucial for efficiently taking down malicious services by force. In addition there needs to be raised some ethical questions concerning how to deal with the compromised computers exploited by the botnet owners.

5.1. Further Work

As for further work, it would be very interesting to see some experimental social network analysis of the domains, nameservers and IP addresses in a FFSN. There exists tools such as Maltego and NetGlub which enables automated structuring and visualization of such networks. There will be a need for a tool that is able to gather DNS information and preparing them for network analysis. It should be interesting to get a measure of just how efficient dynamic blacklisting and whitelisting of domains may be on FFSNs.

Much of the current research are also using subnets in order to classify domains as ma- licious or benign. This technique is suited for the still most popular IPv4 address space. Although not very widespread yet, it could be interesting to see how well suited such anal- ysis is for the new IPv6 address space. Being immensely much larger that IPv4, IPv6 could potentially become more popular. A current limitation is that few personal computers use IPv6 while being connected to the internet. This is however likely to change in the time to come as IPv4 is about to run out of available addresses.

REFERENCES

[1] Nazario, J.; Holz, T.; , As the net churns: Fast-flux botnet observations, Malicious and Unwanted Software, 2008. MALWARE 2008. 3rd International Conference on , vol., no., pp.24-31, 7-8 Oct. 2008

[2] Porras, P.; Saidi, H.; Yegneswaran, V.; , A Multi-perspective Analysis of the Storm (Peacomm) Worm, 2007. http://www.cyber-ta. org/pubs/StormWorm/.

[3] The Honeynet Project. Know Your Enemy: Fast-Flux Service Networks, 2007, http://www.honeynet.org/book/export/html/130

[4] Caglayan, A.; Toothaker, M.; Drapeau, D.; Burke, D.; Eaton, G.; , Real-Time Detection of Fast Flux Service Networks, Conference For Homeland Security, 2009. CATCH ’09. Cybersecurity Applications & Technology , vol., no., pp.285-292, 3-4 March 2009

[5] Caglayan, A.; Toothaker, M.; Drapaeau, D.; Burke, D.; Eaton, G.; , Behavioral analysis of fast flux service networks, Proceedings of the 5th Annual Workshop on Cyber Security and Information Intelligence Research: Cyber Security and Information Intelligence Challenges and Strategies, pp.1-4, 2009

[6] Caglayan, A.; Toothaker, M.; Drapaeau, D.; Burke, D.; Eaton, G.; , Behavioral Patterns of Fast Flux Service Networks, System Sciences (HICSS), 2010 43rd Hawaii International Conference on , vol., no., pp.1-9, 5-8 Jan. 2010

[7] Passerini, E.; Paleari, R..; Martignoni, L..; Bruschi, D.; Zamboni, D.; , FluXOR: Detecting and Monitor- ing Fast-Flux Service Networks, Detection of Intrusions and Malware, and Vulnerability Assessment , pp.186-206, 2008

[8] Campbell, S.; Chan, S.; Lee, J.R.; , Detection of Fast Flux Service Networks Citeseer

[9] Perdisci, R.; Corona, I.; Dagon, D.; Lee, W.; , Detecting Malicious Flux Service Networks through Passive Analysis of Recursive DNS Traces, In Proc. of 25th ACSAC, 2009

[10] Holz, T.; Steiner, M.; Dahl, F.; Biersack, E.; Freiling, F.; , Measurements and mitigation of peer-to-peer-based botnets: a case study on storm worm, Proceedings of the 1st Usenix Workshop on Large-Scale Exploits and Emergent Threats, pp 1-9, 2008

[11] Ao-Jan Su; Choffnes, D.R.; Kuzmanovic, A.; Bustamante, F.E.; , Drafting Behind Akamai: Inferring Network Conditions Based on CDN Redirections, Networking, IEEE/ACM Transactions on , vol.17, no.6, pp.1752-1765, Dec. 2009

[12] Holz, T.; Gorecki, C.; Rieck, K.; Freiling, F.C.; , Measuring and Detecting Fast-Flux Service Networks, Intelligent Data Analysis pp 24-31, Citeseer, 2008

[13] Holz, T.; Gorecki, C.; Freiling, F.; Rieck, K.; , Detection and Mitigation of Fast- Flux Service Networks, In: Proceeding of the 15th Annual Network & Distributed System Security Symposium (NDSS 2008)

[14] Gill, P.; Ganjali, Y.; Wong, B.; Lie, D.; ,Dude, where’s that IP?: circumventing measurement-based IP geolocation, Proceedings of the 19th USENIX conference on Security, 2010

[15] Muir, J.A.; Oorschot P.C.; , Internet geolocation and evasion , Technical Report TR-06-05, Carleton University School of Computer Science, April 2006

[16] Castelluccia, C.; Kaafar, M.A.; Manils, P.; Perito, D.; Geolocalization of Proxied Services and its Application to Fast-Flux Hidden Servers, In Proc. of 9th IMC, 2009.

[17] CANN Security and Stability Advisory Committee, SAC 025: SSA Advisory on Fast Flux Hosting and DNS, March 2008.

[18] Hawkinson, J.; Bates, T.; , Guidelines for creation, selection, and registration of an Autonomous System (AS), RFC1930, 1996

[19] Weimer, F.; , Passive DNS Replication, In Proceedings of 17th Annual FIRST Conference on Computer Security Incident Handling, 2005.

[20] Convention on Cybercrime, http://conventions.coe.int/Treaty/en/Treaties/ html/185.htm, 2001

[21] DomainTools.com: Domain Counts & Internet Statistics, http://www.domaintools.com/internet-statistics/

#GUC #FFSN