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

Karsten M. Self kmself@ix.netcom.com
Wed Feb 11 00:00:15 PST 2004


on Wed, Feb 11, 2004 at 02:07:22AM +0000, Phil Mayers (p.mayers@imperial.ac.uk) wrote:
> On Wed, Feb 11, 2004 at 12:44:17PM +1100, Martin Pool wrote:
> > 
> > I'm not sure, but I think silent absorption is the only sensible
> > response to some attacks.  How many of you strictly comply with the
> > way IP routing was originally meant to work, and how many have
> > firewalls that just log&drop evil packets?
> 
> Good point, and very analogous here. Sending ICMP rejects in response to
> e.g. a single packet UDP exploit like Slammer, or the one someone will
> write for the ASN.1 bug, is a very silly thing to do indeed *in the
> current climate*.

Packets don't have extensive semantic state, particularly if you're
dropping them in SYN state.  Packet-level transactions are happening in
the engineering level of networking.  Email-level transactions hit
layers 8 - 10[1], and the semantics of an accepted email delivery
_aren't_ something which can be strictly programmed around.

UDP is stateless, and most well-engineered protocols anticipate this.
TCP is stateful, but dropping traffic at the SYN state (which is where
you'd almost certainly be dropping malicious or unwanted traffic)
doesn't generate levels of ambiguity.

Accepting mail for delivery, then dropping it on the floor, if done
improperly (and it will be, at least once), is going to annoy the hell
out of someone.  Possibly someone with stateful significance in your own
transactions, Netly or otherwise.

Don't do that.

SMTP should explicitly reject.

> Having said that, the *reason* it's very silly for packets and not
> necessarily so for SMTP streams is that packets are connectionless.
> However, individual legs of SMTP are connectionless in effect. Hmm.
> Interesting thought... I wonder...

SMTP becomes stateful on a "250 OK".


> So, that's a very effective analogy. Because of the poor abilities and
> lax attitudes of a percentage of network operators, ICMPs are no
> longer sent where they should be. This increases timeouts and reduces
> the reliability of the IP protocol in general, and in particular for
> the otherwise well-behaved network operators.

Yeah, but for the most part you shouldn't be spewing random bits places.

SMTP follows well-advertised MXs.  It's directed traffic.  Most of your
other traffic -- :80, :22, :53, etc. -- should follow well-established
tracks.  The timeouts are only going to be occasional (though having a
working ping when shit breaks is helpful).

Some s'kiddie spewing scans and sploits at arbitrary ports up and down a
/20 is quite another story.  Slowing *that* mofo down is entirely legit.



> The correct solution isn't for all OSes round the world to stop using
> ICMP. It's for the crappy network operators to FIX THEIR NETWORK, and
> stop f***ing up the IP protocol.

The other (main?) reason for dropping a lot of ICMP traffic is to reduce
information leakage from a system.  If I drop rather than reject, it
takes the s'kiddie longer to find out if I'm running a service or not.


Peace.

--------------------
Notes:

1.  Politics through religion, email delivery being a matter of faith.

-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
  Backgrounder on the Caldera/SCO vs. IBM and Linux dispute.
      http://sco.iwethey.org/
-------------- 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/7ea56f23/attachment.pgp 


More information about the linux-elitists mailing list