|Intro|
|News|
|Threats|
|Alerts|
|Papers|
|Events|
|Reading|
|Links|
|About Me|
|Powered-by...|
My Apple™ has a worm!
[Back to Main]
Worms are actually a very old threat, dating back to the Morris Worm from 1988. It would be wise for any aspiring security profession, or in fact anyone trying to better understand the nature of internetworking to do some research on the Morris Worm. So what makes a worm different from a virus? Worms are defined as self-replicating mal-ware which does not relying on attaching itself to a host program in order to spread. Worms in general come in many flavors, and several of the most famous (SQL Slammer, MS Blaster) did not use e-mail at all. However, e-mail is an excellent vector for worms since they don't necessarily have to rely on a vulnerability at all! If an e-mail user can be tricked into executing a file they received in e-mail the existence of an exploitable vulnerability becomes moot.
Because of their self-replicating nature, worms (and blended-threat or hybrid worms) are one of the most dangerous digital threats in existence today. Worms can spread at frightening speed and have the potential to infect millions of hosts in a period of a few minutes. Besides the obvious affects of damage or alteration to infected systems, they also choke networks of bandwidth and deny service to legitimate applications.
What can be done about worms? Because of their similarity to viruses, worms are addressed by modern anti-virus software. Unfortunately, because anti-virus technology still largely relies on signature-based detection, timely protection against worms is not likely. Modern worms can spread faster than anti-virus vendors can release signatures to stop them, so it's very likely that your network will become infected even if you have modern and up-to-date anti-virus software. Clearly anti-virus vendors need to do more work on true heuristics-based engines, but this is incredibly difficult because not every context for malicious code can be imagined, and there is always a danger of false-positives when decisions are made by machine-intelligence.
There are some stop-gap solutions that you can put in place to defend yourself. If at all possible, create a strong security policy regarding the use of e-mail. Employees should not be allowed to use off-site e-mail accounts from work equipment, since you don't have any control over the security measures taken by those sites. You should also create strong policies against dangerous file-types in e-mail, such as .vbs, .pif, .scr (for Windows screensavers, although some other files use this extention), etc.
Ideally, anything that is executable should be forbidden. In some environtments the use of self-extracting compressed or encrypted files is required. In these cases the files should not be sent through e-mail, but by some other method such as scp or sftp. Since policies would do little without enforcement, you should filter for the above file types on your e-mail gateway and perhaps also on your groupware server (such as Exchange), depending on whether you want to allow your employees to share executable files internally. I recommend using file shares rather than e-mail for this situation.
The last step is more along the lines of network security, but it applies to e-mail in that it's protecting your e-mail servers. Make sure that you are not running any unnecessary services what so ever on your e-mail infrastructure. Shut down POP and IMAP daemons if you're not using them; the same for Message Submission Protocol (on Sendmail) and UUCP (UNIX). Do not run SunRPC on UNIX boxes unless it's expressly required (such as for NFS), and do not bind Microsoft protocols to external network adaptors on Windows boxes (only leave them enabled for the adaptors which need to talk to your AD server, etc). Make sure the firewall only allows the ports absolutely necessary for e-mail into and out of your network. Make sure you protect your mail servers from your own network as well as from the Wild Internet. It doesn't hurt to run a host-firewall on mail servers if you're familiar with how to configure it. This is particularly easy with BSD and Linux which have their own built-in kernel packet filtering.
This site © copyright 2003-2011 Brian Keefer. Unauthorized republication is forbidden.