Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pseudo Random DNS Query Attacks and Resolver Mitigation Approaches

1,052 views

Published on

A presentation given at APRICOT 2015 during the DNS session.

Published in: Internet
  • Be the first to comment

Pseudo Random DNS Query Attacks and Resolver Mitigation Approaches

  1. 1. © 2014 ISC Pseudo Random DNS Query Attacks & Resolver Mitigation Approaches APRICOT 2015
  2. 2. © 2014 ISC The attacks §  Began in February 2014 §  Attack intent is to DDoS DNS authoritative provider, but incidentally degrades ISP resolvers
  3. 3. © 2014 ISC The parties involved Target of the DDOS Authoritative provider Initiator of DDoS traffic •  Sometimes this is an extortion attack •  Frequently seems to originate and terminate in China •  Target domain may be hosted with many non- targeted domains •  Targets hop from provider to provider
  4. 4. © 2014 ISC Identifying the attack high volume of queries for non- existent sub-domains <randomstring>.www.example.com
 <anotherstring>.www.example.com
 exists"does not exist"
  5. 5. © 2014 ISC Attack begins Target of the DDOS Authoritative provider ISP resolvers Insecure Home gateways Initiator of DDoS traffic 2. Attempt to resolve 1. Requests for randomstring.www.example.com Home users are unaware example.com nothing about this in the cache
  6. 6. © 2014 ISC Initially, the target responds Target of the DDOS Authoritative provider ISP resolvers Insecure Home gateways Initiator of DDoS traffic 3. Server replies “no such domain” Home users are unaware 4. Reply (NXDOMAIN) example.com
  7. 7. © 2014 ISC More requests flood in Target of the DDOS Authoritative provider ISP resolvers Insecure Home gateways Initiator of DDoS traffic 1. More requests for randomstrings.www.example.com Home users are unaware example.com
  8. 8. © 2014 ISC Target is overwhelmed Target of the DDOS Authoritative provider ISP resolvers Insecure Home gateways Initiator of DDoS traffic 2. Attempt to resolve 3. Server is unresponsive Home users are unaware example.com
  9. 9. © 2014 ISC Resolver is degraded Target of the DDOS Authoritative provider ISP resolvers Insecure Home gateways Initiator of DDoS traffic 3. Server is unresponsive Home users are unaware example.com Waiting for responsesWaiting for responsesWaiting for responses
  10. 10. © 2014 ISC Legitimate queries fail Target of the DDOS Authoritative provider ISP resolvers Insecure Home gateways Initiator of DDoS traffic 1. Request for www.example.com Home users are unaware Waiting for responsesWaiting for responsesWaiting for responses
  11. 11. © 2014 ISC
  12. 12. © 2014 ISC MITIGATION TECHNIQUES What can we do? What has been tried in production?
  13. 13. © 2014 ISC Option 1: “hair on fire”
  14. 14. © 2014 ISC
  15. 15. © 2014 ISC Create a local answer Ø  Make recursive server temporarily authoritative for the target domain §  Problem of false-positives (might need white-lists if using scripted detection) §  Manual configuration change §  Need to undo the mitigation afterwards
  16. 16. © 2014 ISC Create a local answer Target of the DDOS Authoritative provider ISP resolvers Insecure Home gateways Initiator of DDoS traffic 1. Requests for randomstring.www.example.com Home users are unaware Auth for example.com 2. Reply (NXDOMAIN) example.com
  17. 17. © 2014 ISC Option 2: Consider Automated filtering (Near) Real Time Block Lists §  Detect ‘bad’ domain names or just the problematic queries & filter them at ingress to the resolver §  Nominum Vantio §  BIND DNS-RPZ §  There are usually fees associated with feeds
  18. 18. © 2014 ISC Option 3: Consider making your resolvers smarter Monitor responses vs timeouts Throttle back queries Monitor responses vs timeouts Adjust throttle
  19. 19. © 2014 ISC Smarter Resolver Target of the DDOS Authoritative provider ISP resolvers Insecure Home gateways Initiator of DDoS traffic 2. Attempt to resolve, less frequently as needed 1. Requests for randomstring.www.example.com Home users are unaware Detect & adapt 4. Reply (NXDOMAIN or SERVFAIL) example.com 3. Detect when auth server returns to health
  20. 20. © 2014 ISC PERSERVER PERZONE
  21. 21. © 2014 ISC fetches-per-server §  Per-server quota dynamically re-sizes itself based on the ratio of timeouts to successful responses §  Completely non-responsive server eventually scales down to fetches quota of 2% of configured limit. §  Similar in principle to what NLNetLabs is doing in Unbound
  22. 22. © 2014 ISC fetches-per-zone §  Works with unique clients §  Default 0 (no limit enforced) §  Tune larger/smaller depending on normal QPS to avoid impact on popular domains §  In practice, this has been the winner so far for those using BIND
  23. 23. © 2014 ISC Fetches-per-zone at Jazztel Spanish triple-play ADSL carrier & ISP Roberto Rodriguez Navio, Jazztel Networking Engineering used with permission
  24. 24. © 2014 ISC Still experimental §  Some controversy about adaptive approach vs blacklists §  Whitelists may be needed §  Per-server/zone settings – Configurable override parameters for fetch limits on a per zone or per server basis §  SERVFAIL cache (for client retries) §  Improved reporting & statistics
  25. 25. © 2014 ISC Options Summary 1)  Configure your resolver to LIE answer authoritatively yourself 2)  Configure a BLACK LIST of domains under attack possibly subscribe to a feed for this 3)  Consider ADAPTIVE LIMITS per server per zone
  26. 26. © 2014 ISC Ideally, close the open resolvers!! www.shadowserver.org
  27. 27. © 2014 ISC GOOD LUCK!

×