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

["Tomas L. Byrnes" <tomb () byrneit net>]

Preaching to the choir about RPZ. Me like very much. Yet another great
addition from the ISC.

Still need IP filtering for connections that don't use the DNS at all,
but RPZ is a great add to the arsenal.

I know I'm topposting, it's for brevity's sake. The problem with MS
Exchange servers is that they typically use the MSDNS in the local AD as
their query host, and that often has an odd forwarder of last resort
chain to some hacked proxy on their firewall that may, or may not, use
BIND forwarders. 

I WISH the whole world used BIND (or Nominum). Life would be MUCH
better.

> -----Original Message-----
> From: funsec-bounces () linuxbox org [mailto:funsec-bounces () linuxbox org]
> On Behalf Of Paul Vixie
> Sent: Sunday, April 17, 2011 1:53 PM
> To: funsec () linuxbox org
> Subject: Re: [funsec] Why spam blacklisting isn't going to work
anymore ...
> > 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.

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