Fighting Spam and Viruses at the Server, Part I

Date: Mar 12, 2004

Return to the article

Mail administration these days has two aspects to the job that can be both thankless and downright brutal: combating spam and viruses. Users moan whenever their mailboxes fill with spam, and whenever you implement a spam-blocking procedure. They cry in pain whenever viruses inundate them with false bounce reports and trick them into breaking their machines. Management comes to you with surveys that quantify how much time and money is lost in productivity due to both problems, demanding fixes, and then they bristle at the solutions you suggest. Somehow, you're supposed to become a spam and virus expert overnight.

Rather than leave you twisting in the wind, this brief series attempts to bring you up to speed on the latest in spam- and virus-blocking techniques, along with helping you to understand why particular solutions touted by some experts are more—or less—desirable than others. The good news is that there are in fact a number of effective measures that can make life much more pleasant for both you and your users. The bad news is that lots of strategies out there actually cause more harm than good.

Ultimately, what you'll find is that the best solutions available all point to the server side of the equation. The key is implementing a solid plan on your mail server(s) while not violating the basic tenet of mail administration: Lose No Mail.

E-mail Hazards

These days, having an E-mail address is a lot like having unprotected sex with strangers—both invite nasty infections that can get participants into a lot of trouble. Today, E-mail is the vector of choice for viruses, worms, Trojans, and various forms of "spyware," which are all generally designed to steal something from the user: login credentials, CPU cycles and bandwidth to broadcast spam and viruses—even the user's very identity (credit card information, banking information, and more). With subject lines as innocent as "pick up your phone," "hey there," or "a question for you," and mail pretending to be from people in the user's address book thanks to forged mail headers, it can be hard for even a computer expert to tell the genuine mail from the dangerous bait.

The worst and most successful of the lot are the so-called "social engineering" tricks, in which the authors of malicious programs use psychological trickery to encourage the recipient to take the bait and execute an attachment. These sneaky little programs are typically disguised as sound files, screensavers, greeting cards, or even patch programs that promise to remove a virus from the user's system. Leaving users on their own to navigate this minefield is just asking for trouble. It can be difficult enough for computer experts.

Of course, even without attachments, E-mail can be dangerous to the end user, if not so much to the mail administrator's precious machines and networks. A lot of the spam making the rounds these days consists of scams and frauds designed by con artists intent on suckering users out of their hard-earned money. Pyramid schemes, "get rich quick in your spare time" scams, and those charming Nigerian letters proposing to make people millionaires (if only they'd help the author launder some nonexistent cash) trick a surprising number of people. More chilling are the "phishing" schemes, where the con artist mocks up a Web page pretending to be a major bank, mortgage broker, or an online e-tailer such as eBay or Amazon.com. From there, the perpetrator uses E-mail to trick people into logging into the fake site with their real credentials. Armed with this information and other personal data gathered "to verify your identity," the con artist then obtains credit in the victim's name, accesses his or her financial assets, and effectively steals the victim's identity.

Finally, in the world of E-mail dangers, there are the "Web bugs." Spammers often place these little beauties in their spam E-mail to track the effectiveness of their campaigns. No, this isn't some slick use of raw text to overcome an E-mail client. It's an HTML trick: Many people have clients that not only support HTML mail, but render the pages by default the moment that the recipient either previews or opens the mail. Instead of attaching the spam's images, the spammers create the Web page to load the pictures from particular Web sites, complete with a tracking code that identifies the reader. This data assures the spammer that the person's E-mail address is valid, and that the user opened his mail. He can then use this information to target this person for more spam, deeming the victim (accurately) to be among the more "vulnerable" to his methods.

So what's a mail administrator to do? Tackle the problem as close to its source as you can. Doing so saves people downstream a lot of time and resources, and cuts down on the potential for human error. Consider that if you have a company with 30 employees and you leave it up to each individual to deal with his or her own spam and virus problem, you've got 30 different chances for chaos. Even if 29 of those employees are savvy and know better than to execute attachments, it only takes one half-awake staffer to make a careless mistake that affects the entire network.

A better approach involves moving the content-filtering task upstream to the mail server, where you can focus more resources on the problem and shield everyone downstream. This action also has the benefit of putting these tasks in the hands of the people who are likely to have the most computer expertise: the mail and network administrators. These people should know more about the dangers of spam and viruses than more casual computer users in the organization, and ought to be vigilant for these problems in the same way that they keep an eye out for intrusion attempts and crashed vital services.

A number of tools are available for the harried mail administrator. Thinking of E-mail in terms of postal mail, it's straightforward to classify these filtering tools according to whether they "open the envelope." In other words, some tools care only about what's written on the outside (information about the sending mail server and the SMTP mail delivery instructions), while others perform a thorough examination of the mail's actual contents (the mail headers and body).

Envelope Tests

When one mail server sends mail to another, a few vital pieces of information are exchanged:

• IP address of the host connecting to the receiving mail server

• Sender's (supposed) hostname

• Sender's (supposed) E-mail address

• List of recipient E-mail addresses

Before the receiving mail server agrees to accept the rest of the mail, it has a chance to use this bit of information from the "outside of the envelope" to decide whether it should reject the mail outright. A few rudimentary tests can be performed:

• Is the connecting host on a DNS block list?

• Are the mail's recipients actually valid users?

• Is the connecting host "authorized" to send mail from its domain?

Let's take a look at each of these types of tests, and what they accomplish.

DNS Block Lists (DNSBLs)

The IP address of the connecting client can be looked up against various DNS-based lists of spammers, spam sources, and spam-related sites. These lists serve as an informal "reputation rating" for Internet hosts (from individual IP addresses to blocks of IP addresses to entire ISPs or domains), in much the same way that credit bureaus let creditors get a feeling for whether a potential customer is likely to make his payments. IP addresses that become known for sending out a lot of spam end up on these lists, which are generally available for any mail administrator to consult.

The purpose of block lists is twofold:

• Protecting one's own network from receiving mail from sites that are known to send spam

• Punishing those sites in the hope of encouraging their administrators to reform their ways

The power of these lists, for better or worse, is achieved when large numbers of sites use them; as more sites use a given list, more parts of the Internet refuse mail from listed sites. This strategy can be crippling to a listed site, isolating it from much of the Internet. When a listed site meets certain "cleaned up" criteria laid out by the operator of the particular block list, it can be removed from the list.

Block lists are not without controversy. The fact that each block list operates by its own rules and sets its own criteria for listing and delisting a site means that mail administrators need to be careful about which ones they choose to use and trust. Some are more aggressive than others, more willing to list large domains—for example, all of AOL.com. You might imagine that blocking all mail from so many millions of users can have a crippling effect on your own users who need to talk to people who are AOL subscribers. Since a certain amount of human judgment is involved in the listing process, innocent sites can also end up on these lists, and some block lists are slower than others at removing sites.

That said, most DNS block lists are quite effective; the more reputable lists, such as the Spamhaus Block List, are in widespread use these days. Their effectiveness is not lost on spammers, who have targeted several DNSBLs with distributed denial-of-service (DDoS) attacks over the past year. By their very nature as DNS-based lists, DNSBLs are vulnerable to such attacks, and two of them—Osirusoft and monkeys.com—were forced to shut down last year as a result of prolonged DDoS attacks.

Tests for Valid Recipients

It seems like common sense to suggest that your mail server should only accept mail addressed to actual users it knows about, but an amazing number of mail servers out there aren't doing this relatively simple check before accepting mail. Instead, they accept the mail and only later in the process discover that the recipient doesn't exist, forcing the mail server to then bounce an error message to the (supposed) sender.

Where this causes serious problems is with "dictionary attacks," used by spammers to try to find out which E-mail addresses actually exist at your site. When a dictionary attack occurs, the spammer sends mail to a large number of addresses that start with common names (jack@..., jackie@..., jacklyn@..., jackson@..., and so on) in the hope that some of these won't result in a bounce-back message. The ones that don't bounce, of course, are valid addresses that the spammer can add to his list. In the meantime, forcing your server to accept this mail in the first place can seriously slow that server during a dictionary attack, when it might well be faced with thousands of such "tests" an hour.

Fortunately, most modern mail servers have built-in features that allow you to explicitly list the E-mail addresses for which you want to accept mail, and automatically reject mail destined for other addresses (for example, Sendmail's "virtusertable" feature).

SPF: Sender Policy Framework

In theory, mail servers should be receiving mail only from local mail clients, and from other mail servers that are "authorized" mail exchangers (MX'es) for their domains. This is how the Internet E-mail system was designed to work, but this intention is not strictly enforced. Knowing this, spammers often take advantage by connecting directly to mail servers to send their spam from dial-up accounts and broadband-connected hosts—hosts that are not listed as "official" mail servers for their domains.

Letting just anyone connect to your mail server generally leads to bad things. If your mail server is poorly configured, it might well agree to deliver mail to anyone from anyone, whether the recipients are local or not. That's called an "open relay," one of the spammers' favorite tools for broadcasting their mailings at your expense. Even if your server is secured against relaying, though, spammers connecting directly to your mail server can use that connection to deliver spam to your local users. Ideally, you should accept mail only from clients and servers that are properly authorized to send your server mail.

Sender Policy Framework (SPF) is an attempt to finally start enforcing this longstanding convention. It works by having administrators add a bit of extra information to the DNS records for their domains, listing the hosts that are authorized to send mail from that domain. When your mail server receives a connection from a client, you can check its IP address against the SPF information in the DNS record for the sender's supposed domain. If the client's IP address is not in that list, it's not an "authorized" mail server for that domain, and should therefore be refused a connection. If there's no SPF information in the domain's DNS record, however, no conclusion can be drawn.

Before SPF will be effective, it needs to be adopted on a reasonably large scale. Administrators need to add SPF information to their DNS records, and mail server software needs to be updated to incorporate SPF support. On the other hand, AOL has been testing SPF, and has plans to implement this technique in 2004. When that happens, AOL will reserve the right to refuse E-mail from sites that don't have SPF records, and that may well be the incentive that administrators across the Internet need to get onboard, given the sheer number of AOL subscribers.

And That's It for Envelope Testing

So now you're familiar with the many hazards that lurk in the average user's E-mail inbox, as well as the technique of the "envelope test," where a number of quick checks can help to cut down the amount of spam your mail server bothers to process. These techniques alone can save a significant amount of bandwidth and CPU cycles—not to mention user and administrator sanity—in the battle against spam. As this series continues, you'll learn about more of the tools available when fighting against this mail administrator's nemesis, and then we'll get into the meat of the thing: how to put all of this knowledge to use.

© 2024 Pearson Education, Informit. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240