See below > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Paul Vixie > Sent: Friday, April 15, 2011 9:49 PM > To: [email protected] > Subject: Re: [funsec] Why spam blacklisting isn't going to work anymore ... > > [email protected] ("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.
