Re: Why spam blacklisting isn't going to work anymore ...

[Paul Vixie <vixie () isc org>]

> Date: Sun, 17 Apr 2011 10:42:31 -0700
> From: "Tomas L. Byrnes" <tomb () byrneit net>
>
> I agree that we'll have to blackhole /64, but doing that with a single
> line preload that's used in an ACL or firewall (IPSET on the mail server
> anyone?) is a lot less work than a query per AAAA. It also gets around
> the entropy issue in the size of the DNSBL. 

this is a technology choice.  my own choice would be RPZ rather than RBL,
since i'd want to poison an IP address no matter what it's used for, and
not limit it to e-mail as we did with the RBL (now called DNSBL).

see <http://www.circleid.com/posts/20100728_taking_back_the_dns/> for more
information about RPZ.

however, my main point here is, this is a technology choice, and RBL (DNSBL)
is completely workable in a /64 wildcard way, so folks who want to do it
that way can do it that way.  we don't need to move this into firewalls;
it can be done in e-mail servers or DNS servers or firewalls.  i think the
market will develop for all three of those approaches plus some others.

> > (any rdns cache without background expiration will die hard and often.)
>
> And for your in parens reason, that means most exchange servers using
> "connection filtering" using DNSbls will have to stop using them.

that's a nonsequitur.  any exchange server who uses a BIND9 recursive name
server will work just fine even with /64 wildcards.  that's because BIND9
does background expiration.  the problem, when felt, will never be in the
mail server (exchange in this case).

> > third, smtp responders already have to do a DNS query per inbound
> > message, there's no new DNS transaction load due to ipv6's new
> > vulnerabilities vs. ipv4.
>
> Sure there is. If a spammer has 64 bits of AAAA to cycle through, they
> can force the targeted host to do a recursive query for each connection,
> as opposed to getting their DNSBl record(s) cached on the first (or
> early, in any event) attempt. The result is, if they can generate
> sufficient volume and IP entropy, that some SPAM will get through due to
> query timeout, which has the same effect to the MTA as "not listed".

ah, i see what you mean here.  there will be more query traffic between
the recursive and authoritative servers in the case you're describing.
i was not interpreting your concern in that way because i do not share
it -- while the malware has control over the bottom 64 address bits, the
cycle time on changing it is "several seconds" which is too long to use
in between outbound spam messages unless one has a large slow-sending
botnet, and is in any case long enough that any resulting increase in
recursive-to-authoritative traffic caused by spam originating from that
malware's /64 network to be statistically insignificant.  if a large
slow-sending botnet uses this trick everywhere at once then the authority
for the RBL (or DNSBL as now called) will indeed be overrunnable but that
is fixable at the provisioning layer.

fundamentally i like the physics of this particular arms race just fine
and i see no reason to move deliberately or urgently away from the RBL
model on the basis of malware-generated host renumbering alone.

> You also have to admit that, with very short TTLs, the recursive query
> load on what is already, for significant parts of the great unwashed, a
> creaking DNS infrastructure, will cause plenty of timeouts, which is the
> same as not being listed.

no i don't (have to admit that), since the infrastructure is not
creaking, and the DNS TTL's i have in mind (short enough to prevent
cache explosions) can still be long enough to prevent authority overruns.
for example, 15 to 45 seconds will probably create a fine working set.

> > i agree for a reason not mentioned yet.  blackholing by source IP
> > hasn't worked for years ...
>
> Actually, things like greylisting and RHSbls are still useful in this
> case.

agreed, but those aren't examples of blackholing by IP source addresses.

> As with so many things in security, the well peered with lots of
> resources will be fine, but unless we find better ways to protect those
> with limited resources who just want to do things, we're going to find
> ourselves like CB Radio, and everyone else will go into the walled
> garden of FRS/GMRS with CSS. 

yes, +1 to this.  information haves and havenots is not a model to pursue.
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.