Recent press is brewing up more concerns about security issues with DNS . This time it pertains to DNS being a possible tool to amplify Denial of Service attacks as an attacker can send a spoofed DNS request that becomes a larger response from the DNS server to the intended victim. This type of attack is not new as it dates back to earliest of DDoS attacks with other protocols such as the character generator ports in Linux. The question for the marketplace is will the focus on this attack lead to tangible changes in DNS infrastructure? Changes are underway and I am not sure this research will necessarily change the prevailing winds but hopefully it will open the eyes of more DNS operators to address these longstanding issues.
One thing to note is that there are really two things at play here. In the reports, they talk about using DNS to attack another Internet target by using the DNS farm to increase the size of an attack. In this manner an attacker with a small amount of bandwidth can cause a denial of service larger than what would be nominally attributed to their network connection or size of their botnet. The second attack is against the root servers or DNS servers in the resolution chain whereby a small request causes an increased amount of processing required on the part of the DNS farm. Both of these cause denial of service attacks, one bandwidth against an Internet target, the other processor consumption against a DNS farm such as the root servers. For some time, arguments have been raised for changing DNS to TCP and adding security mechanisms. These are not going to happen quickly.
By moving DNS queries to TCP only and off of UDP this avoids the described bandwidth attack against an Internet target through spoofed addresses. The problem is that a DNS server can only turn off UDP queries once every client you are going to support has properly moved off of UDP. This is going to take some time. Furthermore, while new security measures are being instituted that can be used to help attribute queries to systems, until they are ubiquitous, we are stuck with the DNS they have. Fortunately all is not hopeless until some future date when the Internet no longer uses IPv4, have moved away from UDP and DNS is only with full DNSSEC features.
What is great about this news, however, is it is a perfect example to highlight why there has become a great marketplace for Infrastructure Security Products. For decades attackers went after comprised web sites or vulnerable clients. Big web sites are built like Fort Knox today and Anti-Virus is a household term in the most non-technical households leaving what is in the middle, the Internet infrastructure ripe for attack. DNS DefenderTM for example is one such new breed of security products. DNS Defender  sits in front of DNS Farms, from enterprises to service provider’s to root servers and is able to, in a sense, fix up the current DNS implementation while we wait for future changes. For example, if we look at the current amplification attack, DNS Defender can use its DNS rate limiting abilities and caching to protect the DNS farm both from processing attacks on the DNS farm as well as it being used as a amplifier against targeted sites. DNS Defender provides numerous controls for rate limiting by either query type or by user. Should a flood of traffic come in from a single IP address of a site that is an intended target, the responses per second can be controlled to some nominal level that prevents any value of using the DNS farm as the amplifier. Furthermore, should the attacker want to simply send queries for the ‘.’ domain to get a list of .com, .net and similar root domains causing processor time, these queries can be cached and answered using the DNS Defender as a cache server. The combination of functionality requires zero changes to the DNS farm while also fighting off both cases of using the DNS farm for amplification.
The good thing is that putting defenses like DNS Defender in place in front of key critical infrastructure is not conceptual but already in place in key locations.
Loading ...