search

Simple-Tracker / qBittorrent-ClientBlocker

一款适用于 qBittorrent/Transmission (Beta)/BitComet (Beta, Partial) 的客户端屏蔽器, 默认屏蔽包括但不限于迅雷等客户端. A client blocker compatible with qBittorrent/Transmission (Beta)/BitComet (Beta, Partial) which is prohibited to include but not limited to clients such as Xunlei.
MIT License
934 stars 24 forks source link

自动屏蔽发现吸血后不进行屏蔽 #3

Closed zhongfly closed 7 months ago

zhongfly commented 7 months ago

版本：v2.1 windows amd64 image

如图所示，为了进行测试，去掉了anacrolix/torrent的屏蔽规则。 根据上传进度发现吸血后，仅仅打印了信息，没有屏蔽它的ip

zhongfly commented 7 months ago

另外，debug设置为true时，程序应该也把debug信息也输出到log文件里

Simple-Tracker commented 7 months ago

感谢测试及反馈此 bug!

  1. 未找到确切原因, 只找到可能的编码错误导致此 bug, 将尝试修复并发布新版本;
  2. Debug 大部分是不记录进日志, 属设计行为, 因日志庞大会严重占据存储空间, 部分用户希望看到 Debug 下更详细的信息, 但不希望其记录到日志中. 但出于用户体验及需求考虑, 将在新版本默认统一不记录调试日志但允许设置是否计入;
Simple-Tracker commented 7 months ago

2.2 已发布, 可供测试!

zhongfly commented 7 months ago
  1. Debug 大部分是不记录进日志, 属设计行为, 因日志庞大会严重占据存储空间, 部分用户希望看到 Debug 下更详细的信息, 但不希望其记录到日志中. 但出于用户体验及需求考虑, 将在新版本默认统一不记录调试日志但允许设置是否计入;

绝大部分软件都是会让日志文件尽可能详细，控制台输出尽量少。 控制台不方便搜索，后期查看，而且debug信息频繁刷新压根是看不清的，相当于没有输出。

Simple-Tracker commented 7 months ago
  1. Debug 大部分是不记录进日志, 属设计行为, 因日志庞大会严重占据存储空间, 部分用户希望看到 Debug 下更详细的信息, 但不希望其记录到日志中. 但出于用户体验及需求考虑, 将在新版本默认统一不记录调试日志但允许设置是否计入;

绝大部分软件都是会让日志文件尽可能详细，控制台输出尽量少。 控制台不方便搜索，后期查看，而且debug信息频繁刷新压根是看不清的，相当于没有输出。

调试信息过度详细了, 其每个 Interval 就刷出一堆, 一天下来恐怕都会需要数 MB 甚至数十数百 MB 的存储空间, 一个月达到数 GB 乃至数十 GB 也并非不可能, 而且记录大量日志会带来额外的资源消耗. 且理论来说若是控制台不便于搜索的话, 可以把控制台输出即 STDOUT 重定向或抄送一份到文件的, 这也是另一种方案. 总之, 随着 2.2 版本的推出, 用户可以选择是否记录调试信息进日志, 故此问题算是圆满解决.

zhongfly commented 7 months ago

image 确认有效

另外就是怎么应对这种新的吸血，图中的客户端从昨天到今天，进度一直是5.1%，然后不停的吃上传。在最激进的进度规则下：1%起始进度，1倍率，需要等它吸血到5.1%*1*种子大小后才会封禁它。要是之后有客户端改成一直99.9%进度吸血，又该如何防范呢？没想出可行的办法

Simple-Tracker commented 7 months ago
  1. 结合 blockList 客户端屏蔽列表及 IP 段 (建议使用 qBittorrent 自带 ipfilter.dat 来结合使用) 进行屏蔽, 此方法较为简易可行;
  2. 目前的机制是客户端绝对上传量大于 Peer 报告的绝对百分比计算出的绝对下载 (及一定倍率) 后进行封禁, 技术上来说, 我们可以追踪并存储每个 Torrent 的客户端历史上传量及 Peer 报告的历史进度 (下载量), 并通过比对当前进度和历史进度及客户端当前上传量和客户端历史上传量即进行相对判断而非绝对判断 (已实现未测试);

就点 2 具体而言 (下列客户端均指本机或设定目标 qBittorrent): 若有一个 100MB 的 Torrent. 在上次检测时, 有一个 Peer 报告其进度为 5% (5MB), 客户端上传量为 1MB (1%), 不作封禁, 但该历史数据被记录. 在本次检测时, 有一个 Peer (和上述相同) 报告进度仍为 5% (5MB), 但客户端上传量为 5MB (5%), 则进行封禁. 由于客户端上传量的变化, 本次检测相比上次检测之差, 推断其报告进度应有 4% 变化 (也可考虑一些余量), 但 Peer 实际报告进度只变化了 0%, 故可认为 Peer 是有问题的. 此功能主要可考虑没有变化进度的 Peer, 相对能够更快速检测并封禁相关 Peer.

还需要考虑以下特殊情况, 并列出以下恶意操作方式:

  1. 一个 Peer (以 Peer ID 划分) 有多个 IP 地址, 它们的端口往往相同;
  2. 一个 IP 地址有多个 Peer, 它们的端口往往不同;
  3. 多个 Peer 有多个 IP 地址, 它们的端口可能相同也可能不同;

而恶意操作可采用以下方式: 并发同一个 IP 下的大量端口+随机化 Peer ID+轮换大量 IP 地址+反复打断并重新下载. 解决大量端口的主要方式: 同一个 IP 最多允许出现 X 个端口, 否则直接判定封禁 (已实现未测试); 解决随机化 Peer ID 的主要方式: 以 IP+端口 判定 Peer 而非使用 Peer ID (我相信我们一开始就是这么做的); 解决轮换大量 IP 地址的主要方式: 若短时间内客户端屏蔽数量突然增高, 采取更激进的封禁策略, 如 IPv4 由封禁 /32 变为封禁 /24, IPv6 则同时对整个后缀进行屏蔽 等; 解决反复打断并重新下载的主要方式: 记录所有 IP 与 Torrent Hash 的关联, 并不允许超过一定上传量; 记录所有 IP 的上传量一段时间, 并不允许超过一定上传量 (已实现未测试);

这种检测逻辑下, 客户端屏蔽器需要保存上一条甚至更多条历史记录, 而这会增大一定的内存占用和其它开销, 最重要的是其实现起来较为繁琐, 因此短期内不太可能会实现它. 若是未来这类客户端出现明显恶意趋势 (即: 1. 覆盖更大量 Torrent; 2. 无可能是上游 bug 所导致的; 3. 变更 Peer ID 或 User Agent 导致屏蔽列表失效;), 则可能会考虑加急实现.

若无特殊必要, 建议加回 blockList 屏蔽列表而不是依赖当前 (或未来版本) 的增强自动屏蔽, 增强自动屏蔽可看作是一种 failsafe 去确保即使屏蔽列表无涵盖到的情况下仍能相对减少浪费无用上传并提供给真正有需要的用户, 可同时开启, 但由于各种原因其必然存在一定误判率, 这也是其为什么默认关闭的一个原因, 若仍要开启仍推荐多种方式组合使用以取得最佳效果, 另通过调整 banTime 屏蔽时间, 可使屏蔽后客户端的解封周期更长, 进而进一步缓解此问题.

最后: 当然欢迎有能力的贡献者通过提交 Pull Request 的方式为此功能/想法添加支持!

zhongfly commented 7 months ago

我觉得重点还是应该在于虚假进度：上传量的变化超过进度的变化量（比对当前进度和历史进度及客户端当前上传量和客户端历史上传量）

对于这个，我觉得目前已经可以实现，我看代码里已经可以记录每个peer的上传量，可以把这个数据扩展成保存正下载种子的hash以及对应的进度和上传量。 每次检查时，新建一个数据记录对象。查找peer是否上一次有相同种子的记录，若有，计算与上一次的差值，判断（上传量变化值/种子大小-进度变化）是否小于预设的误差限制值（负值时说明peer还从其他人获得上传，也是正常的）。无论上次是否存在，将这次的数据写入这次新建的数据记录对象。所有的种子检查完后，删除上一次的记录。

Simple-Tracker commented 7 months ago

我觉得重点还是应该在于虚假进度：上传量的变化超过进度的变化量（比对当前进度和历史进度及客户端当前上传量和客户端历史上传量）

对于这个，我觉得目前已经可以实现，我看代码里已经可以记录每个peer的上传量，可以把这个数据扩展成保存正下载种子的hash以及对应的进度和上传量。 每次检查时，新建一个数据记录对象。查找peer是否上一次有相同种子的记录，若有，计算与上一次的差值，判断（上传量变化值/种子大小-进度变化）是否小于预设的误差限制值（负值时说明peer还从其他人获得上传，也是正常的）。无论上次是否存在，将这次的数据写入这次新建的数据记录对象。所有的种子检查完后，删除上一次的记录。

2.4p10 支持设置 BanByRelativeProgressUploaded 及其相关参数, 以指定间隔确定上一周期及当前周期, 并比对客户端对 Peer 相对上传增量, 若超出指定增量, 则认为 IP 是有问题的并自动封禁. 若编码无误实现有效, 相信应可解决此问题, 对其它部分恶意操作方式也有纳入考虑.