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

Phil Mayers p.mayers@imperial.ac.uk
Tue Feb 10 06:36:05 PST 2004


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:

220 foo.bar.com ESMTP Exim 4.20 Tue, 10 Feb 2004 14:11:32 +0000
MAIL FROM:yeah.forged@example.com
250 <yeah.forged@example.com> is syntactically correct
RCPT TO:poor.user@bar.com
250 <poor.user@bar.com> verified
DATA
354 Enter message, ending with "." on a line by itself
Subject: Hey, open the attachment idiot, violate your AUP!
Content-Type: multipart/death

<virus content>

.
<short pause>
550 I'm not taking that, it's riddled...

Perhaps you're not familiar with exiscan:

http://duncanthrax.net/exiscan-acl/

2nd paragraph:

  These facilities are hooked into exim by adding new conditions
  to exim's ACL system. These conditions are designed to be used
  in the acl_smtp_data ACL. It is run when the sending host has
  completed the DATA phase and is waiting for our final response
  to his end-of-data marker. This allows us to reject messages
  containing unwanted content at that stage.

So yes, in actual fact my smarthost knows exactly who to REJECT (not
bounce) the mail to - it rejects it down the SMTP connection that the
message came up. If that end server doesn't know whom to send its
bounce to, that's their problem, not mine.

Add to that the fact that a sensible organisation will have SMTP
authentication mandatory for sending outbound emails, you'll have the
login of the user who sent the mail, right? And thus could bounce
(should you so want to) to their mailbox?

In fact, if you have the login, you've restricted their MAIL FROM to
their email and it's aliases, right, thus eliminating the spoofed from
altogether?

Add to that the fact we're shortly going to block outbound SMTP, I think
we're covered (we can do that, since we have the infrastructure in
place).

> 
> How, specifically, does the smarthost know which where to send the
> rejection message?  Bear in mind that the client who submitted the
> virus to the smarthost has closed the SMTP connection, and may not
> even be reachable at the same IP address.
> 
> In principle the smarthost admin could look in the server log and use
> the message ID to match up the rejection with the IP address of the
> incoming message.  Then they need to match that IP to the human owner,
> which might be possible in some ISPs, but might not be possible on say
> a DHCP LAN.  Then they need to work out the right address for that
> person.  A good admin might be able to do it but I don't think many
> MTAs can.  (Actually, this might make a pretty good product or
> project...)

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).

> 
> Of course if the admin was that smart and proactive then they probably
> wouldn't be relaying viruses in the first place, would they?

Sadly, the above setup is hypothetical - we're moving towards Exim4, not
there yet, but it will work like this (well, probably...).

> 
> > > Aren't you sick of getting these yet (or blocking them)? 
> > 
> > What I'm sick of is explaining to people who really should know better
> > the difference between an SMTP reject and an email nondelivery
> > notification based on spoofed headers.
> 
> 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.

> 
> Generating rejects for known viruses only adds to the problem without
> achieving anything useful.  It is impossible for a rejection or bounce
> to ever get anywhere useful.  

If by rejects you mean "Non-delivery reports"...

You're correct, generating rejects does (I'm sad to say we were doing
this at one point as a result of limitations on our time and an old Exim
filter).

I (and I suspect Karsten) define rejects as 550s at SMTP transport time.

> 
> For known viruses, the only sensible policy is to accept them and
> either drop, sanitize, or quarantine them.  You can pick any one of
> these, depending on whether you think the chance of getting a
> non-virus .EXE is zero or just nearly zero.  But please don't reject
> them.

550. 550. 550 :o)

-- 

Regards,
Phil

+------------------------------------------+
| Phil Mayers                              |
| Network & Infrastructure Group           |
| Information & Communication Technologies |
| Imperial College                         |
+------------------------------------------+



More information about the linux-elitists mailing list