引言

在我们访问一个网页的时候,总会有若干个http请求发出,比如:阅读量、点赞数,这些一般都是通过ajax动态变更的,如果接口没做校验处理,那么很容易就会被人利用来攻击网站。

解决思路

主要用到了nginx的ngx_http_limit_conn_module和ngx_http_limit_req_module两个配置:

  • ngx_http_limit_conn_module:限制并发连接数;
  • ngx_http_limit_req_module:限制一段时间内同一IP的访问频率;
  1. 我们为了防止别人来攻击,或者访问量异常过高导致服务器崩掉,就需限制访问量,如果是一瞬间的并发访问,那么我们就需要限制一秒之内的并发连接数,此时就需要用到第一个配置

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    http { 

    limit_conn_zone $binary_remote_addr zone=addr:10m;

    #定义一个名为addr的limit_req_zone用来存储session,大小是10M内存,
    #以$binary_remote_addr 为key

    #nginx 1.18以后用limit_conn_zone替换了limit_conn,
    #且只能放在http{}代码段.

    ...

    server {

    ...

    location / {
    limit_conn addr 10;   #连接数限制
    #设置给定键值的共享内存区域和允许的最大连接数。超出此限制时,服务器将返回503(服务临时不可用)错误.
           #如果区域存储空间不足,服务器将返回503(服务临时不可用)错误
    }

    }
    }

    上面的配置能达到的效果就是,一瞬间访问的时候,只会有10个IP能得到响应,后面的IP直接就返回503状态。

  2. 如果一个IP能访问到服务器,那么它如果疯狂的调用接口,如:页面上写个for循环一直刷请求,且不说数据会错乱,最后可能导致将服务器的带宽耗尽,从而导致服务器假死崩溃,此时就需要用到第二个配置

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    http{
    ...

    #定义一个名为allips的limit_req_zone用来存储session,大小是10M内存,
    #以$binary_remote_addr 为key,限制平均每秒的请求为20个,
    #1M能存储16000个状态,rete的值必须为整数,
    #如果限制两秒钟一个请求,可以设置成30r/m

    limit_req_zone $binary_remote_addr zone=allips:10m rate=20r/s;
    ...
    server{
    ...
    location / {
    ...

    #限制每ip每秒不超过20个请求,漏桶数burst为5
    #brust的意思就是,如果第1秒、2,3,4秒请求为19个,
    #第5秒的请求为25个是被允许的。
    #但是如果你第1秒就25个请求,第2秒超过20的请求返回503错误。
    #nodelay,如果不设置该选项,严格使用平均速率限制请求数,
    #第1秒25个请求时,5个请求放到第2秒执行,
    #设置nodelay,25个请求将在第1秒执行。

    limit_req zone=allips burst=5 nodelay;
    ...
    }
    ...
    }
    ...
    }

    此时能达到的效果,同一个ip在一秒钟只能获得20个访问,超过20个请求,后面的也是直接返回503。

上面的两个配置加在一起就可以做到:一秒只有10个连接,每个连接只能发送20个请求。

注意

对request的访问限制,大家一定要注意数量的配置,否则一不小心就会503(ERR_ABORTED 503 (Service Temporarily Unavailable))

很好用的两个功能,但是这两个配置也不是绝对安全,只要有足够的耐心来尝试,摸索出间接等待的时长,一样可以绕过这些校验,所以最好的方式还是在服务端做校验!