[an error occurred while processing this directive]
CurzTech News Network
CurzTech News Network | CurzTech World News | CurzTech U.S. News | CurzTech Entertainment News | CurzTech Political News | CurzTech Conspiracy News | Yesterday's News | Offsite Archive
Whereas TCP connections require a three-way "handshake," UDP connections do not require such an acknowledgement. Therefore, the Slammer worm, which spread via UDP, could make connections as fast as the host servers could send out packets.
Are you paranoid yet? If not, you should be. The SQL Slammer worm was yet another in a long string of wake-up calls indicating that many enterprises' security practices are not up to snuff.
For all its speed and collateral damage, Slammer was not the killer worm. But according to Michael Rasmussen, a security analyst at Giga Information Group, it could have been. It was "the first worm you could trace back to a potential loss of life, because the Slammer worm did take out some of the 911 call centers in the Pacific Northwest," he told NewsFactor, noting that another worm like it "could lead to a very big impact and loss of life."
In fact, Slammer could come to be viewed as the harbinger of a new era of more vicious malware -- especially if IT managers are not more careful in the future. Are enterprises ready for the new world of worms?
ADVERTISEMENT New Approach
Vincent Weafer, senior director of Symantec's (Nasdaq: SYMC) Security Response, pointed out just how fast Slammer moved. Before Slammer, he told NewsFactor, most worms spread within 24 hours. "Slammer was over and done with within four hours. Most [infections] occurred within the first 15 minutes." Unlike many other attacks, Weafer noted, Slammer had "no dependency on human interaction."
Another reason for Slammer's rapid spread is that while most malware to date has been transmitted via TCP, an Internet protocol, Slammer took a different approach via UDP, an older and less secure protocol. Whereas TCP connections require a three-way "handshake," UDP connections do not require such an acknowledgement. Therefore, the Slammer worm could make connections as fast as the host servers could send out packets. Even systems that were not vulnerable to Slammer were bogged down by the number of requests they received.
Indeed, as Aberdeen Group security analyst Eric Hemmendinger told NewsFactor, it does not take many infected machines to create havoc.
Candle in the Wind
On the positive side, an old saying seems to have held true in the Slammer attack: The candle that burns brightest also burns quickest. Weafer said Slammer scans have dropped to near zero, whereas older attacks like Nimda are still producing scans on the order of 10,000 incidents per day.
But one ominous truth may haunt system administrators. Slammer was mainly a proof-of-concept worm, rather than one designed to do real damage, according to Giga's Rasmussen. "Somebody could have made the Slammer worm a lot worse. This was just to make people wake up." In other words, something far more destructive could emerge in the near future.
Not If, When
All of the security experts interviewed agreed that a follow-up to the SQL Slammer worm is inevitable. It is just a matter of when the attack will occur and how painful it will be.
Hemmendinger said companies should view Slammer's emergence as part of a trend. "I wouldn't look at this as being an issue of 'what virus' or 'what worm,' he explained. "The number of vulnerabilities being discovered and published is going up every year. The number of potential exploits goes up every year."
The lesson, he noted, is to be ready for the next wave. "Don't be surprised if later in the year we see another worm that uses the same technique ... and also carries a pretty nasty payload."
Rasmussen agreed that the next worm could be more damaging. "It might not always be aimed at propagating," he said. "Instead, someone who knows what they're after … could be much more damaging to a few targets." For example, he added, the next worm might alter, steal or destroy data after it has infected a server .
What You Can Do
So, what is a system administrator to do? There are no quick-fix solutions or catch-all remedies. Instead, common sense is the key.
"The age-old rule still applies," Hemmendinger said. "If you don't keep your eye on patches and updates … you're likely going to get burned, and you shouldn't be complaining too loudly because the cure was in front of you." He admits, however, that the patch-and-update cycle can be costly. For that reason, he recommends that companies consider automation and intrusion prevention solutions.
Shutting down unnecessary services is also key to staying safe. Weafer noted that although administrators cannot refuse UDP connections or disable all UDP services, they can turn off some unnecessary services that might be vulnerable.
For his part, Gartner security analyst Richard Stiennon told NewsFactor that Slammer highlighted a weakness in enterprise security. Many companies have "a lot of firewalls with rudimentary rule sets. Vendors should bring them into more of a lockdown," he said. "There's no excuse for having a direct SQL connection to the Internet."
A World of Targets
Lastly, although Microsoft (Nasdaq: MSFT) systems have been a favorite -- some would say easy -- target of attackers, they are hardly the only vulnerable ones. As Rasmussen said, "There is no security Nirvana." It is just as possible that crackers could find and exploit a vulnerability in commercial Unix systems or applications or open source systems. They all have vulnerabilities, and they are all potential targets.
Hemmendinger agreed that Microsoft is not alone in its vulnerability. "It's probably appropriate to think about Microsoft as one of the biggest targets on the block in terms of platform, but I would discourage people from thinking that other platforms are immune," he emphasized. "The first guy who stands up and says, 'I run X and I'm not going to have a problem with this,' is basically just posing a challenge."
© 1998-2003 Triad Commerce Group, LLC. All rights reserved.
[an error occurred while processing this directive]