http://www.eweek.com/article2/0,3959,1037127,00.asp By Jim Rapoza April 21, 2003 It's not science fiction. Giant networks of zombie computers are poised to unleash massive destruction on the Internet. You've read about it right here in eWeek (see "Thwarting the zombies" by Dennis Fisher, from the March 31 issue). There are other causes for concern: In this space last week, my colleague Timothy Dyck detailed a litany of root-level vulnerabilities that came to light in March alone; and worm activity has increased tenfold this year. But what bothers me most is a strong sense of déjà vu. Every year bad things happen for security, calls are made to improve security infrastructure and patching practices, and for each step forward, there are two steps back. Threats aren't worse because attackers have gotten smarter. It's either that system administrators have gotten lazier or are overworked due to layoffs or both. In most cases, the big security problems you read about every day are simply due to crackers taking advantage of old problems in tens of thousands of unpatched systems for which patches have been available for months or years. So what's the solution? I think it's time to use the worms' tactics against them and build good worms that fix problems. Two years ago I wrote a column about the Cheese worm, which entered Linux systems that had a known security hole and then patched the systems. As I said at the time, I'm not in favor of vigilante-type good worms like Cheese that come out of nowhere. But I do think trusted security entities like CERT or SANS could create and use good worms very effectively. This tactic has been discussed in the security community before, and there are some strong arguments against the use of good worms. But in the face of zombie networks numbering tens of thousands of machines, which could be disabled in a single night by good worms, I'm willing to take these criticisms on. By far, the most common criticism of good worms is that they would be entering systems uninvited and making changes to the system (that's hacking!). This is generally known as the "It's my system so stay the heck off of it" defense. My response to this is that if you haven't protected your system against well-known holes that have had fixes in place for months or years, then you obviously have abdicated responsibility for your system. Your systems are now a threat to others. With the deadly SARS virus raging in Asia right now, if I decided to fly to Hong Kong, kiss everyone in sight, then cough in crowded theatres in New York, I should fully expect to be hauled off to a hospital and quarantined. I don't think an "It's my body and I can spread disease if I want to" defense would work very well. Another argument is that the good worm could make changes to the system that could cause problems. This is definitely true. So on one side, we have an unpatched system that's been taken over by malicious people who could be using it as part of massive attacks to take down the Internet. On the other, we have a single, poorly managed system that is likely already having problems and may have a few more. Which scenario do you think makes for a better Internet? Of course, a good worm is still a worm, and another argument says that worms are inherently uncontrollable, meaning that good worms will cause traffic problems and spread out of control. This is true of most worms today, but that's only because no one has designed a legitimate, well-coded and peer-reviewed good worm. One can easily envision simple controls such as built-in expirations and bandwidth management that would limit or eliminate these effects. The argument in response is that creating a legitimate, well-coded and peer-reviewed good worm takes a lot of time, much too long given the speed at which worms spread. My reply: Most worms don't take advantage of a newly discovered problem. Most are using security holes that have been known for a long time. There are some questions that need to be answered. Who would design and manage these worms? The government, CERT, vendors or some yet-to-be-formed body? Which problems should be addressed by them? What's the notification procedure for systems that have been patched by a good worm? Does it leave a message for the administrator? None of these are insurmountable roadblocks. The best course of action is to manage your systems effectively and keep them well-patched, hardened and secure against problems. Then you won't have to worry about worms in your own systems, just in your neighbors'. - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Wed Apr 23 2003 - 00:41:37 PDT