博客前几天被cc攻击应对过程，及策略整理-工具盒子

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

第一天的应对过程如下

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

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

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

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

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

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

第二天的应对过程

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

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

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

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

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

后续一些理解
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拦截就能百分百拦截可以说是一种失败了。
偶然发现大佬博客的一个评论，我觉得说得漂亮。