Combating DNS amplification attacks using Cookies

Supervisor:Roland van RijswijkSURFnet

By:Sean Rijs

Agenda

● I am going to do my presentation

DNS amplification attacks

Target

Stub resolverAttacker

Recursive server (Open Resolver)

1

3

Authoritative server

2

1)query ANY delaat.net

2)query ANY delaat.net

response 1.1.1.1.... (and cache)

3)Response 1.1.1.1….

Table by Rijswijk-Deij et al. [DNSSEC and its potential for DDoS attacks]

EDNS0

DNS Cookies IETF Internet Draft

● By Donald Eastlake 2006-2014– Authentication of source IP

– Off-path

● No pre-configuration required

● Research question:– Is the draft effective against DNS amp. attacks?

Client/Resolver Server

Stub resolver Recursive server Authoritative server

Client/Resolver Server

Terminology confusing?

Cookies OPT RR

(EDNS0)

– May occur once

– Max. 22 bytes

hash(Resolver Secret | Server IP Address)

hash(Server Secret | Query IP Address | Resolver Cookie)

– Proposed hash = FNV-64

C(Resolver Cookie + CKPING)

C(Resolver Cookie + Server Cookie + CKPINGR)

Resolver Server

C(Resolver Cookie + Server Cookie)Q(delaat.net. IN A )

C(Resolver Cookie + Server Cookie)R(delaat.net. 600 IN A 212.84.157.4)

C(Resolver Cookie + Server Cookie)Q(delaat.net. IN AAAA)

C(Resolver Cookie + Server Cookie)R(delaat.net. 600 IN AAAA 2001:9e0:....)

● Costs?– Initially 2x RTT

– Hashing

– Caching

What if?

Target

Stub resolverAttacker

Recursive server (Open Resolver)

1

3

Authoritative server

2

just contains small error messages, no big amplification

3

Policy

● Disabled: do nothing with cookies● Enabled: opportunistic (recommends RRL on

server side)– Not a solution for recursive servers

● Enforced: Ignore everything without Cookies– Not gonna happen (in the near future)

● Policy is important, as it determines the incremental implementation

Source Identity Token (SIT)

● BIND 9.10-P1 (two months ago)

2x RTT has disappeared?

Differences SIT / Internet Draft

● Similar except:– Hashing: FNV-64, AES-MAC, SHA1, SHA256– RRL: whitelists valid clients– Policy: no one is going to use it

Analysis of impact

● Stub resolvers are stateless● A lot of end devices: bound by release cycles● Recursive server and authoritative are stateful● Already use RRL

Stub resolver Recursive server Authoritative server

Measurements

● What do want to find out?– Do we need EDNS0 for normal use?

– Do we need large response sizes for normal use?

● How?– PCAPs and EEMO

Measurement sources

● Stub resolver: www.nu.nl (with its adds) using:– Windows - Internet Explorer

– OS X - Safari

– Ubuntu Linux – Firefox

● Stub resolver: Alexa top 10 using:– Ubuntu Linux - Firefox

● Recursive server: SURFnet– 1500 – 2000 queries per second

– 10m during a workday on noon

Stub resolver Recursive server Authoritative server

Stub resolver

● No EDNS0 found● No large response responses:

– Size <= 512 bytes

– truncated/TCP communication = 0

Recursive server

● 22% EDNS0● Average size

– 133 B

● 99% <= 240 B

Conclusion/Discussion

● Based on our results, we suggest unauthenticated stub resolvers should be limited to a max. response size of 240 bytes

● Amplification reduced further: – 240 bytes = 6 amplification factor

– 100M = 600 Mbit/s

Table by Rijswijk-Deij et al. [DNSSEC and its potential for DDoS attacks]

Conclusion

● RRL should not be used– Especially on recursive server

– But authoritative can also be effected

● Policy for incremental implementation must be changed

● Terminology: – stub/recursive/authoritative

– The cookie is actually a Message Authentication Code (MAC) and not just a hash

Discussion

● Do we need to authenticate the server?● Yes, it provides off-path defense against:

– Last mile problem in DNSSEC

– Cache poisoning (by Kaminsky)

Future research

● Need more measurements – to confirm suggested DNS maximum response size

● FNV-64– The non-standard and untested hashing algorithm,

which could provide performance gain. Is a performance gain required?

Questions