FEA-403 final

DNS Amplification d R fl tand Reflector Attacks Duane Wessels DNS-OARC 04/24/09 | Session ID: FEA-403| Session Classification: Advanced Agenda Evolution of DNS Attacks Most Recent AttacksMost Recent Attacks BCP38 R fl ti d A lifi tiBCP38, Reflection, and Amplification What Can Be Done? 2 EvolutionEvolution of DNS A kAttacks Roots Attacked October 2002 • 13 Root nameservers are attacked simulatenously P k t i t f ICMP TCP d UDP ith• Packets are a mixture of ICMP, TCP, and UDP with random sources Ab t 1h 15 d ti• About 1h 15m duration • 50—100 Mbit/s per root • Congested WAN links made some roots unreachable • See http://d root-servers net/october21 txtSee http://d.root servers.net/october21.txt 4 2002 Attack “Parts List” • Botnet (most likely) Abili f ( b b il )• Ability to spoof (maybe, but not necessarily) TLD February 2006 • $TLD nameservers attacked. A k ffi i DNS i i l• Attack traffic is DNS responses containing a large (4K) TXT resource record. • 1—2.5 Gbit/s. • Responses come from open resolvers. • Attacker sends DNS queries to open resolvers with query source address set to $TLD nameserver addresses. 2006 Attack Flow QueriesQueries (spoofed source) Bot Cache miss Open Resolver Responses Victim p 2006 Attack “Parts List” • Botnet Abili f• Ability to spoof • Open Resolvers Roots Attacked February 2007 • 6 of 13 Root server addresses attacked F 2 h h f h• For 2.5 hours, then for 5 hours. • Two Root nameservers significantly affected – Anycast would have helped • Attack traffic is garbage or malformed DNS g g packet sent to port 53. • Seems sources were localized. – Highly anycasted roots saw traffic at only a few instances • About 600 Mbit/s to F-rootAbout 600 Mbit/s to F root 2007 Attack “Parts List” • Botnet? MostMost Recent A kAttacks ISPrime January 2009 • ISPrime and other hosting companies attacked Vi i i DNS “ NS”• Victim receives DNS response to “. NS” query. • 5 Gbit/s, 750,000 sources. • Responses come from authoritiative nameservers. • Attack lasts for weeks, with victim addresses changing from day to day. 2009 Attack Transaction QueriesQueries (spoofed source) Bot Auth Server Responses Victim p 2009 Attack Logged Queries 31-Jan-2009 15:37:28.480 client 76.9.16.171#36929: query: . IN NS + 31-Jan-2009 15:38:31.113 client 76.9.16.171#2296: query: . IN NS + 31-Jan-2009 15:39:33.746 client 76.9.16.171#59758: query: . IN NS + 31-Jan-2009 15:40:36.379 client 76.9.16.171#49411: query: . IN NS + 31-Jan-2009 15:41:39 013 client 76 9 16 171#13003: query: IN NS +31 Jan 2009 15:41:39.013 client 76.9.16.171#13003: query: . IN NS + 31-Jan-2009 15:42:41.646 client 76.9.16.171#50587: query: . IN NS + 31-Jan-2009 15:43:44.301 client 76.9.16.171#48587: query: . IN NS + 31-Jan-2009 15:44:46.913 client 76.9.16.171#60323: query: . IN NS + 31 J 2009 15 45 49 553 li t 76 9 16 171#5359 IN NS31-Jan-2009 15:45:49.553 client 76.9.16.171#5359: query: . IN NS + 31-Jan-2009 15:46:52.180 client 76.9.16.171#40270: query: . IN NS + 31-Jan-2009 15:47:54.813 client 76.9.16.171#6331: query: . IN NS + 31-Jan-2009 15:48:57.455 client 76.9.16.171#59557: query: . IN NS +q y One Possible Response: Referral ; <<>> DiG 9.3.4-P1 <<>> @10.0.0.26 . ns ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41348 fl d QUERY 1 ANSWER 0 AUTHORITY 13 ADDITIONAL 0;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN NS ;; AUTHORITY SECTION: . 3600000 IN NS M.ROOT-SERVERS.NET.. 3600000 IN NS M.ROOT SERVERS.NET. . 3600000 IN NS A.ROOT-SERVERS.NET. . 3600000 IN NS B.ROOT-SERVERS.NET. . 3600000 IN NS C.ROOT-SERVERS.NET. . 3600000 IN NS D.ROOT-SERVERS.NET. . 3600000 IN NS E.ROOT-SERVERS.NET. . 3600000 IN NS F.ROOT-SERVERS.NET. . 3600000 IN NS G.ROOT-SERVERS.NET. . 3600000 IN NS H.ROOT-SERVERS.NET. . 3600000 IN NS I.ROOT-SERVERS.NET. . 3600000 IN NS J.ROOT-SERVERS.NET. . 3600000 IN NS K.ROOT-SERVERS.NET. . 3600000 IN NS L.ROOT-SERVERS.NET. ;; Query time: 4 msec ;; SERVER: 10.0.0.26#53(10.0.0.26) ;; WHEN: Thu Jan 22 10:23:59 2009 ;; MSG SIZE rcvd: 228 Another Possible Response: Refused ; <<>> DiG 9.3.4-P1 <<>> @10.0.0.26 . ns ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 10214 ;; flags: qr rd; QUERY: 1 ANSWER: 0 AUTHORITY: 0 ADDITIONAL: 0;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN NS ;; Query time: 92 msec ;; SERVER: 10.0.0.26#53(10.0.0.26) ;; WHEN: Thu Jan 22 10:24:16 2009;; ;; MSG SIZE rcvd: 17 Notable Characteristics • Traffic rate at the authoritiative nameserver is low. Too low to raise alarms– Too low to raise alarms – Too low to find with netflow? • Authoritiative nameservers can't impose address• Authoritiative nameservers can t impose address- based ACLs. A Referral response nets significant amplification• A Referral response nets significant amplification. BCP38,BCP38, Reflection, A lifi iAmplification BCP38 – Ingress Filtering • Also known as RFC 2827 from May 2000 And RFC 3704 March 2004– And RFC 3704, March 2004 • Simplified: a network should only emit packets where the source address is a valid destination inwhere the source address is a valid destination in the other direction. • See also Unicast Reverse Path Forwarding• See also Unicast Reverse Path Forwarding • Implementable in router products from Cisco, Juniper as well as Linux & BSD systemsJuniper as well as Linux & BSD systems. • Easier at the network edge, harder in the core. BCP38 Continued • According to http://spoofer.csail.mit.edu/, about 20% of address space and 25% of autonomous20% of address space and 25% of autonomous systems allow source address spoofing. • If BCP38 were universal would it shut down theseIf BCP38 were universal would it shut down these types of DNS attacks? Reflection • Both 2006 and 2009-era attacks use reflection. Wh ?• Why? • Perhaps to further obfuscate the bot/source? • Perhaps to assist in the amplification effect? • Fewer bots than reflection points?• Fewer bots than reflection points? • Open Resolvers can (and should) be ACLed, but no so much for authoritative nameserversno so much for authoritative nameservers. Amplification • In 2006 the amplification factor was very big: between 15—20.between 15 20. • In 2009 an upward referral response results in an amplification factor of about 5amplification factor of about 5. – A refused response is about the same size as the query, resulting in no effective amplification. • DNS messages larger than MTU size (~1500) also result in fragmentation, which causes problems for filteringproblems for filtering. What CanWhat Can Be Done? BCP38 • Ensure that ingress filtering is implemented on your network.your network. • http://spoofer.csail.mit.edu/software.php has downloadable toolsdownloadable tools. Open Resolvers • Open Resolvers still represent a threat M k l l l i• Make sure your local resolver accepts queries from internal or allowed sources only. • Query for open resolvers on your network at http://dns.measurement-factory.com/surveys/openresolvers.html Di l i th t l– Disclaimer: thats me also. Authoritative Nameservers • Make sure your authoritative nameservers don't return an upward referral.return an upward referral. • For BIND, add this option to the configuration: i i • Test with dig @ns.example.net . NS additional-from-cache no; • If your nameserver is both caching and authoritative, separate those functions into different instances. Questions? wessels@dns oarc netwessels@dns-oarc.net https://www.dns-oarc.net