DNS Applified Distributed Denial of Service Attacks - Printable Version
+- Eskimo North Forums (http://www.eskimo.com/bbs)
+-- Forum: Eskimo North Support (/forumdisplay.php?fid=3)
+--- Forum: Tech Talk (/forumdisplay.php?fid=7)
+--- Thread: DNS Applified Distributed Denial of Service Attacks (/showthread.php?tid=86)
DNS Applified Distributed Denial of Service Attacks - Nanook - 11-20-2013 06:40 AM
DNS amplified distributed denial of service attacks work by using DNS servers as amplifiers in the attack.
A small query, with the source IP forged as the address under attack, generates a much larger response that is sent to the forged IP.
Often a throw-away domain is created with many bogus DNS records just for the purpose of getting a large response from the DNS servers which are used as intermediary amplifiers in the attack.
The preferred solution is not to have resolving DNS servers accessible
to the outside world. Unfortunately, for those with roaming clients this is
Fortunately, there is another fix. Bind 9.9.4 and newer versions support rate limiting. This is not enabled by default. In order to enable this feature you will need to compile from source with --enable-rrl flag given to configure before you make.
This feature is intended for non-resolving servers, however, I have found that it works quite well in resolving servers provided you have enough memory to throw at it. During an attack, I will typically see an image of around 600-700MB. In my view, if you've got reasonably busy DNS servers, you should be allowing them a gigabyte or so for cache anyway.
Rate limiting can work effectively against attacks with no noticeable effect on legitimate traffic even with tight limits. This is so because the rate limiting present in bind limits identical responses to IPs in the same subnet. The chances of normal traffic generating identical responses in the same subnet within a short time frame are very minimal because normal resolver libraries cache the response and aren't going to repeat the same query right away.
There is an exception to this and this is when DNS is used for real time black hole lists where the TTL is set to zero to prevent caching.
Normally outside access to your serves by roaming clients isn't going to use this but your internal mail servers very well may and this was the case for my installation.
Here, we use spamassassin and clam-av, both of which use numerous RBL's and also look up viral footprints via DNS.
I found it was not possible to limit the rates low enough to impede the use of our servers for DDOS amplification while at the same time allowing them to respond to identical queries for spamassassin and clam-AV to function properly.
But there IS a solution to this as well, views. Views allows you to setup a BIND DNS server such that an external client gets a different view than an internal one. Typically this is used for zones, where externals are allowed only to see certain zones and not do recursive lookups, where internals are allowed to see all zones and use recursion.
But rate-limit is also an option you can put in zones, and so it is possible to create an internal zone with little or no rate limiting and have an external zone tightly limited and that is in fact what I've done here.
Here is an example of the rate limiting I have in our external view:
The responses per second is identical responses in the same subnet, not two responses globally, so this will still suffice for a fairly busy name server.
I'm further restricting error responses to one a second and no-data
responses to one a second and nxdomains to one a second since these
are all non-valid responses and wouldn't result in successful resolution anyway.
I only allow for two identical responses because there is the possibility for a packet to get lost and the requesting node not to receive a response to a request it had made and repeat the request for that reason.
I would allow for more than two just in case packet loss were severe but since we have four name servers, the requester would just go onto the next if both timed out.
The window sets up a sliding window so this would allow up to ten identical responses in a five second time frame.
The slip value allows one truncated response every nth attempts. The default is two, but that only minimally reduces the amplification potential, and again, under normal circumstances rate limiting is rarely invoked. Where it is invoked, it affects only those responses that are identical, not legitimate traffic, so really I see no need for allowing any
One thing to be aware of with views, if you have views, the then
zones must be within them. This I think is unfortunate since it would
have simplified things if you only had to put what you wanted to be
different in the view, but because of this it is necessary to put your
zone records in the view.
Our name servers were regularly being used as amplifiers, this solved that problem and saved us some data fees.