Back in the 1960s there was a time when the demand, "Take me to Havana!" elicited instant grins of recognition. For a while there, the report that yet another airliner had been hijacked (usually to Cuba, although various North African countries had a certain constituency, as well) was so routine that it was barely even front-page news. Eventually, the government started putting armed guards in street clothes aboard U.S. commercial passenger flights--especially those to international destinations. These sky marshalls, as they're known, put thirty to the burgeoning sport of skyjacking and "Take me to Havana!" finally became as quaint and outdated a locution as "Twenty-three skiddoo!" In the Internet world of 1997, we have a serious hijacking problem of our own. It isn't airliners that are being pirated. Instead, it's SMTP servers. And it isn't political radicals who are doing the commandeering. The villains, instead, are spam artists, intent on flooding the Net with yet another solicitation to participate in a pyramid scheme, visit another lame pornographic web site, "fix" your credit or, worst of all, to purchase software that enables you, too, to splatter commercial diarrhea across the Internet (and leave some unsuspecting innocent holding the bag for your misbehavior). Welcome to the Terrordrome! During the first twenty years or so of the Internet, it was a pretty safe assumption that essentially everyone who used it understood the unwritten rules of cooperation by which it ran. One of the most central such rules was, "Bandwidth is precious. Thou shalt not waste it." Another was, "Commercial speech in Usenet is forbidden." And then there was, "Honor thy neighbor's privacy, yea, even as he/she/it honors thine own." Isn't progress wonderful? Three things happened to radically rework the landscape of these Elysian fields. First, and most important, was the evolution of the backbone environment from a single provider--specifically the National Science Foundation's NSFnet--to the present, multiple independent backbone model. NSFnet shut down in May, 1995, after providing 11 years of progressively faster backbone services to the Internet community. With it went the restriction on commercial speech on Usenet and, by convention, the Net in general. That prohibition had been based on the policy that commercial use of a U.S. taxpayer-funded backbone network was forbidden--and, since Usenet was distributed via NSFnet, no commercial speech was permitted there or, by extension, anywhere on the Net. With NSF out of the way and virtually all of the Internet's U.S. backbone services being provided by commercial firms, the legal prohibition against commercial speech on Usenet went the way of the dodo. Although mossbacked Internauts of an earlier generation resisted the change, there wasn't much they could do about it from a practical standpoint. The genie was out of the bottle. The second major evolution came with the explosive growth of the World Wide Web. That brought with it an increasing disregard of the injunction about conserving bandwidth. How could it not? Tim Berners-Lee might originally have designed the Web to act as a front end for text-based content, but the arrival of Mosaic for Microsoft Windows and the Macintosh ensured that, as the anointed successor to the venerable Gopher, the Web would be firmly bedded in a bandwidth-hungry graphical environment. And, what the heck, with the proliferation of backbone providers, bandwidth, per se, was no longer quite the precious commodity it had been in 1984, when NSFnet started up over 56K lines. Within less than a year came the last of the three sea changes that have so completely altered the lay of the Internet landscape, as the major online services--especially America Online--opened the floodgates and let their poor, their tired, their clueless masses pour into Netspace. Credulous, impatient, untutored and utterly bereft of meaningful support from their access providers, this mass of newbies jammed Usenet with multiple crossposts, nit-witted pyramid scheme come-ons and generally inappropriate sludge, much of it of the "Which one is the `any' key?" variety. As P. T. Barnum observed, "There's a sucker born every minute-and two to take him." For con artists, the Internet had suddenly become a target-rich environment. Hi, Jack! The Internet spent most of its existence as an academic and research environment. From the very beginning, by far the largest number of registered domains were in the .EDU namespace. But, by August, 1995, the commercial sector had become the tail that wagged the Internet dog as, for the first time, .COM domains outnumbered those in all the other namespaces combined. This new, commercialized milieu brought with it the scum of the Internet: fast-buck artists, scamsters, commercial pornographers and exploiters of all stripes. The Net was now infested with a menagerie of scoundrels, but at the bottom of the chum bucket there oozed the most loathsome invertebrate of them all--the spammer. Everyone hated them (except AGIS, that is) and the reaction to their spew of unsolicited commercial e-mail was virtually uniform. Each wave brought an instant flood of rage-filled complaints to the perpetrators' service providers, often accompanied by threats of retaliation. Especially in the early days of the plague, action often suited admonition as irritated Internauts struck back at repeat offenders with sustained mail bomb attacks. That situation couldn't be permitted to continue. Mail bombing spammers' ISPs punished the innocent subscribers along with the guilty ones--an intolerable state of affairs for the service providers. In self-defense, ISPs began publishing acceptable use policies and putting teeth into their terms of service. They placed restrictions on the amount of e-mail any one subscriber could send in a day and they instantly cut off service to transgressors. The spam community found itself stymied for all of five seconds by these measures. While AGIS offered aid and comfort to Sanford Wallace's Cyber Promotions and its infamous offspring, the penny-ante operators found a friend in Forrest Dayton's nefarious Stealth Mass Mailer and its repugnant relatives. Both sets of miscreants began to employ the same underhanded tactics to conceal their tracks--forging headers to conceal the true source of their broadcasts and hijacking unprotected SMTP servers to re-mail their bilge. By exploiting the essentially trusting default configuration of third parties' mail servers, they've been able both directly to obscure their actual addresses and to create the appearance that their unwelcome epistles originate with what are actually innocent victims. What the spammers are doing is pretty clearly illegal, and it's a kind of illegality--unjust enrichment, impairment of reputation, theft of services and gross imposition--that violates not only the laws of the United States, but statutes of nearly every country on Earth. So, eventually, mounting civil and criminal cases will catch up with these outlaws and put them out of business, if not behind bars. In the meantime, however, something like a sky marshall corps is needed to prevent the pirates from seizing control of other people's SMTP servers. Like yours, for instance. Any Port 25 in a Storm SMTP servers listen for connection requests on port 25. By default, Unix systems permit a connection to be made to port 25 from any system requesting one. That's the vulnerability at the heart of the spammers' strategy and the single most effective tool to prevent their depredations is to slam that hatch all the way closed. To begin with you should be run sendmail out of inetd. You should install and use smap and smapd from the Trusted Information Systems Firewall Toolkit. And you should also run the smrsh SendMail Restricted Shell to limit the damage that hackers can do, too. It's easy, it's fun and it will greatly enhance your social life. Well, okay, it's only moderately easy and it isn't all that much fun. But it will enhance your social life because it will cut way down on the chances that you will unjustly be accused of spamming or of harboring spammers. Start with the README file for the TIS Firewall Toolkit. It will direct you to read the license agreement and, if you agree to abide by it, (it's not unduly burdensome,) to send an e-mail message with the word "accepted" as its entire content (mind you, be sure not to include your .sig and don't include my quotation marks!) to fwtk-request@tis.com. You'll get an e-mail back within seconds which will reveal the name of the hidden directory on the TIS FTP server within which the Firewall Kit currently resides. As of this writing, Firewall Kit 2.0 is the most current version. There are already a number of mostly tiny patches to the kit (including Marcus Ranum's patches for the respective .c files for both smap and smapd) which you'll want to download along with the 805 kilobyte fwtk-2.0.tar.Z file. Your best bet is to unpack and untar the archive and read all the included documentation before you alter your system. If you're chomping at the bit, you'll find a fairly complete set of installation and configuration information about the kit at http://www.erols.com/avenger, or you can check pages 670-675 in Simson Garfinkel and Gene Spafford's quite wonderful Practical Unix & Internet Security, Second Edition (ISBN 1-56592-148-8, copyright 1996, 1991 O'Reilly & Associates, Inc.) for the quick and dirty essentials. You'll probably want to install other elements of the kit, but smap and smapd are essential. Once you've created the necessary directories and permissions, compiled the smap and smapd binaries and created a non-toxic user for sendmail to run as, you'll also want to get the SendMail Restricted Shell source. (Smrsh allows you to specify those programs that you're willing to let the sendmail user run. It's a great tool for limiting hackers' ability to exploit holes in sendmail to gain root on your mail server.) Smap and smapd allow you to run sendmail from inetd, rather than using send mail's own daemon. Instead of letting sendmail listen for SMTP requests, smap takes over the chore of listening for and receiving incoming mail, leaving sendmail to send mail placed in its queue. Smap can easily be configured to reject connection attempts from an explicit list of hosts, domains or IP address ranges, allowing you to automatically block mail from known spam sites. Also, Craig Hagan has a set of smap hacks designed to block third-party SMTP relaying. He's had a lot of help from various contributors and, while their stuff isn't warrantied, (nor is it supported by TIS,) it's definitely worth a look. The folks who run the Fight Spam on the Internet! site have a bunch of other links for sendmail and other MTA spam blocking measures. Of course, if you're a corporate admin, rather than an ISP, one fairly effective strategy is to set your router to reject port 25 requests from anyone but your ISP's mail server. Most low-end spammers aren't sophisticated enough to research your ISP's mail server address and pretend their request is coming from there. Instead, they'll most likely go elsewhere in search of a suitably unprotected mail server. And, since your ISP will be relaying mail to and from you, your own mail won't get dropped on the floor. Router-based filtering is pretty much a brute-force approach, but it has a certain charm. Most of the MTA-centric filtration methods significantly increase the load on your mail server's CPU. If you're a smaller ISP, that machine is probably already overloaded and doing double or triple duty as a web and/or FTP server. Offloading some of that work to your router can make a good deal of sense, especially if that router isn't laboring under an especially heavy load. The skyjacking epidemic of the 1960s was largely cured by a combination of tough legal sanctions and the creation of the sky marshall program. Nowadays, it's practically unheard-of for a U.S. airliner to be hijacked. If the legal community does its part and enough of us close down port 25 to spammers, maybe we can help bring the mailjacking epidemic to a halt, too. It's worth a shot. (Copyright© 1997 by Thom Stark--all rights reserved) |