如何唯一标识具有相同外部 IP 地址的用户？有没有办法唯一识别这些用户？

是的，有很多方法：

• 饼干
• Evercookies（JavaScript 代码使用许多不同的技术来存储识别信息，其中包括 Flash cookie、各种 HTML5 存储选项、浏览器访问的链接历史记录等）
• 设备指纹识别：使用 HTTP 标头（主要是用户代理，但其他标头及其顺序也可以提供帮助）
• 使用 JavaScript 进行设备指纹识别：使用 JavaScript，您可以获得很多信息，例如屏幕分辨率、时区、插件、系统字体等。
• 行为：用户填写表单的速度，他们点击按钮的哪个位置等。

但其中大多数在防御暴力攻击方面没有用，因为执行它们的程序可能不会接受 cookie 或运行 JavaScript。

在您的情况下，您可以尝试：

• HTTP 标头：这些实际上可能已经足以区分使用相同 IP 地址的用户（当然，攻击者可以随机切换它们，但我认为目前大多数都不会）。
• 轻度限制：您不必阻止 IP 地址，您可以减慢它们的登录过程。这样，暴力破解变得不那么可行了，但使用相同 IP 地址的真实用户仍然可以登录。
• CAPTCHA：这些会惹恼合法用户，但希望不会有太多用户真正使用发起暴力攻击的 IP 地址（当然，有一些工具可以自动解决 CAPTCHA，但它仍然比没有 CAPTCHA 更难）。
• 您可以要求用户接受 cookie，并在允许登录之前发送各种识别信息（例如屏幕分辨率、时区等）。当然，攻击者也可以做到这一点，但我认为目前任何现有的暴力破解工具都不能做到这一点，因此他们必须编写自定义脚本。但这也可能会惹恼合法用户。

您甚至可以通过使用 HTML5 和WebRTC从 Internet 获取用户的内部 IP 地址。您可以查看文章使用 HTML5 WebRTC 发现本地 IP：安全和隐私风险？欲了解更多信息并在http://net.ipcalf.com/上试用。

提供该文章的网站现在似乎已关闭。但是，我认为这篇文章WebRTC Found Leaking Local IP Adresses也可以提供一些信息。

据我所知，没有一种不可欺骗的方法。如果您已经将最大尝试次数限制为每分钟 8 次尝试，并且超时一分钟。只要您向用户提供足够的信息，一分钟的超时通常不会被认为是烦人的。

确保积极审查这些疑似来自 IP 地址的暴力破解的事件，因为调查谁试图暴力破解您可能会很有趣。

这里提到的大多数其他方法很容易被击败和/或显着降低性能。

这就是 Web 应用程序防火墙 (WAF) 不依赖它们的原因。

2个可靠的方法是：

• 分析 IP 标头中的数据包序列：大多数 TCP/IP 按顺序对数据包进行编号，因此如果编号是随机的，则客户端可能位于 NAT（与其他客户端共享的 Internet 连接）之后。记住以前的数据包 ID 需要一些 RAM 开销，但它与会话 cookie 相当。这更难欺骗，因为攻击者需要在低级别重写数据包，但并非不可能，因此应结合速率限制：允许经过 NAT 的公共 IP 每秒有更多的命中。
• 具有加密身份验证的会话 cookie： 普通会话 cookie 是不够的。它们没有使用 HTTP 加密，即使使用 HTTPS，它们也可能不是 HTTPS 加密有效负载的一部分，因此也没有经过身份验证。http://blog.teamtreehouse.com/how-to-create-totally-secure-cookies正确执行。确保它不仅是加密的，而且是经过身份验证的/“签名的”。 http://spring.io/blog/2014/01/20/exploiting-encrypted-cookies-for-fun-and-profit如果您只能访问 Web 应用程序代码，这是更好的选择。显然，如果 cookie 被禁用，则运行区分浏览器和机器人的客户端 JavaScript（调用屏幕分辨率等机器人不支持的，如果脚本失败则返回机器人状态）。将此与经过身份验证的会话 cookie 的速率限制相结合，或者，如果 cookie 被禁用，则基于 IP 的速率限制（“节流”）或阻塞。这会在 IP/HTTP 解析器的例程中尽早接受/拒绝请求，从而节省未来的 CPU 周期，因为暴力攻击者可能会重试数千次。由于 DHCP/PPPoE/新会话 cookie，禁令应在几分钟后到期。请记住，您应该将 Google 和百度等搜索引擎爬虫的非欺骗 IP 列入白名单。

如果您将解决方案与速率限制相结合，正确的速率限制应该是每页 URL 数量的 1-2 倍。例如，如果 login.php 包含 2 个 CSS 文件、4 个 JavaScript 文件和 10 个图像以及 1 个页面本身，则您必须允许每个客户端会话 cookie 每秒至少有 17 次点击。否则，您可能会阻止/限制正常请求。

对于持续性攻击，您应该要求您的 ISP 阻止/黑洞上游路由。

为什么不使用其他解决方案？

'User-Agent:' 很容易被欺骗：

wget -O index.html --user-agent="My Fake Browser"

会话 cookie、“X-Forwarded-For:”HTTP 标头和其他标头也很容易被窃取/欺骗。Google 'Firesheep' 或 'Cookies Manager+' 或 'Modify Headers plugin' 或 'LiveHeaders plugin' 等以作证明。

单独的速率限制也是不够的，因为隐形攻击会随机化或增加请求之间的等待时间：

wget --limit-rate=10 http://example.com/index.php

蛮力通常不是你唯一的问题。 https://www.owasp.org/index.php/Top_10_2013-Top_10编码和测试有效的保护也需要时间。为了节省您的 Web 服务器上的时间和/或 CPU 周期——如果您有一个服务器场，这将成倍增加浪费——您的 Web 主机应该提供一个为您配置的前端 WAF。这是最好的解决方案——不要在服务器端做。在上游做。