«

»

Oct 12 2020

遭受十年不遇的 DDoS 攻击

我在网络安全相关行业公司上班的时候都没见过这么大阵势,而这次攻击目标竟然是个人博客。

丧心病狂。

发现

10 月 8 日中午的时候博客还好好的,到晚上的时候打开博客就开始报 502、503、504 错误。我当时还愣了一会,不对啊 Cloudflare 报错也应该报 522 才对,想了一下不对劲,这明显写着 Apache 给的报错页面,这是我服务器上的 Apache2 给的报错啊。但是我的博客服务是用自己写的 DAMP 建的后端啊,跑了一年了从没出错,怎么会在网关这出错?中午还好好的难道 iptables 还能自己崩了不成?或是 php-fpm 内存溢出自爆了?

(回头一想嘴上说要把 DAMP 开源结果都一年了除了源码什么都没上传)

登上服务器一看,php-fpm 占用 CPU 100%,而且 apache log 疯狂的显示有大量的博客根页访问,而且还都是 HTTP 访问。

Screenshot_from_2020-10-08_21-52-35.png

Screenshot_from_2020-10-08_21-52-46.png

处理

到 Cloudflare 上先把 HTTP 的请求拒掉,结果效果不明显,继续检察新日志发现有 200 的 HTTPS 请求。apache 比 php-fpm 消耗的资源要少,所以静态页面都没有受到影响。

Screenshot_from_2020-10-08_22-21-50.png

(所以处理 HTTP 这一步有点多余)

恢复服务最重要,所以先把 Under Attack Mode 打开。这玩意一旦打卡,所有访客第一次访问都要来一遍 hCaptcha 的图像验证码,而任何一个国际网络服务在中国大陆打不开都是件很正常的事情。

Screenshot_from_2020-10-12_20-06-48.png

(我有什么办法,我也很绝望啊)

全局开这玩意根本不是办法,尤其是这玩意不仅伤正常用户,而且会完全杀死善意的 bot (搜索引擎和RSS阅读器)。

于是只能穿越回 2012 年我还在网络安全公司上班的时候研究下当年看到的那些案例,自己手写个防火墙规则解决。

Screenshot_from_2020-10-08_22-27-41.png

配置上规则也就一小会,阻断超过十万次攻击。什么人啊下手这么狠

分析

以前的网络攻击

作为一个曾在某业界排行第二的网络安全相关行业公司工作过的人来讲,以前见到的那些个攻击都不够塞牙缝的。

大多数攻击都需要针对网络环境的特定漏洞才能实现,比如网关路由上的弱密码或弱设定,网站服务器的系统漏洞,或者网站代码的应用漏洞,或者同广播域服务器劫持。这些攻击一般一攻一个准,毕竟带着这些安全隐患就上线,运营一定是个傻逼。你是不是傻逼我不知道,反正我不是。

尤其是最后一个,当时我在公司第二年,新招来的毕业生就有人在办公网络里耍小聪明搞劫持(目的只是抢带宽,毕竟100多号人就15Mb的电信通企业版),刚好撞在我的枪口上,直接找到他部门的负责人给个简单口头警告。“小伙子,毕业都参加工作了,就别搞那些学校里的小把戏了,没用”

那时真的很少有消耗型攻击,毕竟非分布式的攻击被抓是一抓一个准,除非能像百度作业帮或者南山必胜客一样无赖,否则一般组织是不敢玩非分布式 DoS 的。

至于 DDoS ,那个年代上哪找那么多肉鸡去。

现在的网络攻击

各种云,各种物联网,各种智能设备。

看到这些玩意的设计,你们这些破玩意是专门准备好了免费租借给黑客当肉鸡的吧,安全策略一点没有,前门后门大敞大开,甚至连个日志记录都没。

现在简直就是天堂,燃气表,电饭煲,空调,吸顶灯,电子门锁,太多太多根本不配叫做智能设备的破玩意都成了黑客培育肉鸡的温床。只要黑客有需要的时候就可以唤醒他们并对目标进行打击。

轻轻的我走了,
正如我轻轻的来;
我轻轻的招手,
拷走用户的DATA。

悄悄的我走了,
正如我悄悄的来;
我挥一挥衣袖,
把你变成好吃的鸡肉。

有时候我也会提出来要不要在设备上加一些安全措施,公司就会以成本为由鸡鸡歪歪,安全设备十几万一台,安全软件几十万一套,安全人员雇不起。你妈的给数据库设个密码都这么尿鸡,写个iptables就能要你命了是不是!

(活该找不到工作)

前次攻击

其实上个月大概 23 号左右,服务器也遭过攻击,看日志就能看出来。

Screenshot_from_2020-10-12_11-47-44.png

然而那次攻击完全没当回事,就是突然写了几个G的 apache 日志有点烦。简单分析了一下,比较耗资源的攻击和我之前 被 RSS 订阅给攻击了 说的一样,就是疯狂的抓 feed。我看了一下来源,是某个学校的出口 IP,估计也就是个 脚本小子 。现在就没有以前那种给个提示信息就拉倒的动力,针对复杂场景写 .htaccess 实在太累了,直接给他个图片验证码挡住不管了。

这次攻击

抓了个包,能看到明文的请求是有域名的,也就是说这的确就是针对域名且通过了 Cloudflare 默认防护的攻击。

Screenshot_from_2020-10-08_23-09-56.png

Cloudflare 的默认防护策略完全没有用啊。

而且根据 IP 以及 Cloudflare 给出的防护日志来看,攻击者分布于全球各地。

Screenshot_from_2020-10-08_22-12-49.png

看起来应该都是肉鸡,而且每个 IP 也都以多个的 UA 发出过攻击,可以说是设置得非常好的肉鸡。

(溃客的攻击工具都这么完善,反而做正常产品的烂得一逼)

不过在连续攻击了几个小时,在我完成自定义防火墙规则之后,攻击很快就减弱了。感觉有些智能。

Screenshot_from_2020-10-09_11-35-02.png

总结

这回是真的没法溯源攻击者了。

而且这个攻击力度也真的首次平了我的网络安全相关职业生涯想象力,嗯,并没有超出,毕竟我很多年前就看过一模一样的案例,完全不慌。正经的企业用户应该需要买防火墙才能顶住,而且我不清楚现在最高端的防火墙是否能应付得掉这种正常访问方式的 DDoS 攻击。

这也就是幸亏现在有 Cloudflare 这种免费服务可用,不然就这种复杂攻击,仅凭 iptables 根本招架不住。目前个人能想到的办法,可以说没有好用的。

4 comments

Skip to comment form

  1. Mr.Chou
    Google Chrome 83.0.4103.101 Google Chrome 83.0.4103.101 Android 9 Android 9
    Mozilla/5.0 (Linux; Android 9; HWI-AL00) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.101 Mobile Safari/537.36

    这么看来是有闲得蛋疼的“专业人士”盯上了你的博客!

  2. 陈大猫
    Firefox 80.0 Firefox 80.0 Windows 7 Windows 7
    Mozilla/5.0 (Windows NT 6.1; rv:80.0) Gecko/20100101 Firefox/80.0

    攻击者到底什么目的?这么大量的攻击拿去打私服多好,还能挣钱。打你的话,只能提高你技术。

    1. 石樱灯笼
      Firefox 81.0 Firefox 81.0 Ubuntu x64 Ubuntu x64
      Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0

      打私服?黑吃黑早就不流行了啊。
      提高技术?这个哪里提高技术了?

  3. 小宝
    Safari 13.1.1 Safari 13.1.1 Mac OS X  10.15.4 Mac OS X 10.15.4
    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15

    攻击个人网站…… 好无聊啊

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据