CN1905553A - 在dos攻击或者设备过载时保障所选用户访问的方法 - Google Patents
在dos攻击或者设备过载时保障所选用户访问的方法 Download PDFInfo
- Publication number
- CN1905553A CN1905553A CNA2005100362658A CN200510036265A CN1905553A CN 1905553 A CN1905553 A CN 1905553A CN A2005100362658 A CNA2005100362658 A CN A2005100362658A CN 200510036265 A CN200510036265 A CN 200510036265A CN 1905553 A CN1905553 A CN 1905553A
- Authority
- CN
- China
- Prior art keywords
- user
- visit
- connection
- packet
- server
- 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.)
- Granted
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
一种在DOS攻击或者设备过载时保障所选用户访问的方法,基于系统设置安全通道服务器,解决现有安全手段将貌似合法的攻击和真正用户的访问一样进行压制的弊病,包括步骤:安全通道服务器对被访问设备进出数据流进行监控;用户得到安全控制授权;安全通道服务器为真正用户开通一个快速的安全通道,对连接数据包进行用户归属辨识;用户在安全通道中的访问依安全控制授权得到保护,同时防止也不能进行DOS攻击。本发明既允许被区分的用户优先访问被保护设备,也同时允许未被区分、识别的用户访问被保护设备。本发明方法还支持用户安全特性的动态改变,允许应用服务根据自己特色来修改用户安全特性,使得安全控制可以区别化和精细化。并且算法非常方便硬件的转发实现。
Description
技术领域 本发明涉及数字信息传输,特别涉及以通路配置为特征的网络数据传输,尤其是涉及网络设备在遭遇包括DOS、DDOS攻击的过载访问下为所选择的用户提供正常访问的方法。
背景技术 在网络数据传输领域,网络设备,尤其是包括网站、服务器等的被访问设备,经常会遭遇过载访问情况,特别是受到DOS、DDOS攻击时,访问压力往往超过设备处理能力。所述DOS(Denial Of Service,拒绝服务)攻击和DDOS(Distributed Denial of Service,分布式拒绝服务)攻击均是耗尽服务器资源的攻击方式。DOS攻击是通过从网络上针对设备发送大量的连接数据包,导致该设备因为消耗大量的资源去处理这些连接而无法为其他合法访问的连接提供服务。这种攻击既有大量的非法连接、不完整的连接存在,例如伪造源地址、半连接等等,也有大量的合法连接攻击,利用攻击者的性能优势压垮服务器。而目前危害最严重,也是目前最难防范的是DDOS(分布式拒绝服务攻击),也就是在被控制的多台设备上进行DOS攻击,也是有大量的、看似合法的完整连接(主要是空连接)进行攻击,利用多台设备的总性能超过服务器的性能优势,压垮服务器。DDOS攻击通过首先通过攻击接管大量的网上终端设备,然后通过每个终端设备发送大量的合法连接或者不合法的连接请求与服务器建立大量的连接,因为每一个设备都是合法的,服务器对于合法的连接请求根本无法分辨是否是攻击还是真正的访问,结果导致服务器连接资源枯竭而无法提供服务。这种攻击使得攻击防护更加困难。这种攻击可能是有意或者因为病毒等原因引起的。
目前防止DOS或者DDOS攻击所使用的方法都是接管被访问设备的访问数据流进行数据流检查,为了防止被访问设备崩溃,这时候将会对到达被访问设备的连接数据包进行压制,分析每一个连接,分析此终端设备是否具有一个真实的地址(对于IP网络而言,只能是IP地址),此连接是否合法、是否同一个地址试图建立大量的连接(大大超过正常访问的连接数量)等等信息来分析是否存在攻击。但是因为在用户与网站之间有NAT、PROXY、代理方式的设备大量存在,用户数据包通过这些设备以后,数据包中的网络地址、连接信息都被改变了,许多用户共享了一个网络地址,这样就将用户的信息隐含起来了,也无法确定一个地址后面有多少用户,这样就无法确定什么情况下是在连接攻击、什么时候下是正常的连接使用。那么在使用通常的防止攻击技术的情况下,如果在NAT后面存在一个攻击用户,那么此实际上此NAT后面共享使用同一个地址的所有数据包都会被认为是攻击,都会被丢弃,那么将会影响真正的用户访问。而且更糟糕的是,因为无法确定NAT后面用户的多少,而且有多少用户会访问此服务器,所以就无法确定正常访问情况下,到底有多少数量合法连接存在,结果导致针对单一地址的合法访问的判断将会非常困难和定义,最后只能是大大超过正常需要的数目才会认为是攻击,而实际上在此之前,攻击可能就已经发生。
同时,由于攻击方式不断地在升级,断定是否发生了攻击行为,需要不断地升级保护设备,但由于攻击的方式方法的多样性,有可能造成在攻击发生后才能分析攻击的手法,并加以防范,但损失可能已经造成。
现有VPN解决方案是面向受控用户的方案,它首先要求用户进行注册,然后用户才可以访问被保护设备。但是,由于网站上大量的被访问设备是提供公众服务的,采用VPN方案将使得公众服务无法提供。
区分、保护方案自身还要具备防止DOS攻击的能力,DOS攻击可以是全方位的,一些传统的DOS阻止方案,在阻止DOS攻击的同时,自身成为DOS攻击的对象,同样使得被保护对象无法被访问。
DOS、DDOS攻击从本质上来说,是一种负荷过载的攻击方式。另外往往存在其它原因造成的访问压力超过了设备处理能力(以下简称前述两种情况为过载访问),这些设备包括网站、服务器等网络设备(以下简称被访问设备)。过载访问有可能造成全部或部分用户无法正常访问(其中包括但不限于:访问性能下降、无法访问、时断时续等情况)被访问设备。
发明内容 本发明要解决的技术问题是针对上述现有技术的不足,而提出一种方法,能在包括受到DOS、DDOS攻击或者其他原因导致设备过载访问下,能够为经过验证(验证行为包括但不限于用户名/口令认证、证书认证,而可以是一切可以认定用户行为正常的判断)的用户提供独立的通道,针对需要安全检查的数据,将会进行检查,保证受到保护的用户不会在通道内进行攻击;同时通道的有独立的优先级、带宽等控制,不受通道外的DDOS攻击数据或者过载数据的影响,保证通道合法数据;而且在防止此通道用户对被保护的对象的进行攻击时,还可以定位攻击的用户特征和防范其它未知攻击可能造成的过载访问。
为解决上述技术问题,本发明的基本构思为,在被访问设备前设置保护设备(包括但不限于单台或多台保护设备、分工合作的一组保护设备、在被保护设备前端或设备本身及其一部分安装使用本保护机制的软件,以下简称保护设备),在被访问设备受到DOS或者DDOS攻击时,该保护设备将会接管被访问设备的访问数据流进行数据流检查,为了防止被访问设备崩溃,这时候将会对到达被访问设备的连接数据包进行压制,主要是针对攻击的源头进行数据压制。但不在于识别访问流量中哪些是不“合法”的、无效的流量并加以丢弃,而是识别哪些流量是“合法”的、有效的、或优先的流量并加以区分、保护。可以通过某种区分机制,区分不同类型的用户,根据区分的用户类型保护设备为每类型用户提供一条或多条独立的物理或逻辑通道,进而可以对不同的通道提供不同的访问优先级,使得在被保护设备受到过载访问时,被区分为正常访问或优先访问的用户可以正常访问被保护设备。在被区分为某种用户类型后,本保护机制仍然能区分出在该种类型中不同的用户个体,而且这些用户个体的访问仍受到设定的安全特性控制,从而无法利用所处的通道来攻击被保护设备,一旦已经区分的用户个体访问模式发生改变而导致不符合目前所在用户种类,将会被再次区分,归入其它用户类型。个体用户的区分、识别并不仅仅简单依赖于用户的网络地址或访问端口等网络协议属性,根据区分、识别和算法不同可以识别到不同的精细度(精细度的可能性包括但不限于:某个网络运营商、某个网络自治域、某个地区、某个网络接入服务器、某个IP地址、或某个共享IP地址后面的某台主机、某种服务等)。本保护方法允许保护设备接收外部实时输入用户的区分和判定结果,这就允许被保护对象可以根据自身系统的独有的对于用户的判定标准来决定用户的访问能力。这样,我们在被访问设备受到DOS或者DDOS攻击的时,系统在防止攻击压制连接的情况下,为真正的合法用户开通一个快速的安全通道,这个通道内的用户可以在单个用户安全控制范围内受到保护,优先发送,并不受到系统防止攻击的连接压制影响,同时保证了合法的用户不会攻击被访问设备。
作为实现本发明构思的技术方案是,提供一种在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,基于在被访问设备前端或所述设备本身的保护设备上设置安全通道服务器,构成一个有能力向网络上被选择的用户提供有保障的访问的系统,所述方法包括步骤:
A.安全通道服务器对需要保护的被访问设备的进出数据流进行数据流监控;在必要的情况下进入安全模式,将用户的数据流接管,使数据流通过安全通道服务器;
B.用户得到对应的安全控制授权;
C.安全通道服务器为真正的、被选择的用户开通一个快速的安全通道;
D.安全通道服务器对到达被访问设备的连接数据包进行用户归属辨识;
E.用户在安全通道中访问被保护设备,依据该用户所享有的安全控制授权范围得到保护,优先转发。
上述方案中,所述步骤E中的数据转发采用快速包转发处理方法:
对于TCP数据包,包括步骤:
1)中间的数据包转发服务器,包括所述安全通道服务器,在确定用户的连接可以建立以后,为用户建立到被访问设备的连接;
2)对于该用户连接的后续数据包,包括重传的数据包,保持数据包的大小大致不变,并作处理:
A.对于包括TCP连接包头的IP连接数据包,对所述包头作预定的固定变化,对TCP连接的序列号,使用已经确定的固定差值来计算更换处理,并重新计算校验和;
B.对IP数据包的分片则作透明处理;
对于UDP数据包,包括步骤:
1)在同意可以建立连接以后,中间的数据包转发服务器,包括所述安全通道服务器,对包括UDP包头的IP连接数据包的包头作预定的固定变化;
2)对IP数据包的分片则作透明处理。
上述方案中,所述步骤B~E包括两阶段传输的具体过程:
a)连接建立安全检验阶段:
1)安全通道服务器通知客户端进入安全模式;
2)对用户进行辨识,并作是否“合法”判断;
3)若用户未得到安全控制授权,则对用户进行安全控制授权;
4)在安全控制授权的限制下,辨识数据包归属的用户,并判断用户的连接是否可以建立;
b)数据传输阶段:在安全控制授权的限制下,辨识数据包归属的用户,进行用户的数据传输;
上述方案中,所述步骤D的辨识过程是基于原有的连接进行交互的,对用户的辨识细化到用户的每一个连接。
上述方案中,所述用户的安全控制授权或者接受外界的输入而改变,或者由系统安全模块授予,并在安全保护的过程中动态变化。
采用上述技术方案,能够辨识出真正的单个用户,以及真正的连接需求,即使用户是处于NAT、proxy等设备之后,从而对用户的访问进行区分和控制,避免被访问的网站受到DDOS攻击。如果能够准确的辨识出用户以及用户的数据流,那么单个用户的行为实际上是可以预测的,尤其是与具体的一些网站和应用联系的时候,这种的预测性将会更强!这样,用户的行为是否是一个攻击行为,可以根据为单个用户提供的应用服务正常情况下,单个用户应该具备的行为,进行对比,从而发现用户是否在攻击,从而进行防止。
用户被赋予一定的安全特性等级,用户的访问受到此安全特性的控制。而且此安全特性可以通过外界输入。那么就允许外界服务器根据提供各种应用服务的情况,判断用户的访问行为是否符合此应用服务的安全规定,从而实时更改用户的安全控制。这种方式包括赋予不同的用户访问优先级,从而建立针对用户的差别服务。这样既允许被区分的用户优先访问被保护设备,也同时允许未被区分、识别的用户访问被保护设备,即适应于有使用安全用户客户端的用户和普通用户并发共存的环境。还可以保护被访问设备不会因为处理连接的资源耗尽导致无法为正常的用户的提供服务。为此我们假设一个例子来说明。
假定有一个网站A,带宽为100M,对外提供服务。当到达的网络流量在0-70M之间时,保护设备事实上不做任何处理,所有流量都可以访问A。当到达的网络流量在70-120M之间时,网络流量较大,这时所有的用户访问都可能会受到影响,此时,保护设备开始执行设定的方案。此时,保护设备对区为分高等级用户的流量提供自适应的全优先带宽保护,随着高等级用户的流量的增加,不断地增加高等级用户的总通道带宽。其它未经区分的流量使用剩下的带宽。举例来说,假定高等级用户总带宽为50M,其它用户带宽为60M,如果没有保护设备,对于每个用户来说,都会丢失10%的包,访问受到影响,但采用保护设备后,高等级用户将100%不丢包,普通用户将丢失约20%的包。当到达流量为300M时,网站A处于被DDOS攻击的情况,其中大量的流量应为攻击流量。此时,保护设备执行设定的攻击保护方案。将用户分为三个级别,第一个级别为高等级用户,第二个级别为被“真人识别”(真人识别的意思是辨识用户是一个真正的人在操作,而不是程序在操作)为正常的普通用户,第三个级别为其它用户或无法识别的用户。可以设置将无法识别的流量带宽限制为0,第一、第二个级别根据优先级保护。这样,网站将收不到攻击流量,普通用户依然可以访问。
具体说,采用上述技术方案的特点是:
1、能够在DOS或者DDOS攻击的情况下,为已经被鉴别的合法用户开辟一个快速的安全通道;此通道的优先级较高,不受到其他DDOS攻击数据流的影响。
2、用户被准确的辨识和鉴别;
3、既允许被区分的用户优先访问被保护设备,也同时允许未被区分、识别的用户访问被保护设备,即适应于有使用安全用户客户端的用户和普通用户并发共存的环境;允许用户是被保护的用户或者非保护用户的情况下同时工作;
4、每一个连接都被辨识到归属的用户;
5、能够防止安全通道内的用户进行DOS攻击;
6、可以根据用户的访问情况和应用的特点,确定用户的安全等级,限制用户的非法访问;
7、对于用户的访问“合法性”验证和所属连接的安全等级确定可以本地完成、也支持从外部输入,这种输入是实时生效的。这样就可以使得根据实际的业务服务应用的情况,来确定用户的正常访问定义,不同的业务服务在访问安全要求上可以不同,而且可以在不同的服务阶段,也可以不同。这种情况下,各种应用的对用户行为的判断将可以多样化,独立化。
8、相对于proxy、NAT等技术而言,当时访问业务服务器的用户可以是被辨识的用户,也可以是没有被辨识的用户,自动适应;而并不要求必须全是受到辨识的用户,两种用户可以共存。而且被辨识的用户可以是处于被保护的状态,也可以是正常的使用状态;而且并不需要使用新的IP地址来进行连接的建立。
9、可以追踪到受保护用户的网络位置信息;
10、还可以对NAT或者proxy本身进行一定程度上的保护;
11、安全服务器的数据包转换简单而高效,易于快速实现或者易于硬件实现;中间的处理算法非常简单,适合安全防护的高效处理,尤其是硬件方式的处理(例如采用包处理器来进行处理),使得本身不会成为瓶颈。
附图说明 图1是处于安全模式下的组网示意图
图2是组网中的逻辑用户访问示意图
具体实施方式
下面结合附图所示之最佳实施例进一步阐述本发明。
本发明在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,是基于在被访问设备前端或所述设备本身的保护设备上设置安全通道服务器,构成一个有能力向网络上被选择的用户提供有保障的访问的系统,所述方法包括步骤:
A.安全通道服务器对需要保护的被访问设备的进出数据流进行数据流监控;在必要的情况下进入安全模式,将用户的数据流接管,使数据流通过安全通道服务器;
B.用户得到对应的安全控制授权;
C.安全通道服务器为真正的、被选择的用户开通一个快速的安全通道;
D.安全通道服务器对到达被访问设备的连接数据包进行用户归属辨识;
E.用户在安全通道中访问被保护设备,依据该用户所享有的安全控制授权范围得到保护,优先转发。
附图1是处于安全模式下的组网示意图,该示例中用业务服务器表示被访问设备,因为现在受到攻击最多的就是此种设备;访问所述业务服务器的终端设备Host1和Host2在接入网络中通过NAT设备作地址转换,Host3直接接入网络;所有访问所述业务服务器的网络数据流可以先行经过安全通道服务器(保护设备)。所述安全通道服务器包括单台或多台保护设备,特别是分工合作的一组保护设备;也包括安装使用了本发明方法软件的被访问设备前端或设备本身。在该组网中,被保护用户可以和非保护用户同时并存,为说明问题,设终端设备Host1和Host3为安全通道客户端,Host2为普通客户端。
本发明方案由几部分组成:
●安全通道客户端和安全通道服务器;
●安全服务器中的内含的安全授权模块,外联的安全授权模块;
●安全通道的两阶段传输方法,以及安全通道服务器对安全通道的高效处理;安全通道客户端和安全通道服务器的关系:
每个物理用户(后面附图中的host,也可以看成是一个物理的用户设备,例如主机)可以拥有多个逻辑用户,这与物理用户所访问的应用服务器有关。为用户分配一个用户安全标识(ID),每个ID就表示有一个安全通道的存在!这里所说的用户是指一个安全上的逻辑用户,此逻辑用户对应一个安全通道,安全通道的区分可以是与用户的访问或者应用有关,一般是由被访问的对象所决定的。例如一个物理用户访问的某个或者某一组服务器的服务,是归属于一个安全通道,访问另外的一个服务器是属于另外的安全通道。一个物理的主机(host)上可以有多个逻辑用户的存在,参见附图2。在后续的描述中,如果没有特别说明,那么用户就是指的是逻辑用户。
客户端区分物理用户数据流、建立安全逻辑用户、管理逻辑用户的数据流,客户端与安全模块之间验证用户的身份,安全授权模块对用户的安全特性(等级)进行授权,安全通道服务器对用户的每一个连接进行检查,决定是否建立此连接。
客户端并不限于每一个物理用户一个,可以多个物理用户一个,有很多技术可以非常容易的区分不同的物理用户。附图中仅仅是为了描述方便将客户端与物理用户放在了一起。客户端可以是物理用户本省平台上的软件、也可以是单独的设备。
客户端将工作在两个状态:正常传输状态和安全通道状态。对于每一个连接,客户端都会判断是否是应该安全通道传送还是正常传送,如果是正常传送,那么将不会做任何的动作,直接转发出去,如果是需要安全通道传送,那么客户端将使用两阶段传送方法来进行发送,在两阶段发送方法中,对于未被鉴别的用户,如果需要验证用户,那么还会有验证用户的过程。如果安全传送方式结束,那么将会恢复到正常方式传送。
安全服务器工作在安全监测状态和安全通道保护状态。服务器在安全监测状态的时候,通过观测对服务器的访问数据流或根据预设的条件来判断是否有攻击的情况发生。如果判断到有攻击的情况发生,那么将会转到安全通道保护状态,这时可以采用一些手段(例如通知上级路由器,或者组网上的串接方式),强迫相关访问业务服务器的数据流通过自己。这种情况下,安全通道服务器将会与客户端建立安全通道。如果需要验证用户,那么将会进行用户的验证,并为用户分配唯一性的标识。这是通过内含的安全模块或者外联的安全模块完成的,验证完成实际上也就是安全通道的建立完成。如果用户已经验证过,那么将使用两阶段传送方法传送用户的连接请求,在建立连接的过程中,必须对连接是否满足用户的安全特性(等级)做出判断,满足安全特性规定的才能建立这个连接。安全通道服务器在攻击的情况下完成两个功能,一个是防攻击的连接压制,一个是优先传送安全通道的连接,而且将会根据安全连接的数量进一步调整防攻击情况下的压制参数。在安全通道内,对于DDOS中大连接数量的攻击,由于两阶段连接中对每一个连接(TCP/UDP)都进行了判断,同时可以准确的辨识连接所属于的用户,因为单个用户的行为实际上是可以预测的,尤其是与具体的一些网站和应用联系的时候,这种的预测性将会更强。这样,用户的行为是否是一个攻击行为,可以根据为用户提供的应用服务正常情况下,用户应该具备的行为,进行对比,从而发现用户是否在攻击,并可以控制用户的访问,防止用户在安全通道内进行攻击。对于TCP连接建立阶段的攻击,安全服务器在用户开始时并不记录连接的相关信息,只是在用户端使用两阶段传输方法时,在连接请求阶段,使用恢复连接的方式来防止。
安全授权模块:
安全授权模块(内含或者外联),主要完成以下功能:
●用户的合法性验证和唯一性标识;
●用户访问的安全等级或者特性授权;
如果使用外联的安全模块,那么安全通道服务器将需要与外联模块建立信任关系,这个已经有很多成熟的方法。
用户的连接在安全模式下是否建立,取决于用户是否合法、以及合法用户的此次访问是否满足安全的特性(等级)要求。用户是否合法,就是是否是允许此用户在安全模式下有权建立安全通道。而后续连接访问的合法性判断,就是判断用户在此安全通道中的访问是否满足此用户目前所被允许的安全特性(等级)的规定。安全授权模块将验证用户是否合法,并且将对此用户的安全特性(等级)进行授权,同时,方案中支持外界(例如业务服务器)通过外联的安全模块(或者本身就是外联安全模块的一部分)将用户此时刻对应的安全特性(等级)传递到安全服务器,安全服务器将根据此来判断用户的连接访问是否符合安全规范。
用户的合法性确定是通过用户验证来完成的。用户的验证只是一个抽象的说法,实际上主要就是对用户的合法性做出判断,这个可以有很多种办法,可以通过传统的用户名加口令的方式,也可以采用无认证方式,或者其他一些认证的算法,这个已经非常成熟,不再多描述。认证完成以后,需要完成的一件重要的事就是分配一个唯一的ID给用户(分配方式有很多种方法可以达到唯一性,这里不再描述),确认用户已经通过验证,获得建立安全通道的许可。此ID结合用户一些恒定的信息(例如用户使用的IP地址)将会唯一标识用户。此ID非常重要,不应该被用户猜到其中的分配规律性。同时客户端可以将本端印鉴发给安全服务器,作为以后防攻击的一部分。此印鉴也最好是包含了一些没有规律性的信息(例如最简单的就是含有随机数)。在判断连接的合法性时,只有全信息(其中包含了用户的ID、用户本端印鉴、以及后续描述中的一些本连接的特有信息)都匹配的情况下,才合法。
注:用户本端印鉴是指用户在验证过程中,自己提供一个特有的标识,作为自己的合法证明的一部分,就像银行中要求的本人签名与预留的签名对应,预留的签名可以看成是一种本端的印鉴。这有很多中实现方法,不再累述。
用户访问的合法性安全特性(等级)的确定,可以从两个时机来确定,一个是用户验证完毕的时候,根据用户的验证情况来决定;一个就是中间对用户的行为分析以后,觉得需要变更安全特性(等级),这可以通过外界通过外联安全模块传递给安全通道服务的安全连接控制部分来进行控制。对用户行为的分析可以又很多种,例如判断用户端的操作者、操作特性、目前进展到的时序、历史访问的情况等等。这就会有一个非常好的效果,用户行为的安全判断的可以交给外界提供业务的服务器进行判断,与具体的服务类型挂钩,每一种服务的安全特性、安全的阶段时序性都可以不一样,这种情况下,用户的第一次验证合法性判断将可以不那么严格(例如并不要求用户有用户名、口令的验证),而是在用户端第一次访问时,确认可以作为一个普通用户,分配一个较严格的安全特性,在后续服务的过程中,逐渐的根据服务的特性,提高用户的安全特性(等级)。这种使用特性可以使得业务服务器可以为一些普通的、没有注册的用户提供服务,大大的提高用户面。
为了更加清楚的描述我们的思想,给出几种现实中可被使用的案例:
a)用户可以作为一个不认证的用户验证通过,获得较为严格的安全性的限制,用户可以通过一个“真人识别”页面成为一个正常访问用户(比如,通过识别一个仅人眼可以识别的有背景花纹或变形的字母图案(保护无法被计算机设备OCR识别,同时无规律),要求用户输入正确的字母组合进行认证),这个时候的安全特性将会变更;
b)用户可以作为一个不认证的用户验证通过,获得较为严格的安全性的限制,用户在网站的访问行为被网站进行了记录分析,该访问行为符合正常的使用者的规律。网站通过外联的授权模块,通告安全服务器变更此用户的安全特性。
根据验证和授权的方式不同,一般有以下几种方式,参见附图2:
方案1:完全依赖与安全服务器的内置安全授权模块进行,内置的安全模块验证用户,分配用户的ID,根据用户的访问行为来决定当前用户的安全服务等级,并根据等级作出控制;
方案2:安全服务的内置安全模块将用户的身份信息送到对应的外联用户安全模块验证,外联模块返回结果、还可以授权,安全服务器分配用户的ID,根据授权决定用户的安全服务等级,并根据等级作出控制;
方案3:在用户验证授权(可以是安全服务器内部验证或者外界验证)、安全服务器分配ID以后,在为用户的服务过程中,获得用户ID,判断用户的行为,根据用户的行为,更改指定用户安全等级或安全权限,将此信息传递给安全服务器,安全服务器根据此进行控制;方案4:外联的安全模块将完成用户认证,分配用户ID,同时在为用户的服务过程中,获得用户ID,判断用户的行为,根据用户的行为,更改指定用户安全等级或安全权限,将此信息传递给安全服务器,安全服务器根据此进行控制;
安全防护状态下的通道传输方法,两阶段传输方法(协议):
两阶段主要是这样的两个阶段:安全连接建立阶段,数据传送阶段。安全连接阶段还含有一个用户验证的子阶段。
为了穿越中间的NAT/PROXY等设备,必须利用用户原有的连接,在此连接上完成安全防护。仅仅修改连接的目的端口号,使得连接可以辨识为安全通道。采用只修改端口号而不是修改IP地址的方式,主要是为了安全服务器不会因此而需要占用额外的IP地址来与应用服务器之间进行连接的区分(就类似NAT区分不同的用户连接一样)。连接分成两种TCP、UDP,而对应的具体的方式又不一样。
注意:这里采用的是仅仅修改目的端口的方法来标识安全通道的存在,如果有其他实现,例如采用修改IP地址的方式,而没有其他的变化,那么应该还是本方法的一部分。
TCP:
安全连接阶段:
●客户端将会接管用户的连接,发送新的安全连接SYN,打通到安全服务器的通道;
●此阶段安全服务器针对每一个TCP SYN都会回答,并完整的完成与用户的3次握手,但是为了防止对安全服务器的攻击,并不保存此连接,也就没有自动机的保存,仅仅是数据包的回应,主要是让客户端完成TCP自动机;
●在完成3次握手以后,安全通道服务器通知客户端可以请求安全连接,并同时返回此次连接的cook;cook是通过某种算法生成的,每次都不一样。
●客户端将会进行安全连接请求,这时会带上用户的ID、用户本端印鉴、连接cook、真正需要建立的连接等等;
●安全服务器将会根据用户的状态以下情况,进行不同的后续动作:
如果安全阶段解除,那么会通知客户端恢复正常工作状态;
如果此用户已经是一个安全用户,并通过用户鉴别(合法性辨识,根据用户的ID、用户本端印鉴、连接cook),那么将会根据当前的安全服务特性(等级),进行连接安全性判断,例如已经存在的连接数量、连接请求的速率等等,如果没有通过安全判断,那么此连接将会关闭,如果通过安全检查,那么安全服务器就会恢复此连接,
并与业务服务器建立连接,如果成功,则通知客户端,将会进入数据传送阶段。数据传送阶段:
在完成连接建立以后,实际上安全性已经完全的判断完毕,所以后续是透明的转发数据,仅仅对包头中数据做简单变化,而数据包的大小不变,这样进到安全服务器的数据包和出安全服务器的数据包的序列号变化就相当的简单,序列号的转换将一直都是初始的差值,这样可以做到简单的加上初始的差值来一一对应,这样安全服务器对于TCP的重传等等都可以透明化的处理!不需要去维护TCP的状态,也不需要TCP的定时器维护。这一点(仅仅是数据包序列号的简单变化)非常重要,这样将会使得转发时安全服务器的处理非常简化,并不需要处理TCP自动机,有利于硬件的实现。如果发现连接关闭的数据包,那么进行连接的关闭。
进入数据传送阶段以后,客户端与安全服务器之间将不会再有控制信息的出现,也没有必要出现!除非是结束连接。因为这样的序列号将不会再有新的变化,这非常重要,决定安全通道服务器的处理复杂性!(涉及到TCP重传,序列号的计算,这种方法下,重传已经透明化的处理了)
对于IP分片的处理,安全服务器仅仅需要处理第一片IP数据包中的TCP包头即可。其余的数据包无须处理。这样可能导致TCP包头分片情况下无法处理,但是目前IP层次的数据包在正常使用的过程中还没有这样(TCP包头分片)的小包。
数据传送阶段的处理是非常重要的,因为采用尽可能的简单的处理将会大大的提高处理性能,我们的方案在数据传输阶段,将仅仅修改TCP包头,然后直接转发数据包,对于分片的数据包,也是如此处理,直接转发非第一个TCP包头的数据包,这样就无须处理TCP的自动机和参数调整,这样复杂的TCP处理就完全省略了。
UDP:
UDP因为没有SYN等等的攻击,那么相对而言就简单一些。
●客户端将会接管用户的连接,打通到安全服务器的通道;
●安全服务器通知客户端可以请求安全连接,并同时返回此次连接的cook;cook是通过某种算法生成的;cook是通过某种算法生成的,每次都不一样。
●客户端将会进行安全连接请求,这时会带上用户的ID、用户本端印鉴、连接cook、真正需要建立的连接等等;
●安全服务器将会根据一下情况完成:
如果此用户已经是一个安全用户,并通过用户鉴别(合法性辨识,根据用户的ID、用户本端印鉴、连接cook),那么将会根据当前的安全服务特性(等级),进行连接安全性判断,例如已经存在的连接数量、连接的速率等等,如果没有通过安全判断,那么此连接将会关闭,如果通过安全检查,那么安全服务器就会恢复此连接,并与业务服务器建立连接,如果成功,则通知客户端,将会进入数据传送阶段。数据传送阶段:
在完成连接建立以后,实际上安全性已经完全的判断完毕,所以后续是透明的转发数据,因为UDP没有序列号问题,那么转发时安全服务器的处理非常简化,有利于硬件的实现。对于分片的处理,与TCP的一样。
下面以几种情况下的详细处理过程进一步阐述本发明方法:在我们的案例中,假设是软件实现的客户端,安装在用户的PC机上。同时使用内含的安全授权模块。
TCP穿越(FOR NAT & PROXY):
1.用户发送数据包,安全通道客户端截获;
2.安全通道客户端判断此数据包是否需要通过安全通道,如果无需通过,那么透明发送;否则进行后续安全发送处理;
3.安全通道客户端对用户发送的数据包根据情况处理:
●如果是用户新建连接;转到“步骤:安全新建连接阶段”;
●用户发送其他相关连接信息包;转到步骤:安全通道发送阶段;
●用户发送数据包;转到步骤:安全通道发送;
安全新建连接阶段:
4.安全新建连接:用户设备发送TCP SYN0,安全通道客户端截获,安全通道客户端发送TCPSYN1(使用安全通道的端口替换SYN0中的目的端口);——使用约定的端口标识着正在使用安全模式!
5.NAT或者proxy,收到并处理此连接,虽然模式和过程有所差别,但最后都需要发送SYN 2;
6.安全通道服务器收到SYN2,进行连接有效性判断——判断是否真正有需要连接的IP存在,通过TCP cook验证的方式,防止伪造IP的攻击;
7.安全通道服务器收到连接完成的ACK2以后,这时与NAT或者proxy之间的连接已经建立,那么可以通过此连接来传送安全协议的数据,目前有两种回答:
●目标的安全通道方式解除,告知客户端以后使用正常模式,本连接关闭;
●继续使用安全通道方式,通知安全通道客户端可以使用安全通道请求连接(回答中包含连接的cook——就是上面步骤6中的cook);
8.客户端收到继续使用安全通道的回答以后,表明此连接可以建立安全转发;发送请求连接建立的安全协议数据包,协议包含安全通道服务器连接恢复需要的信息和相关的用户ID、用户端的印鉴、以及cook;
9.安全通道服务器收到连接请求以后,检查是否用户ID、用户端的印鉴等等连接信息进行匹配,将此作为一个安全用户的连接来进行管理。这个时候才恢复连接。
10.如果此用户需要验证,那么将返回需要认证的协议数据包;转到“安全通道客户端验证流程”!当前连接将会关闭;
11.如果用户已经是一个验证的安全用户,那么下一步是进行用户安全特性(例如是否并发连接超过限制、连接请求速率过大等等)判断:
●通过,可以向服务器请求建立此已经经过验证的连接;这时安全通道服务器利用请求协议数据包的数据,真正恢复此连接;
●如果没有通过安全判断,那么将返回不予连接的数据包;关闭当前连接;
12.安全通道服务器与业务服务器建立连接阶段,目前安全通道服务器必须与服务器完成3次握手;安全服务器向业务服务器发起连接时,可以使用此时客户端发送过来TCP的序列号减1,因为TCP初始连接期间的序列号就只有这个变化,这样可以数据传送阶段仅仅处理业务服务器发给安全服务器的数据包的序列号以及对应的ACK中的序列号;
13.安全通道服务器连接建立成功,那么直接向安全通道客户端发送成功消息,告知客户端连接成功,可以进入数据传送阶段;
14.客户端收到对应的回答,进入安全数据传送阶段;
15.安全数据传送阶段:
●安全通道客户端将透明的传送用户发出的TCP数据,但是修改对应的TCP头(目的端口、ACK序列号);
●安全通道服务器判断连接,双向的转发对应的TCP数据,转换对应的TCP头(目的端口、ACK序列号)
●安全通道客户端接受数据,然后发给用户端;
注:进入数据传送阶段以后,将不会再有控制信息的出现,也没有必要出现!因为这样的序列号将不会再有新的变化,序列号的转换将一直都是初始的差值,这非常重要,决定安全通道服务器的处理复杂性!(涉及到TCP重传,序列号的计算,这种方法下,重传已经透明化的处理了)
16.如果发现有FIN或者RST等数据包,结束连接。
UDP的穿越(FOR NAT & PROXY):
1.用户发送数据包,安全通道客户端截获;
2.安全通道客户端判断此数据包是否需要通过安全通道,如果无需通过,那么透明发送;否则进行后续安全发送处理;
3.安全通道客户端对用户发送的数据包根据情况处理:
●如果是用户新建连接,转到“步骤:安全新建连接”;
●用户发送数据包;转到步骤:安全通道发送;
安全新建连接阶段:
4.安全新建连接:用户发送UDP0,安全通道客户端截获,安全通道客户端发现是新的连接,那么发送UDP1(使用安全通道的端口替换SYN0中的目的端口)协议数据包申请建立新安全连接通道;——使用约定的端口标识着正在使用安全模式!
5.NAT/proxy处理,发送的是UDP2;
6.安全通道服务器收到UDP2,也就是收到客户端连接建立请求以后,有两种回答:
●目标的安全通道方式解除,告知客户端以后使用正常模式,安全通道关闭;
●继续使用安全通道方式,通知安全通道客户端可以使用安全通道请求连接(回答中包含连接的cook,验证客户端是否真的存在;一一来确定是否存在真的客户端存在,而不是伪造攻击;)
7.安全通道客户端收到继续使用安全通道的回答以后,表明此连接可以建立安全转发;发送请求连接建立的协议数据包,协议包含安全通道服务器连接恢复需要的信息和相关的用户ID、用户端的印鉴、以及cook;
8.安全通道服务器收到连接请求以后,检查是否用户ID匹配,将此作为一个安全用户的连接来进行管理;
9.如果此用户需要认证,那么将返回需要认证的协议数据包;转到“安全通道客户端认证流程”!当前连接将会关闭;
10.如果用户已经是一个验证的安全用户,那么下一步是进行用户安全特性(例如是否连接过多、速率过大等等)判断:
●通过,可以向服务器请求建立此已经经过验证的连接;这时安全通道服务器利用请求协议数据包的数据,真正恢复此连接;
●如果没有通过安全判断,那么将返回不予连接的数据包;关闭当前连接;
11.由于UDP的特性,安全通道服务器连接建立成功,那么直接向安全通道客户端发送成功消息,告知客户端连接成功,可以进入数据传送阶段;
12.客户端收到对应的回答,进入数据传送阶段;
13.安全数据传送阶段:
●客户端将通过数据隧道方式传递用户的UDP数据包,此数据包客户端将已经完全封装好,安全通道服务器仅仅是拆掉封装进行转发;
●安全通道服务器同时将从业务服务器收到的数据包进行隧道封装发送给客户端;
●客户端接受数据,然后发给用户端;
14.允许连接结束的控制消息在数据发送阶段出现;
注:因为UDP的特性,所以在数据传送阶段,允许连接控制消息出现,来控制连接,而TCP通过FIN、RST等等就可以控制连接了。
用户直接访问,没有NAT和proxy等中间的设备出现:
客户端与服务器端流程与上面有PROXY或者NAT的情况一样。没有任何差别。
如何辨识什么时候使用安全模式:
客户端和服务器如何辨识什么时候使用安全模式,需要解决以下两个问题:
●安全通道客户端:如何辨识对方有安全通道服务器的存在,安全通道服务器的特性是什么。
●安全通道服务器:通过对访问业务服务器数据流的监测,决定什么时候处于安全模式的情况下,在此时,如何辨识对端有客户端的存在;
有很多的方法可以解决此两个问题,下面是其中的两种方法:
方法1:
安全通道客户端手动指定:那些站点优先使用安全模式(可以通过安全的控件方式,由站点自己加入,这时需要征求用户的意见,是否加入此站点);
安全通道服务器通过被访问(目的端口),进而发现客户端的存在;
方法2:
安全通道客户端同时提供手动的模式;
安全通道客户端缺省是处于正常连接状态,监控正常连接;
安全通道服务器在一旦进入安全模式,发现访问的站点需要保护了,而且此连接将会因为连接性能控制原因被丢弃,那么将会通过验证用户是否需要建立此连接(回应一个SYN ACK(cook方式),然后ACK以后)以后,直接返回一个协议数据包(告知客户端需要进入安全模式),然后发送关闭连接的数据包。——因为通过特殊的协议组合字节,被重复的概率应该小的多的多!即使发生了重复,也会被后续的动作自动纠正。
安全通道客户端收到此数据包,将会知道有需要进入安全模式,可以自动进入或者提示用户,并且可以记录下对应的安全访问安全通道服务器;
如果客户端不存在,那么将会不予理睬此数据包,但是连接将会关闭。
安全通道服务器通过被访问,也同时可以发现客户端的存在。
本实施例中的两阶段传输协议的数据包格式定义为:
(1字节) (1字节) (1字节) (1字节)
协议可以承载在TCP或者UDP之上,但是承载在UDP上的控制消息是必须保证可靠传输的。采用包的序列号来保证请求和回答的匹配,每一次包发送的序列号都必须不一样。
版本号:0X00保留,目前合法值0X01;
消息种类:0X00保留
●身份认证的消息:
认证方法请求、回应;消息(0X01 0X02)
认证请求、回应; 消息(0X03 0X04)
●命令消息:
连接建立请求、回应; 消息(0X05 0X06)
连接结束; 消息(0X07)
安全连接是否建立通知; 消息(0X09)
身份认证通知; 消息(0X11)
●数据传送消息; 消息(0X20)
其中,认证方法请求、回应消息可以采用上述数据包的通用格式,客户端发送请求,服务器端发送回应,另外认证算法(1字节)的定义为:
0x00 无验证需求
0x01 CHAP
0x02 PAP
0x03 至X′7F′保留,预备IANA给分配(IANA ASSIGNED)
0x80 至X′FE′私人方法保留(RESERVED FOR PRIVATE METHODS)
0xFF 无可接受方法(NO ACCEPTABLE METHODS)
则请求报文格式为:
(1字节) (1字节) (1字节) (1字节)
回应的报文格式为:
(1字节) (1字节) (1字节) (1字节)
其中,支持的算法参数与具体的算法有关,在CHAP时,就是challenge。
认证消息:
认证请求消息的格式:
(1字节) (1字节) (1字节) (1字节)
其中PAP算法:
(1字节) (由长度域指定)(1字节) (由长度域指定)
CHAP算法:
(1字节) (由长度域指定)(1字节) (由长度域指定)
认证回应消息的格式:验证结果(1字节)
其中00表示认证通过:0X00
用户ID;
其他错误原因代码,目前暂时保留未定义;
连接请求消息:
(1字节) (1字节) (1字节) (1字节)
其中,连接请求内容的格式为:
其中连接COOK与在服务器端返回的“安全连接是否建立通知消息”中的一样。
连接类型 0X01 TCP连接,
0X02 UDP连接;
0X00 表示UDP申请一个新的安全连接(TCP不需要,因为SYN已经代表了此项要求)
连接请求回应消息:
(1字节) (1字节) (1字节) (1字节)
其中,回应内容:0X00 通过,进入数据传送阶段;
0X01 需要重新身份认证,报文格式0X01|认证目的IP|目的端口
0X02 -0X128 保留;
0x129 -0x255自定义原因;
身份认证通知消息:
(1字节) (1字节) (1字节) (1字节)
连接结束通知消息:
(1字节) (1字节) (1字节) (1字节) (6字节)
安全连接是否建立通知消息:
(1字节) (1字节) (1字节) (1字节)
如果源地址、源端口、连接cook全0,表示安全通道方式解除。
源地址、源端口是从收到的IP数据包中学习而来的。
数据传送消息:此消息仅仅用于UDP方式的传送,消息的格式如下
其中,封装内容是客户端根据服务器端返回的连接内容,构造一个类似NAT或者proxy发出的IP/UDP数据包,这样将会减少安全通道服务器的转换工作量。
与现有技术相比,本发明实施例可行并具有如下优点:
1.能够在DOS、DDOS攻击的情况下,为用户开辟一个快速的安全通道;并不会因为攻击导致对真正的用户无法提供服务;
2.DDOS、DOS攻击从本质上来说,是一种负荷过载的攻击方式,所以我们的方案范围包括过载的情况下,同样可以对服务器、用户进行保护;
3.用户被准确的辨识;这样如果用户进行攻击,可以非常容易发现和定位,如果是有人有意攻击,那么定位有利于整个网络安全次序的建立,如果是因为病毒等原因,那么可以提醒用户进行杀毒等增值业务;
4.能够防止安全通道内的用户进行DOS攻击;
5.安全服务器的数据包转换简单而高效,易于快速实现或者易于硬件实现;
6.相对于proxy等等的技术而言,访问业务服务器的用户可以是被保护的用户,也可以是没有被保护的用户,自动适应;而并不要求必须全是受保护的用户,两种用户可以共存使用。用户可以是处于被保护的状态,也可以是正常的使用状态;
7.还可以对NAT或者proxy本身进行一定程度上的保护;
8.可以接受外界对用户安全服务的等级指定,而这种指定可以是通过对用户行为的分析而实时确定的,而且可以与不同的具体应用服务的需求直接挂钩,这样安全的保护范围扩大而且非常的灵活。
9.针对VPN等等的实现方案,并一定需要用户进行用户名、口令方式的认证,而是可以在初始使用严格的安全限制,通过根据通过判定用户的安全性,使用变化用户的安全等级来决定为用户提供服务,而且此安全的特性也可以因为用户的行为更加严格,来对用户进行限制。
10.既能针对TCP/UDP的协议方式提供具体的方法,也能适用于其它非IP协议。
Claims (9)
1.一种在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,基于在被访问设备前端或所述设备本身的保护设备上设置安全通道服务器,构成一个有能力向网络上被选择的用户提供有保障的访问的系统,所述方法包括步骤:
A.安全通道服务器对需要保护的被访问设备的进出数据流进行数据流监控;在必要的情况下进入安全模式,将用户的数据流接管,使数据流通过安全通道服务器;
B.用户得到对应的安全控制授权;
C.安全通道服务器为真正的、被选择的用户开通一个快速的安全通道;
D.安全通道服务器对到达被访问设备的连接数据包进行用户归属辨识;
E.用户在安全通道中访问被保护设备,依据该用户所享有的安全控制授权范围得到保护,优先转发。
2.根据权利要求1所述在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,其特征在于:包括所述步骤E中的数据转发采用快速包转发处理方法:
对于TCP数据包,包括步骤:
1)中间的数据包转发服务器,包括所述安全通道服务器,在确定用户的连接可以建立以后,为用户建立到被访问设备的连接;
2)对于该用户连接的后续数据包,包括重传的数据包,保持数据包的大小大致不变,并作处理:
A.对于包括TCP连接包头的IP连接数据包,对所述包头作预定的固定变化,对TCP连接的序列号,使用已经确定的固定差值来计算更换处理,并重新计算校验和;
B.对IP数据包的分片则作透明处理;
对于UDP数据包,包括步骤:
1)在同意可以建立连接以后,中间的数据包转发服务器,包括所述安全通道服务器,对包括UDP包头的IP连接数据包的包头作预定的固定变化;
2)对IP数据包的分片则作透明处理。
3.根据权利要求1所述在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,其特征在于:
所述步骤D的辨识过程是基于原有的连接进行交互的,对用户的辨识细化到用户的每一个连接。
4.根据权利要求1所述在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,其特征在于:
所述系统既允许被区分的用户优先访问被保护设备,也同时允许未被区分、识别的用户访问被保护设备,即适应于有使用安全用户客户端的用户和普通用户并发共存的环境。
5.根据权利要求3所述在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,其特征在于,所述辨识包括:
1)用户通过各种主动或者被动的方式获得合法性的验证;
2)每一个合法的用户将会获得一个身份标示;
3)用户在每一个需要安全建立的连接之前,带上此标示,作为安全连接的验证手段。
6.根据权利要求1所述在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,其特征在于,所述步骤B~E包括两阶段传输的具体过程:
a)连接建立安全检验阶段:
1)安全通道服务器通知客户端进入安全模式;
2)对用户进行辨识,并作是否“合法”判断;
3)若用户未得到安全控制授权,则对用户进行安全控制授权;
4)在安全控制授权的限制下,辨识数据包归属的用户,并判断用户的连接是否可以建立;
b)数据传输阶段:在安全控制授权的限制下,辨识数据包归属的用户,进行用户的数据传输;
7.根据权利要求1或5所述在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,其特征在于:
所述用户的安全控制授权或者接受外界的输入而改变,或者由系统安全模块授予,并在安全保护的过程中动态变化。
8.根据权利要求4所述在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,其特征在于,对于用户的合法性判断内容包括:
用户行为是否具有合理性、用户是否是一个包括自然人在内的合适用户、用户的用户名和密码、或用户行为统计的结果是否合理。
9.根据权利要求1所述在受到DOS攻击或者其他设备过载访问下,对所选择用户提供有保障访问的方法,其特征在于,被所述安全控制授权范围限制的内容包括:
用户DOS或DDOS攻击的防止、用户连接的建立、连接建立的速率和数量、用户数据转发的优先级、用户的流量、或用户的路由。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2005100362658A CN1905553B (zh) | 2005-07-28 | 2005-07-28 | 在dos攻击或者设备过载时保障所选用户访问的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2005100362658A CN1905553B (zh) | 2005-07-28 | 2005-07-28 | 在dos攻击或者设备过载时保障所选用户访问的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1905553A true CN1905553A (zh) | 2007-01-31 |
CN1905553B CN1905553B (zh) | 2011-04-20 |
Family
ID=37674679
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2005100362658A Expired - Fee Related CN1905553B (zh) | 2005-07-28 | 2005-07-28 | 在dos攻击或者设备过载时保障所选用户访问的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1905553B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101594269B (zh) * | 2009-06-29 | 2012-05-02 | 成都市华为赛门铁克科技有限公司 | 一种异常连接的检测方法、装置及网关设备 |
CN108696498A (zh) * | 2017-03-31 | 2018-10-23 | 三星电子株式会社 | 检测和防范对计算机存储阵列的拒绝服务攻击的系统 |
CN109088878A (zh) * | 2018-09-03 | 2018-12-25 | 中新网络信息安全股份有限公司 | 一种抗拒绝云防护系统的报文处理方法 |
CN109361784A (zh) * | 2018-12-07 | 2019-02-19 | 成都知道创宇信息技术有限公司 | 一种在四层代理网络环境下获取客户端真实ip的方法 |
CN109639699A (zh) * | 2018-12-24 | 2019-04-16 | 华为技术有限公司 | 一种网络管理方法和装置 |
CN115514561A (zh) * | 2022-09-21 | 2022-12-23 | 贵州电网有限责任公司 | 一种数据安全通信系统及方法 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004248198A (ja) * | 2003-02-17 | 2004-09-02 | Fujitsu Ltd | DoS攻撃防御方法及び装置 |
CN1555170A (zh) * | 2003-12-23 | 2004-12-15 | 沈阳东软软件股份有限公司 | 流过滤防火墙 |
KR100566988B1 (ko) * | 2003-12-31 | 2006-04-04 | 엘지전자 주식회사 | 차세대 이동통신 시스템에서 패킷 착신호의 오디비 처리장치 및 그 방법 |
-
2005
- 2005-07-28 CN CN2005100362658A patent/CN1905553B/zh not_active Expired - Fee Related
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101594269B (zh) * | 2009-06-29 | 2012-05-02 | 成都市华为赛门铁克科技有限公司 | 一种异常连接的检测方法、装置及网关设备 |
CN108696498A (zh) * | 2017-03-31 | 2018-10-23 | 三星电子株式会社 | 检测和防范对计算机存储阵列的拒绝服务攻击的系统 |
US11140198B2 (en) | 2017-03-31 | 2021-10-05 | Samsung Electronics Co., Ltd. | System and method of detecting and countering denial-of-service (DoS) attacks on an NVMe-oF-based computer storage array |
CN108696498B (zh) * | 2017-03-31 | 2022-11-15 | 三星电子株式会社 | 检测和防范对计算机存储阵列的拒绝服务攻击的系统 |
CN109088878A (zh) * | 2018-09-03 | 2018-12-25 | 中新网络信息安全股份有限公司 | 一种抗拒绝云防护系统的报文处理方法 |
CN109361784A (zh) * | 2018-12-07 | 2019-02-19 | 成都知道创宇信息技术有限公司 | 一种在四层代理网络环境下获取客户端真实ip的方法 |
CN109361784B (zh) * | 2018-12-07 | 2021-09-21 | 成都知道创宇信息技术有限公司 | 一种在四层代理网络环境下获取客户端真实ip的方法 |
CN109639699A (zh) * | 2018-12-24 | 2019-04-16 | 华为技术有限公司 | 一种网络管理方法和装置 |
CN115514561A (zh) * | 2022-09-21 | 2022-12-23 | 贵州电网有限责任公司 | 一种数据安全通信系统及方法 |
Also Published As
Publication number | Publication date |
---|---|
CN1905553B (zh) | 2011-04-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1555170A (zh) | 流过滤防火墙 | |
CN1833403A (zh) | 通信系统、通信装置、通信方法及用于实现这些的通信程序 | |
CN1855847A (zh) | 公共与专用网络服务管理系统和方法 | |
CN1266875C (zh) | 内容发布/接收方法 | |
CN1615632A (zh) | 用于支持有线和无线客户端和服务器端认证的方法的机制 | |
CN1574792A (zh) | 用于执行网络防火墙的基于多层的方法 | |
CN100338597C (zh) | 信息处理设备和方法 | |
CN1905553A (zh) | 在dos攻击或者设备过载时保障所选用户访问的方法 | |
CN1574791A (zh) | 用于集成多个网络策略的方法和框架 | |
CN1574764A (zh) | 用于管理基于网络过滤器的策略的方法 | |
CN1701573A (zh) | 远程访问虚拟专用网络中介方法和中介装置 | |
CN1600011A (zh) | 包含安全性关联处理器的虚拟专用网络机制 | |
US20090064307A1 (en) | Systems and/or methods for streaming reverse HTTP gateway, and network including the same | |
CN1518823A (zh) | 使用会话追踪的动态分组过滤器 | |
CN1689367A (zh) | 安全装置的安全和保密性增强 | |
CN1969501A (zh) | 安全地产生共享密钥的系统和方法 | |
CN1685689A (zh) | 控制家庭终端的装置、方法和计算机软件产品 | |
CN101040497A (zh) | 防火墙系统和防火墙控制方法 | |
CN1848766A (zh) | 管理专用网络之间的网络服务的系统和方法 | |
CN101052946A (zh) | 用于控制对电子消息接收者的访问的系统和方法 | |
US8780386B2 (en) | Systems and methods for enabling and implementing real-time facsimile over internet protocol | |
CN101064628A (zh) | 家庭网络设备安全管理系统及方法 | |
CN1531284A (zh) | 网络基础结构的保护及控制信息的安全通信 | |
CN1780219A (zh) | 终端远程操作系统和方法,网关服务器,终端及控制设备 | |
CN1855825A (zh) | 计算机系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110420 Termination date: 20180728 |
|
CF01 | Termination of patent right due to non-payment of annual fee |