Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

该项目的封禁列表是否对大的 IP 段设有定期 review 的机制? #38

Open
MisakaMikoto-35c5 opened this issue Jan 9, 2025 · 4 comments

Comments

@MisakaMikoto-35c5
Copy link

最近无意中发现 multi-dial.txt 文件中有如下几行:

# 2024-10-31 广东广州省网滥用,定向爆破开始
240e:3b0::/28
# 2024-10-31 广东广州省网滥用,定向爆破结束

这个 IP 段实际上为中国电信广东省宽带使用的 IPv6 地址段,因此我开始尝试分析是否真有非常多广东电信的用户在运行这类恶意程序。

通过 BGP.tools 可以获取到 AS4134 下 prefix description 为 CHINANET Guangdong province network 的 IP 段有下面这些,其中可以看到前缀长度等于 /12 IP 段共有 7 个,等于 /13 的共有 6 个,等于 /11 和 /10 的各有一个,说明 v4 地址池相当庞大。

14.16.0.0/12
14.112.0.0/12
14.144.0.0/12
14.208.0.0/12
42.99.0.0/18
58.60.0.0/14
59.32.0.0/13
59.40.0.0/15
59.42.0.0/16
61.140.0.0/14
61.144.0.0/15
61.146.0.0/16
106.108.0.0/15
106.110.0.0/15
106.122.0.0/16
106.123.0.0/16
106.124.0.0/16
106.125.0.0/16
106.126.0.0/16
106.127.0.0/16
113.64.0.0/11
113.96.0.0/12
113.112.0.0/13
116.4.0.0/14
116.16.0.0/12
119.120.0.0/13
119.128.0.0/12
119.144.0.0/14
121.8.0.0/13
121.32.0.0/14
125.88.0.0/13
183.0.0.0/10
202.96.128.0/18
202.103.128.0/18
202.105.0.0/16
203.110.208.0/20
218.13.0.0/16
218.14.0.0/15
219.128.0.0/13
219.136.0.0/15

然后,我基于上面的资料,在 combine/all.txt 中尝试使用 grep 工具匹配头几个数字,然后手工匹配属于广东省电信的 IPv4 段(可能有疏漏),得到了下面一些 IP 地址:

14.117.223.127
14.19.37.53
14.153.174.224
14.155.109.21
61.140.123.149
113.88.10.250
113.88.168.178
113.94.113.38
113.118.114.228
116.7.217.72
125.95.83.176
183.17.238.238
183.11.71.149
183.31.101.84
218.14.180.4
61.141.0.0/17
113.88.221.0/24
113.88.222.0/24
113.89.136.0/23
113.89.156.0/23
113.94.214.0/24
183.17.146.0/23

从这份列表中,可以看到实际上因使用恶意程序而被封锁的 IPv4 地址段在属于整个广东省电信的 IPv4 地址段当中属于非常少一部分。因为目前中国的 ISP 一般都会分配 IPv4 地址,而 IPv6 地址则不一定会分配。基于这些条件,我有下面几个问题:

  1. 是否对大的 IP 段设有定期 review 的机制,来确定一些比较大的 IP 段(IPv4 prefix < /16, IPv6 prefix < /40)中出现恶意下载的几率非常大且没有减少的迹象?
  2. 对于封锁某个省的大量 IP 地址的情况,是否有透明度报告说明情况?
  3. 是否有机制结合该省 IPv4 被封禁的量,来断定是否有必要对该省 IPv6 整段封禁?
@Ghost-chu
Copy link
Contributor

是否对大的 IP 段设有定期 review 的机制,来确定一些比较大的 IP 段(IPv4 prefix < /16, IPv6 prefix < /40)中出现恶意下载的几率非常大且没有减少的迹象?

需要分类别讨论:

  • 对于自动生成的规则,Sparkle BTN 程序会自己维护更新。每次生成规则都是全量更新,因此一段时间内恶意活动低于阈值,就不会包括在新生成的规则中。
  • 对于人工编写的规则(multi-dial.txt),则由我手动不定期维护。通常通过 Sparkle Dashboard 和 SQL 查询完成。不过目前数据量庞大,我已经很久没有清理过旧的 IP 了,我今天跑过一次 SQL 清理查询,但是跑了两个小时都没跑完。

对于封锁某个省的大量 IP 地址的情况,是否有透明度报告说明情况?

目前只有 海南省 和 辽宁省大连市 获得如此殊荣。它们分别有透明度 #24 #31 报告,且你仍然能在 Sparkle Dashboard 中看到它们的身影

是否有机制结合该省 IPv4 被封禁的量,来断定是否有必要对该省 IPv6 整段封禁?

目前只有 IPV6 也被滥用的情况下,才会考虑对 IPV6 段封禁。如果未见 IPV6 网络滥用,通常不对 IPV6 采取措施。用户所在区域 IPV4 遭到滥用但 IPV6 未被滥用的情况下,仍然可以通过 IPV6 网络连接其它人。

@Duck1998
Copy link

对于家庭宽带而言我理解中IPv4的可连通性是远不如IPv6的,但省级封禁个人更希望有详细的说明或者单纯列出分析数据统计结果也好。
另外IPv6应该是普及分配了,如果光猫策略默认是开启的话,主要取决于用户额外购置的路由器是否有默认开启。

@MisakaMikoto-35c5
Copy link
Author

另外IPv6应该是普及分配了,如果光猫策略默认是开启的话,主要取决于用户额外购置的路由器是否有默认开启。

虽然用户环境是一方面,但运营商是否分配,以及分配的地址能否使用也是一个问题。

2024 年 10 月正好是广东电信打击 PCDN 的时间。根据网上的讨论,打击的方式主要是回收公网 IPv4,移入 PCDN 竞技场网段,NAT 类型修改为 NAT4,对 UDP 大包丢包 80%,IPv6 老化时间变为 30 分钟以及 IPv6 不能使用(也有说 IPv6 不能入站的)。

基于上面所说的情况,某些 PCDN 用户可能认为刷下行流量可以避免被封锁,而 PCDN 用户并不集中于一个城市,所以导致那一个月突然间在这个大段下面出现大量恶意客户端。基于这个原因,希望在手工针对大段封禁时可以先观察一下小段封禁的效果。比如 IPv4 从 /24,IPv6 从 /48 开始封锁,观察 1~7 天看一下封锁是否有效果(判断基准可以使用从未观测到的 IPv4 /32 或 IPv6 /60 的增长率)。如果发现没有效果再将 IPv4 的 prefix length -4 变成 /20,IPv6 则 -8 变成 /40,然后继续观察,并且重复此步骤来逐步提升封禁等级。

@Ghost-chu
Copy link
Contributor

另外IPv6应该是普及分配了,如果光猫策略默认是开启的话,主要取决于用户额外购置的路由器是否有默认开启。

虽然用户环境是一方面,但运营商是否分配,以及分配的地址能否使用也是一个问题。

2024 年 10 月正好是广东电信打击 PCDN 的时间。根据网上的讨论,打击的方式主要是回收公网 IPv4,移入 PCDN 竞技场网段,NAT 类型修改为 NAT4,对 UDP 大包丢包 80%,IPv6 老化时间变为 30 分钟以及 IPv6 不能使用(也有说 IPv6 不能入站的)。

基于上面所说的情况,某些 PCDN 用户可能认为刷下行流量可以避免被封锁,而 PCDN 用户并不集中于一个城市,所以导致那一个月突然间在这个大段下面出现大量恶意客户端。基于这个原因,希望在手工针对大段封禁时可以先观察一下小段封禁的效果。比如 IPv4 从 /24,IPv6 从 /48 开始封锁,观察 1~7 天看一下封锁是否有效果(判断基准可以使用从未观测到的 IPv4 /32 或 IPv6 /60 的增长率)。如果发现没有效果再将 IPv4 的 prefix length -4 变成 /20,IPv6 则 -8 变成 /40,然后继续观察,并且重复此步骤来逐步提升封禁等级。

我们是不需要封禁看效果的,Sparkle BTN 收集的数据可以直接看具体分布。
现在已经解封了一批。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants