当前位置 主页 > 服务器问题 > nginx问题汇总 >

    Nginx服务器抵御CC攻击的相关配置讲解

    栏目:nginx问题汇总 时间:2018-10-24 10:36

    这篇文章主要介绍了Nginx服务器抵御CC攻击的相关配置讲解,CC攻击原理与DDoS基本相似而且技术含量低,注意防范即可,需要的朋友可以参考下

    0x00 CC攻击的基本原理
      CC攻击利用代理服务器向网站发送大量需要较长计算时间的URL请求,如数据库查询等,导致服务器进行大量计算而很快达到自身的处理能力而形成DOS。而攻击者一旦发送请求给代理后就主动断开连接,因爲代理并不因爲客户端这边连接的断开就不去连接目标服务器。因此攻击机的资源消耗相对很小,而从目标服务器看来,来自代理的请求都是合法的。
      以前防CC攻击的方法
      为了防范CC,以前的方法一个是限制每个IP的连接数,这在地址范围很广阔的情况下比较难实现;二是限制代理的访问,因为一般的代理都会在HTTP头中带 X_FORWARDED_FOR字段,但也有局限,有的代理的请求中是不带该字段的,另外有的客户端确实需要代理才能连接目标服务器,这种限制就会拒绝一些正常用户访问。
      CC攻击用硬防难防住
      CC攻击比DDOS攻击更可怕的就是,CC攻击一般是硬防很难防止住的。
      个人分析原因有三:
      一、因为CC攻击来的IP都是真实的,分散的;
      二、CC攻击的数据包都是正常的数据包;
      三、CC攻击的请求,全都是有效的请求,无法拒绝的请求。
      防CC攻击思路
      防CC有效性在于攻击方不接受服务器回应的数据,发送完请求后就主动断开连接,因此要确认连接是否是CC,服务器端不立即执行URL请求命令,而是简单的返回一个页面转向的回应,回应中包含新的URL请求地址。如果是正常访问,客户端会主动再次连接到转向页面,对用户来说是透明的;而对于CC攻击者,由于不接收回应数据,因此就不会重新连接,服务器也就不需要继续进行操作。

    0x01 验证浏览器行为

    简易版

    我们先来做个比喻。

    社区在搞福利,在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包,聪明工作人员需要想出办法来防止红包被冒领。

    于是工作人员在发红包之前,会给领取者一张纸,上面写着“红包拿来”,如果那人能念出纸上的字,那么就是人,给红包,如果你不能念出来,那么请自觉。于是机器人便被识破,灰溜溜地回来了。

    是的,在这个比喻中,人就是浏览器,机器人就是攻击器,我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。

    if ($cookie_say != "hbnl"){   add_header Set-Cookie "say=hbnl";   rewrite .* "$scheme://$host$uri" redirect;}

    让我们看下这几行的意思,当cookie中say为空时,给一个设置cookie say为hbnl的302重定向包,如果访问者能够在第二个包中携带上cookie值,那么就能正常访问网站了,如果不能的话,那他永远活在了302中。你也可以测试一下,用CC攻击器或者webbench或者直接curl发包做测试,他们都活在了302世界中。

    当然,这么简单就能防住了?当然没有那么简单。

    增强版

    仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl(CC攻击器上就可以这么设置),那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。

    坏人发现这个规律后,给每个机器人安上了扬声器,一直重复着“红包拿来,红包拿来”,浩浩荡荡地又来领红包了。

    这时,工作人员的对策是这样做的,要求领取者出示有自己名字的户口本,并且念出自己的名字,“我是xxx,红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。

    当然,为了配合说明问题,每个机器人是有户口本的,被赶回去的原因是不会念自己的名字,虽然这个有点荒诞,唉。

缩小 缩小 缩小 缩小