友人C

一次被攻击记录和CC 防护简单指南
2019.2.20 晚上22:50 ~ 23:30 遭受了CC攻击,当时我在看《武林外传》,被群友提醒的我的博客已...
扫描右侧二维码阅读全文
22
2019/02

一次被攻击记录和CC 防护简单指南

  • 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 元)

2019.2.20
2019.2.20
2019.2.21
2019.2.21

我的服务器配置是:腾讯云学生机 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

原理都是差不多。


以上内容如果知识性错误,欢迎指出,感谢!

最后修改:2019 年 03 月 23 日 11 : 37 AM
如果觉得我的文章对你有用,请随意赞赏

30 条评论

  1. cnguu

    用不起cdn的我,图片压缩之后,1M还是可以带的起的

  2. 清雨

    源站的 WAF ,博主可以试试 ModSecurity,功能很强大,就是规则配置稍微麻烦了点,不详细配置的话容易误伤。

  3. genghao

    我更那个,6个cdn(海外2个),被人c了一天,最后还有dd,导致所有cdn流量用完后回源,最终源站卒

  4. underworld

    大佬,我想问一下,我的博客网站从腾讯云cdn搬到又拍云之后,右上角的音乐播放为什么一直加载不出来,而且绑定的admin无法登录,WAF我也没有打开,求教是怎么回事?

    1. 她与空白
      @underworld

      和你一样,你解决了没有?

      1. underworld
        @她与空白

        没有,尝试了很多方法,包括又拍云设置不缓存规则啥的,都没用。

        1. 友人C
          @underworld

          admin无法登陆原因应该是你全站静态缓存了...我用的也是又拍云

  5. 萧小七

    同被cc了一次!!!一篇文章刷到3000多的浏览!!!

  6. 无限UCW

    简单说一下我个人对这种行为的感受和评价:十分厌恶。原因在于恶意的攻击往往是在无仇无怨的情况下,近乎“炫技”的情景中进行的,就好像“你看我都能搞别人网站,我多强啊”的宣言一般,愚蠢至极,而他们恰恰无法领悟破坏往往比建设来的容易,防守需要面面俱到“对任意”,攻击却只需要抓住一个疏漏“存在”,底层苍蝇的快乐往往只能建立在糟践美食之上。但是,天道好轮回,当年的“网络恶霸”们,而今安在?

  7. Lansky

    有CDN的话,其实一般的CC打不进去,因为根本不知道主机地址。OωO,不过也看CDN的防御策略咯

    1. genghao
      @Lansky

      动态页面一般还是要回源站取

    2. 六号博客
      @Lansky

      CDN 防不住CC的

      1. 远方
        @六号博客

        kangleCC防护了解一下

  8. moozik

    其实吧,说不定只是随便找个人测试一下,就是欺负你机器不行,打别人有防火墙也没啥效果,可能就是点背了

  9. 微信抢房

    感谢博主的教程还是能有效的防住一些CC

  10. 左岸

    同中枪,老大的教程很不错!

  11. 墨竹

    难怪那天直接上不去了。。。

  12. Quanyin

    无辜中枪 ,CC 攻击的重点在于请求多,CPU和内存资源占满,导致无法处理用户访问,带宽反而是次要的

    1. 友人C
      @Quanyin

      这些都是衡量服务器性能的关键性指标,只不过带宽是我的服务器中最差的,所以他就成为了短板

  13. ridd1ot

    我服务器被ssh暴力破解近2天。 不过并没有被跑出密码来。

    1. 友人C
      @ridd1ot

      ssh 你可以尝试换个端口

  14. BigCoke

    听别人说是handsome的某个售后群被集体CC,不得不说这种行为真的很可耻

    1. 友人C
      @BigCoke

      是的,有一个群里好几个都被CC了,这种行为十分以及特别的可耻!

      1. 洛小依
        @友人C

        同样中枪,峰值1秒1800多次,2G内存都给CC满了。。

        1. 夏尺
          @洛小依

          幸亏这几天新增备案把网站关掉了哈哈哈

  15. 雨心Dream
    该评论仅登录用户及评论双方可见
    1. 友人C
      @雨心Dream
      该评论仅登录用户及评论双方可见

发表评论