How Can We Take Domains Down Faster?

 
 
By Larry Seltzer  |  Posted 2007-04-05 Email Print this article Print
 
 
 
 
 
 
 

Opinion: Often the best way to thwart an Internet attack is to take down the domain names involved in it, but this is a hard thing to do under current rules.

Shortly before the revelation of the .ANI bug and the inevitable development of attack sites that it engendered, a prescient discussion was beginning about better ways to bring these sites down. Veteran botnet hunter Gadi Evron took his concerns public after a private discussion on the reg-ops (Registrar Operations) mailing list. The message stated that DNS abuse is the biggest security problem in Internet operations.

As Roger Thompson of Exploit Prevention Labs points out, the usual way bugs such as the ANI bug are exploited is by creating masses of Web sites that implement the exploit, usually through an IFRAME tag, and luring users to visit the site. The IFRAME can also be inserted into legitimate sites by hacking into them through a variety of well-known, usually PHP-based attacks.

A new report by Webroot Software has found that more than 40 percent of companies surveyed had been hit with malware that disrupted their business. Click here to read more.

And of course bogus domain names are a major problem enabling phishing. If "paypaa1.com" is discovered to be hosing a phishing site, then it would be good to be able to disable the name quickly. But it turns out that its really hard to have a domain name removed quickly.

There are many ways you can argue the point, but taking the site or IP address down just isnt as good. In seconds, the DNS can be updated to point to some other address, probably on some other compromised system. So taking down the domain can be the best tool in taking down an attack.

Evron calls this "the weakest link online today in Internet security." Getting a little technical here, he cites two types of "fast-flux" attacks that are very common today:
  1. Those that keep changing A records by using a very low TTL.
  2. Those that keep changing NS records, pretty much the same.
This means, in effect, that the DNS resolution for the domain changes rapidly. The only thing worth taking down in order to fight the attack is the domain name.

Evron doesnt claim to know the best solution; hes asking around for one. In his blog, he cites five ideas that he has heard, three of which strike him as bad:
  1. A black list for registrars, a system being set up right now at the ISOTF, which monitors and attempts to fight botnets. Under this system, reports of problem domains would be sent to registrars who would remove them under strict guidelines and under their own AUPs and ICANN policy. The problem is this can be slow and malicious ("black hat") registrars dont care.
  2. A black list for resolvers, basically the very large network providers like the Baby Bells, in order to make the domains less accessible. This would be unenforceable and sporadically effective.
  3. A black list for TLD registries, such as Verisign for the .com and .net domains. Evron doesnt like this. Karl Auerbach did, although the feedback he got for suggesting it has him thinking twice.
  4. An alternate root which is trustworthy. Right, maybe we can set it up for the human Martian colony when we begin it.
  5. Apply to change ICANN policy. There are many policies involved here, including the allowance of domain "tasting" that makes five-day throwaway domains free, if your registrar cooperates.

Im tempted to like #3 because it means theres one point to go to for stopping a domain, but clearly there are problems with it. The really big one, and this applies to all of these approaches, is who gets to decide a domain has to be taken down and how are they accountable?

Evron is right that this needs to be dealt with. Certain very serious classes of problem can never be effectively mitigated until this is done. If you know the magic answer please let him know, but I think any answer will be only partially successful and bring with it undesirable trade-offs.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog. More from Larry Seltzer
 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel