Will IPv6 help form-spammers?

Question

A large (the major) part of developing a web application is to make it abuse-proof, more specifically spammer-proof.

I've just noticed that today's spambots manage to request a form, fill it in, submit it, and re-submit it (e.g. in case the CMS asks for more information before actually taking in the form data)... all from different IPv4 addresses.

First, two side questions:

• What techniques do they use to route different requests belonging to the same session (form submission) via different IPs, all within seconds?
• I could code a IP-based hash to check that the IP requesting the form and the one submitting it are the same; but: is there a legitimate reason why a user (i.e. not a spammer) might want to submit the form from a different IP than the one that requested it?

Then, to the meat of this question:

With its practically limitless number of addresses, will IPv6 make it easier for spammers to make webmasters' and web application developers' lives miserable?

Maybe end users will all have their own, static IPv6, which is a good thing for us because we can more easily block users whose machines are compromised.

Or spammers could continue to attack us from different angles, never using the same IPv6 twice... I am not too sure how it would work technically, especially since I don't even understand how it works with IPv4.

Question asked more or less on the day when IPv4 addresses are exhausted at the top level.

Rivalry

The purpose of this question is to make sure that the web application I just started to develop is ready for ipv6-spam while also dealing with IPv4 spam. – Rivalry

Answer 1

The short answer is that IPv6 probably makes stopping spammers easier, not more difficult.

To elaborate: while IPv6 allows hosts to cycle through a virtually unlimited number of RFC 4941 privacy addresses from which to make connections to your web application, the good news is that the 64-bit network identifier part of their addresses can pretty reasonably be mapped to a fairly static subscriber identifier.

Going forward with IPv4 on the other hand, the situation will soon start looking pretty grim. As more Internet service providers start dealing with IPv4 address exhaustion by aggregating subscribers behind large-scale NAT gateways, you're going to lose the ability to treat subscribers as if they each have a unique identifier in their IPv4 address. At some point, spammers will use this to their advantage against you, and your choice will be to cut off vast tracts of innocent IPv4 users coming through NAT gateways where a lot of compromised hosts are located, or to get better about detecting and removing spam after the fact.

Defamatory

Answer 2

Well, some users will probably use static IPv6 addresses for http requests; others won't.

Take a look at [some of] the IPv6 addresses on the main interface for the machine I'm posting from:

C:\>netsh interface ipv6 show address interface=4 level=normal
Querying active state...


Interface 4: Local Area Connection

Addr Type  DAD State  Valid Life   Pref. Life   Address
---------  ---------- ------------ ------------ -----------------------------
[...]
Temporary  Preferred     23h59m47s     3h59m47s 2001:4830:16c0:0:f51c:8f47:26ff:596b
Temporary  Deprecated    23h59m47s           0s 2001:4830:16c0:0:8d09:1a8:6039:548b
Temporary  Deprecated    23h59m47s           0s 2001:4830:16c0:0:954b:fd2d:6528:a6b2
Temporary  Deprecated    23h59m47s           0s 2001:4830:16c0:0:4c27:9415:e1cc:5a5a
Temporary  Deprecated    23h59m47s           0s 2001:4830:16c0:0:951f:b93:b21e:1d97
Temporary  Deprecated    23h59m47s           0s 2001:4830:16c0:0:59c3:d575:189e:4fbb
Temporary  Deprecated     6h32m45s           0s 2001:4830:16c0:0:f838:1133:38d0:894c
Public     Preferred     23h59m47s     3h59m47s 2001:4830:16c0:0:20b:dbff:fe26:9fc5
Link       Preferred      infinite     infinite fe80::20b:dbff:fe26:9fc5
No entries were found.

(I've left out some other addresses that would only serve to confuse.)

Notice that, in addition to the "Link" address, there is a "Public" address and a bunch of a "Temporary" addresses (most of which are "Deprecated").

The "Link" address is just the link-local address of the interface, which is used for various local administrative chatter. (As the name implies, it can only be used to communicate with other hosts on the same "link"; it can't be used in traffic that is to be routed.)

naesten@hydrogen:~% ipv6calc -i fe80::20b:dbff:fe26:9fc5 2>/dev/null
Address type: unicast, link-local
Registry for address: reserved
Interface identifier: 020b:dbff:fe26:9fc5
EUI-48/MAC address: 00:0b:db:26:9f:c5
MAC is a global unique one
MAC is an unicast one
OUI is: Dell ESG PCBA Test

As you can see, the interface identifier (right 64-bit half) of this address is directly based on the MAC address of the interface.

The other addresses shown happen to be from my sixxs-provided subnet, 2001:4830:16c0::/48, though unfortunately they aren't working right now because the Point of Presence is down.

The "Public" address just sticks the prefix together with the same interface identifier as in the link-local address, and it should be no surprise (given the name) that this is the address which servers and long-running peer-to-peer programs usually listen on.

But what about those "Temporary" addresses?

Now for the puzzling bit: what are all those other addresses for, and where do they come from?

The answer may be found in RFC 4941 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6. You see, it turns out that using the same interface identifier in your IP addresses forever makes it really easy for adversaries to "correlate seemingly unrelated activity" (obviating the need for "tracking cookies", as well as allowing data collected independently to be combined later on).

The solution is to use temporary IPv6 addresses for most communications. At any given time, one of these is the "preferred" address, which is used for new communications, and some others are "valid" but not "preferred", so that ongoing communication is not unduly disrupted when it comes time to switch to a new "preferred" address. No address remains "preferred" or "valid" for longer than TEMP_VALID_LIFETIME or TEMP_PREFERRED_LIFETIME, respectively.

In particular, section 5 establishes the following defaults, which are certainly consistent with what we see here:

TEMP_VALID_LIFETIME -- Default value: 1 week.  Users should be able
to override the default value.

TEMP_PREFERRED_LIFETIME -- Default value: 1 day.  Users should be
able to override the default value.

Codify

Answer 3

IP addresses may change whilst the form is being completed due to network topology changes, for example a laptop being disconnected from a railway station's wi-fi service and connected to an on-train wi-fi service. A multi-homed host may change source address randomly or in response to routing protocols.

Hartsell

Answer 4

If you match abuses with a mask against a /64 prefix length, i.e. ignoring the host portion of the address, you have a pretty good chance of having thwarted basic attacks from a single host.

And if you want to be able to handle attackers with access to even more address space (e.g. a /56 or /48) then there’s no reason why you can’t handle that too.

Cytoplasm