一种攻击请求处理方法和装置与流程

文档序号:11594190阅读:172来源:国知局

本发明涉及计算机技术,特别涉及一种攻击请求处理方法和装置。



背景技术:

随着移动应用app的逐渐普及,时刻都面临着各种恶意手段的潜在威胁。比如,客户端可能遭受针对rpc(remoteprocedurecallprotocol,远程过程调用协议)接口请求时的恶意攻击,该攻击会以较高的频率连续发送业务请求,致使服务端的负载加大,严重时甚至造成服务端运行异常。因此,需要对这种连续频繁的进行业务请求的恶意攻击进行识别和阻断。

相关技术中,一种可以采取的控制方式是,在客户端内置业务接口请求白名单,该名单上可以设置需要监控的业务接口及对应的请求次数阈值,客户端在监测到单位时间内对该接口的请求次数超过阈值时,可以屏蔽该接口的业务请求。但是这种方式的缺陷是,名单的变更依赖于客户端应用的版本升级,不够灵活和快速。另一种方式是可以在服务端监控,当服务端监测到某个业务接口的请求次数超过阈值时,屏蔽所有对该接口的业务请求。该方式的缺陷是,可能会因为一个客户端的恶意请求而影响对该接口访问的所有客户端。



技术实现要素:

有鉴于此,本发明提供一种攻击请求处理方法和装置,以使得对恶意攻击的业务请求的控制更加灵活、快速和精准。

具体地,本发明是通过如下技术方案实现的:

第一方面,提供一种攻击请求处理方法,所述方法包括:

在接收到调用业务接口的业务请求时,获取相邻两次请求的时间间隔;

根据熔断系数和所述时间间隔确定熔断值;其中,随着业务请求次数的增加,所述熔断值向熔断条件值靠近,且所述熔断系数是服务端反馈的根据所述业务接口的性能数据生成的系数;

当在单位时间内所统计的所述熔断值满足所述熔断条件值时,则确定受到攻击请求,阻塞对所述业务接口的业务请求,其中,所述熔断值向所述熔断条件值靠近的过程中,任意两次业务请求的时间间隔均小于预定间隔。

第二方面,提供一种攻击请求处理方法,所述方法包括:

根据业务接口对应的性能数据,生成熔断系数;

将所述熔断系数发送至客户端,以使得客户端根据所述熔断系数确定用于阻塞对所述业务接口的攻击请求的熔断值。

第三方面,提供一种攻击请求处理装置,所述装置包括:

时间获取模块,用于在接收到调用业务接口的业务请求时,获取相邻两次请求的时间间隔;

数值确定模块,用于根据熔断系数和所述时间间隔确定熔断值;其中,随着业务请求次数的增加,所述熔断值向熔断条件值靠近,且所述熔断系数是服务端反馈的根据所述业务接口的性能数据生成的系数;

请求处理模块,用于当在单位时间内所统计的所述熔断值满足所述熔断条件值时,则确定受到攻击请求,阻塞对所述业务接口的业务请求,其中,所述熔断值向所述熔断条件值靠近的过程中,任意两次业务请求的时间间隔均小于预定间隔。

第四方面,提供一种攻击请求处理装置,所述装置包括:

系数生成模块,用于根据业务接口对应的性能数据,生成熔断系数;

系数发送模块,用于将所述熔断系数发送至客户端,以使得客户端根据所述熔断系数确定用于阻塞对所述业务接口的攻击请求的熔断值。

本发明的攻击请求处理方法和装置,通过在客户端利用熔断机制识别和阻断恶意攻击,相对于在服务端侧控制,基本不会对其他客户端的正常请求造成影响,如果某个客户端受到了对接口的攻击请求,在该客户端侧阻断请求即可,其他客户端仍然可以照常调用该接口进行访问;并且,相对于传统方式中单独在客户端根据名单和阈值控制的方式,本方案采用熔断机制符合攻击请求的特点,可以更快的识别到攻击请求,而且该方法还结合了服务端侧提供的熔断系数,在考虑攻击请求自身的特点的基础上还综合考虑了服务端的负载情况,当服务端性能较差时,可以通过熔断系数使得客户端侧更快的熔断,从而有效避免加剧服务端的负载。

附图说明

图1是本发明实施例提供的一种攻击表现形式;

图2是本发明实施例提供的一种攻击表现形式;

图3是本发明实施例提供的一种攻击请求处理方法的流程图;

图4是本发明实施例提供的一种服务端侧的处理流程;

图5是本发明实施例提供的一种客户端侧的处理流程;

图6是本发明实施例提供的一种攻击请求处理装置的结构示意图;

图7是本发明实施例提供的一种攻击请求处理装置的结构示意图。

具体实施方式

移动应用通常由客户端和服务端支撑其正常运行,例如,客户端通指安装在智能终端上的应用软件,服务端则通指安装在服务器上支撑客户端应用软件正常运行的系统。客户端可以通过rpc协议远程调用服务端提供的业务接口,使得服务端运行的各种业务规则能够展现在客户端使用。一些恶意攻击可以模拟客户端的操作,频繁连续的调用业务接口,从而导致服务端的接口压力较大,导致运行异常,甚至宕机,比如,正常情况下,单位时间内如1s内用户发送业务请求1次,而恶意的攻击请求可能达到1s内发送业务请求成千上万次。

本申请提供的攻击请求处理方法,可以用于识别到对于某个业务接口调用的业务请求是否是攻击请求,并在确定为攻击请求时,及时阻断该请求。

请结合参见图1所示,根据实验验证,如果客户端侧发生了恶意攻击,即单位时间内密集完成接口调用,那么将呈现一种欠阻尼运动的形式。如图1的示例,纵轴表示振幅,横轴表示时间,如果单位时间内连续进行业务请求,且任意两次请求之间的时间间隔均小于预定间隔t_interval,则随着业务请求次数的增加,最终振幅将达到0。而继续参见图2,假设在振幅随着业务请求次数增加而不断下降的过程中,出现一次两个业务请求的时间间隔超过了t_interval,则振幅将恢复到初始值。

根据图1和图2的特点,可以借用阻尼公式来识别攻击请求。例如,阻尼公式可以是:x=ae-δtcos(ωt),其中,ae-δt为振幅,a根据实际经验可以取值为1.5,δ为阻尼系数,可以为1;ω代表角频率取值为0;t随单位时间内的业务请求次数的增加而累积,每接收到一次业务请求,可以产生一个累积增量,该增量可以是本次业务请求与上一次请求之间的时间间隔。

根据上述的阻尼公式,如果在统计的单位时间内(可以是1s,甚至更小的时间片),任意两次业务请求的时间间隔均小于t_interval,则t可以一直累积,当持续点击达到一定量时,x将小于或等于0。本申请的方法中,可以将x小于或等于0作为确定攻击请求的条件,即如果出现了x小于或等于0,则表明在单位时间内已经出现了一定量的持续频繁的业务请求,可以认为是恶意的攻击请求。当然,在其他例子中,也可以采用非阻尼公式的其他方式。

此外,仍以上述的客户端利用阻尼公式的计算确定攻击请求为例,本申请的攻击请求处理方法中,客户端在使用阻尼公式时,还可以结合一个参数“熔断系数”,该熔断系数可以是服务端反馈给客户端,并且可以是服务端根据业务请求所调用的业务接口的性能数据(例如,cpu、内存等)计算得到,能够反映业务接口当前的负载情况。例如,如果业务接口负载较大,内存占用较多,则熔断系数可以较高,反之,如果业务接口负载较低,熔断系数可以较低。该熔断系数可以作为阻尼公式中的t的累积基数t_dumping,那么可以得到,假设单位时间内同样进行一定量的持续频繁业务请求,不同的累积基数,阻尼公式中的x达到临界值0的时间不同,如果累积基数t_dumping较高,x将更快的下降到0。如果在确定攻击请求后及时采取阻断对接口的业务请求的处理,可以将这种对业务接口请求的阻断称为“熔断”(即相当于对该接口进行限流),相应的,如上所述,累积基数越高,业务请求越频繁,则将越快的熔断。

上述的处理可以示例为图3的攻击请求处理方法的流程,如图3所示,本方法可以由客户端和服务端之间配合,服务端向客户端提供熔断系数,客户端结合该熔断系数控制业务接口请求的阻断与否。该方法可以包括:

在步骤301中,服务端根据业务接口对应的性能数据,生成熔断系数。

例如,该性能数据可以包括:业务接口的tps(transactionpersecond)、内存、cpu占用等。本例子并不限制根据性能数据生成熔断系数的方式,例如,可以采用多个因子加权求和的方式,示例性的,可以将内存使用率作为一个因子,将接口的tps作为另一个因子,并根据各个因子的重要性设置对应的因子权重,再将各因子加权求和得到熔断系数。

在步骤302中,服务端将熔断系数发送至客户端。

例如,服务端可以将熔断系数封装在向客户端发送的响应消息中。

在步骤303中,客户端获取相邻两次请求的时间间隔。

例如,客户端在接收到熔断系数后,可以将该熔断系数用于后续是否熔断的判断中。本步骤中,客户端可以接收到调用业务接口的业务请求,并可以获得相邻两次请求的时间间隔。

在步骤304中,客户端根据熔断系数和所述时间间隔确定熔断值。

例如,可以按照上面提到的阻尼公式计算熔断值,当利用阻尼公式时,时间间隔可以是阻尼公式中的累积增量,而熔断系数可以作为公式中的累积基数。

本步骤中,每当接收到一次业务请求,就计算一次熔断值,并且,可以在接收到业务请求时,判断下相邻请求即本次请求与上一次请求的时间间隔是否大于预定间隔t_interval。例如,通常正常的请求时,两次请求的时间间隔是大于t_interval,该预定间隔可以根据经验值设定,比如可以是100ms。如果判断的结果为相邻请求的间隔小于t_interval,则继续计算熔断值,阻尼公式中的t要增加累积增量;如果判断的结果为相邻请求的间隔大于或等于t_interval,则可以将熔断值清零,下次重新计算。

如果在统计的单位时间内遇到攻击请求,该攻击请求是连续的频繁的请求,任意两次请求的时间间隔小于t_interval,则本步骤将一直累积计算熔断值。随着业务请求次数的增加,所述熔断值将向熔断条件值靠近,该熔断条件值可以是在熔断条件中限定的该熔断值要满足的条件,例如可以是上面提到过的阻尼公式中的x小于或等于0,即接收到的攻击请求的请求次数越多,计算的熔断值就不断减小。

在步骤305中,当在单位时间内所统计的熔断值满足熔断条件值时,则确定受到攻击请求。

例如,本例子中假设的场景为,在所述熔断值由初始计算,直至满足所述熔断条件值的过程中,任意两次业务请求的时间间隔均小于预定间隔。那么随着业务请求次数的增加,熔断值将逐渐下降直至小于或等于0,此时满足熔断条件值,表明此时可以确定这一系列的连续频繁的业务请求确定为恶意的攻击请求。

需要注意的是,本例子中熔断条件的判断可以是在统计的一个单位时间内(例如,1s),若超出一个单位时间仍然未达到熔断条件,则下一个单位时间要重新开始计算熔断值,原熔断值要清零。

在步骤306中,阻塞对所述业务接口的业务请求。

例如,当在步骤305中确定为攻击请求后,可以阻断对该业务接口调用的业务请求,丢弃掉请求,从而可以降低服务端的负载。

本例子的攻击请求处理方法,通过在客户端利用熔断机制识别和阻断恶意攻击,相对于在服务端侧控制,基本不会对其他客户端的正常请求造成影响,如果某个客户端受到了对接口的攻击请求,在该客户端侧阻断请求即可,其他客户端仍然可以照常调用该接口进行访问;并且,相对于传统方式中单独在客户端根据名单和阈值控制的方式,本方案采用熔断机制符合攻击请求的特点,可以更快的识别到攻击请求,而且该方法还结合了服务端侧提供的熔断系数,在考虑攻击请求自身的特点的基础上还综合考虑了服务端的负载情况,当服务端性能较差时,可以通过熔断系数使得客户端侧更快的熔断,从而有效避免加剧服务端的负载。

在另一个例子中,结合图4和图5,来描述本申请的方法,其中,图4描述服务端侧的处理流程,图5描述客户端侧的处理流程。

如图4所示,在步骤401中,服务端获取业务接口名单。

例如,服务端可以由drm(distributedresourcemanagement,分布式资源管理,用于在系统运行期间动态调整业务参数配置,并即时生效)读取熔断机制使能开关。若熔断机制开关打开,则可以由drm读取rpc业务接口灰名单,该灰名单上记录有需要进行流控的各个业务接口,后续如果有客户端向服务端发送调用该灰名单上的某个接口的请求,则服务端将对应该接口的熔断系数发送至客户端,以使得客户端根据熔断系数控制该接口的流量,进行攻击请求的处理。

在步骤402中,服务端获取对应业务接口的性能阈值。

例如,服务端可以由drm获取业务接口灰名单上的各个接口对应的性能阈值。

在步骤403中,服务端采集业务接口的性能数据。

例如,服务端可以由性能监控平台获取接口的性能数据,例如,cpu、内存等。性能监控平台可以用于监控业务运行状态,监控信息包括但不限于操作系统资源(如,cpu、内存等)的使用情况、业务运行期间链路时延信息、业务系统各类告警等。

在步骤404中,服务端判断采集的性能数据是否高于性能阈值。

如果性能数据低于性能阈值,表明当前服务端该业务接口的负载较重,则执行步骤405;否则,执行步骤406。

在步骤405中,服务端屏蔽对该业务接口的业务请求。

本步骤中,可以由服务端屏蔽掉对该业务接口的所有rpc调用请求。

在步骤406中,服务端根据性能数据,计算业务接口对应的熔断系数。

例如,熔断系数可以用t_dumping表示,可以根据cpu、内存、tps等参数计算该系数;若cpu、内存等负载较大,计算的熔断系数的数值越高。

此外,服务端可以周期性执行步骤403至406,即可以周期性采集性能数据,根据性能数据更新熔断系数,并且可以将熔断系数存储在缓存中,用新生成的熔断系数更新替换掉原来的熔断系数,新生成的熔断系数可以表征单位时间内的服务端负载。

在步骤407中,服务端将熔断系数发送至客户端。

本例子中,服务端可以周期性将熔断系数发送至客户端,比如,服务端在接收到客户端发送的对于某个业务接口的rpc调用请求时,如果距离向该客户端上次发送熔断系数已经达到预定固定间隔(例如,3秒),则在向该客户端反馈的rpc调用响应中,封装携带最新计算的熔断系数。又例如,还可以是服务端在接收到客户端发送的接口请求阻塞通知时,向客户端发送熔断系数,所述的接口请求阻塞通知用于表明客户端确定攻击请求且阻断向业务接口的调用请求。

上述图4的流程中,由服务端根据业务接口灰名单获取需要流控的接口及对应的性能阈值,这样当需要更改灰名单时就相对比较容易,不用像在客户端内置名单那样依靠版本升级实现;此外,服务端根据性能数据生成熔断系数,用于客户端根据该系数调控流量,使得客户端侧的流控综合考虑了服务端的负载承受情况,可以实现更准确和有效的控制。

服务端将熔断系数发送至客户端后,客户端依据该系数进行攻击请求处理的流程,可以参见图5所示例。

在步骤501中,客户端接收到调用业务接口的业务请求。

在步骤502中,客户端判断两次相邻请求的时间间隔是否小于预定间隔。

例如,根据经验值,正常的两次请求的间隔时间大于t_interval,可以将预定间隔设为t_interval,可以是100ms。

如果两次相邻请求的时间间隔小于t_interval,则继续执行503;否则,在统计的单位时间内,若出现两次请求的间隔时间大于t_interval,则可以确定不是恶意攻击,执行步骤504。

在步骤503中,客户端根据熔断系数和时间间隔,计算熔断值。

例如,可以利用阻尼公式计算熔断值x。

在步骤504中,将熔断值清零。

待将熔断值清零后,下次再出现两次请求的间隔时间小于t_interval,则重新开始计算熔断值,进入下一次的熔断判断。

在步骤505中,客户端判断熔断值是否满足熔断条件值。

例如,可以判断利用阻尼公式计算的x是否小于等于0。若满足小于或等于0,则可以确认满足熔断条件值,继续执行步骤506;否则,若不满足熔断条件值,则执行步骤510。

在步骤506中,客户端阻塞对业务接口的业务请求。

例如,客户端可以将对该业务接口的调用请求丢弃,以降低服务端负载。

在步骤507中,客户端向服务端发送接口请求阻塞通知。

该接口请求阻塞通知可以用于告知服务端,客户端确定遭受到对于业务接口的攻击请求,且阻断了向该业务接口的调用请求。

在步骤508中,客户端接收服务端发送的熔断时间、以及更新的熔断系数。

例如,熔断时间可以是n小时,n为大于0的任意数,服务端还可以将最新的熔断系数一并发送至客户端。

在步骤509中,客户端在熔断时间之后停止对该接口请求的阻塞。

例如,在经过n小时后,客户端再接收到对于该业务接口的调用时,可以允许其调用请求,并将该请求发送至服务端。

在步骤510中,客户端将所述业务请求发送至服务端处理。

在步骤511中,客户端接收服务端对请求的响应。

图6提供了一种攻击请求处理装置,该装置可以应用于客户端,如图6所示,该装置可以包括:时间获取模块61、数值确定模块62和请求处理模块63。

时间获取模块61,用于在接收到调用业务接口的业务请求时,获取相邻两次请求的时间间隔;

数值确定模块62,用于根据熔断系数和所述时间间隔确定熔断值;其中,随着业务请求次数的增加,所述熔断值向熔断条件值靠近,且所述熔断系数是服务端反馈的根据所述业务接口的性能数据生成的系数;

请求处理模块63,用于当在单位时间内所统计的所述熔断值满足所述熔断条件值时,则确定受到攻击请求,阻塞对所述业务接口的业务请求,其中,所述熔断值向所述熔断条件值靠近的过程中,任意两次业务请求的时间间隔均小于预定间隔。

在一个例子中,数值确定模块62,还用于在所述时间获取模块获取到的相邻两次请求的时间间隔大于预定间隔时,将所述熔断值清零。

在一个例子中,请求处理模块63,还用于在阻塞对所述业务接口的业务请求之后,向服务端发送接口请求阻塞通知;

所述数值确定模块62,还用于接收所述服务端反馈的更新的熔断系数。

图7提供了一种攻击请求处理装置,该装置可以应用于服务端,如图7所示,该装置可以包括:系数生成模块71和系数发送模块72。

系数生成模块71,用于根据业务接口对应的性能数据,生成熔断系数;

系数发送模块72,用于将所述熔断系数发送至客户端,以使得客户端根据所述熔断系数确定用于阻塞对所述业务接口的攻击请求的熔断值。

在一个例子中,系数生成模块71,还用于由业务接口灰名单中获取所述业务接口、以及对应所述业务接口的性能阈值;采集所述业务接口的性能数据;判断所述性能数据是否高于所述性能阈值,并且判断结果为是。

以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1