DNS smurf attacks - The lowdown

By Scott Clark

About seven years ago, “Smurf attacks” were all the rage.  A “Smurf attack” describes a type of attack in which the attacker exploits a system or service that responds to a small amount of data with a much larger amount of data – the bigger the response, the more destructive the attack. If the attacker lies about his or her source IP address and uses the IP address of some unwilling ‘victim’, that larger response is sent to the victim.

When this is directed at a single exploitable service on a single system, this does not manifest as a significant problem.  However, when the attacker sends requests to a large number of systems running the exploitable service, the attacker can cripple the victim with overwhelming bandwidth, thus causing an effective denial of service.

Due to the principals of openness and interoperability that the Internet was originally built upon, some of the services that make the Internet work have been found to be vulnerable to these types of attacks. Sadly, the ‘vulnerability’ in this case is not a bug or a coding error, but flaws in the protocols themselves. Now that the Internet has become a vast war zone, no one is exempt from attack - if you have an exploitable system, it will be exploited eventually – and it will most likely happen sooner rather than later.

One of the foundations of the Internet is DNS – or Domain Name System.  Simply stated, DNS is the service that maps “names” to “IP addresses”, allowing people to identify systems using descriptive names as opposed to having to remember non-descriptive IP addresses.  Therefore, you can type “peer1.com” in your browser to reach our company’s website instead of remembering the IP address 64.69.87.228.

DNS is one of those Internet services that evolved out of the values of openness and interoperability.  Now, unfortunately, those values are its vulnerability.

For example, let’s say you own a domain called “mydomain.com”.  By default, when your DNS server responds to a lookup request for “mydomain.com”, it will reply with the IP address for “mydomain.com”.  However, you can pad the DNS TXT resource record with more “attribute” data.  If done properly, you can pad the TXT record with enough data to create a very large packet without fragmenting. Now, when your DNS server is asked to resolve “mydomain.com”, the reply is much larger than the request.

So how is the Above Example an Effective Attack Vector?
If you query another DNS server for the IP address of “mydomain.com”, that DNS server will query your DNS server for the IP address of “mydomain.com”, cache the authoritative response from your server (including the attribute date found in the TXT record), and the other DNS server will reply back to you with everything – including the TXT record.  This is standard operating procedure for DNS.

However, if you tell the DNS server that you are someone else by spoofing the source IP address in the request, you can direct that large DNS response to the spoofed IP address (who we will call the ‘victim’).  Therefore, if you know how to send a spoofed request for “mydomain.com” to a large number of DNS servers, you can create a very efficient denial of service targeted at the victim’s IP address.

How can this Affect PEER 1 Customers?
PEER 1 focuses on the dedicated hosting market so we host servers on our network that are fully managed by our customers.  It is expected that some of our customers will also install and configure DNS servers on these servers to allow them to resolve their Internet resources.

As an example, a company called XYZ Widgets buys the rights to use “xyz.com” and they place two servers on the Internet – a mail server named “mail.xyz.com” and a web server named “www.xyz.com”.  When someone surfs the Internet looking for “www.xyz.com”, the browser will ask the DNS server to resolve the name www.xyz.com to an IP address and allow the browser to connect to the correct server.  When that same someone attempts to email them a question, the mail servers will ask the DNS server to identify the mail server for “xyz.com” and get the IP address so that the email will safely arrive at “mail.xyz.com”.

In the above scenario, the company uses this DNS server as an “authoritative source” for the “xyz.com” domain.  This is an expected and acceptable use of DNS on those systems.

The real problem arises when a company configures their desktop computers to use that DNS server for name resolution – as opposed to configuring those computers to use the DNS servers of their ISP as is normally expected.

In the context of the attack vector described above, if your DNS server is listening for DNS requests from your company and you haven’t defined rules limiting who the DNS server responds to, then your server could be used in one of these denial of service attacks using DNS Smurf.  An attacker could ask your DNS server for the IP address of “mydomain.com” and your DNS server would ask their DNS server for the IP address of “mydomain.com”.  If the attacker uses a spoofed IP address in the DNS request, your DNS server would send the reply to the spoofed IP address with that large packet of data, thus contributing to the denial of service.

Since the vast amount of traffic that ensues would compromise the integrity of the PEER 1 network, as a result of its participation in the denial of service attack, we would be forced to manually disconnect your server from the network until such time that the issue is resolved.

FOR FURTHER INFORMATION
About DNS – start here: http://en.wikipedia.org/wiki/DNS
DNS BIND acl (9.x) http://www.zytrax.com/books/dns/ch7/acl.html
DNS BIND options (9.x) http://www.zytrax.com/books/dns/ch7/statements.html