Reproducing DNS 10Gbps flooding attacks with commodity-hardware

International audienceBeing DNS an essential service for Internet reliability, it is an attractive target for malicious users. The constantly increasing Internet traffic rate challenges DNS services and their attack detection methods to handle actual queries while being flooded by tens of millions of malicious requests per second. Moreover, state of the art on hostile actions evolve fast. DNS administrators continuously face new kinds of attacks and they regularly need to evaluate their detection systems. We have studied different approaches to develop a tool able to reproduce state-of-the-art attacks, aiming to make it easy to evaluate countermeasure strategies. We have focused on commodity-hardware, DPDK and MoonGen to build a flexible flood query generator. The described tool can saturate a 10Gbps link, sending more than 12 million attack-like random DNS requests per second

MoonGen: A Scriptable High-Speed Packet Generator

We present MoonGen, a flexible high-speed packet generator. It can saturate 10 GbE links with minimum sized packets using only a single CPU core by running on top of the packet processing framework DPDK. Linear multi-core scaling allows for even higher rates: We have tested MoonGen with up to 178.5 Mpps at 120 Gbit/s. We move the whole packet generation logic into user-controlled Lua scripts to achieve the highest possible flexibility. In addition, we utilize hardware features of Intel NICs that have not been used for packet generators previously. A key feature is the measurement of latency with sub-microsecond precision and accuracy by using hardware timestamping capabilities of modern commodity NICs. We address timing issues with software-based packet generators and apply methods to mitigate them with both hardware support on commodity NICs and with a novel method to control the inter-packet gap in software. Features that were previously only possible with hardware-based solutions are now provided by MoonGen on commodity hardware. MoonGen is available as free software under the MIT license at https://github.com/emmericp/MoonGenComment: Published at IMC 201

Flexible high performance traffic generation on commodity multi-core platforms

Generating high-volume and accurate test traffic is crucial for assessing the performance of network devices in a reliable way and under different stress conditions. However, traffic generation still relies mostly on special purpose hardware. In fact, available software generators are able to reproduce rich and involved traffic patterns, but do not meet the performance requirements that are needed for effectively challenging the device under test. Nevertheless, hardware devices usually provide limited flexibility with respect to the traffic patterns that they can generate. The aim of this work is to design a traffic generator which can both achieve good performance and provide a flexible framework for supporting arbitrary traffic models. The key factor that enables our system to meet both requirements is parallelism, which is increasingly provided by modern commodity hardware: indeed our generator, which includes both kernel and user space components, can efficiently scale with multiple cores and multi-queue commodity network cards. By leveraging such a design, our generator is able to produce close-to-line-rate traffic on a 10Gbps link, while accommodating multiple traffic models and providing good accuracy

Performance Metrics for Network Intrusion Systems

Intrusion systems have been the subject of considerable research during the past 33 years, since the original work of Anderson. Much has been published attempting to improve their performance using advanced data processing techniques including neural nets, statistical pattern recognition and genetic algorithms. Whilst some significant improvements have been achieved they are often the result of assumptions that are difficult to justify and comparing performance between different research groups is difficult. The thesis develops a new approach to defining performance focussed on comparing intrusion systems and technologies. A new taxonomy is proposed in which the type of output and the data scale over which an intrusion system operates is used for classification. The inconsistencies and inadequacies of existing definitions of detection are examined and five new intrusion levels are proposed from analogy with other detection-based technologies. These levels are known as detection, recognition, identification, confirmation and prosecution, each representing an increase in the information output from, and functionality of, the intrusion system. These levels are contrasted over four physical data scales, from application/host through to enterprise networks, introducing and developing the concept of a footprint as a pictorial representation of the scope of an intrusion system. An intrusion is now defined as “an activity that leads to the violation of the security policy of a computer system”. Five different intrusion technologies are illustrated using the footprint with current challenges also shown to stimulate further research. Integrity in the presence of mixed trust data streams at the highest intrusion level is identified as particularly challenging. Two metrics new to intrusion systems are defined to quantify performance and further aid comparison. Sensitivity is introduced to define basic detectability of an attack in terms of a single parameter, rather than the usual four currently in use. Selectivity is used to describe the ability of an intrusion system to discriminate between attack types. These metrics are quantified experimentally for network intrusion using the DARPA 1999 dataset and SNORT. Only nine of the 58 attack types present were detected with sensitivities in excess of 12dB indicating that detection performance of the attack types present in this dataset remains a challenge. The measured selectivity was also poor indicting that only three of the attack types could be confidently distinguished. The highest value of selectivity was 3.52, significantly lower than the theoretical limit of 5.83 for the evaluated system. Options for improving selectivity and sensitivity through additional measurements are examined.Stochastic Systems Lt