Spam and Viruses: Unholy Matrimony, Part 1

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. Carla Schroder's new series takes a look at server-level and client-side defenses for defeating the two-headed monster.

By Carla Schroder | Posted Aug 4, 2003
Page 1 of 2
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

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?

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter