Spammers Skirt IP Authentication Attempts

Mailman List Mirror (Read Only)
1

From owner-nanog@merit.edu Wed Sep 8 12:05:02 2004
To: nanog@merit.edu
Subject: Re: Spammers Skirt IP Authentication Attempts
From: Paul Vixie <vixie@vix.com>
Date: 08 Sep 2004 16:59:51 +0000

vgill@vijaygill.com (vijay gill) writes:

> ... That means that if I do get a mail purporting to be from citi from
> randomgibberish, I can junk it without hesitation.

agreed, that is what it means.

however, and this is the important part so everybody please pay attention,
if you can junk something "without hesitation," then spammers will stop
sending that kind of "something." they make their money on clickthroughs,
final sales, and referrals, which translates to one thing and one thing
only: "volume." if the way to keep their volume up means "put SPF metadata
in for the domains they use" or even just "stop forging mail from domains
that have SPF metadata" then that is exactly what they will do. guaranteed.

there's a bet here. you could bet that by closing off this avenue, SPF will
force spammers to use other methods that are more easily detected/filtered,
and that if you play this cat&mouse game long enough, it will drive the cost
of spam so high (or drive the volume benefit so low) that it'll just die out.

I, for one, don't think that SPF is a FUSSP (tm vernon), or anything close to
it.

I _do_ think that it is _a_step_ 'in the right direction'. I'd *love* to
see SPF-type data returned on rDNS queries -- that would practically put
the zombie spam-sending machines out of business.

SPF _can_ serve a 'useful function' in spam-fighting. As follows:

   SPF verification query gets returns one of three kinds of result:
     1) MISMATCH on point-of-origin vs domain 'authorized' senders. *VERY*
  probably spam. Need a white-list check of the specific sender e-mail,
  and if that fails, an SMTP-session rejection is indicated.
     2) MATCH on point-of-origin for domain vs domain 'authorized' senders.
  'reliable' data-point that the domain owner 'authorized' the use
  of the domain-name. Now it makes sense to query an _internally_
  _maintained_ database of 'familiar to me' domains, to see what types
  of prior mail from this domain have been seen. This is a much
  simpler, quicker, less CPU-intensive test than the 'full' set of
  spam checks. Match on 'known spammer' domain causes immediate
  SMTP-time rejection; match on 'known NON-ISP, non-spammer' domain
  and one is quite 'safe' in accepting the message without further
  checks. Messages from 'unfamiliar' domains, and/or 'ISP' domains,
  get the full spam-check treatment.
     3) NO DATA. In this scenario, doing the full set of spam checks, is
  unavoidable. Unless you reject traffic based on the lack of SPF
  data; which is a non-starter strategy, until such time as SPF is
  near-universally deployed.

If _nobody_ published SPF data, then the situation degenerates into case 3),
as a worst-case scenario. This is no worse than the situation _without_ SPF
checking. (For the nit-pickers, yes, it is a _little_ worse, by the overhead
of the 100% no-constructive-date SPF queries.)

If a 'non trivial' share of the incoming message traffic falls into case 1)
and/or case 2), then the use of SPF is a net 'win' for the recipient.

*IF* the time comes when SPF deployment is near-univeral, then case 3) drops
out of the picture. _IN_THAT_CASE_, spammers pretty much _have_ to publish
SPF data for their outgoing mail sources, to have any 'hope' of delivery.
Whereupon, either they're sending from 'known spammer' domains, or the
'unfamiliar domain' handling kicks in.

It aint the (or even 'a') FUSSP, But it is a _big_ win for places that handle
large volumes of e-mail. For those big shops, it doesn't take long for a
spammer domain to get out of the 'unrecognied' category, and into the 'known
spammer' class. Whereupon, one SPF check, plus one internal database dip, and
they can dump the mail as from 'known spammers'. The savings in system
resources, by using such an approach on several _billion_ pieces of mail per
day is definitely non-trivial.

It takes a while for wide-spread acceptance/implementation, but when that
state of affairs _is_ achieved, large-scale spammers have a serious problem:
  Messages claiming to be from sources lacking SPF validation get rejected.
  Messages with SPF-mismatch get bit-bucketed.
  Messages with SPF-validation from identified spammer domains get bit-bucketed

What's an _honest_ spammer to do? <muffled snicker>

2

[ Two replies in one. Last point has operational content. ]

I see that 56trf5.com is a real domain. Does this mean that
the domain name registries and DNS are now being polluted
with piles of garbage entries in the same way that Google
searches have been polluted with tons of pages full of
nothing but search keywords and ads?

Absolutely. As one example out of thousands, there are at
least 350 domains names of the form:

  aaefelb.info
  abbbafd.info
  acdfiaj.info
  aclbkcdc.info
  adkehgi.info
  aeamdgi.info

that have been burned through by one currently-active group of spammers.
Another group has about 16,700 domains (and counting) that I'm aware of.

Note also the relationship betwen this proliferation, the zombies,
and rapidly-updating DNS -- see below.

I _do_ think that it is _a_step_ 'in the right direction'. I'd *love* to
see SPF-type data returned on rDNS queries -- that would practically put
the zombie spam-sending machines out of business.

Not even close, I'm afraid. Yes, it would deal, to some extent, with
direct-to-MX spam from them (*if* all the domain they were forging
cooperated), but:

1. Nothing stops those zombies from sending out spam via the mail
servers on the networks on which they're located. (And in the process,
forging either the address of the former owner of the zombie or another
user on the same network.)

Before you say "but the network operators would detect and fix that"
let me point out that zombie-generated spam has been epidemic for
going on two years and many -- MANY --ISPs have yet to perform basic
network triage that could mitigate much of this very quickly. It's
reaching, I think, to expect that those same ISPs, who by now have grown
quite comfortable sitting on their hands, would do anything about this.

(I recently speculated n Spam-L that I was willing to bet that at
least one such ISP would respond by plugging in more mail servers
in order to alleviate the resulting congestion. Bruce Gingery promptly
pointed out that this is a sucker bet: it's already happened.)

2A. Nothing stops those zombies from embedding spam payloads in
ordinary messages sent by their [putative] users. Mail grandma?
Spam grandma.

2B. Nothing stops those zombies from accepting spam payloads on port
XXXX and writing it directly to disk in the place and format expected
by the end user's mail client. No SMTP. No DNS. And with optional
forged headers "proving" SPF/DomainKeys/etc. validity, just in case
tools for checking those are in use.

3. Spammers have been using rapidly-updating DNS for quite some time
in order to spread out their zombie-hosted web sites. With today's
change they can now extend that up a level: nothing is stopping them
from, say, registering 1000 domains, using 100,000 zombies to host
copies of the content, and using rapidly-updating DNS to distribute
the traffic (as well as making shutting it all down tedious).

And as if that won't be enough fun (and here's the operational bit):

4. This is the point that I think a lot of us tend to overlook: arguably,
SMTP spam from those zombies is the *least* of our problems. Those
systems are under the control of an unknown number of unknown persons, and
can be put to many more uses -- and already have. They've already been
observed hosting spamvertised web sites [1], probing for open proxies,
and participating in DDoS attacks. They represent an enormous computing
resource that's effectively in the hands of The Bad Guys. (To put this
in perspective, compare the estimated size of the zombie farm to the
much-vaunted Google cluster in terms of CPU count, aggregate bandwidth,
and network diversity.)

And as I said previously, none of the three entities who could do anything
about it (the zombies' former owners, consumer broadband ISPs, Microsoft)
are willing to step up, admit there's a problem, and do whatever it takes
to fix it. There is thus no reason at all to expect the problem to decrease;
on the contrary, there is every reason (given the miserable track records
of all concerned) to expect it to increase.

---Rsk

[1] Including some with content of interest to the FTC, DEA, FBI, RIAA,
MPAA, BSA, SPA and other people who have lawyers, guns and/or money.
Makes sense from spammy's point of view: it's free, it's fault-tolerant
and scalable (thanks to rapidly-updating DNS), and maybe someone else
will get clobbered for it.