Reproducing DNS 10Gbps flooding attacks with

Reproducing DNS 10Gbps flooding attacks with commodity-hardware S. Ruano Rincon

S. Vaton

S.Bortzmeyer

Télécom Bretagne (Brest, France) & AFNIC Labs (Saint Quentin en Yvelines, France)

TRAC 2016, September 7th, 2016

S.Ruano Rincon et al. (TB & AFNIC Labs)

10 Gbps DNS flooding traffic generator

TRAC 2016

1 / 19

Outline

1

Introduction



TRAC 2016

2 / 19

Attacks against the DNS DNS (Domain Name System): association between an IP address (used for routing), and a domain name (easier to remind) Exemple: Name: telecom-bretagne.eu Address: 192.108.117.241 DNS is an essential service for Internet reliability (with other services such as BGP) Read, for ex., the ANSSI Annual Report on the Resilience of the French Internet (with the collaboration of AFNIC) DNS servers: target of frequent and sometimes severe denial-of-service (DoS) attacks Exemple: random qnames attacks targeting a country TLD Out-of-service or slow DNS servers ⇒ partial Internet blackout, and a slow down of all services over the Internet It is then essential to protect DNS servers, and in particular TLD servers, against DoS attacks such as flooding attacks (or reflect-and-amplify attacks). S.Ruano Rincon et al. (TB & AFNIC Labs)


TRAC 2016

3 / 19

DNS flooding attack detection testbed Goal of this study: to be able to monitor DNS servers and detect flooding attacks at tens of Gb/sec with commodity hardware 1 2 3

4

generate "classical" DNS flooding attacks ⇒ traffic generation monitor DNS requests ⇒ traffic capture identify flooding attacks ⇒ traffic analysis (statistical approach rather than signature-based approach) Need: Access to actual attack captures take appropriate countermeasures

Xena traffic generator

Attacking machine

Analysis machine

Target server

10GbE Network



TRAC 2016

4 / 19

DNS flooding attacks Random qname attacks I

I

I

attack against authoritative servers of a specific domain (for example .pt or .fr) principle: huge number of queries for domain names composed of non existing random prefixes and a given fixed domain suffix

because of the hierarchical structure of the DNS service these queries are eventually handled by the authoritative server for the target specific domain (for example, .fr) ⇒ Denial of Service



TRAC 2016

5 / 19

DNS flooding attacks

Random qname attacks I

I

Example: september 4th 2014, random attack against the Wallis-et-Futuma’s .wf domain, "dafa888" ⇒ 14 hours at a maximum rate of 1 million requests per second. RIPE Atlas DNSMON reported 99% of unanswered queries from one AFNIC TLD servers (e.ext.nic.fr) Traffic characteristics in case of a random qname attack F F

F F

fixed DNS server’s IP address (the victim’s) varying queried qname over a fixed domain suffix, for ex. randomqname.www.dafa888.wf varying source IPv4 or IPv6 address varying query type, for example A (IPv4 address), AAAA (IPv6 address), ANY (all records) or TXT (text records)



TRAC 2016

5 / 19

DNS flooding attacks Reflect-and-amplify attack I

I

reflection attack: use the DNS server as a weapon to flood a given target Operating mode: F F

F I

botnet: a large number of zombie machines controlled by a bot herder use zombies to send a large number of DNS requests with a spoofed source IP adress (that of the victim) DNS answers are sent to the victim, which causes a denial of service

amplification: F F

F

F

DNS answers much larger than requests ⇒ amplification example: use misconfigured DNS servers (open resolvers) and ask all their records (request ANY) Top Level Domain DNS servers are also commonly used for reflect+amplify attacks (because they hold a large number of records) DNSSEC signed domains: signature involves even larger DNS answers



TRAC 2016

5 / 19

DNS flooding attacks

Reflect-and-amplify attack I

I

Example: attack against Spamhaus in 2013, 300 Gb/sec of inbound traffic Traffic characteristics in case of a reflect+amplify attack: F F

F F F

fixed spoofed source IP address (that of the victim) public open DNS resolvers or TLD DNS servers (as DNS server’s IP address) commonly, query type ANY fixed or randomized queried qname and additionnally include an EDNS0 OPT-pseudo record advertising a large buffer size (for example, 9000 bytes), and indicate that DNSSEC signed records are supported



TRAC 2016

5 / 19

Countermeasures

Existing counter-measures set a Response Rate Limit (RRL) at DNS server it is possible to drop ANY type queries with Linux’s netfilter Best Current Practices: I I

close open resolvers authenticate DNS clients by signatures (to avoid IP spoofing)



TRAC 2016

6 / 19

Generating traffic at Nx10 Gbps

Commercial hardware based appliances. E.g. XENA traffic generator Programmable hardware such as NetFPGA boards Commodity hardware



TRAC 2016

7 / 19


Commercial hardware based appliances. E.g. XENA traffic generator I I I

Lack of flexibility Expensive Accurate rate control and timestamping

Programmable hardware such as NetFPGA boards Commodity hardware



TRAC 2016

7 / 19


Commercial hardware based appliances. E.g. XENA traffic generator Programmable hardware such as NetFPGA boards I I I I I

Specialized hardware More flexible Less expensive Highly supported by academic institutions Needs hardware description languages programming

Commodity hardware



TRAC 2016

7 / 19


Commercial hardware based appliances. E.g. XENA traffic generator Programmable hardware such as NetFPGA boards Commodity hardware I I

I I

Even less expensive Requires specific software frameworks to handle communication between NICs and processing applications Relies on general-purpose components (CPU, memory, etc.) Less precise/accurate than hardware-based solutions



TRAC 2016

7 / 19


Commercial hardware based appliances. E.g. XENA traffic generator Programmable hardware such as NetFPGA boards Commodity hardware ⇒ in this work, we use commodity hardware to generate DNS related attacks



TRAC 2016

7 / 19

Software network engines for commodity hardware

DPDK (Intel) I

Strong support from industry

HPCAP (Moreno et al., Univ Autónoma de Madrid) I I

Specially designed for capture with no packet losses. Still an academic work that needs a stable release.

PF_RING (Deri et al., Ntop) I

Zero-copy version needs a commercial license.

PFQ (Bonelli et al., Univ. of Pisa) I I

Uses the Intel vanilla driver, relying on multi-core processing. Unable to handle 10Gbps on a single core.



TRAC 2016

8 / 19

General-purpose software-based traffic generators

based on DPDK (Intel) I I I

pktgen-dpdk (by Keith Wiles, Intel) Ostinato (specific accelerated version) MoonGen (Paul Emmerich, Tech. Univ. Munchen)

based on HPCAP (Moreno et al., Univ Autónoma de Madrid) I

Not-known public generator (or lacking documentation)

based on PF_RING (Deri et al., Ntop) I

zsend (that relies on zero-copy to handle high-speed traffic)

based on PFQ (Bonelli et al., Univ. of Pisa) I I

Not-known scriptable or high-level generator. Test tool in source code.



TRAC 2016

9 / 19

DPDK-based traffic generators based on DPDK I

pktgen-dpdk F F

I

Ostinato (specific accelerated version) F F F

I

Still unstable. Poorly documented on how to use Lua scripts Designed to be easily configured via a GUI Originally designed on top of the Linux NAPI Accelerated version unable to saturate a 10GbE link

MoonGen F F F F

Highly configurable via Lua scripts Then: highest abstraction level Easily able to saturate 10GbE links On-development

⇒ we have decided to use MoonGen to script attacks against (or using) DNS



TRAC 2016

10 / 19

Generating DNS flooding attacks Requirements Randomize different bytes/fields I I I I I I I

Source IP addresses Ports TTL qname (of several lengths) Varying DNS query data EDNS, UDP buffer size ...

Easily take into account other attacking strategies => High flexibility No need of highly accurate timestamping/control (as could be provided by hardware)



TRAC 2016

11 / 19

MoonGen Link user-controlled Lua scripts to CPU cores and NIC ports Delegate rate control and timestamping to hardware

Figure: MoonGen Architecture, from IMC 2015 paper S.Ruano Rincon et al. (TB & AFNIC Labs)


TRAC 2016

12 / 19

Using MoonGen to generate DNS-related attacks

Master function to control environment and configure devices: f u n c t i o n master ( . . . ) l o c a l rxMempool = memory . createMemPool ( ) l o c a l txDev = d e v i c e . c o n f i g ( { p o r t=t x P o r t , mempool=rxMempool , r x Q u e u e s =1, t x Q u e u e s =1}) f o r i = 0 , c o r e s − 1 do txDev : getTxQueue ( i ) : s e t R a t e ( r a t e / c o r e s ) dpdk . l a u n c h L u a ( " l o a d S l a v e " , t x P o r t , i ) end



TRAC 2016

13 / 19

Using MoonGen to generate DNS-related attacks Include DNS protocol support Slave functions to generate packets. Format and fill random DNS data function loadSlave ( . . . ) l o c a l mem = memory . createMemPool ( f u n c t i o n ( b u f ) buf : getDnsPacket ( ipv4 ) : f i l l { i p 4 S r c=g e n I P v 4 A d d S o u r c e ( ) , i p 4 D s t=d n s S e r v e r I P , ... d n s M e s s a g e C o n t e n t=genBody ( ) } end )

w h i l e dpdk . r u n n i n g ( ) do l o c a l b u f s = mem : b u f A r r a y (MAX_BURST_SIZE) bufs : a l l o c () ... s e n t = queue : s e n d ( b u f s ) S.Ruano Rincon et al. (TB & AFNIC Labs)


TRAC 2016

14 / 19

Testing environment

Single-processor quad-core Intel i7-2600K 8GB RAM Debian Jessie Two Intel NICs: I I

Dual SFP+ port X520-DA2 Dual RJ45 port X520-TA2.



TRAC 2016

15 / 19

CPU Requirements to saturate a 10 GbE link Comparing: I I I

Shield of Perseus (SOP): DNS-specialised generator Our DNS generator MoonGen’s example/tx-multi-core.lua (simple, non-random packets) 1.4 1e7 1.2

Packets per second

1.0 0.8

SOP Our DNS flooding tool MoonGen's ex. script

0.6 0.4 0.2


00

00


22

CPU Frequency (Mhz)

21

00 20

00 19

00 18

00 17

16

00

0.0

TRAC 2016

16 / 19

Limited by random fields? Using a single core, CPU @1.6Ghz Randomising fields does not strongly impact performance 1.102 1e7 1.100

Packets per second

1.098 1.096 1.094 1.092 1.090 1.088 1.086

1


2

3 4 5 6 7 8 Number of random fields per packet


9

10

TRAC 2016

17 / 19

Results and conclusions

MoonGen suited best our requirements Generating packets controlled by Lua scripts I I

Then: highest possible level of abstraction Highly flexible

Succesfully reproduce random qnames and reflect-and-amplify Able to scale to Nx10Gbps (as claimed by MoonGen authors): Our results: 30Gbps on a quad-core CPU



TRAC 2016

18 / 19

Next steps

Capture and analyse traffic I

What approach scores highest at minimizing packet drops?

Is MoonGen efficient enough? (designed to generate) Detect attacks relating to DNS I

Statistics-based detection

Thank you for your attention!



TRAC 2016

19 / 19