funsec mailing list archives
Re: Why spam blacklisting isn't going to work anymore ...
From: Paul Vixie <vixie () isc org>
Date: Sun, 17 Apr 2011 20:52:58 +0000
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.
Current thread:
- Re: Why spam blacklisting isn't going to work anymore ... Tomas L. Byrnes (Apr 13)
- Re: Why spam blacklisting isn't going to work anymore ... Tomas L. Byrnes (Apr 14)
- Re: Why spam blacklisting isn't going to work anymore ... der Mouse (Apr 14)
- Re: Why spam blacklisting isn't going to work anymore ... Paul Vixie (Apr 15)
- Re: Why spam blacklisting isn't going to work anymore ... Rob, grandpa of Ryan, Trevor, Devon & Hannah (Apr 15)
- Re: Why spam blacklisting isn't going to work anymore ... der Mouse (Apr 16)
- Re: Why spam blacklisting isn't going to work anymore ... Paul Vixie (Apr 17)
- Re: Why spam blacklisting isn't going to work anymore ... Tomas L. Byrnes (Apr 17)
- Re: Why spam blacklisting isn't going to work anymore ... der Mouse (Apr 17)
- Re: Why spam blacklisting isn't going to work anymore ... Paul Vixie (Apr 17)
- Re: Why spam blacklisting isn't going to work anymore ... Larry Seltzer (Apr 17)
- Re: Why spam blacklisting isn't going to work anymore ... Tomas L. Byrnes (Apr 18)
- Re: Why spam blacklisting isn't going to work anymore ... Rich Kulawiec (Apr 19)