IPv6 会帮助垃圾邮件发送者吗？
开发 Web 应用程序的一个重要（主要）部分是使其防滥用，更具体地说是防垃圾邮件发送者。
我刚刚注意到今天的垃圾邮件机器人设法请求表单、填写、提交并重新提交（例如，如果 CMS 在实际获取表单数据之前要求提供更多信息）...所有这些都来自不同的IPv4 地址。
首先，有两个附带问题：
- 他们使用什么技术通过不同的 IP 路由属于同一会话（表单提交）的不同请求，所有这些都在几秒钟内完成？
- 我可以编写一个基于 IP 的哈希值来检查请求表单的 IP 和提交表单的 IP 是否相同；但是：用户（即不是垃圾邮件发送者）可能希望从与请求的 IP 不同的 IP 提交表单，是否有正当理由？
然后，回到这个问题的核心：
由于 IPv6 的地址数量几乎无限，是否会让垃圾邮件发送者更容易让网站管理员和 Web 应用程序开发人员的生活变得悲惨？
也许最终用户都会拥有自己的静态 IPv6，这对我们来说是一件好事，因为我们可以更轻松地阻止机器受到威胁的用户。
或者垃圾邮件发送者可能会继续从不同的角度攻击我们，永远不会两次使用相同的 IPv6...我不太确定它在技术上如何工作，特别是因为我什至不了解它如何与 IPv4 一起工作。
这个问题或多或少是在顶层 IPv4 地址耗尽的那天提出的。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
简而言之，IPv6 可能会让阻止垃圾邮件发送者变得更容易，而不是更困难。
详细说明：虽然 IPv6 允许主机循环浏览几乎无限数量的 RFC 4941 隐私与您的 Web 应用程序建立连接的地址，好消息是其地址的 64 位网络标识符部分可以相当合理地映射到相当静态的订阅者标识符。
另一方面，随着 IPv4 的发展，情况很快就会开始变得相当严峻。随着越来越多的互联网服务提供商开始通过在大规模 NAT 网关后面聚合订阅者来处理 IPv4 地址耗尽问题，您将失去将订阅者视为每个订阅者的 IPv4 地址都有唯一标识符的能力。在某些时候，垃圾邮件发送者会利用这一点来对付您，您的选择将是切断大量通过 NAT 网关（其中有许多受感染主机所在）的无辜 IPv4 用户的网络，或者更好地检测和删除垃圾邮件事后。
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.
好吧，有些用户可能会使用静态 IPv6 地址进行 http 请求；其他人不会。
看一下我发帖的机器主界面上的[一些] IPv6 地址：（
我遗漏了一些其他地址，它们只会造成混淆。）
请注意，除了“链接”之外， ”地址，有一个“公共”地址和一堆“临时”地址（其中大部分已“弃用”）。
“链接”地址只是接口的链接本地地址，用于各种本地管理通信。 （顾名思义，它只能用于与同一“链路”上的其他主机进行通信；不能用于要路由的流量。）
如您所见，接口标识符（右侧 64-该地址的一半）直接基于接口的 MAC 地址。
显示的其他地址恰好来自我的 Sixxs 提供的子网
2001:4830:16c0::/48，但不幸的是，由于存在点已关闭，它们现在无法工作。“公共”地址只是将前缀与与链路本地地址中相同的接口标识符粘贴在一起，并且毫不奇怪（给出名称）这是服务器和长期运行的对等网络的地址节目通常会收听。
但是那些“临时”地址呢？
现在令人费解的是：所有这些其他地址是做什么用的，它们来自哪里？
答案可以在 RFC 4941 - IPv6 中无状态地址自动配置的隐私扩展中找到。您看，事实证明，在您的 IP 地址中永远使用相同的接口标识符使对手很容易“关联看似不相关的活动”（消除了“跟踪 cookie”的需要，并允许将独立收集的数据合并起来）稍后）。
解决方案是使用临时 IPv6 地址进行大多数通信。在任何给定时间，其中之一是“首选”地址，用于新的通信，而其他一些地址是“有效”但不是“首选”，因此当需要切换到时，正在进行的通信不会过度中断。新的“首选”地址。没有地址保持“首选”或“有效”的时间分别超过
TEMP_VALID_LIFETIME或TEMP_PREFERRED_LIFETIME。特别是，第 5 节建立了以下默认值，这些默认值当然是一致的我们在这里看到的：
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:
(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.)
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_LIFETIMEorTEMP_PREFERRED_LIFETIME, respectively.In particular, section 5 establishes the following defaults, which are certainly consistent with what we see here:
由于网络拓扑变化，在填写表格时，IP 地址可能会发生变化，例如笔记本电脑与火车站的 Wi-Fi 服务断开连接并连接到火车上的 Wi-Fi 服务。多宿主主机可以随机地或响应路由协议来改变源地址。
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.
如果您将滥用与掩码与 /64 前缀长度相匹配，即忽略地址的主机部分，则您很有可能阻止来自单个主机的基本攻击。
如果您希望能够应对能够访问更多地址空间（例如 /56 或 /48）的攻击者，那么您也没有理由不能处理这一问题。
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.