GFW大炮被滥用

北大未名

inferior · 2021-03-17

tttt

北大未名
inferior
我之间记得这么搞只会reset发包的机器与境外服务器的连接，看来GFW升级了呀

不知道能不能把windows update和几大学术出版商给墙了值得试试

22021-03-17
天下无贼
@inferior <#131374>

两会期间可能规则比较严格。下个月可能就只会reset连接了。

2021-03-17
NullPointer
这个帖我看过，现在已经找不到了，八成是被 v2ex 删掉了。

不过，文中所述的攻击方式可能不太对。如果 gfw 屏蔽的是域名，那么就不会影响到 cloudflare 的官网。所以它这个攻击方式，我感觉影响到的是 ip，也就是说，还是 reset 那一套。

而且据我所知，dns 污染是比较严重的举措。一般被 dns 污染的网站，都是被长期屏蔽的。要被长期屏蔽的网站，gfw 一般会有人工审查。

不过我也是猜的，我没真正遇到这个攻击。

2021-03-17
Iratsume
都市传说

2021-03-17
北大未名
inferior
@NullPointer <#131385>

为啥说

gfw 屏蔽的是域名，那么就不会影响到 cloudflare 的官网。所以它这个攻击方式，我感觉影响到的是 ip，也就是说，还是 reset 那一套。

Cloudflare是个CDN，ip不可能全给屏蔽了吧，就屏蔽一两个ip对它毫无意义

2021-03-17
NullPointer
@inferior <#131398> gfw 的这种屏蔽显然是自动化操作，并不判断对象是谁。攻击者通过发送敏感词来触发屏蔽。关键是 gfw 屏蔽的是 ip 还是域名。

这个帖子里说：

2 月初该团伙的一个攻击目标便将自己的域名 cname 解析到了 cf 的官网。导致所有中国用户一天无法打开 cf 官网。

我通过搜索找到了这个帖子其中讲到他在不停尝试更换 ip 来躲避攻击。
如果他是域名被屏蔽，那么这个时候更换 ip 是徒劳无用的。而他更换解析目标从而可以缓解攻击来看，实际上 gfw 屏蔽的是解析目标。而且是临时屏蔽。

那 v2ex 这个帖子里所述的攻击方式在我来看应该是不对的。攻击者应该并不需要准备境外服务器，而是用境内的肉鸡给攻击目标发敏感词，就足够了。gfw 看到好多境内客户端往这个 ip 上发敏感词，就阻断了这个 ip 与境内的通信。
当被攻击目标修改了域名指向，比如指向了 cloudflare 的 IP，那么攻击者含有敏感词的请求就会被发到 cloudflare 的 ip 上。变成实质上攻击 cloudflare。
这种攻击的成本是需要一直不停用许多肉鸡发敏感词。一旦停止，gfw 就不再阻断了。

32021-03-17
NullPointer
@Iratsume <#131397> 应该不是都市传说，我在不同的渠道都看到类似的报告了。包括个人站、telegram、twitter、hostloc、以及上面的 v2ex。攻击团队也都是有名有姓的，比如“七色光联盟”、“将军”。

2021-03-17
Iratsume
@NullPointer <#131422> 喔，原来是这样

DNS 污染 / 检测 SNI / 路由黑洞中只有最后一项是对 IP 的，或者是路由黑洞有什么存在的必要吗？中的「基于检测 IP 的 reset」

给将军团队提供一个新方案:

和发送大量明文敏感词类似，之前有人提到用特定 servername 发起 HTTPS 连接也会让客户端与目标 IP 的连接维持中断几分钟。

Oct 3, 2017

e2889e: 这么干是有bug的,嘿嘿嘿 curl https://www.google.com -H "Host: www.apple.com" --resolve 'www.google.com:443:23.218.213.175' --insecure --verbose

e2889e: 我是说,如果是针对sni,那么,大量没有被墙的网站也会被墙

dou4cc: 你可以试试用黑名单里的servername碰瓷，我等你报平安~

SeaHoH: 感觉可以做个脚本来攻击这个系统

dou4cc: 这个系统不会有这种bug的，servername拉黑的话也只针对发起请求的ip，否则那么多扫描器，整个网络不要坏掉了？

这个系统看起来仍然有这种 bug , 从 2017 至今

2021-03-17
Iratsume

SeaHoH: 感觉可以做个脚本来攻击这个系统

SeaHoH: 可惜不敢，肯定被抓……

这个帐是记在那的。

不要老侥幸，运气好不出事，哪一天你出了事那就倒大霉。

2021-03-17
NullPointer
@Iratsume <#131443> sni 检测和敏感词检测可能是一个机制：敏感域名是敏感词，被墙从 sni 里看见就 reset。

同时 reset 的连接数量如果达到一个阈值，就会触发全网 reset。（这样设计应该是为了节省 gfw 的内存。同时连接太多的话，gfw 可以不必拉黑每对连接双方的地址，只拉黑最常出现的那个，就能事半功倍。但应该也是怕误封，所以这个自动封锁都是临时的。）

PS：路由黑洞是丢包，现在墙很少用这个技术了，因为会造成很大负担。

22021-03-17
NullPointer
可以反向利用这个漏洞来进行加速：

从境外很多终端发送含有敏感词的请求到境内的网站上，就可以利用 GFW 将这些网站锁在墙内，让墙外访问不到。例如可以让 CGTN、~~中国政府网~~（有跨境cdn所以此攻击无效）等被 GFW 屏蔽掉。

这也利用了 GFW 的双向屏蔽特性。

42021-03-17
图书馆革命
libgen天堂应该是图书馆的模样。一个阅读诗歌的人要比不读诗歌的人更难被战胜。创造是一种拯救。创造拯救了创造者本身。
https://t.me/vps_xhq/181

利用GFW漏洞进行勒索的恶行正在蔓延

越来越多的信息表明有人正以屏蔽网站为要挟勒索大中型境外华文站点。

攻击者通过向目标网站提交大量包含违禁词的http明文请求、将被墙域名解析到目标网站所用IP等方式触发GFW的封锁机制。

攻击者要求网站以低廉的价格给他们投放广告，如果拒绝则进行上述的栽赃嫁祸。

更为糟糕的是越来越多的人正照猫画虎，当你有一把锤子看什么都像钉子。

那些选择托管于境外呕心沥血成长起来的网站现在要面临新的挑战。

https://t.me/vps_xhq/184

针对 Cloudflare 官网的封锁正在解除，多地用户反馈已可以直连网站

此前一条发表于HostLoc论坛上稍显调侃的内容似乎并非杜撰，而是道出了此次事件的真相。

发帖者声称自己网站遭受利用GFW漏洞进行勒索的攻击，在防御无果的情况下将域名解析到了CF的官网，结果连cloudflare网站一并被墙。

如果是真实的，将印证利用高墙勒索的技术手法行之有效。它的成本是低廉的，造成的损失却是巨大的，而现在没有一个网站是安全的。

52021-03-17
Iratsume
@NullPointer <#131469>

就可以利用 GFW 将这些网站锁在墙内，让墙外访问不到

捉不到 RESET 的

curl -v https://ao3.org --connect-to ::www.gov.cn

or

curl -v http://dw.com --connect-to ::www.gov.cn

中国和中国外的 vps 都正常

curl -v https://ao3.org --connect-to ::fastly.net

and

curl -v http://dw.com --connect-to ::1.1.1.1

仅中国的测试机会收到 RESET

32021-03-17
NullPointer
@Iratsume <#131482> 这超出了我的认知。

以前一般认为封锁是双向的，敏感词从境外往境内传送也会被封锁。

难道现在这个策略更新升级了？不对称了？

2021-03-17
外逃贪官CA
邹韬奋虽然韬光养晦，亦当奋起而争(拜登永不为奴：h.2047.one)
@libgen <#131481> 在境外开设华文网站还想讨GFW欢心的本来就是有问题。

被人用GFW spoofing，就算他丫被加速了。

如果真想在墙外开设华文网站又不被墙，最好的选择是和中共勾兑，上GFW白名单，这样的话，攻击者自己的ip就会被拉清单，被干烂。

2021-03-17
NullPointer
@Iratsume <#131482> 我知道了。境外访问 www.gov.cn 是境外的 cdn 的 ip，我刚才测试了： curl -H "Host: www.google.com" http://223.215.189.172 这就： Connection reset by peer 所以封锁仍然是双向的，从境外往境内传送敏感词也会被封锁。

所以这个方法是可行的，但是 www.gov.cn 有跨境 cdn，在国外访问的是国外镜像，这就没办法了。

42021-03-17
NullPointer
@消极 <#131500> 这种类型的网站主要有：
- 图便宜省事的个人站
- 盗版网站（托管在版权不严的地方）
- 黄
- 赌
- 药（包括毒品和境内管制药）
- 走私/水货跨境电商
42021-03-17

Iratsume

@NullPointer <#131502>

确实。

nali 182.131.26.231 
182.131.26.231 [四川省成都市 电信]

curl https://twitter.com --connect-to ::182.131.26.231 -v

用特定 SNI 是这样的

* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to twitter.com:443 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to twitter.com:443

tshark:

Capturing on 'ens3'
    1 0.000000000 x → 182.131.26.231 TCP 74 34220 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3441818677 TSecr=0 WS=128
    2 0.287222997 182.131.26.231 → x TCP 74 443 → 34220 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 TSval=1088020212 TSecr=3441818677 SACK_PERM=1
    3 0.287304158 x → 182.131.26.231 TCP 66 34220 → 443 [ACK] Seq=1 Ack=1 Win=64240 Len=0 TSval=3441818964 TSecr=1088020212
    4 0.293815959 x → 182.131.26.231 TLSv1 583 Client Hello
    5 1.098692003 x → 182.131.26.231 TCP 583 [TCP Retransmission] 34220 → 443 [PSH, ACK] Seq=1 Ack=1 Win=64240 Len=517 TSval=3441819776 TSecr=1088020212
    6 1.355147840 182.131.26.231 → x TCP 54 443 → 34220 [RST, ACK] Seq=1 Ack=518 Win=4207 Len=0
    7 1.355233191 182.131.26.231 → x TCP 54 443 → 34220 [RST, ACK] Seq=1 Ack=518 Win=4207 Len=0
    8 1.355242867 182.131.26.231 → x TCP 54 443 → 34220 [RST, ACK] Seq=1 Ack=518 Win=4207 Len=0

北大未名
inferior
@NullPointer <#131422>

我认真想了想，那个帖子说的cloudflare官网全中国都上不去，如果是真的，解释可能有很多种，比如SNI被检测了，cloudflare官网解析到的ip即使被屏蔽之后也一直没有变（但这个可能性感觉很小）。我总觉得GFW不会轻易作SNI检查这么蛋疼的事情。。能在上层协议就解决的问题为啥要弄DPI才能解决的方案，难道后者开销更小？

2021-03-18
Iratsume
@inferior <#131601> 这个只是对 IP 的，和 DPI 无关。

cloudflare官网解析到的ip即使被屏蔽之后也一直没有变（但这个可能性感觉很小）

被屏蔽是单方面的，如果不向他们报告（或者媒体发文）也只有中国用户知道。

给某个域名分配的节点 IP 不会变，除非有 toggle DNS - Proxied 开关。

比如 e-hentai.org 从 11 May 2019 到 15 February 2021 的 IP 都是
```
104.20.27.25
104.20.26.25
```
~~精准屏蔽方法+1~~
12021-03-18