Re: Exchange Server Virus Scanning

[Alan Amesbury <amesbury () OITSEC UMN EDU>]

Graham Toal wrote:

> There are two distinct routes you can go: the first is Exchange-specific
> software hosted on the server.  Almost certainly proprietary, and almost
> certainly contributing a significant amount of load on your server.  I
> don't know much about that route - apart from when I last looked at
> it, it was *very* expensive.

A product specific to MSExchange may also not work with future versions
of MSExchange, depending on whether or not future versions are fully
backwards-compatible.  It may also serve to further tie you to a
specific product (MSExchange, in this case), rather than leaving it
possible for you to use other products in the future.  These technical
reasons are usually enough for all but the true, die-hard MSExchange
fans to consider other technologies.

[snip - good observations on transparent SMTP filtering]
> Note there are other network topolgies for spam filtering - you
> could put the filter at the edge of your campus, and even have it
> serving more than one on-campus Exchange server from different
> departments.  However if you do this, make sure that there is no
> way for local mail to bypass the filter and go directly to the
> Exchange server - if that happens, should a virus get on to your
> campus some other way, it will propogate internally through your
> Exchange server and not get caught by your spam/virus appliance.

A significant disadvantage to the SMTP proxy approach is that it can't
reject e-mail destined to non-existent users unless the proxy has some
sort of awareness of what your valid usernames actually are.  Solutions
to this problem are usually found in the form of directory services
(e.g., LDAP), databases identifying your users (e.g., an SQL-backend of
some sort), or manual replication of lists of users to the proxy.
That's not to say that an SMTP proxy can't function *without* an
awareness of valid accounts; it's just more likely for it to get clogged
up by mail for non-existent accounts.  (Mail for
"abcdefghijklmno@your.domain" won't bounce at your border.)  Again, it's
not an intractable problem, just one caveat to this sort of architecture.

[snip - good notes on compatibility and remote access and scalability of
developers]
> Just FYI our home-made spam filter uses a combination of spamd
> on OpenBSD to do greylisting (the biggest win of all), SpamAssassin
[snip]

While some very large ISPs and "free e-mail" shops (like Hotmail) don't
like greylisting, I completely agree with your assessment:  It's HUGELY
effective in blocking garbage.  I'm also a big fan of address
verification, a feature available in later versions of Postfix, which
checks that the envelope sender is valid, and rejects or defers messages
for which addresses can't be verified.  Like greylisting, though, its
use should be carefully measured against your mission requirements.

In addition, I'm a pretty big fan of SPF, although I realize its use in
the .edu environment is somewhat more limited.  However, at the very
least your spam-scanning product should be SPF-aware, and weight SPF
data accordingly when trying to classify a message as spam or not.  For
example, if you get a message claiming to be from a gmail.com account
that originated from somewhere other than the hosts gmail.com identifies
as valid senders, I think that raise the suspicion level considerably.

> them.  We do delete viruses on sight and do not report back to
> either the sender or the recipient, to keep the noise and user
> confusion to a minimum.  Reporting viruses to the sender does
> nothing to help whatsoever.  Some commercial systems do this and
> we're reasonably sure it's just an excuse to advertise their
> product.  Do NOT buy a system that does this.

I completely agree with your automated "reply to sender with virus
report" observations.  Since forging SMTP headers and envelope
information is trivial, and any message arriving that contains a virus
is already by definition suspect.  Sending mail to addresses based on
suspect information is ill-advised at best, much less blasting out cheap
advertising at the expense of your customers and (possibly) innocent
victims.  However, I'm not a big fan of silently dropping messages,
either, as this violates the SMTP spec.

I think a better way to handle this sort of thing is to have your AV
software scan messages as they arrive but *before* they get queued
locally.  Messages that pass the scan get queued normally, but those
that fail to pass never get accepted in the first place; a 5xx rejection
is simply handed back to the sending host, which then has the
responsibility of handling that rejection correctly.  This sort of thing
should be possible with reasonably modest hardware and free software.
In particular, clamav+clamsmtpd+Postfix can do this sort of thing very
easily, and very, very well.  Again, this sort of thing probably isn't
suitable for extremely high-volume sites; its use should be weighed
against needs.


--
Alan Amesbury
University of Minnesota