DNS Amplification Attack Detection and Mitigation via ...

DNS Amplification Attack Detection and Mitigation via sFlow with Security-Centric SDN Ahmad Ariff Aizuddin Mohd Atan

Megat Norulazmi Megat Mohamed Noor

Shadil Akimi Zainal Abidin

University of Kuala Lumpur 1016, Jalan Sultan Ismail, 50250 Kuala Lumpur, Malaysia 60321754000

University of Kuala Lumpur 1016, Jalan Sultan Ismail, 50250 Kuala Lumpur, Malaysia 60321754000

University of Kuala Lumpur 1016, Jalan Sultan Ismail, 50250 Kuala Lumpur, Malaysia 60321754000

[email protected] [email protected]

ABSTRACT Following the rise of modern networking, DDoS attacks are undeniably becoming more abusive. DNS amplification attack is a type of reflected DDoS attack that exploits DNS servers to distribute amplified responses. Detection-wise, related studies have focused on flow-based analysis as the alternative due to its feasibility within high-speed networks. However, fixed flowmonitoring application (i.e. NetFlow) is highly subjected to cache timeout hence lacks the support for a near real-time detection. Mitigation-wise, previous works have concentrated on the use of varying hardware appliances to handle excessive traffic. Nonetheless, such diversities introduce issues regarding flexibility and correlative control thus indicates the absence of centralized/autonomous mitigation. This paper proposed a substitute solution via sFlow with security-centric SDN to timely detect and reasonably mitigate DNS amplification attack.

CCS Concepts • Security and privacy➝Network security➝Denial-of-service attacks

Keywords DDoS; DNS Amplification Attack; Detection and Mitigation; sFlow; Security-Centric SDN

1. INTRODUCTION On March 18 2013 [1], a cyber-attack caused by DNS amplification has resulted in what many security experts are calling one of the biggest DDoS to date. The attack works by distributing spoofed DNS requests to numerous open resolvers. An open resolver is a DNS server that recursively replies to random DNS queries from anyone all over the cyberspace. Due to spoofing, these servers then would assume as if the DNS requests were sent from the intended target and all DNS responses are reflected (redirected) to that target instead (see Figure 1). The attack takes advantage of the fact that a regular DNS query (small investment) can produce huge DNS replies (amplified returns), where Amplification Factor is defined as: response size / request size. Cisco [2] highlighted that DNS amplification attack remains Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. IMCOM '17, January 05 - 07, 2017, Beppu, Japan Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-4888-1/17/01…$15.00 DOI: http://dx.doi.org/10.1145/3022227.3022230

[email protected]

a concern in 2016. Conventional countermeasures like Firewall/IDS mostly rely upon predetermined attack signatures, where each packet is compared against the state-table for deep packet inspections. The approach however does not apply to protocols like DNS since it transparently involves legitimate traffic, and would not be viable to inspect all data at high throughput levels. Subsequently, an incentive-driven approach is achievable through flow-based analysis [3]. A flow is a unidirectional sequence of packets that share the values of, but not limited to, ingress interface, source/destination IP address with port number, protocol, and ToS. A flow-based operation typically works by caching incoming packets in the flow cache for aggregation purpose. The aggregated flows are then exported as flow records to a dedicated server (collector) for analysis. The main advantage of flow-based analysis is its efficacy in today’s rapid networks since it relies on packet headers instead of the actual payload. As of today, there are two well-known types of flow-based application; NetFlow (fixed) and sFlow (flexible). Relatively, sFlow is gaining considerable attention due to its extensibility and association with recent technology called SDN [4]. SDN is an emerging network architecture that aims to simplify networking by decoupling the control planes (path decider) from the underlying data planes (packet forwarder) [4]. Control plane (controller) now is realized in a centralized server, while data plane (e.g. switch) becomes a simple forwarding device (see Figure 2). The separation of both planes allow more programmability and flexibility in a sense that a controller can run various applications from different programming languages, and streamline policy implementation or network reconfiguration in any forwarding device despite its vendors or platforms.

Figure 1. Theoretical concept of DNS amplification attack.

Figure 2. Standard SDN component. As shown in Figure 3, a typical SDN architecture consists of SDN application, Northbound Interface (NI), controller (control plane), Southbound Interface (SI), and forwarding device (data plane). NI defines the API (e.g. REST) that enables the interaction between controller and SDN application, while SI defines the API (i.e. OpenFlow) that permits the communication between controller and forwarding device. One might confuse OpenFlow to be the same as sFlow for its name, but in practice, they are primarily different. Technically, sFlow, short for sampled-Flow, is a flowbased monitoring technology developed by InMon Corporation, while OpenFlow is a flow-based configuration technology [3][4]. Thus, both technologies are required in order to have a pragmatic SDN architecture.

2. RELATED WORKS Most of the previous studies are NetFlow-related since it was formerly considered as a de-facto industry standard and has large community support back then [3]. Huistra [5] concentrated on detecting malicious DNS traffic by analyzing flow dataset simulated from NetFlow-configured routers. The traffic is characterized by the total number of packets/flow, or average number of bytes/flow. Rossow [6] focused on identifying potential DNS amplifiers by analyzing private flow dataset obtained from NetFlow-configured exporters. The amplifiers are defined by the number of received bytes/pairflow, and ratio of sent-received bytes. In both of these studies, the analysis require at least 5 to 10 minutes (timeout) of aggregated flows before the flow can be determined as benign or malicious. Hence, there is a delay in the detection. The main issue with shorter timeout is that not enough flow data is collected, thus resulting in high false positives. Then again, 5 to 10 minutes duration is contradicting the concept of a near real-time environment. Bhuyan et al. [7] discussed that emphasis should be given more to detection speed over accuracy (e.g. up to 90% accuracy for less than 1 minute) in order to facilitate a practical flow-based detection/mitigation within the DDoS defense mechanism. Hofstede et al. [8] presented an extension for exporter (i.e. Cisco’s IOS) to mitigate flooding attack by partly integrating the detection logic onto forwarding devices that support TCL-based scripting. Though it automates CLI command sequences, performing prevention using said approach however appeared to be disruptive for a forwarding device in a large network as it causes system bottleneck once the load increases due to excessive script execution. Another option would be using proprietary hardware appliance, as presented by Ye and Ye [9]. While this approach is distinctively devised to withstand amplification by load balancing incoming DNS traffic at the aggregation point, the embedded nature of it still introduces issues regarding network agility and dynamism, other than CAPEX and OPEX in a mass-deployment scenario.

Figure 3. SDN architecture. van der Steeg et al. [10] proposed a NetFlow-based Firewall mechanism to blacklist potentially abnormal source traffic. In terms of threat response, traffic blocking is not a definitive solution when treating attack involving legitimate network function like DNS since attackers generally hide behind open resolvers instead of distributing the attack themselves. These servers still serve for normal DNS operation where there are scenarios that a targeted network and the servers having common DNS sessions. So this is considered as intrusive if traffic from the servers are plainly blocked; preventing normal DNS operation. In lieu to that, the threat response may be replaced by another option granted thru BGP and GRE protocols, as proposed by Velmayil and Pannirselvam [11]. Patently, the solution works by statistically collecting NetFlow records and using BGP protocol to divert the suspicious traffic to a scrubbing center where filtering process is initiated. The valid traffic is then returned to the intended target using GRE protocol to avoid routing loops. Apart from long detection time, the concern with this solution is that it implicates additional traffic latency (impact performance) and complex routing hack (error-prone). Therefore, a holistic-cumautomated defense module is derived from sFlow with securitycentric SDN.

3. PROPOSED DETECTION/MITIGATION The flowchart in Figure 4 and pseudocode of Algorithm I show that the proposed solution starts by collecting flow data from the forwarding device and check the predefined flow values in the packet header to see if the traffic originated from DNS servers. sFlow enables aggregated flows to be exported instantly via immediate cache. If the source port number belongs to other than 53, the flow is stored in the normal cache, else, it is stored in the immediate cache. Next, filtered DNS traffic is further scrutinized by looking into DNS application data. sFlow permits users to optimally add extended flow values (i.e. DNS attributes) that fulfill the detection criterion. If there is a matching request Query ID in the flow records, the traffic is classified as a normal DNS response, else, it is marked suspicious, since there is no request involved in the first place. Marked flows are then forwarded to the SDN controller for mitigation purpose. Another applicable rule action for DDoS mitigation is to rate-limit the response received at a targeted network [7]. The approach appears to be rational on client-side as it reduces the amplification effect while preserving normal DNS operation. OpenFlow v1.3 brings support for traffic shaping; allowing SDN controller to alter the frequency of packets in each flow entry (flow-table) based on the specified deceleration parameter (meter-table) (see Figure 5). A series of testbed experiments are conducted to validate the hypothesis.

Begin

Collect Flow Data

NO

Normal Cache

YES UDP Src. Port 53?

Immediate Cache

Request Query ID Exist?

Check Query ID

YES

NO

Figure 5. Overall detection/mitigation module process.

Mark Suspicious

Add Rate Limit Rule

End

Figure 4. Flowchart of proposed solution. Algorithm I Proposed Solution of DNS Amplification Attack 1: function GetDNSResponse 2: Fresponses = {IPsrc, IPdest, Psrc, Pdest, Prot, Bytes} 3: FDNS = {QID} 4: export Fresponses by Psrc to Fexported 5: for each Fresponse in Fexported do

Figure 6. Proof-of-concept topology.

10: end if

Prior to generating the results, a number of benchmark data are selected for the experimental procedure. The dataset [12] includes real network traces (pcap) consisting both benign and malicious DNS traffic, courtesy of University of Twente, Netherlands. In order to mimic attack scenarios, the traces (located in VM’s root directory) are rewritten and replayed to exporter from the attacking host via tcprewrite/tcpreplay. The results are divided into two parts; synthetic (preliminary) and authentic, in which the former serves as the basis to derive the latter.

11: end for

5. RESULTS

12: end function

This section evaluates the efficiency and effectiveness of using DNS Query ID to detect DNS amplification attack on synthetic dataset.

6: Fext. = Fresponse.FDNS = {IPsrc, IPdest, Psrc, Pdest, Prot, Bytes, QID} 7: if QID > 1 or QID = 0 then 8: return “Fresponse.IPsrc suspicious” 9: go to rate limit

4. TESTBED Figure 6 shows the initial setup of the testbed, where all research instruments are mainly set on a single machine. The machine runs a 64-bit Windows 7 with Intel Core i5-3337U CPU @ 1.80GHz and 8GB RAM. The topology consists of one controller, single switch, and two hosts (attacker/victim). To produce the presented topology, a hypervisor (VirtualBox) is installed along with a virtual machine (VM) appliance (SDN Hub Tutorial VM). The VM runs a 64-bit Ubuntu 14.04 LTS with Intel Core i5-3337U CPU @ 1.80GHz and 2GB RAM. The VM is preloaded with SDN emulator (Mininet), virtual switch/exporter (OvS; where the mitigation logic resides and enabled), and flow analyzer/collector (sFlow-RT; where the detection logic resides and enabled).

The overall preliminary results of this method can be referred in Figure 7, 8, and 9, tested with 1Gbps of network speed, where the size (bytes) of each DNS query is approximately ±4096 for ANY, ±2900 bytes for A, and ±512 for TXT. The obtained results are observed and analyzed by taking into account the network speed, total test runs, average attack and detection duration, as well as the period between attack and detection, induced from the dataset. From Figure 7, 8, and 9, it is observed that the average detection time increases as the total volume sent rises, due to the average duration it takes for an attack to complete its cycle. It is also observed that there is an increment in the average detection time for the 50% attack ratio compared to 10% and 100%.

100 0

5000

10000 15000 20000 25000

DETECTION TIME (EPOCH) ANY

A

TOTAL VOLUME SENT (MBPS)

500 100 80000 85000 90000 95000 100000 105000

DETECTION TIME (EPOCH) ANY

500 100 20000

30000

40000

DETECTION TIME (EPOCH) A

TXT

1000 500 100 90000

95000

100000

105000

110000

DETECTION TIME (EPOCH) ANY

ANY

A

Figure 10. 10% Attack ratio over 1Gbps link via Huistra’s.

1000

10000

1000

TXT

Figure 7. 10% Attack ratio over 1Gbps link.

0

TOTAL VOLUME SENT (MBPS)

500

TOTAL VOLUME SENT (MBPS)

TOTAL VOLUME SENT (MBPS)

1000

A

TXT

TXT Figure 11. 50% Attack ratio over 1Gbps link via Huistra’s.

1000 500 100 0

5000

10000 15000 20000 25000

DETECTION TIME (EPOCH) ANY

A

TXT

Figure 9. 100% Attack ratio over 1Gbps link. This is considered nonstandard, albeit acceptable, since the average detection time pattern is projected to be decreasing as the attack ratio increases. Based on the experiments, the interval value increases as the number of resolvers rises. This means that the more resolvers involved in an attack, the quicker the malicious traffic is detected due to the increasing levels of distinctiveness in DNS Query ID. Figure 7, 8, and 9 show that there is a slight decrement in the average detection time, when measured in epoch, as the response size for each type of query increases. This conforms the principal of DNS amplification attack, where bigger response size leads to the rapid saturation of network link, hence speeds up both average attack and detection duration. The max. average detection time recorded, counting in the discrepancies with 50% attack ratio, is approximately within 50 seconds; fulfilling the requirement of the proposed solution to work below 1 minute of data. Relatively, both Huistra [5] and Rossow [6] are among the current and closely related researches in terms of identifying reflected DDoS attack via flow-based analysis.

TOTAL VOLUME SENT (MBPS)

TOTAL VOLUME SENT (MBPS)

Figure 8. 50% Attack ratio over 1Gbps link. 1000 500 100 95000

100000

105000

110000

115000

DETECTION TIME (EPOCH) ANY

A

TXT

Figure 12. 100% Attack ratio over 1Gbps link via Huistra’s. For comparative study purpose, their methods are replicated in the research framework as well.

5.1 Comparison with Huistra This section evaluates the comparison between proposed solution and existing solution done by Huistra [5] on synthetic dataset. Accordingly, any defined threshold in this detection logic is multiplied 100x when tested upon non-sampled dataset as the dataset from this network is sampled at a rate of 1:100 for brevity. The overall preliminary results of this method can be referred in Figure 10, 11, and 12. Based on the experiments, the average detection time decreases as the attack ratio increases. Unlike the proposed solution, this method parallels the projected pattern, where the more attacking traffic are being distributed, the sooner they are being detected. This is due to the fact that the method is based upon statistical analysis (total packets and average bytes) instead of pattern matching (DNS Query ID). However, it is also observed that this method works better if the number of open resolvers involved are comparatively higher.

RUN 25

RUN 23

RUN 21

RUN 19

RUN 17

RUN 15

RUN 13

RUN 11

RUN 9

RUN 7

DETECTION TIME (EPOCH)

RUN 5

380000 385000 390000 395000 400000 405000

RUN 3

100

21500 21000 20500 20000 19500 RUN 1

500

DETECTION TIME (EPOCH)

TOTAL VOLUME SENT (MBPS)

1000

TOTAL TEST RUNS TXT

ANY

A

RUN 25

RUN 23

RUN 21

RUN 19

DETECTION TIME (EPOCH)

RUN 17

410000

RUN 15

405000

RUN 13

400000

20500 RUN 11

395000

21000 RUN 9

100

21500

RUN 7

500

22000

RUN 5

1000

390000

Figure 16. 10% attack ratio over 1Gbps link via traces 2.

DETECTION TIME (EPOCH)

TOTAL VOLUME SENT (MBPS)

Figure 13. 10% Attack ratio over 1Gbps link via Rossow’s.

RUN 3

A

RUN 1

ANY

TOTAL TEST RUNS

TXT Figure 17. 10% attack ratio over 1Gbps link via traces 3.

TOTAL VOLUME SENT (MBPS)

Figure 14. 50% Attack ratio over 1Gbps link via Rossow’s.

1000 500 100 395000

400000

405000

410000

415000

DETECTION TIME (EPOCH) ANY

A

TXT

Figure 15. 100% Attack ratio over 1Gbps link via Rossow’s. Based on the generated data, the method is only able to detect an attack after its cycle is completed (network link saturated) if the number of open resolvers are relatively lower (±4 and below). Then again, the potential damage is expected to be trivial in some real case scenarios since it would lessen the amplification effect to have smaller amounts of open resolver and defeat the sole purpose of the attack. Conversely, the max. average detection time recorded is approximately within 300 seconds (over 100Mbps link); 6 times more than the proposed solution.

5.2 Comparison with Rossow This section evaluates the comparison between proposed solution and existing solution done by Rossow [6] on synthetic dataset. The overall preliminary results of this method can be referred in Figure 13, 14, and 15.

Though the hypothetical concept is practically similar to the proposed solution, in which a targeted network shall receive huge sums of traffic from DNS servers without any request involved, this method is still based upon statistical analysis instead of pattern matching. This means that the detection is susceptible to delays in the same way as Huistra [5], where the attack would not be detected until it exceeds the threshold value. Moreover, it also reflects that the overall pattern of the method is technically equivalent to Huistra [5]; when the attacking traffic increases, the detection time decreases. Nonetheless, based on the generated data, there is a minor difference in terms of the number of open resolvers required for this method to operate adequately (±12 and above). The max. average detection time recorded is approximately within 600 seconds (over 100Mbps link); 12 times more than the proposed solution.

5.3 Authentic Evaluation The overall results of proposed solution can be referred in Figure 16 and 17. The obtained results are observed and analyzed by taking into account the average attack/detection duration, period between attack, and detection time induced from the dataset. Number of DNS servers are based on the attack traces [12]. It should be noted that the evaluation is exclusively performed on Traces 2 and Traces 3 over 1Gbps network speed with 10% attack ratio to represent flash crowd scenario. This is also due to resource limitations and constraints as the traces are built up to the max. size of 7588 attack sources. The main difference between these two datasets (i.e. Traces 2 and Traces 3) is distinguishable by the number of open resolvers involved. Traces 2 and 3 consist of 78 and 54 attack sources respectively. The MAC address in both pcap files are adjusted to that of the targeted MAC address (i.e. H1). Based on the experiments, it is observed that the average detection time is lesser with Traces 2 (i.e. ±20 seconds) than with

Traces 3 (±21 seconds). This is due to the fact that the traces contain not only ANY, A, and TXT records, but other types of DNS queries too (i.e. MX, NS, A, and AAAA). Therefore, apart from the number of attack sources, the assortments of DNS query type increase the distinctiveness of DNS Query ID as well, hence speeds up the pattern matching process (average detection time) among the traces. This corroborates that the detection logic behaves sensibly with real data, and does not entail huge DNS response for distinguishing amplified traffic from legitimate flows as it is based upon pattern matching instead of statistical analysis. The max. average detection time recorded is approximately within 16.9 seconds; fulfilling the requirement of proposed solution to work below 1 minute of data.

5.4 Classification Measurement The detection results are classified into two groups; (T)rue/(F)alse (P)ositive and (N)egative. TP refers to correctly classified abnormal DNS traffic, and TN refers to correctly classified normal DNS traffic. Correspondingly, FP refers to benign DNS traffic that is wrongly classified as malicious DNS traffic, and FN refers to malicious DNS traffic that is wrongly classified as benign DNS traffic. Relatively, FPRate, FNRate, accuracy, precision, and recall are computed for the classification measurement. FPR and FNR states the proportion of misclassified benign and malicious DNS traffic respectively. Accuracy states the overall percentage of maliciously classified DNS traffic. Precision states the degree in which the maliciously classified DNS traffic are indeed DNS amplification attack. Recall states the percentage of DNS amplification attack that the detection logic managed to classify correctly. It should be noted that the evaluation is manually performed on Traces 3 over 1Gbps network speed with varying attack ratio, since the traces have as well been reputedly exerted by Huistra [5] in validating his detection logic. Manual inspection is done by importing Traces 3 via Wireshark and perusing the source IP addresses in the pcap files while comparing them with the detected ones in the web browser (sFlow). In comparison, the approach by Huistra [5] resulted in 93% accuracy (given a ratio of 100% attack traffic) over approximately 5 minutes of average detection time. Table 1 shows the performance of proposed solution. Record ID A1, A2, and A3 in Table 1 show that the overall percentage of maliciously classified DNS traffic rises as the attack ratio increases (i.e. 10% ratio with 96.4% accuracy, 50% ratio with 97.7% accuracy, and 100% ratio with 98.0% accuracy). Even when the ratio of benign traffic is larger than with malicious traffic, the detection logic maintains a high accuracy level (i.e. 90% ratio of normal traffic with more than 93% accuracy, as noted from record ID A1). The proportion of both FPR and FNR are also reduced with the increase of attacking traffic (i.e. FPR of 1.5% and FNR of 1.0% with 100% ratio, as noted from record ID A3). This correspondingly demonstrates that the approach can detect DNS amplification attack with a high level of precision and recall in less than 1 minute. The false negatives are primarily derived from two aspects. First is due to the increasing rates of normal traffic; causing the pattern dissimilarity to become smaller for a detection. Second is due to the inadvertently matching Query ID between malicious DNS response and existing DNS request. This however is expected to be trivial since the attack sources are still being detected and marked as the following or remaining suspicious DNS responses from that particular attacking source IP addresses appears to be unrequested (unmatched Query ID).

Table 1. Classification result of traces 3 ID A1 A2 A3

Ratio 10% 50% 100%

Accuracy 96.4% 97.7% 98.0%

FPR 3.5% 2.2% 1.5%

FNR 2.6% 2.0% 1.0%

Precision 96.8% 97.2% 98.3%

Recall 97.0% 98.0% 98.5%

Table 2. Attack-response time ID B1 B2

Traces Traces 2 Traces 3

Average Latency 34.32 seconds 25.44 seconds

Standard Deviation ±2.39305 seconds ±2.64701 seconds

5.5 Performance Overhead The performance overhead is evaluated by looking into transmission delays of experimental environment. Transmission delays are divided into 4 parts; delay between collector (sFlowRT) and exporter (OvS), delay between controller (Kinetic) and exporter, delay between API (Rate-Limit application) and collector, delay between API and controller. In the context of this research, transmission delays are providentially represented as delay between controller and exporter. The reduction of performance overhead is contributed by the combination of collector, controller, and API into a single machine. In this evaluation, a secondary experiment is conducted where the performance is measured according to attack-response latency; the time it takes for an attack to be mitigated. The experiments are performed on Traces 2 and 3 over 1Gbps network speed with 10% attack ratio for brevity. Based on the experiments, the mitigation logic is actuated to rate-limit the traffic at around 34.5 seconds for Traces 2, and around 24 seconds for Traces 3, due to the overhead of flow entries forwarding (flow-table) and transmission (metertable) between exporter and controller. Table 2 shows the results of the experiments with two types of measurements, average latency and standard deviation. The former measurement is the average attack-response latency for 25 runs of each experiment. The latter measurement is the standard deviation resulted from 25 runs of each experiment. Based on the results, Traces 2 introduces a latency of approximately 8.88 seconds compared to Traces 3. This is because there are more attack sources involved in Traces 2 (78 distinct IP addresses) compared to Traces 3 (54 distinct IP addresses). It should be noted that this overhead eventually comes at the cost of decreased detection time. The aggregated rate of detection time for Traces 2 and its mitigation time is approximately within 49.5 seconds, while the aggregated rate of detection time for Traces 3 and its mitigation time is approximately within 41 seconds; fulfilling the requirement of proposed solution to work below 1 minute of data.

6. SUMMARY Findings from this research showed that even with a lightweight attribute, the module managed to produce high classification results in a near real-time environment while minimizing cache overload. Moreover, the module managed to decelerate amplified flows in an automated manner without intruding normal DNS operation as well. The utilization of sFlow with security-centric SDN eventually aid the instant exportation of anomalous DNS responses and consequently control the forwarding of admissible DNS replies. Despite meeting the objectives, there are dormant areas that could foster further research and future work. Detection-wise, multi-types of metadata extracted from sFlow’s extended flow values should be equally constructive to analyze amplification attacks involving other protocols as well (e.g. NTP).

Mitigation-wise, Service Function Chaining enables overriding of default routing where suspiciously marked packets could be steered by OpenFlow towards corresponding middleboxes (e.g. Snort) for added analysis in order to deliver better results.

7. ACKNOWLEDGMENTS Our thanks to Malaysian Institute of Information Technology, University of Kuala Lumpur for the Short-Term Research Grant to support this work.

8. REFERENCES [1] Anagnostopoulos, M., G. Kambourakis, P. Kopanos, G. Louloudakis and S. Gritzalis. 2013. DNS Amplification Attack Revisited. Computer Security, 39 (0167-4048): 475485. DOI:10.1016/j.cose.2013.10.001. [2] Cisco, 2015. Cisco 2015 Annual Security Report.Cisco Public Information, California, USA.http://www.cisco.com/web/offers/lp/2015-annualsecurity-report/index.html (Accessed on March 17, 2016) [3] Li, B., J. Springer, G. Bebis and M.H. Gunes. 2013. A survey of network flow applications. Computer Applications, 36 (567-581): 1084-8045. DOI:10.1016/j.jnca.2012.12.020. [4] Afaq, M., S. Rehman, and W. C. Song. 2015. Large Flows Detection, Marking, and Mitigation based on sFlow Standard in SDN. Journal of Korea Multimedia Society, 18 (2): 189198. DOI:10.9717/kmms.2015.18.2.189. [5] D. Huistra, "Detecting Reflection Attacks in DNS Flows," in 19th Twente Student Conference on IT, Enschede, Netherlands, 2013. [6] Rossow, C., 2014. Amplification Hell: Revisiting Network Protocols for DDoS Abuse. Proceedings of the 2014 Network and Distributed System Security, Feb. 23-26, Internet Society, USA, pp: 1-15. DOI: 10.14722/ndss.2014.23233.

[7] Bhuyan, M. H., H. J. Kashyap, D. K. Bhattacharyya and J. K. Kalita. 2014. Detecting Distributed Denial of Service Attacks: Methods, Tools and Future Directions. The Computer Journal, 57 (4): 537-556. DOI:10.1093/comjnl/bxt031. [8] Hofstede, R., P. Celeda, B. Trammell, I. Drago, R. Sadre, A. Sperotto and A. Pras. 2014. Flow Monitoring Explained: From Packet Capture to Data Analysis With NetFlow and IPFIX. Communications Surveys & Tutorials, 16 (20372064): 1553-877X. DOI:10.1109/COMST.2014.2321898. [9] Ye, X. and Y. Ye. 2013. A Practical Mechanism to Counteract DNS Amplification DDoS Attacks. Computational Information Systems, 9 (265–272): 1553– 9105. URL:http://www.jofcis.com/publishedpapers/2013_9_1_265 _272.pdf. [10] van der Steeg, D., R. Hofstede, A. Sperotto and A. Pras. 2015. Real-time DDoS attack detection for Cisco IOS using NetFlow. IFIP/IEEE International Symposium: 972-977. DOI:10.1109/INM.2015.7140420. [11] Velmayil G. and S. Pannirselvam. 2013. Defending of IP Spoofing by Ingress Filter in Extended-Inter Domain Packet Key Marking System. International Journal of Computer Network and Information Security, 5 (5): 47–54. DOI:10.5815/ijcnis.2013.05.06. [12] Santanna, J.J., R. van Rijswijk-Deij, A. Sperotto, R. Hofstede and M. Wierbosch, 2015. Booters - An analysis of DDoS-asa-Service Attacks. Proceedings of 14th IFIP/IEEE Symposium on Integrated Network and Service Management, May 11-15, IEEE Xplore Press, Canada. URL: http://im2015.ieee-im.org/content/technical-sessions-0.