Spam and Viruses: Unholy Matrimony, Part 1

By Carla Schroder | Aug 4, 2003 | Print this Page
http://www.enterprisenetworkingplanet.com/netsysm/article.php/10954_2244141_2/Spam-and-Viruses-Unholy-Matrimony-Part-1.htm

Make no mistake about it — spam and viruses are deliberate, malicious assaults on our systems that often work together to penetrate and compromise our networks. A popular dirty trick by spammers is to plant malicious code in their spew to exploit recipients' systems. Remember jeem.mail.pv? Proxy-guzu? These sweet little Trojans, just two of many, compromise Windows boxes and turn them into spam servers. The moral here? Keep spam off your network and it will be considerably more secure.

While the vast majority of viruses, Trojans, worms, and other malware are aimed at Windows, users of Linux, Unix, BSD, and MacOS should not be complacent. You never know where the next exploit will be aimed. We'll look at server-level defenses in part 1 of combating the two-headed monster, while part 2 will cover the client side, including how to decode mail headers and recognize malicious code.

Email: The #1 Security Hole

No matter how much we cajole, nag, pester, plead, implore, educate, and even threaten, it's inevitable that our users will continue to open malicious attachments. Why bother with a firewall at all when email rolls out the red carpet to viruses, worms, and Trojan horses? Anti-virus software and gateway software that scan message content and mime types are important and essential, but they simply can't catch everything. And even when users are well-behaved, certain email clients will happily execute malicious code without any user intervention. All the spam has to do is land in the user's inbox.

There is a simple, if somewhat extreme, solution — strip all email attachments at the server and chuck 'em into the bitbucket. Encourage (or accept nothing less than) the use of FTP instead for file transfers. After all, as us cranky oldtimers like to rant, email is not a file transfer protocol.

The stumbling block with FTP is more of a social issue than a technical one. While setting up a nice FTP server is easy and inexpensive — I recommend using an old Pentium and free/Open Source software — getting your users to happily (or even willingly) hop on the FTP train can be tricky. You should also be very choosy about which FTP server you select — the popular WU-FTPD, for example, is as holey as Swiss cheese. I like vsftpd, the "very secure FTP daemon"; it's written from the ground up with security and performance in mind.

Using FTP Instead of Email Attachments

Getting users to warm up to FTP can be a challenge, especially converting those outside your company that wish to send files to your co-workers. However, we must stand our ground and enforce sensible security policies. After all, it's not the lamer in Marketing who clicked on "Free Nekkid Pictures!" that will be blamed for a virus infestation or for the Trojan turning your PCs into pr0n servers; rather, it's you, the poor overworked, harassed admin, that will be stuck with both the blame and the cleanup.

I personally favor the carrot and stick approach. Discarding all email attachments, both incoming and outgoing, at the server is a powerful stick. The carrot is presenting FTP transfer in the right manner. The benefits are many: user authentication, batch transfers, the ability to resume interrupted transfers, no limits on file size, secure login, secure SSH transfer, and confidentiality.

Plus, FTP is easier than futzing with email attachments. All web browsers come with simple FTP clients, for those users that need to cling to the familiar. All they do is drag-and-drop files — what could be simpler? In my experience, once users get accustomed to FTP, they like it.

Anonymous FTP, though, is good for one thing only: letting the public download non-sensitive documents from your servers. Unless you enjoy hosting warez and other mischiefs, everything else must be protected by authenticating users.

Page 2: How About Blocking Only Executable Attachments?

How About Blocking Only Executable Attachments?

What about blocking only executable attachments, such as .exe, .pif, .bat, and so forth? Unfortunately, that just isn't good enough anymore. As the recent infestation of the deceptive, .zip-abusing Mimail worm proves, the bad guys don't stand still. It's an ever-escalating war, and it's impossible to tell what trick spammers will think of next.

And even if your gateway software is smart enough to recognize deceitfully-named attachments, such as .jpg.pif or .doc.exe, what about the myriad of undocumented Windows executables? That's right, there's a boatload of them that have accumulated over the years, and I doubt anyone knows what all of them are. (And of course, only spammers and black hats are interested in finding and exploiting them.)

So back to using FTP rather than email for file transfer — what if someone uploads a malicious file to your FTP server? The benefit of using FTP is that, unlike email, which is open to random pounding by total strangers, you'll know exactly who put what on your FTP server.

I know the thought of getting all your users to jump on the FTP bandwagon sounds rather challenging, especially early on, but in the long run it will mean a lot less work — and will be a lot less traumatic — than trying to police a network awash in unrestricted email.

Chuck HTML Mail

It's a shame how nice things get ruined. HTML-formatted messages can carry all sorts of nastiness, such as executables disguised as URLs, malicious javascripts, and even more dangerous VB scripts. All of these are adept at doing nasty things like phoning home upon receipt and again on read, connecting to nefarious Web sites, and tracking users with clandestine web bugs. In short, any dirty trick that can be executed on a web site can be duplicated in HTML-formatted mail.

Us cranky oldtimers like to gripe that "plain text was good enough for my granny, and it's good enough for me!" Well, I have mixed feelings. Yes, HTML messages waste bandwidth; and yes, they permit people to display their bad taste in color schemes; and yes, these messages look like crap in plain text. However, people do like pretty stationery and imagery, which means fancy-formatted mail is here to stay. Hopefully a new ornamental format will emerge at some point — one that is not exploitable.

In the meantime, I can't think of a single good technical reason to accept HTML-formatted mail. The risk is too great. Divert it to the same bitbucket stripped attachments are tossed into. Be sure to send a polite rejection message so the sender knows their mail did not get delivered. It's good to include a brief explanation and instructions on how to send plain text messages. Many users don't even know what mail formatting is; a little polite education goes a long way.

Alternatives to the Bitbucket

A blanket rejection of attachments and HTML messages is not always desirable. Messages from customers, mail from the dimwitted but important executive — there are many situations where sending a rejection notice is probably not a good idea. And technical staff (hey, that's us!) typically object strenuously to any kind of mail restrictions.

While there are numerous utilities for removing HTML code from messages at the server, and although we might be more comfortable with controlling events at the server level, the client side is equally important. There are many email clients, such as Eudora, Pegasus, Kmail, and Evolution, that have advanced message-management features and ways to foil malicious code. We will look at these in part 2.

Resources

vsftpd
FAQ: Web Bugs
Symantec: The Mimail Worm
OL2000: Information About the Outlook E-mail Security Update


» See All Articles by Columnist Carla Schroder