Joh*_*nal 3 ipv6 web-applications ip-address throttling rate-limiting
我对保护 Web 应用程序免受机器人攻击的背景感兴趣,但我认为它适用于机器人可以通过 IPv6 进行的所有类型的攻击。
在 Web 应用程序中,您希望保护一些页面免受机器人攻击。
它可能是一个登录页面:您希望避免数百万个尝试用户名/密码组合的请求。
它可能是一个注册页面。您不希望在您的网站上创建数千个机器人帐户。
或者您可能不希望立即下载数据库的全部内容。您认为匿名用户每天向您的数据库发出 100 或 200 个请求来获取一些信息是可以接受的,但您不能接受机器人每分钟执行 1000 个请求来下载您提供的所有内容。
或者只是为了统计目的。您正在记录网站上的访问者活动,并且您不希望机器人完全影响您的数据,例如,人为地点击链接数千次,以便其链接到的文章成为您的新闻网站上“最受欢迎的文章” 。
我经常使用基于 IP 地址的节流/速率限制以及 Nginx 速率限制功能来处理此问题:
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/m;
server {
location /sensitiveUrl {
limit_req zone=mylimit;
proxy_pass http://my_upstream;
}
}
Run Code Online (Sandbox Code Playgroud)
但对于 IPv6,我不确定这有多有效。我的意思是,使用 IPv4 相对有效,因为攻击者创建和使用数千个 IP 地址的成本很高,但使用 IPv6 似乎任何人都可以创建数百万个 IP。这要怎么处理呢?我应该对 IPv6 网络而不是地址应用限制吗?如果我这样做的话,实际效果如何?
IPv6 的寻址灵活性非常好,但它确实让事情变得更加困难。我推荐的算法:
/128)。它可能是具有多个用户的网络上的单个用户,并且您希望避免阻止无辜的用户(由于 NAT,这种情况在 IPv4 中经常发生,我们不再重复)x如果同一个内部有多个块/64,则假设整个块/64被污染并阻止所有块。您现在可以从黑名单中删除个别/128记录,因为它们现在已被/64. 这可以防止您的黑名单系统内存/存储溢出。/64. 默认大小是 a /48,但是/56甚至/60(对于 IPv6 来说太小了,但有些 ISP 永远不会知道)会发生。我会按每 4 位进行扩展:如果/64来自同一位的多个 s/60被阻止,则扩展以阻止整个/60. 与/60a 中的多个相同/56。/64单个用户意外阻止 a比某人“意外”阻止整个 a更容易/48。恕我直言,较大的块应该在黑名单上停留更长的时间。/48从一开始就将攻击分散到整体上,从而无法快速触发扩展算法。因此,您可能需要并行多个条件来快速扩展。这种扩展机制的一个例子是:
+---------------+----------------------------------------+-----------+
| | Block when containing >= of these: | Blacklist |
| Prefix length | /128 | /64 | /60 | /56 | /52 | time |
+---------------+--------+-------+-------+-------+-------+-----------+
| /128 | N/A | N/A | N/A | N/A | N/A | 5 min |
| /64 | 5 | N/A | N/A | N/A | N/A | 15 min |
| /60 | 15 | 2 | N/A | N/A | N/A | 30 min |
| /56 | 50 | 4 | 2 | N/A | N/A | 60 min |
| /52 | 75 | 8 | 4 | 2 | N/A | 120 min |
| /48 | 100 | 16 | 8 | 4 | 2 | 240 min |
+---------------+--------+-------+-------+-------+-------+-----------+
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
711 次 |
| 最近记录: |