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. > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of [email protected] > Sent: Wednesday, March 09, 2011 7:06 AM > To: [email protected] > Cc: [email protected] > Subject: Re: [funsec] Why spam blacklisting isn't going to work anymore ... > > On Tue, 08 Mar 2011 13:38:11 PST, "Rob, grandpa of Ryan, Trevor, Devon & > Hannah" said: > > http://www.theregister.co.uk/2011/03/08/ipv6_spam_filtering_headache/ > > What total bozo blocks single IP addresses anyhow? The chances it's a > snowshoe spammer are high enough that if you're going to go that route, > you just block the whole /24 (or more). > > And if you can figure out how to block an IPv4 /24, the additional clue to > figure out how to block an IPv6 /56 or /48 isn't much. And if you can't figure > out how to block a /24, the secret is to keep banging the rocks together... > _______________________________________________ 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.
