博客前几天被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攻击出现的效果和拦截的效果

此处内容需要评论回复后方可阅读o(╯□╰)o

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

此处内容需要评论回复后方可阅读o(╯□╰)o

发表评论
加载中...
    1. sagds   2019-11-12 21:19

      来看看。 icon_smile.gif

    2. 王生   2019-07-25 02:08

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

      查看对话
        1. 不暇   2019-07-25 13:05

          是啊,要是ddos还真没辙

    3. yang   2019-07-05 11:35

      破坏远远比建设来的容易

    4. 肛门斗士   2019-05-21 00:57

      当然是选择关机啦

    5. 路过   2019-05-20 09:25

      看看 icon_mrgreen.gif

    6. 密码木有   2019-04-23 23:18

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

    7. Logan   2019-03-29 09:01

      厉害了,大佬

      查看对话
    8.   2019-03-18 16:34

      icon_mrgreen.gif

    9. 冷漠   2019-03-17 04:42

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

    10. 航旗   2019-03-16 20:33

      学到了,感谢分享

    11. 0000000   2019-03-14 22:28

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

    12. fsdad   2019-03-12 09:10

      有点厉害啊

    13. 小白mix   2019-03-11 12:35

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

      查看对话
        1. 不暇   2019-03-11 14:22

          转载注明来源就好

    14. genghao   2019-03-07 22:35

      支持支持

相关文章