Banners and Internet Protocols

You may already be vulnerable

By Bruce Schneier
Dr. Dobb's Journal
November 2001

It used to be that when you connected to one of Counterpane's mailers, it responded with a standard SMTP banner that read something like the following:

220 counterpane.com ESMTP Sendmail 8.8.88. 7.5; Mon, 7 May 2001 21:13:35 0600 (MDT

Because this information includes a Sendmail version number, some people sent us mail that read (loosely interpreted): "Heh, heh, heh. Bruce's company runs a stupid Sendmail!"

Until recently, our IT staffs standard response was to smile and say, "Yes, that certainly is what the banner says," leaving the original respondent to wonder why we didn't care. (There are a bunch of reasons we don't care, and explaining them would take both the amusement and security out of it all.)

However, we were getting a bit tired of the whole thing. Companies run penetration tests against us on a regular basis, and more often than not they complained that every one of our publicly available SMTP servers had the same stupid version of Sendmail on it.

Then, we got the results of a vulnerability scanner run against our Sentry, a network monitoring device our company provides. The scanner complained that:

The Sentry's SMTP service produced a banner,

SMTP banners usually contain version information.

Hence, there was a potential security vulnerability. The banner in question was:

220 natasha ESMTP Sentry

As you can see, this banner does not contain any version information. The scanner blindly alerts every time an SMTP server returns a banner. This is the equivalent of those envelopes that say "You May Already Have Won!" in big red letters on the outside. You might have a vulnerability. Probably not; but you never know, you're telling people something and they might be able to get information out of it.

Unfortunately, RFC 821 requires an SMTP server to return a banner. The original RFC calls for a banner that starts with "220" and the official name of the machine; the rest of the banner is up to the user. It's traditional for servers that support ESMTP to mention this in their banner. Now, many RFCs are more honored in the breach than in the observance, but in pure practical terms, if your SMTP server doesn't say something that starts with 220, it won't work- no banner, no mail.

What this means is that it is impossible to avoid setting off the vulnerability scanner. It is, however, possible to avoid giving out useful information. There are lots of approaches to this:

The strong, silent type that our second example almost achieves (220 hostname ESMTP).

The deceptive type, which our first example achieves (giving out a banner that implies vulnerabilities you don't have-- for maximum amusement value, pick one from ancient times).

The confusing type, where you give out a different banner every time (some hosts do really funny versions of this).

However, none of these approaches solve the basic problem of getting people to stop complaining, and the complainers are a bigger problem for us than the attackers.

Attackers will figure out what SMTP server is running, regardless of its banner. They can simply try all the vulnerabilities. Therefore, you get rid of attackers by getting rid of vulnerabilities. Since a lot of attackers are just running scripts, you can reduce the annoyance value by running a banner that doesn't match the script, but almost any approach will achieve that.

The human beings who complain, however, are unwilling to beat on your SMTP server to figure out what it is. Deceptive banners fool them reliably, wasting precious time dealing with them. Empty banners don't get rid of them reliably. Consequently, we have moved to the amusing defense and our new banners read:

220 This ESMTP banner intentionally left blank.

Scanners will still go off, but pretty much anybody can tell that this doesn't contain useful information.

Of course, this isn't RFC compliant, unless you name your host "This." We would worry about this more if we hadn't already been running a single host under multiple IP addresses, each with a different name attached, each with exactly the same banner- hostname and all. Nothing ever complained that the name in the banner didn't match the hostname. No penetration test ever even noticed that all these supposedly different machines were the same- even when they complained about the informative banner that told them that. We figure "This" will do us just as well as a name. (You could put the hostname after the 220 if you feel compliant, or use a mail system that cares.)

This is all amusing and reduces complaint letters, but it doesn't do a thing for scanners. And it isn't just SMTP that the scanners complain about. They complain about SSH (it has a banner too, which is equally required) and about our mail server accepting EXPN (it doesn't return an error; it doesn't return any information, either, but you have to look at the output to tell that). They often complain that the Sentry accepts EXPN, even though it doesn't respond to the command. All in all, the scanner output is all too much like mail-the important bills are in danger of being buried by the junk mail.

earlier essay: Protecting Privacy and Liberty
later essay: The Case for Outsourcing Security
categories: Computer and Information Security
back to Essays and Op Eds

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..