Water Torture: A Slow Drip DNS DDoS Attack

/in , /by

A number of our service provider customers around the world are reporting that they see a new type of DNS DDoS attack that uses the DNS as the attack vector. The service providers themselves do not appear to be the target of this attack. Instead, the attack tries to overwhelm an outside victim’s authoritative DNS servers. Once the DNS server is taken down, the victim’s domains will appear to be inaccessible.

As a side effect, our service provider customers are seeing a spike in DNS traffic resulting in increased CPU and memory usage. This blogs gives some more details about the attack and suggests what you can do to mitigate the impact of it.

The Attack

It appears that a fairly large botnet is used to send queries for the victim’s domain. Queries are made-up, with random string with up to 16 letters prepended to the victim’s domain, like:

xyuicosic.www.victimdomain.com

A query for this domain is then sent to the service providers DNS server. The DNS server attempts to contact the authoritative nameserver to find the answer. If the authoritative nameserver does not reply (because it is too busy responding to queries from DNS servers all over the world, or perhaps has crashed), the DNS server attempts to contact the next authoritative nameserver and so on. Modern DNS server will make multiple attempts to contact each authoritative nameserver before giving up and responding back to the client with a SERVFAIL response.
The infected client will then repeat the same pattern but this time with another random string prepended, for example:

alkdfasd.www.victimdomain.com

Even though the DNS server was unable to get a response from any of the victimdomain.com authoritative nameservers during the previous query, most DNS servers will still attempt to contact them for this second query.
Now imagine that thousands of bots are sending a relatively small number of queries for such made-up subdomains. This will trigger a large increase in the number of DNS queries sent by the service provider’s DNS servers to the victim’s nameservers.

How to Detect the Attack

While this attack most likely is targeting the authoritative servers for victimdomain.com, it also puts an increased CPU load on the DNS server by forcing it to continually initiate recursive queries and also consumes large amounts of resolver memory resources. More importantly, if the internal resolver resources are fully consumed, the resolver may drop any inbound queries, including queries from legitimate clients.

If the DNS server’s behavior is being monitored, the symptoms of the attack will also show up as:

  • Increased CPU utilization
  • Increased number of SERVFAIL responses
  • Increased number of outbound queries and retransmissions
  • Increased query latency
  • Increased number of dropped client queries (if the resolver resources are fully consumed)

One thing all of the victim domains have in common is that they appear to be Chinese sites, perhaps gaming or gambling sites.

How to Block the Attack

Because the query rate from each client IP address is quite low and because there is no response amplification, it is difficult to determine simply from packet rates or bandwidth consumption which client IP-addresses are participating in the attack. And because the names change periodically, it can be time consuming to track and block queries to the domains being used in the attack.

However, here are some specific steps you can take to minimize the impact of the attack:

  • Check your timeout settings. Most resolvers allow you to specify the initial and subsequent timeout intervals. Make sure that these values are not too high (if they are, they will tie up resolver resources longer than necessary before a query fails).
  • Increase the number of outstanding recursive queries if you have sufficient RAM on your server. This will give the resolver more resources to work with.
  • Specify a non-zero TTL for the negative responses so that if a client requests the same non-responsive name more than once, the SERVFAIL answer is cached. By RFC, you should be able to specify up to a 5 minute TTL.

Secure64 Defenses

Secure64’s DNS Cache has built-in defenses against such an attack. Under attack conditions, the Secure64 resolver will not consume any CPU or memory resources attempting to reach nameservers that it already knows are non-responsive. This adaptive behavior allows the Secure64 resolver to remain 100% available to legitimate clients under such attack conditions.