靓仔，我们使用的v2rayn的规则集安全吗？ #9874
Replies: 4 comments
|
不想看视频，这里有视频的文字稿。 在上期节目中，我们详细介绍了有关 IP 泄露检测用来识别和追踪、打击代理类犯罪的审查逻辑和权力结构。鉴于 GFW 及其相关组织已经将 IP 泄露作为锁定翻墙用户的可靠技术手段，搞清楚什么情况下会出问题、怎样避免问题，就成了普通用户重点关注的内容。 目前 GFW 工作的重心是管控下沉。核心的“666工程”，代号 YSP（艺术品），这是一个广泛部署的自动化检测管控系统。这个系统受到国安和应急领导的高度重视。领导要求“艺术品”的分析检测能力要不断下沉，要在靠近用户的位置进行分析和处理，越靠近越能有效提升管控能力。生成的海量数据能够共享给其他部门。领导的要求是有针对性而不是普适性，对用户有深度分析，把事后发现转为事前预测，在威胁还没有到来之前就进行预审计，提前预估风险发生的可能。 这套成型于 2021 年的基础管控策略，使得越来越多的 GFW 系统向用户侧逼近，简称“纵深防御”。想要根据用户的态势对未来进行预测，就必须能够有效地建立用户画像。对于翻墙者来说，如何在海量的流量中确定翻墙者变得至关重要。因为只有确定翻墙者，才能帮助系统利用这些种子用户扩线，再将人员聚类进行批量打击。 从目前掌握的情况来看，纵深防御在用户端主要由三部分构成：一、流量意图识别；二、蜜罐服务或应用；三、开源软件投毒。这里的二和三是紧密联合的。我们之前介绍的翻墙专用论坛、恶意一键安装脚本都属于第二类。第三类是从 2024 年开始延续到今天的工作重点。简单来说，就是加入翻墙软件的研发，并进而让其成为 GFW 工作的一部分。 社会工程学领域有个著名的特洛伊木马原理：恶意软件和间谍类似，必须表现得正常、有用、可信，通过这种方式建立掩护身份。以良性行为换取信任累积后，再用极低频率的恶意行为完成目标。这种策略不仅能够让恶意者长期存活，还可以通过温和寄生的方式避免宿主的检测。 对于翻墙来说也是这样。在用户侧检测是否存在违法翻墙，就要让用户安装被植入木马的程序。一种方式是通过行政手段强制用户安装某个应用，比如学习强国或反诈 APP。但很多用户会拒绝安装，转而选择使用开源软件。因为开源软件代码是开放的，任何人都可以进行独立验证和审查。理论上，只要有安全问题都能被社区及时发现。人民卫士就算渗透进开发社区，也对投毒无能为力。开源代码又怎么可能有问题呢？ 其实这是对开源软件不切实际的幻想。人民卫士正是利用群众的偏听偏信，将 GFW 的触角伸入了寻常百姓家。这种方式有个好听的名字叫“供应链攻击”。简单来说，所有软件都不可能仅凭自己实现全部功能。用户使用的 APP 都要依赖其他软件或配置。由于用户或安全检查通常只关注最终的软件，往往忽视了依赖供应链上的其他内容，这就让攻击者有机可乘。他们通过将恶意内容注入张三依赖库，而后李四引用了张三，赵六又将李四和王五两套内容合并。这里的张三、李四、王五、赵六都是供应链，他们的后续还可能有更多的依赖。比如这里赵六合并了多个依赖，他同时还在开源社区拥有较高的知名度。于是张三的恶意代码成功地被赵六放大，送到了更多的终端软件中。用户使用后，张三就可以酌情判断、溯源到人。 生活在大陆、经常有翻墙需求的朋友，对软件的规则设置往往并不陌生。简单来说，规则的目标是通过自己的设置，让某些流量使用代理，另一些流量直连访问。大陆的域名就需要直连访问，海外被 GFW 封禁的域名则需要代理中转。这是个非常合理的需求。比如，机场的套餐通常会标识每月流量限额，机场流量还会有倍率。倍率的存在让相同流量消耗可能被翻几倍。同时，很多大陆朋友在单一设备上访问大陆和海外服务，或是在自己的路由器上部署翻墙服务，让家中的设备都能无缝翻墙。这些都要求代理软件能够判断哪些内容需要用代理，哪些不需要。 中国的域名有很多，GFW 封禁的域名也很多，这些域名还会不断增减。由于规则太多，开始出现专门的开源规则集。这些规则集每天更新、实时推送，绝大部分翻墙用户都会使用。相应的规则也会被各种代理 VPN 工具打包进自己的安装程序。维护规则集是个脏活累活，开源作者往往精力不足。既然精力不足，就需要社区他人的支持。人民卫士就在这种情况下看到了机会。 在所有的规则集中，最为重要的就是直连和代理的规则。生活在大陆的朋友可以简单地将其理解为 CN 或非 CN 规则，非 CN 规则通常写成 !CN，感叹号在编程中表示否定。我们分析了翻墙用户最常使用的规则集。从图中可以发现，Loyalsoldier 的规则集被 v2rayN 和 v2rayNG 使用。MetaCubeX 不仅拥有 Mihomo 规则引擎，还自有多个终端代理开源软件。Clash Meta、Clash Verge、Party、FlClash、OpenClash、Karing 都使用 MetaCubeX 提供的规则。这些软件本身就占据了翻墙应用大量份额，再加上 Mihomo 开源内核被各种机场 VPN 公司集成。毫不客气地说，MetaCubeX 合并 Loyalsoldier 和 ChinaMax 后的规则，在翻墙领域居于统治地位。 一个机场的订阅用户大概率会和三份不同的规则打交道：一是翻墙软件自带的规则集，二是机场主在订阅信息中写入的规则集，三是订阅规则的后续更新，很多更新频率是 24 小时。这就导致规则优先级可能改变，规则的内容可能变化，不同路由的新旧版本还可能出现冲突。而所有这些对于普通用户来说都是静默完成的。很多大陆翻墙用户每天都在关心自己 IP 纯净度和协议特征，殊不知，规则错误导致的特征对 GFW 来说更为明显。 在已知的 GFW 文档中就明确分析了多个 VPN 工具，认为 IPv4 和 IPv6 双栈处理的差异会导致真实 IP 泄露。比如赛风就会在 IPv4 连接失败的时候尝试 IPv6，但这种尝试使用的是本机 IP 而不是代理 IP。TurboVPN 在中科院的测试中则出现默认不代理 IPv6 流量的情况，用户访问 IPv6 站点的时候是直接使用自己的 IP。GFW 使用这种特征用于识别流量穿透。中科院的一名研究员则在自己的文档中记载：TCP 与 UDP 处理的不一致是个非常明显的特征。由于这种不匹配往往会无意中泄露用户真实的 IP 地址，所以可以用来轻易地辨别代理用户。Shadowsocks 在默认状态下工作在 TCP 模式，如果没有显式开启的话会导致 UDP 泄露，而这正是 GFW 乐于看见的。 不仅 GFW 早已利用协议栈的二义性和配置错误来判断用户，很多网站也用这种方式来检测用户。这里面既有银行、金融等高安全需求应用，比如支付宝、微信，又有人民卫士建立的各种蜜罐，比如各种翻墙论坛和黄色网站。那么问题就变成了：广泛应用于用户端的规则集是否已经成了人民卫士渗透的目标？ 我们刚才提到过，MetaCubeX 合并 Loyalsoldier 和 ChinaMax 后的规则在翻墙领域处于统治地位。这套规则集合每日更新，不仅被大量 Mihomo 内核的泛 Clash 客户端使用，还通过格式转换应用于 sing-box。我们首先对其发布的规则进行了校验。校验的核心是找到直连模式与代理模式规则之间的冲突。因为一旦发生冲突，就可能造成用户的真实 IP 泄露。毕竟如果一个域名属于 CN，那么同一个域名就不应该属于非 CN。 MetaCubeX 里的 CN 规则共 11 万条，非 CN 规则两万六千条。其中有 146 个域名后缀同时存在于 CN 和非 CN 中。同时有 214 条非 CN 会被 CN 后缀匹配，又有 241 条 CN 规则会被某些非 CN 匹配。双向共有 309 个域名互相交叠。有些域名的匹配非常宽泛，导致非 CN 后缀被更宽泛的 CN 后缀吞噬。还有 95 个额外的 CN 子域名处于非 CN 的父域名之下。我们发现 MetaCubeX 不仅合并其他规则源，还对规则进行了错误的二次转换。比如用“+.cn”来匹配整个“.cn”域名空间，但 google.cn 显然不应该直连访问。“+.ms”并非属于微软，而是 Montserrat 这个国家的顶级域名，但现有规则把它们都送给了微软。 在调查中我们还发现，MetaCubeX 的规则将 18 个成人、盗版站点集成到了直连规则中。无论这些网站是不是可以直连访问，它们都属于中国法律明令禁止的内容。这些站点理论上都应该使用代理访问。一旦用户使用真实 IP 访问诸如 91short、熊猫看片之类的域名，网安部门必然接到高危警报。而对于其中的 5 个加密货币站点，也是监管部门重点关注的内容。直连访问很可能遭受中间人攻击，被锁定非法金融活动的证据。 有人可能会说 MetaCubeX 的成员日理万机，他们只是照抄上游的规则进行整合，所以不应该承担责任。这句话是不正确的。我们将 MetaCubeX 的规则与其上游进行了交叉比对，发现 ChinaMax 有 295 个精确域名和 111904 个后缀域名，而 MetaCubeX 当前的 CN 域名共有 111873 条后缀规则。没有保留任何精确域名规则，并且包含了一个“full:”、上游缺失的合成后缀。这个 full: 前缀是 MetaCubeX 错误实现转换程序引入的问题。工作流首先在精确的 ChinaMax 域名前加上 用户并非对这些问题没有感知。比如我们上期提到的 BrowserLeaks 就既在 CN 列表也在非 CN 列表中。而 MetaCubeX 对如此显而易见的错误采取了回避态度，既不回复也不修复。由此可见，MetaCubeX 不仅无法免责，更有可能已经被人民卫士渗透，成为 GFW 的帮凶。毕竟，那些成人站点很可能都有红色血脉。 那么什么情况下这些规则会导致代理用户的真实 IP 被 GFW 和目标网站发现呢？Mihomo 的官方文档显示，规则是按顺序自上而下匹配的。第一个被匹配了，后面的规则就会跳过。比如我们刚刚说的 BrowserLeaks 就会命中直连规则。但问题在于 HTTP/3 使用的是 UDP，而 UDP 和 TCP 使用的是不同的路由。比如这个规则看起来似乎是安全的，因为非 CN 在 CN 之前。但是 TCP 可能连接成功，假如 UDP 受到阻碍可能会进行回退。而一旦回退，就会进入第二个直连的规则。很多网站可以接收 HTTP/2 和 UDP 传输的 HTTP/3。而如果出现代理回退，那么就会出现单一用户使用两个 IP 访问同一目标网站的情况。一个 Karing 的问题中就提到了 IPv4 和 IPv6 双栈处理的差异。这个问题只是关闭，但并没有得到解决。简单来说是因为 Karing 路径分歧导致 IPv4 和 IPv6 访问同一网站展现出不同行为，形成了对同一站点访问同时使用 IPv4 直连与 IPv6 代理的古怪特征。 我们对 MetaCubeX 的规则错误进行了分析。溯源发现，少量错误是由 MetaCubeX 直接引入的，更多的错误来自于 Loyalsoldier 错误地将 felixonmars 提供的中国 DNS 加速列表作为直连规则导入。那个规则本身是个加速列表，并不代表是否应该属于 CN。换句话说，人民卫士可以选择对这条供应链的任何一个节点投毒。MetaCubeX 作为重要的聚合者，会将投毒放大并发送到多种终端中。 其实，刚刚提到的所有问题都很容易解决。但是 MetaCubeX 对社区报告选择了有意的漠视。那么作为使用这些规则的普通用户，如何才能保证自己的安全呢？答案其实非常简单：就是不要使用规则模式。在单一设备上只使用开启了 TUN 并打开 strict route 的全局模式。专门准备一台设备访问中国大陆服务。 总结一下，目前最大的规则社区 MetaCubeX 的 CN 和非 CN 规则不是互补的地理集合。其中的内容互相重叠，混合了错误的国籍和域名，混淆了地理位置和产品区域。由于存在多个供应链节点，导致任何错误都会向下游传导，正中 GFW 和安全部门的下怀。同时，开发社区对这些非常容易修复的错误采取了漠视态度。在这种情况下，请尽可能不要使用规则模式进行分流。协议栈实现的二义性和配置错误，已经成为人民卫士监控的重点。 好了，本期内容就到这里。感谢订阅。我们下期再见！ |
|
都是人维护的，如果你或ta 觉得不行可以自己动手维护。 |
|
规则无法确保绝对正确，而且有些条目的分类也是可能随时间变化，也不可能做到绝对及时 |
|
真想干你方法多的是，担心这个有什么意思呢 |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
相关问题
有个博主把这份规则集的安全打了个大大的问号
描述你希望的解决方案
我发给你看看【踏雪无痕 | 规则疑云 —— 从IP泄露、翻墙规则谈GFW锁定用户的一种方法https://youtu.be/IaHyaN46A6c】
描述你所考虑的替代方案
下面有视频的逐字稿
No response
我确认已查询历史issues
All reactions