CN103731314B - 一种通信业务行为异常的检测方法、系统及设备 - Google Patents
一种通信业务行为异常的检测方法、系统及设备 Download PDFInfo
- Publication number
- CN103731314B CN103731314B CN201210392776.3A CN201210392776A CN103731314B CN 103731314 B CN103731314 B CN 103731314B CN 201210392776 A CN201210392776 A CN 201210392776A CN 103731314 B CN103731314 B CN 103731314B
- Authority
- CN
- China
- Prior art keywords
- detection
- node
- node device
- request message
- detection device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Abstract
本申请公开一种检测通信业务行为异常的方法、系统及设备,其中方法包括:检测设备检测节点设备的后端交换机的流量;如果发现行为异常则向所述节点设备发送告警信息;以及所述节点设备基于所述告警信息进行异常控制。通过本申请的实施方式,节约了节点设备的资源,而且由于不需要节点设备检测请求报文是否正常以及通信业务的行为是否发生异常因而提高了安全性。
Description
技术领域
本申请涉及通信领域,尤其涉及一种通信业务行为异常的检测方法、系统及设备。
背景技术
目前对于通信业务的异常行为检测有两种方式:1、利用SBC(Session BorderController;会话边界控制器)自身安全功能进行检测;2、利用旁路监控设备进行检测。
第一种方案至少存在以下缺陷:
1、SBC在解析协议数据包过程中存在崩溃风险。SBC本身具有协议解析的能力,如果攻击者向SBC发送恶意构造的畸形数据包,SBC在解析这些畸形数据包时存在系统资源耗尽、内存泄漏、拒绝服务等安全风险,导致SBC停止对正常服务的响应。由于SBC是部署在网络中的inline设备,作为网络边界关键设备,如果SBC崩溃,将直接导致业务系统的瘫痪;
2、无法确保后续连接关系的逻辑正确性。目前的解决方案,只在SBC设备侧进行异常行为分析,对后续的连接关系并不关注。因此将产生如下问题:攻击者构造的恶意数据包绕过SBC侧的异常行为分析系统,就可以完成对网络的攻击,无法检测攻击者后续的恶意行为,比如绕过关键设备、改变业务逻辑等。
第二种方案中,旁路设备无法有效控制数据包。现有的方案不具备检测复杂数据的能力,因此存在放行恶意数据包和丢弃正常流数据包的风险。而且,旁路设备只部署在SBC设备入口处,所以无法有效控制数据包。
发明内容
本申请旨在提出一种能够提高安全性的通信业务行为异常的检测方案。
本申请的一个实施方式提供了一种通信业务行为异常的检测方法,包括:检测设备检测节点设备的后端交换机的流量;如果发现行为异常则向所述节点设备发送告警信息;以及所述节点设备基于所述告警信息进行异常控制。
本申请的另一个实施方式提供了一种通信业务行为异常的检测系统,包括:节点设备,接收终端发送的业务请求;以及检测设备,检测节点设备的后端交换机的流量,如果发现行为异常向所述节点设备发送告警信息;其中,所述节点设备根据所述告警信息进行异常控制。
本申请的另一个实施方式提供了一种通信业务行为异常的检测设备,包括:检测模块,检测节点设备的后端交换机的流量,其中所述节点设备接收终端发送的业务请求;以及告警模块,当所述检测模块发现行为异常时,向所述节点设备发出告警信息。
通过本申请的实施方式,节约了节点设备的资源,而且由于不需要节点设备检测请求报文是否正常以及通信业务的行为是否发生异常因而提高了安全性。
附图说明
图1是根据本申请一个实施方式的通信业务行为异常的检测系统;
图2是根据本申请一个实施方式的通信业务行为异常的检测方法1000;
图3是根据本申请另一个实施方式的通信业务行为异常的检测方法2000;
图4是根据本申请一个实施方式的通信业务行为异常的检测设备;
图5是根据本申请另一个实施方式的通信业务行为异常的检测设备。
具体实施方式
下面结合附图详细描述本申请的实施方式。
图1是根据本申请一个实施方式的通信业务行为异常的检测系统。如图1所示,该系统包括节点设备10和检测设备20。节点设备10接收终端发送的业务请求。检测设备20检测节点设备10的后端交换机的流量,如果发现行为异常则向节点设备10发送告警信息。节点设备10还根据所述告警信息进行异常控制。节点设备例如可以为SBC,下面以节点设备为SBC为例进行说明。
图2是根据本申请一个实施方式的通信业务行为异常的检测方法1000。下面结合图1所述的系统来描述图2所示的方法1000。
步骤S110中,检测设备20检测节点设备10的后端交换机的流量。例如,检测设备20可设置在节点设备10的旁侧。检测设备20通过与SBC10的后端交换机之间的接口(例如,流量镜像接口)来检测SBC10上通过的业务流量,从而检测SBC10上所通过的业务是否异常。
步骤S120中,检测设备20检测节点设备10上通过的业务的行为是否异常。例如,检测设备20通过流量镜像接口从SBC10后端核心交换机获取信息,以检测SBC10上通过的业务流量的后续行为是否异常,该行为至少包括连接行为(例如连接顺序、连接频率和/或连接时间等)。
当发现检测设备20发现通信业务行为异常时,在步骤S130中向节点设备10发送告警信息。然后步骤S140中,节点设备根据告警信息进行异常控制。例如,当检测设备20发现通信业务行为异常时,向SBC10发送告警信息。SBC10根据该告警信息对发生异常行为的业务进行处理,例如丢弃该业务流量中的数据报文。
通过上述实施方式,检测设备与节点设备(例如SBC)后端核心交换机相连,可通过通信接口检测该后端核心交换机的流量,从而检测该节点设备上通过的通信业务是否发生行为异常,而不需要节点设备检测通信业务的行为是否发生异常。因此,节点设备只需要根据检测设备的告警信息来进行异常控制。因此,不仅节约了节点设备的资源,而且由于不需要节点设备检测通信业务的行为是否发生异常而提高了安全性。
图3是根据本申请另一个实施方式的通信业务行为异常的检测方法2000。下面结合图1所述的系统来描述图2所示的方法2000。
步骤S210中,节点设备10向检测设备20转发请求报文并进行阻塞等待。例如,节点设备10接收来自终端的请求报文,然后将该请求报文转发给检测设备,同时进行阻塞等待。例如,节点设备收到来自终端的两条请求报文,第一请求报文和第二请求报文,如果节点设备10将第一请求报文转发给了检测设备20,则节点设备10会对采取阻塞等待,即第一请求报文没有得到处理(例如根据检测设备20的检测结果进行后续过程或者终止后续过程)之前不会向检测设备20发送第二请求报文。
步骤S220中,检测设备20检测该请求报文是否异常。然后在步骤S230中检测设备20向节点设备10返回检测结果。例如,检测设备20检测该请求报文的字段的长度、格式等是否存在畸形错误,然后将检测结果返回给SBC10。
步骤S240中,节点设备10判断检测结果。如果检测结果表示请求报文异常,则在步骤S250中节点设备10根据检测结果进行异常控制。例如,SBC10判断检测设备20返回的检测结果,当检测结果表示请求报文异常时,则终止该请求的后续连接。
作为一种选择,当如果步骤S240中节点设备10判断出检测结果表示请求报文正常,则在步骤S260中,检测设备20检测节点设备10的后端核心交换机的流量。例如,检测设备20通过与SBC10的后端交换机之间的接口(例如,流量镜像接口)来检测SBC10上通过的业务的流量,从而检测SBC10上通过的业务是否异常。
步骤S270中,检测设备20检测节点设备10上通过的业务的行为是否异常。例如,检测设备20通过流量镜像接口从SBC10后端核心交换机获取信息,以检测SBC10上通过的业务的后续行为是否异常,该行为至少包括连接行为(例如连接顺序、连接频率和/或连接时间等)。
也就是说,当检测设备20对请求报文本身进行检测并认为其正常后,还通过检测节点设备10的后端核心交换机的流量来检测该请求报文对应的请求的后续行为是否正常。
当发现检测设备20发现通信业务行为异常时,在步骤S280中向节点设备10发送告警信息。然后步骤S290中,节点设备10根据告警信息进行异常控制。例如,当检测设备20发现通信业务行为异常时,向SBC10发送告警信息。SBC10根据该告警信息丢弃该业务的流量中数据报文。
通过上述实施方式,检测设备与节点设备相连接,节点设备接收到请求报文时并不检测请求报文而是转发给检测设备,然后根据检测设备的检测结果决定是否终止请求的后续连接,这样可以防止节点设备(例如SBC)受到恶意构造的畸形数据包的攻击。并且检测设备与节点设备(例如SBC)后端核心交换机相连,可通过通信接口检测该后端核心交换机的流量,从而检测该节点设备上通过的通信业务是否发生行为异常,而不需要节点设备检测通信业务的行为是否发生异常。因此,检测设备可以在检测过请求报文之后,通过检测节点设备的后端核心交换机的流量来继续检测该请求报文对应的请求的后续行为是否正常。节点设备只需要根据检测设备的告警信息来进行异常控制。因此,不仅节约了节点设备的资源,而且由于不需要节点设备检测请求报文是否正常以及通信业务的行为是否发生异常因而提高了安全性。
作为一种选择,节点设备10与检测设备20之间的传输接口协议采用UDP通信方式且以C/S模式运行。作为一种选择,节点设备10与检测设备20之间的传输接口协议对消息的发送和接受采用同步处理方式。
节点设备10与检测设备20之间的通信举例如下。设节点设备为Client端,检测设备20为Server端。Client端主动发送请求消息并阻塞等待,即节点设备10主动将所接收到的第一请求消息发送至检测设备20;Server端始终监听在接收端口(例如,缺省端口15061),收到Client端的请求消息后,返回应答消息;Client端收到应答消息后,根据消息类型决定继续发送下一条消息或进行重传,例如,应答消息指示该第一请求报文接收成功则发送下一条请求报文,应带消息指示该第一请求报文接受失败则进行重传该第一请求报文。作为一种选择,为增强容错能力,协议中可增加失败重传机制,即如果Client端对同一消息重传两次仍然失败,可以丢弃该消息;Client端发送请求消息阻塞等待时,还可设置超时机制,超时后丢弃该消息。
例如,当Server端接收请求消息出现问题的时候,会通过应答消息要求Client端重传上一条消息。Client端收到后,可以根据预先的设定最多重传两次该消息,如果均失败,则放弃该消息的发送,继续发送下一条消息。如果应答消息中要求重传,但Event ID字段为0,则忽略重传消息请求,继续发送下一条消息。当Client端接收应答消息出现问题的时候,会直接放弃当前消息,继续发送下一条消息,以防止重复发送同一条已接收成功的消息。当Client端发送请求消息并进入阻塞等待后,会开启一个5秒钟的超时定时器,如果5秒钟内接收不到任何应答消息,则放弃该消息的发送,继续发送下一条消息。
节点设备10与检测设备20之间的传输接口协议中,请求消息和应答消息都由消息头和消息体两部分组成,如表1所示。
表1
UDP Header | Request/Response Header | Message Body |
请求消息可以只有一种类型,正常的请求消息和重传的请求消息结构和内容完全一样。请求消息可以是可变长度的,具体长度由内部各字段长度决定。应答消息有两种类型,一种为接收成功消息,一种为接收失败消息,结构相同,内容不同。上面所描述的消息头和消息体部分均封装在UDPpayload当中。
请求消息头包含三个长整型字段(64bit),分别为Event ID、FieldNumber和TotalLength(如表2所示)。其中Event ID为事件ID,顺序递增且不会重复;Field Number表示Message Body中包含多少个字段;Total Length为Message Body部分的总长度(单位:bytes)。
表2
Event ID (8bytes) | Field Number (8bytes) | Total Length(8bytes) |
请求消息体当中包含多个字段,其数目为消息头中的Field Number值。每个字段由四部分组成:Field Name(字段名称);Field Type(字段类型);Field Length(字段长度);Field Content(字段内容)。如表3所示。
表3
Field Name (8bytes) | Field Type(1byte) | Field Length (8bytes) | Field Content(bytes) |
其中,Field Name为8字节字符串;Field Type为1字节枚举类型(1,long int;2,char;3,bool),表示Field Content的数据类型;Field Length为Field Content的长度;Field Content为字段值,可变长度数据。
应答消息头包含一个长整型字段(64bit),为接收到的相应Event ID,如果接收过程中出现错误,无法获得Event ID,则该字段置为0。如表4所示。
表4
Event ID (8bytes) |
应答消息体包含两个字段,Status为1字节bool类型,Error Code为8字节长整型。如表5所示。
表5
Status (1byte) | Error Code (8bytes) |
其中,Status为接收状态,0表示接收成功,即接收成功应答;1表示接收失败,即请求重传应答。当Status为1时,Error Code字段保存相应的错误原因代码。
图4是根据本申请一个实施方式的通信业务行为异常的检测设备。如图所示,该设备包括检测模块201和告警模块202。检测模块201检测节点设备的后端核心交换机的流量;告警模块202在检测模块201发现行为异常时,向节点设备发出告警信息。以下结合图1所示的系统描述图4所示的检测设备。
例如,检测模块201通过与SBC10的后端交换机之间的接口(例如,流量镜像接口)来检测SBC10上通过的业务的流量,从而检测SBC10上通过的业务是否异常。例如,检测模块201通过流量镜像接口从SBC10后端核心交换机获取信息,以检测SBC10上通过的业务的后续行为是否异常,该行为至少包括连接行为(例如连接顺序、连接频率和/或连接时间等)。当检测模块201发现通信业务行为异常时,告警模块202向节点设备10发送告警信息,以使得节点设备10根据告警信息进行异常控制。
图5是根据本申请另一个实施方式的通信业务行为异常的检测设备。如图所示,该设备除包括检测模块201、告警模块202之外,还包括收发模块203。收发模块03接收节点设备10转发的终端请求报文。检测模块201还检测该请求报文是否异常。收发模块203还向节点设备10返回检测结果。
例如,节点设备10接收来自终端的请求报文,然后将该请求报文转发给检测设备,同时进行阻塞等待。检测设备20的收发模块203接受节点设备10转发的请求报文。检测模块202检测该请求报文是否异常。然后收发模块203向节点设备10返回检测结果,以使得节点设备10根据检测结果进行异常控制。
在检测出请报文正常的情况下,检测模块202还通过与SBC10的后端交换机之间的接口(例如,流量镜像接口)来检测节点设备10上通过的业务的流量,从而检测节点设备10上通过的业务(包括上述请求报文对应的请求业务)是否异常。当检测模块201发现通信业务行为异常时,告警模块202向节点设备10发送告警信息,以使得节点设备10根据告警信息进行异常控制。
通过上述实施方式,检测设备不仅检测节点设备转发的报文,而且在该请求报文正常的情况下,还会继续检测该请求报文对应的请求的后续行为是否正常,从而使节点设备根据检测设备的检测结果或告警信息来决定是否执行异常控制。这样不仅节约了节点设备的资源,而且由于不需要节点设备检测请求报文是否正常以及通信业务的行为是否发生异常因而提高了安全性。
以上仅为本申请的优选实施方式,并非因此限制本申请的专利范围,凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其它相关的技术领域,均同理包括在本申请的专利保护范围内。
Claims (10)
1.一种通信业务行为异常的检测方法,包括:
检测设备检测节点设备与后端交换机之间的接口的流量;
如果发现行为异常则向所述节点设备发送告警信息;以及
所述节点设备基于所述告警信息进行异常控制;
在所述检测设备检测节点设备的后端交换机的流量的步骤之前还包括:
所述节点设备接收终端的请求报文;
将所述请求报文转发至所述检测设备并进行阻塞等待;
所述检测设备检测所述请求报文是否异常;
向所述节点设备返回检测结果;以及
所述节点设备基于所述检测结果进行异常控制。
2.如权利要求1所述的方法,其中,所述检测设备检测节点设备的后端交换机的流量的步骤包括:
所述检测设备通过检测节点设备的后端交换机的流量来检测业务的连接行为。
3.如权利要求1所述的方法,还包括:
当所述检测结果正确,所述节点设备向所述检测设备转发新的请求报文。
4.如权利要求1所述的方法,其中,在所述将所述请求报文转发至所述检测设备并进行阻塞等待的步骤之后包括:
如果所述节点设备在预定时间内未收到来自所述检测设备的应答,则不再向所述检测设备发送所述请求报文,并向所述检测设备转发新的请求报文。
5.一种通信业务行为异常的检测系统,包括:
节点设备,接收终端发送的业务请求;以及
检测设备,检测节点设备与后端交换机之间的接口的流量,如果发现行为异常向所述节点设备发送告警信息;
其中,所述节点设备根据所述告警信息进行异常控制;
所述节点设备还将所接收的请求报文转发至所述检测设备并进行阻塞等待;
所述检测设备还检测所述请求报文是否异常,并向所述节点设备返回检测结果;
所述节点设备根据所述检测结果进行异常控制。
6.如权利要求5所述的系统,其中,所述检测设备通过检测节点设备的后端交换机的流量来检测业务的连接行为。
7.如权利要求5所述的系统,其中,所述节点设备在所述检测结果正确时向所述检测设备转发新的请求报文。
8.如权利要求5所述的系统,其中,所述节点设备如果在预定时间内未收到来自所述检测设备的应答,则不再向所述检测设备发送所述请求报文,并向所述检测设备转发新的请求报文。
9.一种通信业务行为异常的检测设备,包括:
检测模块,检测节点设备与后端交换机之间的接口的流量,其中所述节点设备接收终端发送的业务请求;以及
告警模块,当所述检测模块发现行为异常时,向所述节点设备发出告警信息;
所述检测设备还包括收发模块,所述收发模块用于接收所述节点设备转发的终端请求报文;
所述检测模块还检测所述请求报文是否异常;
所述收发模块还向所述节点设备返回检测结果。
10.如权利要求9所述的设备,其中,所述检测模块通过检测节点设备的后端交换机的流量来检测业务的连接行为。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210392776.3A CN103731314B (zh) | 2012-10-16 | 2012-10-16 | 一种通信业务行为异常的检测方法、系统及设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210392776.3A CN103731314B (zh) | 2012-10-16 | 2012-10-16 | 一种通信业务行为异常的检测方法、系统及设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103731314A CN103731314A (zh) | 2014-04-16 |
CN103731314B true CN103731314B (zh) | 2017-11-21 |
Family
ID=50455249
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210392776.3A Active CN103731314B (zh) | 2012-10-16 | 2012-10-16 | 一种通信业务行为异常的检测方法、系统及设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103731314B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111813073B (zh) * | 2020-06-11 | 2023-11-07 | 珠海格力电器股份有限公司 | 节点预警方法和装置 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101299724A (zh) * | 2008-07-04 | 2008-11-05 | 杭州华三通信技术有限公司 | 流量清洗的方法、系统和设备 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2912271A1 (fr) * | 2007-02-06 | 2008-08-08 | France Telecom | Gestion de service dans un reseau |
CN100579054C (zh) * | 2007-06-11 | 2010-01-06 | 华为技术有限公司 | 一种互为归属的会话边界控制器的控制方法、系统及装置 |
CN101594265B (zh) * | 2009-06-30 | 2011-11-16 | 北京星网锐捷网络技术有限公司 | 一种网络故障诊断方法、装置和网络设备 |
CN101997860B (zh) * | 2009-08-25 | 2014-03-12 | 中兴通讯股份有限公司 | 一种ngn网络架构中通信链路检测管理的方法和装置 |
-
2012
- 2012-10-16 CN CN201210392776.3A patent/CN103731314B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101299724A (zh) * | 2008-07-04 | 2008-11-05 | 杭州华三通信技术有限公司 | 流量清洗的方法、系统和设备 |
Also Published As
Publication number | Publication date |
---|---|
CN103731314A (zh) | 2014-04-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8799504B2 (en) | System and method of TCP tunneling | |
KR101610715B1 (ko) | 단방향 데이터 송수신 시스템 및 방법 | |
CN109391560A (zh) | 网络拥塞的通告方法、代理节点及计算机设备 | |
CN111083161A (zh) | 数据传输的处理方法及装置、物联网设备 | |
US7447222B2 (en) | Automated path tracing through switching mesh | |
US8976814B2 (en) | Method of transporting data from sending node to destination node | |
CN111164923A (zh) | 用于单向传输数据的设计 | |
US6741566B1 (en) | Remote management ethernet network and device | |
US11729184B2 (en) | Detecting covertly stored payloads of data within a network | |
CN104717105A (zh) | 一种基于ISA100.11a标准的工业传感网数据重复检测方法 | |
CN100466583C (zh) | 基于rrpp的快速环网防攻击的方法、装置和系统 | |
JP2001308900A (ja) | グループマルチキャスティングのためのネットワークおよびプロトコル | |
WO2005074195A1 (en) | Method of retransmitting data frame and network apparatus using the method | |
CN101841424A (zh) | 基于socks代理连接的ems网管系统和方法 | |
CN107426166A (zh) | 一种信息的获取方法、装置及电子设备 | |
US10142058B2 (en) | Communication device and communication method | |
CN102843274B (zh) | 一种多链路故障检测的方法及装置 | |
EP2525527B1 (en) | Network relay device and network relay method | |
US20090210770A1 (en) | Method, system and computer program product for end to end error checking in ethernet | |
WO2024032742A1 (zh) | 业务处理方法、装置、设备、存储介质及程序产品 | |
US11700271B2 (en) | Device and method for anomaly detection in a communications network | |
CN103731314B (zh) | 一种通信业务行为异常的检测方法、系统及设备 | |
CN109068328B (zh) | 安全网络通信方法、终端及系统 | |
CN111147514A (zh) | 一种适用于实时以太网会话层的通信帧及设计方法 | |
US10237018B2 (en) | Communication device and communication method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |