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

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

See below

> -----Original Message-----
> From: funsec-bounces () linuxbox org [mailto:funsec-bounces () linuxbox org]
> On Behalf Of Paul Vixie
> Sent: Friday, April 15, 2011 9:49 PM
> To: funsec () linuxbox org
> Subject: Re: [funsec] Why spam blacklisting isn't going to work
anymore ...
> tomb () byrneit net ("Tomas L. Byrnes") writes:
>
> > The real issue isn't that you can't block an entire CIDR, but that
the
> > current DNSBL query methods compare with the full IP, which means
that
> > caching becomes useless, since the /56 that a given user gets can be
> > cycled through randomly with more than the 2^40 times the current
> > Internet worth of AAAA RRs.
> >
> > Sure, you can have the entire CIDR in your DNSBL, but you can't use
> > that DNSBL, using current methods, effectively, since you have to
> > reverse, query, and wait for each source IP.
> >
> > You need to preload, and use an alternate query method. RFC 3123 is
a
> > good start for such a method. It's part of how we do this in
ThreatSTOP.
> i disagree for three reasons.
>
> first, i suggest that we'll have to blackhole by /64 most of the time
anyway
> since the lower 64 bits of an IP address are assignable by the
malware.  doing
> it on the /56 (or /48) will be an adaptive thing based on density and
can be
> automated.
[Tomas L. Byrnes] 
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. 

> second, we'll be wildcarding this in the authority servers to keep the
zone to
> a manageable size, and using very short DNS TTL's in order that the
recursive
> server's cache won't explode when rapid readdressing occurs.
> (any rdns cache without background expiration will die hard and
often.)
[Tomas L. Byrnes] 
[Tomas L. Byrnes] 
And for your in parens reason, that means most exchange servers using
"connection filtering" using DNSbls will have to stop using them.

> 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.
[Tomas L. Byrnes] 
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".

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.

> i agree for a reason not mentioned yet.  blackholing by source IP
hasn't
> worked for years since so much spam is mixed in with non-spam from
> addresses like the gmail and hotmail and aol servers which for
business
> reasons noone is comfortable blackholing.  the spammers won this round
in
> 2002 or so.
[Tomas L. Byrnes] 
Actually, things like greylisting and RHSbls are still useful in this
case.


> also, the absence of a PTR RR or its presence having a specific
pattern is a
> better input to the filter than the recent reputation of the ip
address.
[Tomas L. Byrnes] 
For SPAM alone, perhaps, but IP reputation has many more uses than just
SPAM, but that's another topic.

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