The recent Distributed Denial of Service attack against international spam-fighting group SpamHaus used a technique called DNS reflection to generate huge amounts of traffic for SpamHaus, overloading their servers. This technique relies on using thousands of improperly configured DNS servers to amplify the DDoS attack, in this case by a factor of several hundred. There are plenty to find; the Open DNS Resolver Project has identified over 25 million such servers. Is yours (or your company's) one of them?

My Security Watch colleague Fahmida Rashid has a DNS resolver in her basement, but for most home and small business networks DNS is just another service supplied by the ISP. A more likely spot for problems is a business big enough to have its own complete network infrastructure but not big enough to have a full time network administrator. If I worked in such a company, I'd want to check my DNS resolver to make sure it couldn't be conscripted into a zombie army.

What's my DNS?Checking your Internet connection properties or entering IPCONFIG /ALL at a Command Prompt won't necessarily help you identify the IP address of your DNS server. Chances are good that in the Internet connection's TCP/IP properties it's set to obtain a DNS server address automatically, and IPCONFIG /ALL will probably show an internal-only NAT address like 192.168.1.254.

A little searching turned up the handy website http://myresolver.info. When you visit this site, it reports your IP address along with the address of your DNS resolver. Armed with this information, I came up with a plan:

In the resulting chart you'll find one or more addresses under the heading "Announcement", e.g. 69.224.0.0/12

Copy the first of these to the clipboard

Navigate to Open Resolver Project http://openresolverproject.org/ and paste the address into the search box near the top.

Repeat for any additional addresses

If the search comes up empty, you're OK

Or are you?

Sanity CheckI'm a network dilettante at best, certainly not an expert, so I ran my plan past Matthew Prince, CEO of CloudFlare. He pointed out a few flaws in my logic. Prince noted that my first step will likely return "either the resolver run by their ISP or someone like Google or OpenDNS." He suggested instead that one might "figure out what your network's IP address is and then check the space around that." Since myresolver.info also returns your IP address, that's easy enough; you could check both.

Price pointed out that the active DNS resolver being used for queries on your network is most likely configured correctly. "The open resolvers are often not what are being used for PCs," he said, but for other services... These are often forgotten installs running on a network somewhere not being used for much."

He also pointed out that the Open Resolver Project limits the number of addresses checked with each query to 256—that's what the "/24" after the IP address means. Prince pointed out that "accepting more could allow bad guys to use the Project in order to discover open resolvers themselves."

To check your network's IP address space, explained Prince, you start with your actual IP address, which has the form AAA.BBB.CCC.DDD. "Take the DDD part," he said, "and replace it with a 0. Then add a /24 to the end." This is the value you'll pass to the Open Resolver Project.

As for my conclusion, that an empty search means you're OK, Prince cautioned that it's not quite true. On the one hand, if your network spans more than 256 addresses "they may not be checking their entire corporate network (a false negative)." He went on to note, "On the other hand, most small businesses and residential users actually have an allocation of IPs that's smaller than a /24, so they'll effectively be checking IPs over which they don't have any control." A non-OK result, then, could be a false positive.

Prince concluded that this check might have some usefulness. "Just make sure you give all the appropriate caveats," he said, "so people don't get a false sense of security or panic about their neighbor's open resolver over which they have no control."

A Bigger ProblemI got a rather different view from Gur Shatz, CEO of website security company Incapsula. "For both good and bad," said Shatz, "it's easy to detect open resolvers. Good guys can detect and fix them; bad guys can detect and use them. The IPv4 address space is very small, so it's easy to map and scan it."

Shatz isn't optimistic about solving the open resolver problem. "There are millions of open resolvers," he noted. "What are the chances of getting them all shut down? It will be a slow and painful process." And even if we do succeed, that's not the end. "Other amplification attacks exist," noted Shatz. "DNS reflection is just the easiest."

"We're seeing larger and larger attacks," said Shatz, "even without amplification. Part of the problem is that more and more users have broadband, so botnets can use more bandwidth." But the biggest problem is anonymity. If hackers can spoof the origin IP address, the attack becomes untraceable. Shatz noted that the only way we know CyberBunker as the attacker in the SpamHaus case is that a representative of the group claimed credit.

A thirteen-year-old document called BCP 38 clearly spells out a technique for "Defeating Denial of Service Attacks which employ IP Source Address Spoofing." Shatz noted that smaller providers may be unaware of BCP 38, yet widespread implementation could "close down spoofing at the edges, the guys actually giving out IP addresses."

A Higher-Level ProblemChecking your company's DNS resolver using the technique I described couldn't hurt, but for a real solution you need an audit by a network expert, someone who can understand and implement any necessary security measures. Evenif you do have a network expert in house, don't assume he's already taken care of this. IT Professional Trevor Pott confessed in The Register that his own DNS resolver had been used in the attack against SpamHaus.

One thing is certain; the bad guys won't stop just because we shut down a particular type of attack. They'll just switch to another technique. Ripping off the mask, though, taking away their anonymity, that might actually do some good.

About the Author

Neil Rubenking served as vice president and president of the San Francisco PC User Group for three years when the IBM PC was brand new. He was present at the formation of the Association of Shareware Professionals, and served on its board of directors. In 1986, PC Magazine brought Neil on board to handle the torrent of Turbo Pascal tips submitted b... See Full Bio

Get Our Best Stories!

This newsletter may contain advertising, deals, or affiliate links. Subscribing to a newsletter indicates your consent to our Terms of Use and Privacy Policy. You may unsubscribe from the newsletters at any time.