> Smith wrote:
> > After mulling over the idea of having a virus/spam filter on an MTA, I
> > believe that the best solution is to use an enterprise anti-virus
> > program like Norton Anti-Virus and an email client that supports
> > Bayesian spam filtering. The setup should be where the anti-virus
> > server downloads the latest updates and sends them to each Windows
> > workstation to update their Norton Anti-Virus client. Why?
This is a very dangerous approach to take, relying solely on the
final mail reader's client to correctly handle malicious messages.
Security exposure aside, if your architecture can reject and drop
the most common "empty" virus (worm, etc) email messages as
they arrive at your edge-facing MTA, you reduce the disk storage and
other resources wasted in storing a huge volume of garbage messages.
> > 2. Have the workstations do all the work, not the MTA.
It's a heck of a lot easier to scale-up your MX pool than it is to
upgrade the mail spool and desktop clients with more disk and CPU.
As ray says, "Belt and suspenders".
Use one vendor's AV signature database to scan all inbound
(and outbound) SMTP messages, a different signature database
for the desktop, and perhaps a third product to directly scan the
Exchange message store itself.
If one AV vendor drops the ball and fails to keep their signatures
updated, you still have protection (I had a horribly offensive birth
control analogy here, but thought better of it at the last moment).
> > 4. If spam gets through, have the email client do all the work with
> > Bayesian spam filtering, not your MTA.
Bayesian spam filtering is pretty much the only exception,
it needs to be individualized. All other AV/Antispam (in a
corporate environment) is most effective when centralized.
On 5/10/05, Raymond Lillard <[EMAIL PROTECTED]> wrote:
> I find your reasoning mostly sound, but improvable for three reasons:
>
> 1. Workstations often have Norton disabled, through user ignorance,
> carelessness or automatically by malware. This opens a channel
> for viruses sent by known and (foolishly) trusted corespondents.
>
> 2. Open source virus tools like ClamAV use an independent database
> that is often updated sooner than Norton et.al. and is often
> more comprehensive.
The last time I actually researched the signature release history of
AV vendors (Clam/Trend/McAfee/Symantec(Norton), was a couple
of weeks after Sasser. No one vendor showed a clear lead in
getting "production" signatures out when a new worm hit.
For larger enterprises you will most likely have a corporate contract
with the major vendors, they will often push out a quick-and-dirty
signature within hours of the initial outbreak, long before a final
"production ready" signature is distributed to the general public.
> 3. It is a belt and suspenders world.
> Having two chances of blocking a virus is better than one.
Amen.
> My preferred mail arrangement for small offices (I have built others)
> looks like this:
>
> Unfiltered Internet
> |
> V
> MTA (sendmail/graylisting) RELAY
^^^^Why not add DNSBL here?
> |
> V
> Firewall (tunnel)
> |
> V
> MTA (sendmail/ClamAV) LOCAL_DELIVERY
> |
> V
> Workstations (Norton/virus blocking)
> (Thunderbird/spam filter)
>
> Those Windows users who insist on using Outlook just have
> to eat the remaining spam.
And if you are slightly paranoid, the Internet-facing MTA is a
vetted non-sendmail MTA (Postfix, qmail, etc), the firewall
connection between the publicly visible MTA and the internal
delivery agent is capable of enforcing RFC-compliant SMTP.
And I'm not just saying "use something other than sendmail on the
outermost edge" because I am all too aware of the long history of
remotely exploitable sendmail vulnerabilities, but also because if
you are going to "chain" transports for security, you gain the most
by using different MTAs for the "outside" and the "inside". Otherwise
a script kiddie bearing a "0day sendmail on openBSD on intel" sploit
who compromises your internet-facing ("RELAY" in the diagram)
server won't delay long in using the firewall-evading tunnel to use the
same tool to take over the internal ("LOCAL_DELIVERY") host.
Kevin Kadow
(P.S. And the _truly_ paranoid do not detail the complete range
their security precautions to [EMAIL PROTECTED] Let's just say it involves a
two different processor architectures and a really fast serial link).
