zoukankan      html  css  js  c++  java
  • Nginx服务器抵御CC攻击的相关配置讲解

    CC攻击利用代理服务器向网站发送大量需要较长计算时间的URL请求,如数据库查询等,导致服务器进行大量计算而很快达到自身的处理能力而形成DOS。而攻击者一旦发送请求给代理后就主动断开连接,因??代理并不因??客户端这边连接的断开就不去连接目标服务器。

    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攻击者,由于不接收回应数据,因此就不会重新连接,服务器也就不需要继续进行操作。

    完美版

    http{ 
       ... 
       limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s; 
       limit_req_zone $binary_remote_addr $uri zone=auth_limit:3m rate=1r/m; 
    } 
    location /{ 
       limit_req zone=session_limit burst=5; 
       rewrite_by_lua ' 
       local random = ngx.var.cookie_random   if (random == nil) then     return ngx.redirect("/auth?url=" .. ngx.var.request_uri) 
       end 
       local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)   if (ngx.var.cookie_token ~= token) then     return ngx.redirect("/auth?url=".. ngx.var.request_uri) 
       end 
    '; 
    } 
    location /auth { 
       limit_req zone=auth_limit burst=1;   if ($arg_url = "") { 
         return403; 
       } 
       access_by_lua ' 
         local random = math.random(9999) 
         local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)     if (ngx.var.cookie_token ~= token) then 
           ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}       return ngx.redirect(ngx.var.arg_url) 
         end 
       '; 
    } 

    我想大家也应该已经猜到,这段配置文件的原理就是:把本来的发token的功能分离到一个auth页面,然后用limit对这个auth页面进行频率限制即可。这边的频率是1个IP每分钟授权1个token。当然,这个数量可以根据业务需要进行调整。

    需要注意的是,这个auth部分我lua采用的是access_by_lua,原因在于limit模块是在rewrite阶段后执行的,如果在rewrite阶段302的话,limit将会失效。因此,这段lua配置我不能保证可以用原生的配置文件实现,因为不知道如何用配置文件在rewrite阶段后进行302跳转,也求大牛能够指点一下啊。

    当然,你如果还不满足于这种限制的话,想要做到某个IP如果一天到达上限超过几次之后就直接封IP的话,也是可以的,你可以用类似的思路再做个错误页面,然后到达上限之后不返回503而是跳转到那个错误页面,然后错误页面也做个请求次数限制,比如每天只能访问100次,那么当超过报错超过100次(请求错误页面100次)之后,那天这个IP就不能再访问这个网站了。

    于是,通过这些配置我们便实现了一个网站访问频率限制。不过,这样的配置也不是说可以完全防止了攻击,只能说让攻击者的成本变高,让网站的扛攻击能力变强,当然,前提是nginx能够扛得住这些流量,然后带宽不被堵死。如果你家门被堵了,你还想开门营业,那真心没有办法了。

    然后,做完流量上的防护,让我们来看看对于扫描器之类的攻击的防御。

    0x01 防扫描

    ngx_lua_waf模块

    这个是一个不错的waf模块,这块我们也就不再重复造轮子了。可以直接用这个模块来做防护,当然也完全可以再配合limit模块,用上文的思路来做到一个封IP或者封session的效果。

    0x02总结

    本文旨在达到抛砖引玉的作用,我们并不希望你直接单纯的复制我们的这些例子中的配置,而是希望根据你的自身业务需要,写出适合自身站点的配置文件。

  • 相关阅读:
    LeetCode 453 Minimum Moves to Equal Array Elements
    LeetCode 112 Path Sum
    LeetCode 437 Path Sum III
    LeetCode 263 Ugly Number
    Solutions and Summay for Linked List Naive and Easy Questions
    AWS–Sysops notes
    Linked List
    All About Linked List
    datatable fix error–Invalid JSON response
    [转]反编译c#的相关问题
  • 原文地址:https://www.cnblogs.com/IPYQ/p/8479060.html
Copyright © 2011-2022 走看看