博客前几天被cc攻击应对过程,及策略整理

上周五下午,我本来在愉快的收尾公司项目,那之后就准备在博客更新了一篇文章,本来都写完了准备发布,上传所缩略图的时候总是失败,我还以为是我网断了,结果刷新一下页面,网站502了,简直有毒。然后我跑去腾讯云看了看,根据cdn暴涨的请求数和流量,我推测是被CC攻击了。
过程信息没有收集了,总之星期六下午的时候,数据是这样。我思来想去也没得罪谁啊,但是网站502了,也没办法,还是要做一些措施。到3月2号攻击停止的时候,共损失了1.7元钱,主要原因是忘记设置一个拦截规则,于是被刷了一晚上流量。
Snap.jpg

第一天的应对过程如下

1.获取真实的访客ip,我听群友的意见,加了如下代码到nginx的配置文件,目的是上服务器可以获取到用户真实ip,而不会误拦截cdn的节点ip(应该是这样吧,不太懂,主要是获取请求头X-Forwarded-For)

proxy_set_header Host $host; 
proxy_set_header X-Real-IP $remote_addr; 
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

2.CCKiller脚本的安装,这是个Linux轻量级CC攻击防御工具,可以去官网看看:点击进入

curl -ko install.sh https://zhang.ge/wp-content/uploads/files/cckiller/install.sh?ver=1.0.7 && sh install.sh -i

开始拦截后,查看日志看拦截有没有成功的,发现已经在正常拦截了,感觉还行。但是问题是,我的服务器是腾讯云配置最低的学生机,就算拦截了大部分,还是阻挡不了它的GG,所以还需要再增强一下。

3.于是我配置了nginx用户访问限制,就算按照博客之前的一篇教程,给网站的配置文件加上了,将用户的线程和频率限制了。

limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=50r/s;
limit_conn conn_limit_per_ip 20;
limit_req zone=req_limit_per_ip burst=20;

这个的话,挂了cdn的在cdn那边肯定都有设置了,如果限制得太死会导致正常用户的访问也受影响。效果很快就出来了,博客可以访问,但是很慢,而且502还是存在。

4.查了一会儿资料,我链接服务器终端查找访客user-agent,看到的东西成功的证明,发起CC攻击的是个菜鸟,连user-agent头都不会伪装,我一个不太懂网络攻击,但是玩过采集的看到这个简直要笑死

tcpdump -s0 -A -n -i any | grep  ^User-Agent

Snap1.jpg
这个攻击的对象居然没有隐藏自己的user-agent请求头,这水平得有多低啊,打我这个低配置服务器是在秀智商吧,那我之前还折腾个什么鬼,所以直接跑去nginx配置文件,加上了一句。

if ($http_user_agent ~* "Python-urllib") { 
    return 403; 
}

首先测试一下拦截的效果,很快就反馈处理的,识别为Python-urllib全部拦截为403,完美。

curl -I -A "Python-urllib" www.ruletree.club

Snap3.jpg

3.通知为了缓解服务器的压力,我将缓存的时间设置为24个小时,这样攻击者就不那么容易影响到服务器性能了,做完这些时间也不早了,看着网站恢复正常访问,我就安心睡觉了。
Snap5.jpg

第二天的应对过程

早上登录腾讯云,首先发现昨晚消耗了15G流量,手机接到短信提示免费的流量包用完了。网站倒是没问题,看来昨晚上的部署有效果,应该是拦截那里还是不够全面。

1.我继续在服务器终端查找访客user-agent,发现了一个新的,看来这家伙学聪明了,知道伪装了,但还是很蠢,因为user-agent全都是一样的,傻子都看得出来。而且看来就是没有拦截这个user-agent头,所以昨晚被刷了那么多流量,所以继续拦截掉。
Snap2.jpg

2.腾讯云的cdn也昨天设置user-agent拦截,今天再加了一条,但是我有点怀疑拦截效果,所以提交了工单(后续腾讯云给了我完美的答复,只能说好评)
Snap4.jpg

3.拦截效果立刻出现了,大量的403状态出现在了服务器,这代表这攻击ip的被拦截。攻击者技术不够强,他做不到每个代理都设置不同的user-agent头,所以拦截起来跟闹着玩似的,就是必须是他先攻击了才能识别拦截,显得有些被动(主要是服务器配置太低了啊,要是不是这么低的配置,这种CC攻击硬扛没问题)。
8.jpg

这次拦截成功后,攻击停止了,似乎好像还没有罢休,也不知到是cdn误报警还是其它的,总之网站没问题了就行。
9.jpg

后续一些理解
1.无论什么拦截措施,都得建立在服务器性能足够的基础上,攻击ip一大起来,环境先崩了总是那么尴尬。
2.低级的CC攻击,针对user-agent拦截是非常有效的措施,配合cdn缓存的时间延长,网站就当场恢复了。
3.我可能还缺了这玩意,php五秒盾,对于typecho而言,直接将cc.php放在模板目录,把以下代码加在模板header.php最顶部就能生效,根据cookies验证进行5秒拦截缓解服务器压力。

<?php include 'cc.php'; ?>

补充的一些说明

写这篇文章之前,发现友人C,也就是handsome模板的开发者,以及大量的使用者都被CC攻击了,看来又是个学了点技术的小学生在typecho博客圈闹腾,其实CC应该是最好防御的攻击了,要是DDOS过来我也表示服气。他的博客被攻击给我只有几天的间隔,让我有点怀疑是同一个人所为,但是我想说啊,你技术真的很差劲啊,连我这个门外的都知道这攻击不行,user-agent拦截就能百分百拦截可以说是一种失败了。
偶然发现大佬博客的一个评论,我觉得说得漂亮。
10.jpg

相关文件下载

2019年3月2日博客访问日志,可以看看CC攻击出现的效果和拦截的效果

此处内容需要评论回复后方可阅读。

php CC攻击5秒盾,一般php网站都用得上。

此处内容需要评论回复后方可阅读。

您的大名:
万水千山总是情,给个打赏行不行。 打赏
原创文章,作者:不暇,如若转载,请注明出处:https://www.ruletree.club/archives/1054/
typecho多用户会员中心功能实现,附项目源码
« 上一篇 03-06
科幻故事,《演化》
下一篇 » 03-09

发表评论

已有 18 条评论

  1. 路过Lv.1 说道:

    我来看看

  2. sagdsLv.1 说道:

    来看看。 icon_smile.gif

  3. 王生Lv.1 说道:

    CC攻击还是比较好防御的。

    1. 不暇VLv.6 说道:

      是啊,要是ddos还真没辙

  4. yangLv.1 说道:

    破坏远远比建设来的容易

  5. 肛门斗士Lv.1 说道:

    当然是选择关机啦

  6. 路过Lv.2 说道:

    看看 icon_mrgreen.gif

  7. 密码木有Lv.2 说道:

    看看,学习一下,菜鸟一个

  8. LoganLv.1 说道:

    厉害了,大佬

    1. 不暇VLv.6 说道:

      被逼无奈哦

  9. Lv.1 说道:

    icon_mrgreen.gif

  10. 冷漠Lv.1 说道:

    感谢分享群主,你这里就是学习的好地方

  11. 航旗Lv.1 说道:

    学到了,感谢分享

  12. 0000000Lv.1 说道:

    我过来看看,顺便学个技术,转载个文章

  13. fsdadLv.1 说道:

    有点厉害啊

  14. 小白mixLv.1 说道:

    想加到自己网站上,谢谢哈。

    1. 不暇VLv.6 说道:

      转载注明来源就好

  15. genghaoLv.1 说道:

    支持支持