关于旅游期间博客再次被攻击一事

陪她去流浪 桃子 2024年07月01日 编辑 阅读次数：1043

今天周日，我刚结束为期一周的大西北自驾游。 旅途很愉快，不过，出现了一点不美好的小插曲：我的博客服务器再次被坏人攻击了。 这些坏人好像非常熟悉我/非常清楚我的动向一样，偏偏选在我旅游/不方便的时间段。

攻击概述

攻击的方式仍然非常原始且简单——耗尽我的流量：不断地向我的服务器发送垃圾 UDP 数据包。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

root@twofei:~# tcpdump -i any -c 10 host 163.172.135.143
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
18:49:50.909376 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1408
18:49:50.909613 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1493
18:49:50.909849 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1466
18:49:50.910088 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1489
18:49:50.910334 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1437
18:49:50.910587 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1443
18:49:50.910808 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1400
18:49:50.911037 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1487
18:49:50.911282 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1463
18:49:50.911524 eth0 In IP 143-135-172-163.instances.scw.cloud.59610 > 185.186.147.32.netbios-ns: UDP, length 1487
10 packets captured
177 packets received by filter
0 packets dropped by kernel

鉴于当前套餐的流量配额非常有限并且与服务商交涉后得知其也无法阻挡类似攻击后，我暂时关闭了服务器两、三天。 应该是自上次攻击以来停机时间最长的一次。心想，也不是什么重要的网站，也不想影响旅游的心情。

2024-7-3 17:01:34 新的 IP
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

root@twofei:~# tcpdump -i any -nc9  host 209.141.34.4
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
17:00:27.396855 eth0  In  IP 209.141.34.4.33589 > x.x.x.x.36132: UDP, length 1470
17:00:27.397087 eth0  In  IP 209.141.34.4.33589 > x.x.x.x.36132: UDP, length 1495
17:00:27.397362 eth0  In  IP 209.141.34.4.33589 > x.x.x.x.36132: UDP, length 1472
17:00:27.397581 eth0  In  IP 209.141.34.4.33589 > x.x.x.x.36132: UDP, length 1483
17:00:27.397829 eth0  In  IP 209.141.34.4.33589 > x.x.x.x.36132: UDP, length 1450
17:00:27.398059 eth0  In  IP 209.141.34.4.33589 > x.x.x.x.36132: UDP, length 1483
17:00:27.398299 eth0  In  IP 209.141.34.4.33589 > x.x.x.x.36132: UDP, length 1464
17:00:27.398543 eth0  In  IP 209.141.34.4.33589 > x.x.x.x.36132: UDP, length 1496
17:00:27.398783 eth0  In  IP 209.141.34.4.33589 > x.x.x.x.36132: UDP, length 1414
9 packets captured
176 packets received by filter
0 packets dropped by kernel
2024-7-9 09:44:06

换了个无限流量的主机商，把 IP 暴露出去了，喜欢打就打吧，随便你打多久……

2024-7-31 22:23:43

笑死，它停止后我又切换回来到流量有限但是速度更快的机器上了，但是它又开始打了……

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

root@twofei:~# date
Wed Jul 31 10:25:48 PM CST 2024
root@twofei:~# tcpdump -i any -c10  -n  udp
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
22:24:44.172738 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1412
22:24:44.172964 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1475
22:24:44.173198 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1460
22:24:44.173434 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1453
22:24:44.173687 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1409
22:24:44.173910 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1421
22:24:44.174125 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1482
22:24:44.174362 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1450
22:24:44.174594 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1486
22:24:44.174831 eth0  In  IP 209.141.34.4.39260 > 185.201.226.166.31112: UDP, length 1412
10 packets captured
174 packets received by filter
0 packets dropped by kernel

这死妈的玩意儿，祝你明天全家暴毙……开心不？受虐狂。

反制？

我写了个 UDP 程序，向对方的服务器发送了数百 G 的垃圾数据（内容包括再次问候了它家人）。 然后觉得这其实没啥意义，浪费我时间，就停掉了。

我也希望那些攻击我的人，希望你们给我上点强度，这种毫无技术的攻击手段实在是低级趣味，只会让我学会更多新知识。 所以这次我学到了哪些？：

  1. 通过 cloudflare 保护网站
  2. 通过 argo tunnel 暴露内网服务
  3. 促成了我把域名从 DnsPod 搬迁到 cloudflare，懒，拖了几年了

后续

不想折腾了，按照之前 @laixintao 的建议，把主站挂在了 cloudflare 后面，迁移过程非常轻松。

遇到的几个小问题：

  • 无限重定向：Cloudflare 默认采用 灵活/flexible 的方式（即：HTTP，非 HTTPS）与我的服务器连接，而由于我禁用了 HTTP，所以导致无限重定向。 需要将“SSL/TLS 加密模式”修改为“完全”或者“完全（严格）”。
  • 我在本地写文章的时候是通过命令行客户端走 GRPC 发表的，服务器上的 nginx 配置了 grpc_pass（类似于 proxy_pass)，cloudflare 默认没有开启，需要在“网络”里面开启“允许通过 gRPC 连接到您的源服务器”。

第一次 真正意义上使用 #Cloudflare，感觉是个非常成熟的产品，考虑得很全面。

接下来要做的事只有一件：隐藏好我的真实 IP。

致谢

非常感谢二狗在我驾车途中帮助我排查相关问题，以及在我唯一的🪜不可用的时候非常大方地把他私用的🪜分享给我，让我不至于“失联”。

一些截图：

标签：Cloudflare