Postfix anti-antivirus (was Re: [linux-elitists] procmail recipe for mydoom?)

Martin Pool mbp@samba.org
Tue Feb 10 15:54:48 PST 2004


On 10 Feb 2004, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
> On Tue, Feb 10, 2004 at 06:20:52PM +1100, Martin Pool wrote:
> > On  4 Feb 2004, "Karsten M. Self" <kmself@ix.netcom.com> wrote:
> >
> > > > It does add to the problem. Forged-sender worm hits your server, you
> > > > reject it, thus kicking the client MTA into sending a bounce.
> > >
> > > No.
> > >
> > > Your 55x reject causes:
> > >
> > >   - A virus with a minimal SMTP server to not give a whit.
> > >
> > >   - A smarthosted SMTP server to reject the mail to the sending client.
> > >     Which it, unlike you, can identify.
> >
> > Wow, really?  You have a smarthost so smart that when a client
> > connects to it and forges envelopes and headers, the smarthost can
> > still work out the right address to send the bounce?  I'd like to see
> > that.  That is a hell of a smart host to work out the right address
> > from thin air.
>
> Not especially:

I think you missed the point.  Yes, it's possible for smarthosts to
filter out viruses, and it would be great if more people did that.  I
am glad that yours is safe.  That only leaves a few million to go...

It's also possible to restrict MAIL FROM based on some kind of
authentication mechanism, but I don't think that is very common.  The
great majority of smarthosts just check the sender's IP, then let them
send whatever they want.

> Interesting. We call it the Host Database at our site, and it has
> near-real-time overwatch of all the network (5-minutely import of DHCP
> lease file, 20-minutely import of router ARP tables, I'm working on the
> Radius accounting logs). The whole thing is a Postgres+Zope plus some
> Python SNMP gathering and a bit of infrastructure, and it's not
> particularly clever.
>
> I get pretty reports which tell me when someone changes their NIC.
> Shortly, they'll be sin-binned to a wildcarded DNS which sends them to
> an update CGI, and eventually pushes a block-by-MAC into the routers if
> the fail to comply (e.g. by setting DNS servers manually).

That's very impressive.  Of course it doesn't actually achieve the
functionality Karsten promised, of integrating this into the MTA.  But
I agree that it's theoretically possible.

> > OK, but there is another case you're not considering: sending a reject
> > causes the smarthost to generate a bounce.  That bounce will *always*
> > go to the wrong address.
>
> No, it goes as a 550 at the end of the DATA connection, so by definition
> goes to the right person.

You're talking about filtering mail coming into the smarthost.  That's
fine.  The problem is filtering mail coming into the destination.


    Client ---> Smarthost ---> Destination
                     |
                     |
                     v
                example.com

In this diagram, the Client has a virus infection.  The smarthost is
run by their ISP/company/whatever, and has a pretty dumb admin who has
not put in place the filters you describe, so it just passes viruses.
The destination is us.

This is a pretty common scenario: many viruses can now send through
smarthosts, and many infected home computers are configured to use
smarthosts.  Many smarthosts do not do virus filtering.  I agree that
they should, but the simple fact is that they do not.

So the client sends forged mail containing a virus from
forged@example.com to victim@dest.org.  The smarthost accepts this for
relaying.

Now the smarthost connects to mx.dest.org, and tries to send the mail.
The destination sends 550.  So the smarthost generates a nondelivery
message, and shoots it off to mx.example.com, needlessly annoying
forged@example.com.

Depending on the percentage of mail through smarthosts, this could
double the number of junk messages generated by a particular virus.

What's worse is that these pointless bounce messages are much harder
for forged@example.com to filter out, because they don't contain an
easier identifier like an PE body.

Of course the fault really lies with the client and the smarthost for
being so stupid as to send viruses.  But they're not under our
control.  (By all means flame their postmaster or blacklist them --
that's independant of how the messages are handled.)  What is under
our control is whether to reject or absorb viruses once they get to
Destination.

It is no good to say "people should fix their mailservers".  They
should, but they won't.  People shouldn't run random executables, or
dodgy operating systems.  The fact is they do; we need to deal with it
as it is.

Rejecting them never has any useful effect, but it does cause extra
junk to forged@example.com.  Absorbing them breaks the loop.

> 550. 550. 550 :o)

And (almost) every time, an extra junk message.  Thanks very much.
Why bother putting in so much effort to clever MAC tracking when
you're doubling the amount of junk email?

--
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20040211/2a420a69/attachment.pgp 


More information about the linux-elitists mailing list