- 2019.2.20 晚上22:50 ~ 23:30 遭受了CC攻击,当时我在看《武林外传》,被群友提醒的我的博客已经打不开!!( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃,从下面的又拍云监控请求数的峰值才17次/s,可是带宽已经突破了承受极限(> 1Mbps)
- 2019.2.21 晚上23:20 ~ 23:35 同样遭到了CC攻击,峰值高达1千次/1s,因为前一晚上临时加了一些cc防护,所以期间晚上仍然是可以正常打开的,只是可能比正常慢很多,但让我的又拍云账单多花费了3元(平时约1元,昨天一共消费了4.61 元)
我的服务器配置是:腾讯云学生机 1 核 1 GB(内存) 1 Mbps(带宽)+ 又拍云 CDN
我们分析一下上面的数据,从而制定一个较为合适的防护措施(可以直接拉到「防护错误」标题处做一个简单的参考)
什么是带宽?
带宽就是你的服务器(所有网站的)最大数据传输速率(极限状态下)
除了带宽,还有一个名词是流量,则是一段时间内的数据传输量。
计算机领域的单位换算很麻烦,麻烦在于有标准,但是网络上遵守的标准并不一致,导致了最终的标准混乱的问题。
简单来说,根据国际上的单位标准,
bps 等价于 b/s ,两者是完全等价的写法
- 表示通信速率、 数据传输速率中,相邻单位换算的比是1000,即K的含义是10^3(即1000),M的含义是10^6,G的含义是10^9,故1Mbps = 1000Kbps = 10^6b/s
- 表示数据存储、传输大小、流量或者硬盘容量的时候,相邻单位换算之间是1024,也就是我们常见的1Kb = 1024b
- 字节和位换算比是8,即1B = 8b
但是由于,现在执行标准十分混乱,具体要以对应的规则而定(考研的计算机网络一般按照怎么算是整数来定的规则,各个学校的出题人认定的标准都不一样的)。
一般的CDN云服务商,相邻单位换算比都是1024。所以我们均以此标准计算。
1Mbps = 1Mb/s = 1024Kb/s = 128kB/s
- 访问我的博客的一个页面的平均大小 1MB,去除图片、css、js等静态资源,一个页面大小平均为50KB(因为1s内静态资源并不会立即加载的)
- 极限速率是128KB/s
- 也就是3个人同时并发访问我的博客是我的服务器极限
但事实上,由于我的博客并没什么人看,所以几个人在同一秒中访问的几率还是很小的,所以正常访问是完全没有问题的。
但是如果遇到了CC攻击,我的博客遇到甚至不是很强的攻击都会达到带宽极限,无法为正常用户提供访问。
什么是CC攻击?
CC攻击是DDOS攻击的一种,认识到带宽的意义,就很容易理解,攻击者使用一定数量的IP并发访问你的博客,你博客就是超出带宽极限,服务器处于瘫痪状态,无法为其他用户提供请求响应。
我们知道浏览器的访问是TCP协议,TCP响应也称作“3报文握手”也就是客户端和服务器端之间一共发了3个报文才完成TCP连接。
CC攻击的时候,服务器已经无法接收和处理正常客户传过来的TCP报文也就无法建立连接。
怎样防护CC攻击?
提升带宽大小,是一个好办法,但治标不治本。问题在于处理非法的请求。
对IP请求数目进行判断
又拍云
又拍云这两个功能都可以有一定作用:
IP访问限制
ip访问限制就是请求数目太多,就是禁止这个ip访问一段时间(最小是60s)
- 这里的访问频率是指请求你的服务器的request数目!!并不表示只访问某个URL的数目
比如你访问我的博客http://www.ihewro.com,指向我的服务器的request实际上约30个(引用别的服务器资源的request不计算在内),那么访问次数就是30次。
- 禁止时间:又拍云的计数周期是固定的,60s。禁止时间最小值也是60s。
下面是我的设置规则:
CC防护
分为两种:
- 强制防护:用户访问你的博客,都会先显示一个约5秒的等待页面,检查客户端的在这段时间内的请求次数是否正常,是否请求特征正常,就会给用户浏览器添加一个cookie,表示认证通过,在一段时间内,该用户都被视为正常用户,不会再看到等待页面
- 智能防护:有一个
访问频率阈值
(最小是200),超过这个阈值,才会显示等待页面,实现原理和上面是一样的。
我的设置如下图:
建议CC防护频率限度要小于ip访问限制的频率限度,因为用户因为IP被误判导致的封禁,用户体验会很差!
宝塔防火墙
由于CC攻击峰值比较大,我被迫开通了宝塔防火墙,19.8/元。
相比又拍云的防护,宝塔防火墙的自定义程度更高,而且是在源站保护的层面上的。
我的设置如上图。
CC防御
这里的访问次数和又拍云不一样,就是URL的访问次数,而不是request的数目,一定不要搞错!否则你的设置很可能有问题
正常用户平均1s内访问并不会超过2s,所以10s内不会超过20次。
这里的封锁时间,一般应设置比计数周期时间长。比如计数周期是10s,封锁时间要大于10s。就算你封锁时间是3s,非法用户的封锁时间很可能是超过3s的。
因为在同一个计数周期内,用户被解封,但是计数次数仍然没有清零。再次访问仍然次数超过限制的。
还有一个选项是CC防御威力加强版,开启后可能会影响用户体验
。具体效果是:
- 增强模式下疑似混合CC攻击的请求将弹出验证问题,用户正确输入答案后可继续访问(官方更新记录)
- 我自己测试,增强模式下,偶尔会出现很短的等待的页面,这个不是百分百出现的(和又拍云的强制防护还是不一样)
恶意容忍设置
恶意容忍设置的周期,建议比较长,比如2分钟,或者3分钟内,超过这个限制,较大可能是CC攻击,应该封锁较长时间。
这里的恶意请求次数
设置:180s/30s(在10s末尾封禁,封禁时间为20s) = 6次
即,180s内,持续的CC攻击的情况下,最少也会有6次恶意请求,最多会有9次请求(180s/20s = 9 (在10s周期一开始就被封禁))
对IP请求的HTTP报文段一些非法字段判断
在宝塔面板的响应日志里面可以看到每个请求的HTTP 报文以及响应报文如下:
124.***.123.171 - - [22/Feb/2019:15:19:06 +0800] "GET /usr/themes/handsome/usr/OwO.json?v=5.0.020181241319 HTTP/1.1" 200 6785 "https://www.ihewro.com/archives/363/comment-page-2" "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/56.0.2924.75 Mobile/14E5239e YisouSpider/5.0 Safari/602.1"
- 远程主机(Remote Host)的IP地址/名字:124.160.123.171
- 登录名(Log Name)和登录全名(Full Name):登录名和登录全名指的是发起这个请求的用户的名字,这个一般大家是不想要透露的了,所以远程主机会禁止给出这两个信息,log file当然就记录不下来了,用两个短中划线代替。
请求时间:
- 请求发生的日期(Date):22/Feb/2019
- 请求发生的时间(Time):15:19:06
- 和标准格林威治时间的差值(GMT Offset):0800
请求和响应报文:
- 请求的方法(Request Method)GET
- 请求的文件的地址(File)/usr/themes/handsome/usr/OwO.json?v=5.0.020181241319 HTTP/1.1
- 请求遵守的协议(Protocol)HTTP/1.1
- 请求的状态(Status)200
- 被请求文档的长度(Length,单位字节):6785字节
- 请求来源(Referrer):指连接到被请求资源的网站的URL,如果请求时通过点击一个链接时发生,那么这个项目就会被记录;如果直接访问就没有请求来源:这里是一个页面评论区“https://www.ihewro.com/archives/363/comment-page-2”
- 客户端(User Agent):记录用户的浏览器或者发出请求的程序的相关信息;"Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/56.0.2924.75 Mobile/14E5239e YisouSpider/5.0 Safari/602.1"
- 所需时间(Time Taken):从请求的发出到请求的资源全部传输完毕所需花费的时间;这一项服务器没有记录
可以对异常IP进行添加黑名单
对异常请求的 Referrer 添加黑名单
对异常请求的 User Agent 添加黑名单
这个在又拍云的宝塔面板中有规则设置,一般需要管理员手动添加。就不多说了。
如果没有用宝塔防火墙,也可以尝试使用jagerzhang/CCKiller
原理都是差不多。
以上内容如果知识性错误,欢迎指出,感谢!
32 条评论
听别人说是handsome的某个售后群被集体CC,不得不说这种行为真的很可耻
是的,有一个群里好几个都被CC了,这种行为十分以及特别的可耻!
同样中枪,峰值1秒1800多次,2G内存都给CC满了。。
幸亏这几天新增备案把网站关掉了哈哈哈
根本在于你是1M带宽。
那么有没有一款价格便宜带宽重组的VPS呢?
搬瓦工千兆版欢迎你
搬瓦工在国外速度应该不怎么行吧,准备毕业了换个好一点的
我就是搬瓦工啊