Re: BGP blackholing spam [was Spammer Bust]

[Paul A Vixie <paul () vix com>]

> Well I think you hit the nail on the head with this paragraph. Whilst
> Microsoft and the standard sendmail distribution ship with realying on
> by default, 95% of sites will probably relay. If this was changed (yup,
> makes installation harder), 95% of sites wouldn't have relaying on by
> default.

Last time I asked Eric Allman to make non-relay the default, he claimed
that it would do more harm than good since it would be a change from 
previous behaviour and if not configured perfectly would make a Sendmail
upgrade into something that would break previously working config files.
I was sympathetic, BIND has the same problem from time to time.  Maybe I
should ask him again -- depending on how much spam he's received in the
year or so since I last asked him, he may be willing to change his mind.

Microsoft's situation is inverted and they have NO excuse at all.  Could
somebody who hasn't been burned to a crisp by IETF politics please write
a "Mail Relay Requirements" RFC that we can brandish at these vendors?
(Dave Crocker seems like a logical choice for this given his past credits.)

> One of the big problems we found is that if you naively blackhole a route,
> you only stop backtraffic to that destination. Some sites were sending us
> so many SYN opens, that as our SYNACKs never got there, we ended up turning
> a mild source of SPAM into a powerful SYN flood attack. The solution is
> to (a) ensure you are running kernels capable of handling this reasonably
> well,

As it happens, you need this anyway.  There are a lot of SYN-flood generators
out there and there are a lot of sociopathic teenagers (of all ages) willing
to torpedo your mail servers just for fun, with or without a blackhole list.

>        and (b) (more important) ensure that your blackholing router returns
> ICMP unreachable for these nets, not simply swallows the packet. For various
> reasons this is difficult to do with Cisco's without unpleasant things
> like telnet <blackholed address> giving you a logon onto the router. 

I think the access-list that controls telnet is still in force in this case,
so if you're only allowing telnet from your NOC (which seems wise, right?)
then only your NOC will get the IOS prompt when telnetting to a black hole.

The ICMP thing is hard for another reason, which is that modern TCP's ignore
ICMP _even_in_SYN_WAIT_ which seems utterly wrong to me.  (I patched it here
but not everybody has OS source for their mail relays.)  This is another 
possible topic to be covered in a Mail Relay Requirements RFC, perhaps.

> I'll publish the fix when we have it honed. (The unreachable should make the
> kernel drop the record of the half open connection).

Should, but doesn't, unless you have OS kernel source and know how to use it.

> One particular site (something at AT&T worldnet - no compulsion about
> naming them as this was so ridiculous) was sending us one open every
> minute *per mail message queued* (i.e. they were running with -q1m). This
> is seriously clueless. We spent the best part of a half a day's engineering
> time trying to get through to a clueful person there. Evenetually we
> got through to the person allegedly running the server who had no idea
> how or why it had been set up like that, but didn't want to change it,
> or disable relaying. So now they are in the appropriate access list deny
> in the relevant border router even for incoming packets. No complaints yet.

The Worldnet people are not stupid.  They've spent a huge amount of time and
money preventing third party relay even though they have nationwide dialup
pools which they lease to other providers, and vice versa.  The only spam I
get via Worldnet's relays comes from Worldnet customers at this point, which
is a heck of a feat, one worthy of succession by, oh, let's say UUNET.