防止在高速网络中受到攻击的方法

技术领域

本发明涉及防止在高速网络中受到攻击的技术领域，具体地说，涉及一种防止目标在高速网络中受到攻击的方法和模块。本发明还涉及一种具有计算机可读媒体和存储在计算机可读媒体上的具有程序编码装置的计算机程序的计算机程序产品有关，所述程序编码装置适于在所述计算机程序在计算机上运行时执行上述方法。此外，本发明还涉及在高速网络中处理请求的方法。

背景技术

在高速网络中，数据交换根据诸如TCP/IP或InfiniBand之类的标准化协议进行。这种网络中节点之间的通信由保证所涉及的网络节点之间的正确数据传送的所谓握手协议发起。这样，网络中的一些所谓发起方的节点能够使用其他节点(下称为目标)提供的服务。因此，发起方将请求发送给提供发起方所需的服务的目标。

在网络中，诸如拒绝服务攻击之类的攻击的特征为攻击方明显试图阻止服务的合法用户使用该服务。这可以通过分别使用虚假地址或源ID以及发送需要资源的大量请求使网络中的目标溢出(flood)，从而阻止服务器正常工作来实现。

拒绝服务攻击可以导致许多使用网络的组织在时间和金钱上受到重大损失。

一种已知的方法是采用包括含有特定参数的发起消息、第一问题消息、含有所述参数的对问题的答案和最终消息的4向握手协议。然而，对于一些遵从预先规定的握手消息序列的协议来说，这种解决方案并不能有效地防止溢出攻击。

发明内容

本发明的目的是提供一种防止目标在高速网络中受到攻击的方法和模块，这克服了现有技术的已知缺点。具体地说，本发明的目的是提供一种处理高速网络中的请求、防止目标在网络中受到攻击的方法，这能够确保网络中所有服务的无限制可用性。

这些目的是通过采用具有如权利要求1所述的特征的防止在高速网络中受到攻击的方法、具有如在权利要求9中所述的特征的防止在高速网络中受到攻击的模块和具有如在权利要求16中所述的特征的处理高速网络中的请求的方法来达到的。

按照本发明，提出了防止目标在高速网络中受到攻击的方法，包括下列步骤：在从由与网络中的特定节点相关联的源ID标识的发起方接收到请求后，产生问题；将问题发送给由源ID标识的节点；在接收到对问题的答案的情况下，评估这个答案；以及在接收到适当答案的情况下，通过将另一个消息，例如准备接收消息，从目标发送给发起方使发起方与目标之间可以进行通信。

采用本发明，可以防止在网络中受到通过将大量的请求从使用虚假源ID的发起方发送给目标而引起的拒绝服务攻击。

按照优选实施例，按照本发明设计的方法可以嵌入在3向(3-way)握手协议中。

有益的是，产生问题和评估答案的步骤在独立的模块中执行。这个独立的模块可以纳入硬件模块中，诸如逻辑芯片、PLD或FPGA，以得到高的处理速度。

优选的是，发送给发起方的问题包括与源ID和目标相关联的参数。问题可以加密，以便进一步提高按照本发明所设计的这种方法的可靠性。

按照优选实施例，按照本发明设计的方法还包括在表中输入与发起方有关的信息的步骤。因此，就有可能发现在特定发起方与目标之间的连接的数量或请求的数量。一旦所发现的连接或请求的数量超过预定值，就不再建立连接，以防止该特定发起方使目标溢出。

有益的是，网络为提供高速度和高性能的InfiniBand网络。

此外，本发明涵盖了一种防止目标在高速网络中受到攻击的模块，这种模块包括产生由请求触发的问题的装置和评估对问题的答案的装置。

优选的是，这种模块纳入在硬件模块中，诸如逻辑片、FLD或FPGA。这个硬件模块可以整合在网络适配器壳体中，也可以整合在独立的壳体中。

按照另一个实施例，这种模块优选地并入在独立的处理器上运行的软件模块中。

本发明还涵盖了一种计算机程序产品，其具有计算机可读媒体和存储在所述计算机可读媒体上的具有程序编码装置的计算机程序，当所述计算机程序在计算机上运行时，所述程序编码装置可执行按照本发明的方法。

此外，本发明还涵盖了一种在目标处采用通用握手协议处理高速网络中的请求的方法，其中一旦由处理请求导致的目标的负荷超过预定门限值，就用按照权利要求1至8的任一项所述的方法修改所述通用握手协议。

由于这种防止请求溢出的保护只是在高峰使用时间需要，因此在低峰使用时间可以使用典型为3向握手协议的通用握手协议。按照本发明的握手协议引入了两个附加的步骤并用于高峰使用时间。

从附图和以下说明中可以清楚地看到本发明的其他一些特征和实施例。

可以理解，上述的特征和以下所说明的特征不仅可以以所说明的组合方式使用，而且也可以以其他组合方式或单独使用，这并不背离本发明的专利保护范围。

在附图中示意性地例示了本发明的情况，下面将结合这些附图进行详细说明。可以理解，这说明并不是对本发明的专利保护范围有所限制，而只是对本发明的一些优选实施例的例示性说明。

附图说明

从以下结合附图的详细说明中可以清楚地看到本发明的其他方面和优点，在这些附图中：

图1示出了拒绝服务攻击的一种可能情况；

图2示出了说明3向握手协议的示意图；

图3示出了说明在TCP网络中的4向握手协议的示意图；

图4示出了说明在InfiniBand网络中的4向握手协议的示意图；

图5示出了例示按照本发明的在InfiniBand网络中的5向握手协议的示意图；

图6为原理性地示出按照本发明的在网络环境中的模块的方框图；

图7示出了说明按照本发明处理网络中的请求的示意图，含有实现图8流程的各个组件；以及

图8为例示按照本发明的方法的流程图。

具体实施方式

图1示出了拒绝服务攻击的可能情况。使用授权发起方12的源ID的攻击方10通过光纤16将请求发送给目标14。按照本发明，这个请求在硬件联网模块18中予以评估，以确保目标中主CPU 20的资源没有被使用并且防止目标溢出。

来看图2，图中例示了了一种3向握手协议。由源ID确定的发起方向用目的地ID标识的目标发送请求消息。目标回发包括目标参数的准备接收消息。为了建立连接，发起方发送含有发起方参数的准备接收消息。

用这种3向握手协议，使用伪造地址的攻击方可以用连接请求使目标溢出，因为目标在对发起方进行识别前就为这些请求分配资源。

来看图3，图中示出了在TCP网络中的4向握手协议。在从发起方接收到请求后，目标就向分配资源的发起方发送问题。发起方将对这个问题的答案与包括发起方参数的准备接收消息一起发送给目标。目标对这个答案进行评估，在它是有效答案的情况下，回发准备接收消息，以建立连接。因此，在识别了发起方后执行资源分配。

然而，如图4所示，这种4向握手协议没有解决InfiniBand网络中的请求溢出攻击问题，因为其导致了I→T和T→I的不透明序列改变，而这对上层协议是不透明的。由于I→T和T消息含有上层连接建立参数和QPN，因此这种方式对于InfiniBand网络来说不可行。问题在于，目标不知道什么时候允许发送。此外，这种方式并没有解决与有限的可能队列对数量相关的问题。

来看图5，其中按照本发明的5向握手协议嵌入3向握手协议中。从由源ID标识的发起方接收到请求后，目标(优选的是与目标关联的硬件模块)产生从源ID得出的问题，这个问题不包含对由源ID标识的节点的永久性数据。因此，使用伪造地址的攻击方接收不到这个问题，从而不能回答这个问题。在使用有效源ID的情况下，目标会回答这个问题。由目标对该答案进行评估。如果答案匹配，就建立连接。

在不涉及目标的软件的情况下执行问题产生和答案检验。在问题与答案之间，没有永久性数据必须存储在目标中。此外，这种方式在正常情况下对于上层协议是透明的而且是向后兼容的。

按照图6，连接HW辅助模块30与包含要发送的外发消息的发送缓冲器32相连。SERDES 34读取所有的到来消息，这些到来消息存储在接收缓冲器36中。模块30与控制逻辑38相连，以触发“转发消息”(forward message)和“丢弃消息”(drop message)操作和发出“附加高负荷信息”，例如具有源地址的连接请求的到达或到达速率。含有包括与发起方相关数据的表的负荷检测模块40向连接HW辅助模块发信号“正常操作”、“高负荷”和“丢弃来自核实发起方的所有连接请求”。

所提出的5向握手协议是防止使目标溢出的有效解决方案。由于这种防止请求溢出的保护只是在高峰使用时间需要，因此在低峰使用时间可以使用3向握手协议。5向握手引入了分别为问题或询问和询问响应这两个附加消息。

来看图7，图中示出了使用源ID的发起方向目标发送建立连接的请求R。目标产生问题Q＝f(...)，该问题通过交换网络发送给由包含在R中的源ID标识的实体。只有接收到Q的实体能创建答案A，并将答案A回发给目标。交换网络根据包含在Q中的目的地ID将A传送给目标。目标验证A的创建者是否通过g(A，...)看到Q。在优选实施例中Q＝f(源ID、密钥、...)，而valid＝g(A、源ID、密钥、...)。

在不知道“密钥(key)”(明文加密攻击，自由可选的明文)的情况下(例如，用规则改变的密钥)，f的结果应该是任何发起方都难以预测的。密钥生成必须是任何发起方都不可预测的，例如使用物理噪声产生密钥。此外，不同的发起方必须导致不同的密钥，例如用InfiniBand LID、GID、GUID作为输入参数。目标根据A和“密钥”确定是否由地址与Q匹配的发起方发送了答案A。

在另一个实现中，问题消息可以是InfiniBand重定向消息(GetResp(ClassPortInfo))，含有要在答案中使用的InfiniBand参数。答案是重复的连接建立消息(InfiniBand REQ)，其具有除了在问题消息(GetResp(ClassportInfo))中指定的参数外的原始参数组。所有能用于重定向的参数均可用来形成问题消息。

来看图8，与需保护的目标关联的模块等待到来消息(步骤50)。接收到消息后，在步骤52，分析这个消息的头标。如果接收到的消息是对连接的请求54，就在步骤56中产生问题，在步骤58将所产生的问题发送给由接收到的源ID标识的节点。

如果接收到的消息是答案60，就在步骤62对这个答案进行评估。在答案有效的情况下，将消息转给目标(步骤64)。如果不是这样，就丢弃这个消息(步骤66)。

如果接收到的消息既不是请求也不是答案68，则将所述消息转发给目标(70)。