On 12/30/2010 8:10 PM, David F. Skoll wrote:
So assume a spammer has 1,000 botnet nodes, each of which has 2^64 possible
IPv6 addresses. Explain how you can efficiently detect such cycling and block
it.
Well perhaps not efficiently but the RBL has got to step up to the
plate and do some more analysis of IPv6 addresses on received spam
Each IPv6 botnet will be originating from at most a /48 If an RBL gets
3 or 4 spam reports from IPv6 addresses within that /48 then it ought to
just go ahead and blacklist every IP in the /48
Yes I know there will be collateral damage in cases where the ISP is
being overly miserly with it's IPv6. But such ISP's need to get
off the damn can and read RFC 3177.
Perhaps you've heard of "snowshoe spamming"?
This brings up another point with RBLs that is being ignored in
the discussion.
Assume for the sake of argument that under IPv6 this so-called "snowshoe
spamming" becomes very prevalent WITHIN smaller IPv6 blocks like /64's
and /48's.
As we all know most RBL's operate off of honeypot and abandoned
e-mail addresses that are on spammers lists. If under IPv6 an RBL
continues to adhere to the principle that "every IP number is legitimate
until it proves itself bogus" then it is clear that a spammer can
merely rotate through every possible IPv6 address in a small block of
IPv6 and end up with maybe a couple dozen RBL listings WITHIN the
block he is using, that will never be hit again.
Obviously the RBL is not doing anyone a service in that case. I just
cannot see how the RBL's can continue in this manner, they have
absolutely got to introduce some logic into their listings that
starts to consider a minimum allocation and Spam Assassin needs to
do the same thing.
It's far better for the RBL's to just blacklist the entire /48 that
a spamming IPv6 address appears in. Sure that sounds draconian but
that's because your thinking in IPv4 address-scarcity terms. The
RBLs can always offer 3 different query servers, one for /48's, one
for /56's and one for /64s but a /48 is what we need to be shooting for.
I think /48 might be a bit much, but here I mostly agree with you.
I think John's solution is over-engineered and that a /64 or greater
granularity would be perfectly fine.
It will only work when SA matches this logic which is why an RFC is
called for that defines a minimum "contaminated" block of IPv6 -or
at least an agreement between the RBL's and the spamfilters.
If a spammer is rotating though IPv6 numbers then a site running SA
is going to start generating a lot of queries and the logical way to
put a stop to this is for SA to maintain an internal database and
query that first, before querying the RBL servers. If an IP is present
anywhere in a /48 within the internal DB of SA then bang - it's spam.
No need to query an RBL. Conversely if the RBL recieves a spam then
after extracting the IPv6 address from it then bang - the entire /48
is blacklisted that that IP came from. Then if the RBL gets a query for
any IP within that /48 block then bang- it's spam. RFC3177 should be
the guide, here.
Yes, there are a lot more /48's out there but clearly we have a problem
with ISP's who host snowshoe spammers out there. This problem can be
taken care if by the RBL's getting a lot more militant - and if they
see a pattern of /48's from a particular ISP then BL the entire /32
One thing that will help here is that the RIR's have all taken the
initiative to assign very large minimum allocations. It will no longer
be a world where an ISP can go back repeatedly to the RIR and
request small block after small block, of fresh IP numbers to subnet
out to snowshoe spammers. Nowadays the ISP gets a massive /32 and
since there will be so few ISP's who LEGITIMATELY need successive
/32's we will not see the issue as much where a single ISP has
blocks scattered throughout the IP space that it can use to help
conceal showshoers. The RIR's are doing this to
help reduce the DFZ but it has other benefits like this. And the
very large ISP's are coming out of the gate now with far more massive
IPv6 allocations than a /32.
Lastly it is important to keep in mind that EVERY IPv6 address assigned
is going to an org that PAYS A FEE to an RIR. At least now with ARIN
(I don't know about the other RIR's) ARIN is now REGULARLY checking up
on bogus WHOIS entries. I was one of the people who helped push that
though, by the way. Since these ISP's are paying a fee they had to sign
a contract with the RIR that has the usual statements in it that
disallow fraud. Under the IPv6 regime if a spamfighter sees a
correlation on a /32 of a high amount of spam coming from it, and
starts investigating and discovers that the street address/e-mail
address of the ISP that is assigned the /32 is bogus then he can
report the ISP to the RIR and the RIR will sue them for breech of
contract and pull their allocation. That was not possible under the
IPv4 regimen where the legacy allocations had no contract at all that
anyone signed. So this is going to force the ISP's that host snowshoes
to put traceable info into the whois database which will also make it
easier for the RBLs to figure out who the bad guys are.
Ted
Regards,
David.
