阅读视图

发现新文章,点击刷新页面。

又遭大规模 DDoS 攻击 2023 第二版

我就跟你说我招人恨吧!

注:本文于2023年7月20日中午开始撰写,所以请以20日为当前日期阅读。(因为写得太慢导致时间观都错位了)


发现

我跟你讲这次我完全就没发现。

我甚至都不知道攻击是从什么时候开始的。

就是今天中午又发现博客打不开。本以为只是GFW又开始抽风,毕竟眼看就要开大运会了。谁知道等半天甩出来一个纯文字的超时错误……不该是Apache报错吗,怎么一堆文字出来。

登上服务器一看果然是大规模 DDoS 攻击 2023 第二版


处理

随便写了个 Cloudflare 规则糊弄了事。


分析(Part1)

我甚至不知道这次攻击是啥时候开始的。就好像昨天还在回复 挨踢路 – 老狼评论,还在那想办法弄清谷歌索引抽风的问题。仔细一看,什么?!两天前?!?!? 那我昨天干啥去了?

尤其是我刚刚重温完《速水玲香诱拐杀人事件》,中间差一天这事情或许是某种邪恶的阴谋?

z6sJqJk75r7SszezK5ddLbYBdFwiXvXS5PJswqEN

开始重新看 Cloudflare 的汇总信息。

screenshot_on_b85m_by_flameshot_at_2023-07-20_16-11-05

screenshot_on_b85m_by_flameshot_at_2023-07-20_16-11-22

screenshot_on_b85m_by_flameshot_at_2023-07-20_16-11-32

没啥收获。

24小时内流量一直是平的。7天内和30天内虽然有波动,但是有一部分流量是因为《幽灵诡计》发布了Steam版而一大堆人来看我当初转载的那篇幽灵诡计无剧透文字攻略

现在的互联网真是惨,那个攻略的原文因各种原因最终被和谐的一干二净,以至于原作者是谁我都不知道。

看看流量统计。

screenshot_on_b85m_by_flameshot_at_2023-07-20_16-17-01

再看威胁统计。

screenshot_on_b85m_by_flameshot_at_2023-07-20_16-17-31

都没看出啥名堂。

就好像是有多次攻击,也消耗了不少资源,但我也没感觉到的样子。

点点防火墙拦截日志。

screenshot_on_b85m_by_flameshot_at_2023-07-20_13-45-34

这IP是真的有够多,感觉脚本小子不应该能有这么个规模的资源,这莫不是 花钱 找的什么黑产吧?

……

算了还是回归看 access.log 吧。


分析(Part2)

打开 access.log,扑面而来一堆屎。

screenshot_on_b85m_by_flameshot_at_2023-07-20_14-04-49

Yee

screenshot_on_b85m_by_flameshot_at_2023-07-21_00-00-35

这个攻击者脾气还挺大,关键字里一大堆脏话。

看来攻击是从14日就开始了,然后……好像攻击没啥效果,也可能大部分被 Cloudflare 给拦截了还是怎样。正式能造成性能问题的攻击应该是开始于7月18日夜间,而我在回复过老狼的评论之后也一直没有注意过博客,总之一直到刚才我才发现。

总不会是网站都挂了整整一天了才发现吧。

也真是太懒,我都提到过多少次我有个监控工具了但是一直不部署,就有种中国人特有的大病,啥玩意都拖到治不了了才求医似的。


分析(Part3)

然后就是这个攻击者,妥妥的是本站的读者,攻击的目标页面也刚好是《又遭大规模 DDoS 攻击 2023 第一版》,简直就是想要公开挑战。

……谁想理你似的。

但是你模拟攻击前能不能先搞个肉鸡跳板啊,这重庆的IP记录得一清二楚。

这可就有趣了,因为我在现实生活中基本上不认识多少重庆人,网络上认识的重庆人就更少,但唯独这个IP却是知道的:

screenshot_on_b85m_by_flameshot_at_2023-07-20_23-40-22

一看这小屁孩发言……

罢了罢了,以后自然会有其他人教他做人,我才懒得动弹。


结论

黑客这玩意在国内早就完犊子了,乌云网昨天不是刚刚好被关站7年么。

上一次我也说了,就连小学生都在做当黑客攻击五角大楼的白日梦,老奶奶都开始吹牛逼,那黑客就跟股市房市一样,基本上已经完犊子了。

现在这天气热啊,天热就想多喝水,多喝水就总想上厕所,总想上厕所就睡不着觉。

screenshot_on_b85m_by_flameshot_at_2023-07-21_00-53-43

防护规则开了大概12个小时,就已经有一百七十万次已拦截攻击了,是上一次攻击力度的两倍。这是比上一次多花了不少钱吧。

哦对了,那个小屁孩的 IPv6 地址我也有,但没有采取措施的必要。

毕竟,我已经懒到宁可憋尿都不想起床了。

The post 又遭大规模 DDoS 攻击 2023 第二版 first appeared on 石樱灯笼博客.

华为USG防火墙配置NAT映射回流解决内网通过公网映射访问内部服务器

  标题有点绕,问题就是在公网出接口上配置了内网某台服务器的端口映射,内网的普通用户通过内网地址访问正常,但无法通过公网IP进行正常访问,拓扑图如下:

华为USG防火墙配置NAT映射回流解决内网通过公网映射访问内部服务器

  上图以出接口地址100.100.100.100:80映射为192.168.1.11:80为例,实际问题为192.168.1.100与192.168.1.110无法通过100.100.100.100:80进行访问,但通过互联网访问映射端口正常。

问题原因分析

  假设以192.168.1.100通过公网访问192.168.1.11:80的话,这里假设访问的源端口是10000,目标端口是80,主机发起web请求,那么访问目标就是100.100.100.100:80即数据包分析如下:

  192.168.1.100:10000—>100.100.100.100:80

  数据包最终会被路由到防火墙上,防火墙检查访问的目的地址,匹配到它的端口映射策略,将目标地址改为对192.168.1.11的访问,建立起一个针对目标ip地址转换的NAT会话表:

  192.168.1.100:10000—>192.168.1.11:80

  然后数据包到会被转发到192.168.1.11服务器上并会响应192.168.1.100主机的请求,将上述访问的源目ip地址及端口进行倒转,并将数据包交给它的网关处理,拓扑中即为USG防火墙:

  192.168.1.11:80—>192.168.1.100:10000

  网关发现目标ip地址是192.168.1.100,是在路由表中的内网直连地址,就会将数据包直接路由到主机上,主机接收到数据包,检查数据包的源ip和端口是192.168.1.11:80,发现其本身并没有这样一个http会话与之相匹配,就是说主机并没有主动发起对192.168.1.11:80的访问,实际发起的是对100.100.100.100:80的访问,那么主机就会丢弃这个数据包,导致内网用户通过域名或者公网ip地址访问自己的内网服务器不通的现象。

  192.168.1.11:80—>192.168.1.100:10000

  发生上述问题的原因,就是因为网关发现响应数据包的目的ip地址是内网一个可直接路由的地址,就会直接在内网进行路由转发。然而这并不是一个BUG,任何设备只要做了端口映射,都绕不开这个问题,因为TCP/IP协议栈就是这样工作的,有的设备在你做端口映射的时候,偷偷地把端口回流的问题也给你解决了。然而你也不要以为它们帮你做了端口回流,你就认为那些设备是好设备,感觉好高端,那你错了,我很少见企业级设备偷偷地帮你解决这个问题的(不是说没有,一般是应用层网络设备有这个),都是需要你主动去处理解决,这也体现了它们设备高度可定制性及专业性。

问题解决方案

  实际解决这个问题也很简单,即在192.168.1.100:10000访问192.168.1.11:80的时候,不走内网路由,再做一次回流的NAT映射即可。

华为USG防火墙配置NAT映射回流解决内网通过公网映射访问内部服务器

回流NAT映射验证

华为USG防火墙配置NAT映射回流解决内网通过公网映射访问内部服务器

参考:

https://blog.51cto.com/11555417/2288036

http://www.360doc.com/content/18/0419/01/11935121_746788625.shtml

https://blog.csdn.net/weixin_30376509/article/details/97982837?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~all~first_rank_v2~rank_v28-1-97982837.nonecase&utm_term=%E9%98%B2%E7%81%AB%E5%A2%99%E5%81%9A%E5%9B%9E%E6%B5%81%E9%85%8D%E7%BD%AE&spm=1000.2123.3001.4430

❌