CN117061484A - Dhcp处理方法、装置、攻击防御方法、设备及介质 - Google Patents

Abstract

本申请公开了DHCP处理方法、装置、攻击防御方法、设备及介质，DHCP处理方法能够针对外部设备发送的第一DHCP报文和拟态设备内部执行体发送的第二DHCP报文分别处理，处理时结合了拟态设备类型、报文类型、接口信息、缓存信息以及主、从执行体等信息，确保了拟态设备及外部设备之间的DHCP数据交互的有效性。动态主机配置协议攻击防御方法，基于上述DHCP处理方法，使得各个执行体输入相同的来自外部设备的DHCP报文，将各个执行体的输出结果进行拟态裁决，根据裁决结果发现并防御DHCP攻击。这样，基于DHCP协议的拟态设备能够在正常提供DHCP服务的情况下，有效预防DHCP攻击。

Description

DHCP处理方法、装置、攻击防御方法、设备及介质

技术领域

本申请涉及网络安全技术领域，特别是涉及DHCP处理方法、装置、攻击防御方法、设备及介质。

背景技术

近些年，随着互联网通信技术的不断发展，通信应用得到了前所未有的普及。网络安全已成为制约互联网发展的重要因素。针对主机的攻击，只会导致主机一个点被攻击，而针对路由器等网络设备的攻击，则可能会危及整个网络。

DHCP(Dynamic Host Configuration Protocol，动态主机配置协议)通常被应用在大型的局域网络环境中，主要作用是集中地管理、分配IP(网际互连协议)地址，使网络环境中的主机动态地获得IP地址、Gateway(网关)地址、DNS(域名服务器)服务器地址等信息，并能够提升地址的使用率。DHCP协议使用UDP(用户数据报协议)协议工作，统一使用两个IANA(互联网数字分配机构)分配的端口：67(服务器端)，68(客户端)。DHCP协议功能是路由器设备的重要组成部分。

DHCP协议被广泛部署在全世界数以万计的路由器、交换机上，现实世界中，IP地址的分配和管理，往往通过DHCP协议进行，能够有效避免IP地址冲突。DHCP协议安全是网络安全的重要组成部分，也是路由设备必备的功能。

传统的网络设备一般没有防火墙、防病毒等针对恶意DHCP攻击的相关安全防护手段，并且其潜在的漏洞众多，现实网络环境中，攻击者利用DHCP协议漏洞伪造大量的虚假路由信息发起攻击，制造大量的伪造MAC(媒体存储控制位址)地址来请求地址，导致DHCP服务器中的IP地址耗尽，使得正常运行的主机不能正常获取IP地址，严重影响网络。拟态路由器等拟态网络设备的出现提供了一种新的解决思路，拟态设备在其架构引入多个异构冗余的执行体，增强系统广义鲁棒，通过不同执行体的策略或者周期性调度，对外呈现特征的不确定性变化，增强系统安全性。

综上所述，如何解决拟态设备及外部设备之间的DHCP数据交互的有效性是目前本领域技术人员急需解决的技术问题，从而使得基于DHCP协议的拟态设备能够在正常提供DHCP服务的情况下，有效预防DHCP攻击。

发明内容

本申请的目的是提供DHCP处理方法、装置、攻击防御方法、设备及介质，确保了拟态设备及外部设备之间的DHCP数据交互的有效性以及有效预防DHCP攻击。

为解决上述技术问题，本申请提供如下技术方案：

一种动态主机配置协议处理方法，应用于拟态设备，包括：

接收外部设备发送的第一DHCP报文；

根据所述拟态设备的类型和所述第一DHCP报文的类型，确定是否提取所述第一DHCP报文中的地址信息，若是，则根据地址信息、报文类型与接口信息，查询缓存信息，利用所述第一DHCP报文更新或新增缓存信息；根据所述第一DHCP报文的类型，确定是否将所述第一DHCP报文发送给所述拟态设备中的相应执行体；

接收所述拟态设备中执行体发送的第二DHCP报文；

若所述第二DHCP报文为主执行体发送的，则将所述第二DHCP报文透传给相应外部设备；若所述第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据所述第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给所述从执行体。

一种动态主机配置协议处理装置，应用于拟态设备，所述拟态设备中具有多个异构冗余的执行体，所述装置包括：

对外接收单元，用于接收外部设备发送的第一DHCP报文；

对外处理单元，用于根据所述拟态设备的类型和所述第一DHCP报文的类型，确定是否提取所述第一DHCP报文中的地址信息，若是，则根据地址信息、报文类型与接口信息，查询缓存信息，利用所述第一DHCP报文更新或新增缓存信息；根据所述第一DHCP报文的类型，确定是否将所述第一DHCP报文发送给所述拟态设备中的相应执行体；

对内接收单元，用于接收所述拟态设备中执行体发送的第二DHCP报文；

对内处理单元，用于若所述第二DHCP报文为主执行体发送的，则将所述第二DHCP报文透传给相应外部设备；若所述第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据所述第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给所述从执行体。

一种动态主机配置协议攻击防御方法，基于上述的动态主机配置协议处理方法，使得各个执行体输入相同的来自外部设备的DHCP报文，将各个执行体的输出结果进行拟态裁决，根据裁决结果发现并防御DHCP攻击。

一种动态主机配置协议攻击防御装置，包括：

攻击防御模块，用于基于上述的动态主机配置协议处理方法，使得各个执行体输入相同的来自外部设备的DHCP报文，将各个执行体的输出结果进行拟态裁决，根据裁决结果发现并防御DHCP攻击。

一种拟态设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上述动态主机配置协议处理方法的步骤或者如上述动态主机配置协议攻击防御方法的步骤。

一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述动态主机配置协议处理方法的步骤或者如上述动态主机配置协议攻击防御方法的步骤。

本申请提供的一种动态主机配置协议处理方法，包括：接收外部设备发送的第一DHCP报文；根据拟态设备的类型和第一DHCP报文的类型，确定是否提取第一DHCP报文中的地址信息，若是，则根据地址信息与接口信息，查询缓存信息，利用第一DHCP报文更新或新增缓存信息；根据第一DHCP报文的类型，确定是否将第一DHCP报文发送给拟态设备中的执行体；接收拟态设备中执行体发送的第二DHCP报文，若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则根据第二DHCP报文类型，确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体。

通过上述处理方法，能够针对外部设备发送的第一DHCP报文和拟态设备内部执行体发送的第二DHCP报文分别处理，处理时结合了拟态设备类型、报文类型、接口信息、缓存信息以及主、从执行体等信息，确保了拟态设备及外部设备之间的DHCP数据交互的有效性。

本申请还提供一种动态主机配置协议攻击防御方法，基于上述DHCP处理方法，使得各个执行体输入相同的来自外部设备的DHCP报文，将各个执行体的输出结果进行拟态裁决，根据裁决结果发现并防御DHCP攻击。这样，基于DHCP协议的拟态设备能够在正常提供DHCP服务的情况下，有效预防DHCP攻击。

相应地，本申请实施例还提供了与上述动态主机配置协议处理方法、攻击防御方法相对应的装置、设备和可读存储介质，具有上述技术效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例中一种动态主机配置协议处理方法的实施流程图；

图2为本申请实施例中一种拟态设备内部结构示意图；

图3为本申请实施例中一种DHCP代理示意图；

图4为本申请实施例中一种动态主机配置协议处理装置的结构示意图；

图5为本申请实施例中一种拟态设备的结构示意图；

图6为本申请实施例中一种拟态设备的具体结构示意图。

具体实施方式

本申请的核心是为了解决拟态设备及外部设备之间的DHCP数据交互的有效性以及DHCP攻击，通过在拟态设备中设置DHCP代理模块实现外部设备与拟态设备中各执行体之间协议报文的交互处理，实现各执行体与外部设备之间的有效交互通信。DHCP代理支持对DHCP报文的基本收发功能，能够对外部设备发来的报文进行复制分发到各执行体；支持IPv4/IPv6双栈，能够对DHCPv4和DHCPv6同时进行处理；支持执行体轮换，执行体重新上线后，针对每一个与拟态设备建立DHCP联系的外部设备，能够主动模拟外部设备与该执行体进行DHCP关系建立。

通过在拟态设备中引入依据报文类型进行相应处理的DHCP代理模块，能够保证DHCP协议数据的多元化，便于网络防御中拟态方案的有效实施。

拟态设备在启动时，会指定一个执行体为主执行体，用于外部设备与拟态设备之间的交互，DHCP代理将透传主执行体与外界交互的DHCP报文，内部其他执行体的DHCP报文只能与DHCP代理交互，并不发送给外部设备，外部设备不会感知到内部多个执行体的存在。DHCP代理能够实现其他执行体的DHCP状态与主执行体一致，对内面向多个执行体，支持多执行体并行运行。支持执行体上线、下线，并且在执行体上线后使其DHCP状态与主执行体达到一致。

拟态设备在其架构引入多个异构冗余的执行体，增强系统广义鲁棒，通过不同执行体的策略或者周期性调度，对外呈现特征的不确定性变化，增强系统安全性。通过DHCP相关裁决机制能够识别DHCP攻击等恶意行为，极大地提高了拟态设备应对DHCP网络攻击的能力。为配合拟态设备及外部设备之间的DHCP数据交互，需要DHCP协议代理组件能够针对报文类型分别进行处理，以保证报文交互有效性。

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为便于理解，下面对DHCPv4中的不同报文进行详细说明：

Discover报文(发现报文，同Discover)：DHCP客户端寻找DHCP服务器位置时所使用的报文。DHCP客户端寻找服务器时，因不知服务器位置，便在本地网络中以广播形式发送Discover发现报文。所有收到该报文的DHCP服务器会发送应答报文(即Offer报文)，以此知道服务器在网络中的位置。

Offer报文(提供报文，同Offer)：DHCP服务器收到Discover报文后，就会在所配置的地址池中查找一个合适的IP地址，加上相应的租约期限和其他配置信息，构造一个Offer报文，发送给DHCP客户端，告知用户本服务器可以为其提供IP地址。但这个报文只是告诉DHCP客户端可以提供IP地址，但最终还需要客户端通过ARP来检测该IP地址是否重复。

Request报文(请求报文，同Request)：DHCP客户端可能会收到很多Offer报文，所以必须在这些应答中选择一个。通常是第一个Offer应答报文对应的服务器作为自己的目标服务器，并向该服务器发送一个广播的Request请求报文通告选择的服务器。希望获得所分配的IP地址。另外，DHCP客户端在成功获取IP地址后，在地址使用租期到达50％时，会向DHCP服务器发送单播Request请求报文延续租约，如果没有收到服务器的ACK报文，在租期达到87.5％时，会再次发送Request请求报文以请求延续租约。

Ack报文(确认报文，同Ack)：DHCP服务器收到Request请求报文后，根据Request报文中携带的用户MAC来查找有没有相应的租约记录，如果有则发送Ack报文，通知用户可以使用分配的IP地址。

Nak报文(否定确认报文，同Nak)：如果DHCP服务器收到Request请求报文后，没有发现有相应的租约记录，或者由于某些原因无法正常分配地址，则向DHCP客户端发送Nak报文，通知用户无法分配合适的IP地址。

Release报文(释放报文，同Release)：当DHCP客户端不再需要使用分配IP地址时(一般出现在客户端关机，下线等状况)就会主动向DHCP服务器发送Release请求报文，告知服务器用户不再需要分配IP地址，请求DHCP服务器释放对应的IP地址。

Decline报文(拒绝报文，同Decline)：DHCP客户端收到DHCP服务器Ack报文后，通过地址冲突检测发现服务器分配的地址冲突或者由于其他原因导致不能使用，则会向DHCP服务器发送Decline报文，通知服务器所分配的IP地址不可用，以获得新的IP地址。

Inform报文(通告报文，同Inform)：DHCP客户端如果需要从DHCP服务器端获取更为详细的配置信息，则向DHCP服务器发送Inform报文；DHCP服务器在收到该报文后，将根据租约进行查找，找到相应的配置信息后，向DHCP客户端发送Ack报文。

请参考图1，图1为本申请实施例中一种动态主机配置协议处理方法的流程图，该方法可以应用于拟态设备，拟态设备中具有多个异构冗余的执行体。具体的，拟态设备中的执行体包括主执行体和从执行体。具体的，在实际应用中，为方便实现该动态主机配置协议处理方法，可以在拟态设备中设置一个DHCP代理，即该DHCP代理中实现该动态主机配置协议处理方法的步骤。请参考图2，图2为本申请实施例中一种拟态设备内部结构示意图。即，在该拟态设备中，DHCP代理与拟态设备中的主执行体、从执行体(执行体1、执行体2、执行体N)均有DHCP交互通路。

该方法包括以下步骤：

S101、接收外部设备发送的第一DHCP报文。

在本申请中为了便于区别，将拟态设备之外的其他设备所发送的DHCP报文(动态主机配置协议报文)称之为第一DHCP报文，将拟态设备内部的执行体所发送的DHCP报文称之为第二DHCP报文，本文中的第一和第二仅用于表示拟态设备所获得到的DHCP报文的源头是内部还是外部，而并非主次、先后等限定。

在本申请中，该拟态设备可以为服务器、客户端或服务器与客户端之间的中继器，相应地，该外部设备也可以为相应的服务器、客户端或中继器。即：拟态设备的类型包括：DHCPv4服务器、DHCPv4客户端设备、DHCPv4中继器、DHCPv6服务器、DHCPv6客户端和DHCPv6中继器。

具体的，请参考图3，图3为本申请实施例中一种DHCP代理示意图，DHCP代理可以具体为DHCPv4服务器代理(相应地，该拟态设备即为DHCPv4服务器)、DHCPv4客户端代理(相应地，该拟态设备即为DHCPv4客户端设备)、DHCPv4中继代理(相应地，该拟态设备即为DHCPv4中继器)、DHCPv6服务器代理(相应地，该拟态设备即为DHCPv6服务器)、DHCPv6客户端代理(相应地，该拟态设备即为DHCPv6客户端设备)、DHCPv6中继代理(相应地，该拟态设备即为DHCPv6中继器)以及进一步地DHCPv6PD代理(相应地，该拟态设备即为DHCPv6PD设备)等。

S102、根据拟态设备的类型和第一DHCP报文的类型，确定是否提取第一DHCP报文中的地址信息，若是，则根据地址信息、报文类型与接口信息，查询缓存信息，利用第一DHCP报文更新或新增缓存信息；根据第一DHCP报文的类型，确定是否将第一DHCP报文发送给拟态设备中的相应执行体；

从上文可知，DHCP报文本身即包括不同的类型，按照DHCP发送者不同，例如，服务器发送、客户端发送或中继发送。根据外部设备类型及第一DHCP报文的类型，确定是否提取第一DHCP报文中的地址信息，若是，则根据地址信息、报文类型与接口信息，查询缓存信息，利用第一DHCP报文更新或新增缓存信息；根据第一DHCP报文的类型，确定是否将第一DHCP报文发送给拟态设备中的相应执行体；

S103、接收拟态设备中执行体发送的第二DHCP报文；

当拟态设备为服务器时，其内部的执行体即执行服务器所执行的操作，从而产生相应的服务端侧的DHCP报文；当拟态设备为客户端设备时，其内部的执行体即执行客户端所执行的操作，从而产生相应地的客户端侧的DHCP报文；当拟态设备为中继器时，其内部的执行体即执行中继器所执行的操作，从而产生相应的中继侧的DHCP报文。

S104、若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体。

对于第二DHCP报文(第二动态主机配置协议报文)的处理，需要按照主、从执行体发送的两种情况分别处理。

在本文中，相应的外部设备可以为服务器、中继器和客户端中的任意一种。

也就是说，在本申请中，DHCP代理可以具体为以下代理：

DHCPv4服务器代理：当拟态设备作为DHCPv4服务器管理和分配IPv4地址时，负责处理外部客户端发送的DHCPv4信息以及内部各个执行体发出的DHCPv4报文，实现非攻击状态下各个执行体DHCPv4服务器状态的一致。

DHCPv4客户端代理：拟态设备作为DHCPv4客户端请求DHCPv4服务器分配地址时，负责处理外部服务器发送的DHCPv4报文以及内部各个执行体发出的DHCPv4报文，实现非攻击状态下各个执行体DHCPv4客户端状态的一致。

DHCPv4中继代理：拟态设备作为DHCPv4中继实现在不同子网和物理网段之间处理和转发DHCPv4信息的功能。负责处理外部服务器、客户端发送的DHCPv4报文以及内部各个执行体发出的DHCPv4报文，实现非攻击状态下各个执行体DHCPv4中继状态的一致。

DHCPv6服务器代理：拟态设备作为DHCPv6服务器管理和分配IPv6地址或前缀，同时分配DNS(域名服务器)、NIS(网络信息服务)、SNTP(简单网络时间协议)服务器等网络配置参数。负责处理外部客户端发送的DHCPv6信息以及内部各个执行体发出的DHCPv6信息，实现非攻击状态下各个执行体DHCPv6服务器状态的一致。

DHCPv6PD(Prefix Delegation，前缀分配)服务器代理：当拟态设备作为DHCPv6PD服务器分配合适的IPv6地址前缀给下游设备时，负责处理外部客户端发送的DHCPv6信息以及内部各个执行体发出的DHCPv6信息，实现非攻击状态下各个执行体DHCPv6PD服务器状态的一致。

DHCPv6客户端代理：拟态设备作为DHCPv6客户端请求外部DHCPv6服务器分配地址时，负责处理外部服务器发送的DHCPv6信息以及内部各个执行体发出的DHCPv6信息，实现非攻击状态下各个执行体DHCPv6客户端状态的一致。

DHCPv6PD客户端代理：拟态设备作为DHCPv6PD客户端请求外部DHCPv6PD服务器分配地址前缀时，负责处理外部PD服务器发送的DHCPv6信息以及内部各个执行体发出的DHCPv6信息，实现非攻击状态下各个执行体DHCPv6PD客户端状态的一致。

DHCPv6中继代理：当服务器和客户端不在一个网段时，需要使用到DHCPv6中继来完成IPv6地址/前缀和其他网络配置参数的获取。拟态设备作为DHCPv6中继实现在不同IPv6网段之间处理和转发DHCPv6信息的功能。负责处理外部服务器、客户端发送的DHCPv6报文以及内部各个执行体发出的DHCPv6报文，实现非攻击状态下各个执行体DHCPv6中继状态的一致。

在拟态设备中应用本申请实施例所提供的方法，包括：

接收外部设备发送的第一DHCP报文；根据拟态设备的类型和第一DHCP报文的类型，确定是否提取第一DHCP报文中的地址信息，若是，则根据地址信息与接口信息，查询缓存信息，利用第一DHCP报文更新或新增缓存信息；根据第一DHCP报文的类型，确定是否将第一DHCP报文发送给拟态设备中的执行体；接收拟态设备中执行体发送的第二DHCP报文，若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则根据第二DHCP报文类型，确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体。

通过上述处理方法，能够针对外部设备发送的第一DHCP报文和拟态设备内部执行体发送的第二DHCP报文分别处理，处理时结合了拟态设备类型、报文类型、接口信息、缓存信息以及主、从执行体等信息，确保了拟态设备及外部设备之间的DHCP数据交互的有效性。

需要说明的是，基于上述实施例，本申请实施例还提供了相应的改进方案。在优选/改进实施例中涉及与上述实施例中相同步骤或相应步骤之间可相互参考，相应的有益效果也可相互参照，在本文的优选/改进实施例中不再一一赘述。

在本申请中的一种具体实施方式中，拟态设备为DHCPv4服务器，根据拟态设备的类型和第一DHCP报文的类型，确定是否提取第一DHCP报文中的地址信息，若是，则根据地址信息与接口信息，查询缓存信息，利用第一DHCP报文更新或新增缓存信息；根据第一DHCP报文的类型，确定是否将第一DHCP报文发送给拟态设备中的相应执行体；

若第一DHCP报文为外部客户端发送的Discover、Request、Decline、Release、Inform报文，则提取报文中的源IP地址、源MAC地址，根据地址信息、报文类型以及接口信息查询缓存信息，如果查询到对应报文，则更新缓存信息，如果未查询到，则在缓存中新增第一DHCP报文，记录收到该报文的时间戳，并将该报文发送给主执行体和从执行体；

注意，此处的从执行体是处于工作状态的从执行体；

相应地，接收拟态设备中执行体发送的第二DHCP报文；若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，包括：

若第二DHCP报文为主执行体发送的，且第二DHCP报文类型为Offer、Ack、Nak时，将第二DHCP报文透传给外部DHCP客户端设备。

若第二DHCP报文为从执行体发送的，且第二DHCP报文类型为Offer或Nak报文，则根据接口信息查询缓存信息，对于相同的源MAC、源IP：

若缓存中存在Request和Decline，或存在Request和Release，或存在Request、Decline和Release报文，且Request报文的时间戳是最新的，或若缓存中只存在Request，则根据Request报文构造相应报文发送给从执行体，否则，丢弃第二DHCP报文；若缓存中存在Inform报文，则根据Inform报文构造相应的报文发送给从执行体；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型为Ack报文，则丢弃第二DHCP报文。

为便于描述，下面将上述步骤结合起来进行说明。

当拟态设备作为DHCPv4服务器管理和分配IPv4地址时，负责处理外部客户端发送的DHCPv4信息以及内部各个执行体发出的DHCPv4报文，实现非攻击状态下各个执行体DHCPv4服务器状态的一致。针对来自外设备的DHCPv4报文，缓存DHCPv4客户端相关地址信息，该相关地址信息中每个邻居的键值由外部设备IP地址、外部设备MAC地址组成，并依据报文类型确定是否转发给拟态设备中各执行体；针对来自拟态设备中各执行体的DHCPv4报文，依据报文类型确定是否将该报文转发给外部设备。

当DHCPv4服务器代理接收到外部客户端发送的DHCP Discover(发现)、Request(请求)、Decline(拒绝)、Release(释放)、Inform(通告)报文时，提取报文中的源IP地址、源MAC地址，并且根据地址信息、报文类型(pAcketType)以及对应的接收接口(interface)查询并更新缓存相关报文，如果未查询到，则在缓存中新增该报文。即：cache[pAcketType，srcMac，srcIP，interface]＝pkt，即：缓存[报文类型、源MAC地址、源IP地址、接口名称]＝报文。然后，记录收到该报文的时间戳t1(time，时间)，并将该报文发送给主执行体和处于工作状态的从执行体。

当DHCPv4服务器代理接收到主执行体发送的DHCP Offer(提供)、Ack(确认)、Nak(否定确认)消息时，将其透传发送给外部DHCP客户端设备。

当DHCPv4服务器代理接收到从执行体发送的DHCP Offer、Ack、Nak消息时，将根据消息类型做不同的处理，具体如下：

对于来自从执行体的DHCP Offer报文，根据接口信息查询缓存中相关信息，对于相同的源MAC、源IP，若缓存中同时存在Request、Decline、Release，或同时存在Request、Decline，或同时存在Request和Release，则比较缓存的时间戳信息，若Request缓存的时间戳是最新的，则构造相应的报文发送给相应的执行体。若缓存中只存在Request，则也根据Request报文构造相应报文发送给从执行体；哪个从执行体发送了DHCP Offer报文，构造相应的报文后即反馈给哪个从执行体。否则，对报文做丢弃处理。若查询到缓存中存在Inform信息，则构造成相应的报文新发送给相应的执行体。

构造即：提取缓存的request(此处是request报文)，对其进行必要的字段修改。修改后，发送给相应执行体。

即，根据缓存提取对应的回复的报文(此报文为客户端发出来的第一DHCP报文)，修改之后发送(回复)给发送了DHCP Offer报文的从执行体。

对于来自从执行体的DHCP Nak报文，根据接口信息查询缓存中相关信息，对于相同的源MAC、源IP，若缓存中同时存在Request、Decline、Release，或同时存在Request、Decline，或同时存在Request和Release，则比较缓存的时间戳信息，若Request缓存的时间戳是最新的，则构造相应的报文发送给相应的执行体。若缓存中只存在Request，则也根据Request报文构造相应报文发送给从执行体。否则，对报文做丢弃处理。若查询到缓存中存在Inform信息，则构造成相应的报文新发送给相应的执行体。

对于来自从执行体的DHCP Ack报文，对报文做丢弃处理。

在本申请中的一种具体实施方式中，拟态设备为DHCPv4服务器，当出现新执行体时，可执行以下步骤，以保障各个执行体的状态一致：

步骤一、新执行体上线时，遍历缓存信息；

步骤二、对于相同的源MAC、源IP和接口信息，根据缓存信息中的报文，内生构造相应报文并发送给新执行体，以与新执行体进行DHCP交互。

其中，内生构造，内生即内部生产，指内部自己构造。也就是说，提取(复制)该缓存Discover消息，修改里面的必要字段后发送给新执行体。

具体的，当一个从执行体上线时，遍历缓存中的所有信息，对于相同的源MAC、源IP，接口信息，根据缓存里存储的Discover消息，内生构造Discover消息发送给该执行体，触发与执行体的DHCP交互。对于后续收到的DHCP Offer、Nak、Ack消息，参考以上处理流程。

在本申请中的一种具体实施方式中，拟态设备为DHCPv4客户端设备，相应地，根据拟态设备的类型和第一DHCP报文的类型，确定是否提取第一DHCP报文中的地址信息，若是，则根据地址信息、报文类型与接口信息，查询缓存信息，利用第一DHCP报文更新或新增缓存信息；根据第一DHCP报文的类型，确定是否将第一DHCP报文发送给拟态设备中的相应执行体，包括：

若第一DHCP报文为外部服务器发送的Offer、Ack、Nak报文，则提取报文中的源IP地址、源MAC地址，根据地址信息、报文类型以及接口信息查询缓存信息，如果查询到对应报文，则更新缓存信息，如果未查询到，则在缓存中新增第一DHCP报文，记录收到该报文的时间戳，将该报文发送给主执行体和处于工作状态的从执行体；

相应地，接收拟态设备中执行体发送的第二DHCP报文；若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则根据第二DHCP报文类型，确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，包括：

若第二DHCP报文为主执行体发送的，且第二DHCP报文类型为Discover、Request、Decline、Release、Inform时，将第二DHCP报文透传给外部DHCP服务器设备；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型为Discover报文，则根据接口信息查询缓存信息，若缓存中存在Offer报文，则根据Offer报文构造相应的报文发送给从执行体；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型为Request报文，根据接口信息查询缓存信息，若缓存中存在Ack或Nak报文，则根据Ack或Nak报文构造相应的报文发送给从执行体。

为便于描述，下面将上述步骤结合起来进行说明。

当DHCPv4客户端代理接收到外部服务器发送的DHCP Offer、Ack、Nak报文时，提取报文中的源IP地址、源MAC地址，并且根据报文类型(pAcketType)以及对应的接收接口(interface)查询并更新缓存相关报文，如果未查询到，则在缓存中新增该报文，即：cache[pAcketType，srcMac，srcIP，interface]＝pkt(pkt即报文)。然后，记录收到该报文的时间戳t1，并将该报文发送给主执行体。

当DHCPv4客户端代理接收到主执行体发送的DHCP Discover、Request、Decline、Release、Inform消息时，将其透传发送给外部DHCP服务器设备。

当DHCPv4客户端代理接收到从执行体发送的DHCP Discover、Request、Decline、Release、Inform消息时，将根据消息类型做不同的处理：

对于来自从执行体的DHCP Discover报文，根据接口信息查询缓存中相关信息，若缓存中存在DHCP Offer信息，则修改构造相应的Offer报文新发送给相应的执行体，报文中，修改xid(请求标识)与从执行体的Discover报文中的xid保持一致。

对于来自从执行体的DHCP Request报文，根据接口信息查询缓存中相关信息，并根据Request中的MAC地址查询缓存中存在DHCP Ack、Nak信息，若命中，提取相应的Ack或Nak报文，对其进行修改，发送给该从执行体。报文中，修改xid与收到的从执行体的DHCPRequest报文中的xid保持一致，获取当前的时间戳t2，并修改lease time(租约时间)选项为：

lease time＝lease time–(t2-t1)。

对于来自从执行体的DHCP Decline或者Release报文，对报文做丢弃处理。后续从执行体会使用Discover消息发起新一轮的DHCP交互流程，具体处理见上述步骤。

在本申请中的一种具体实施方式中，拟态设备为DHCPv4中继器，相应地，当DHCPv4中继代理接收到外部客户端或者服务器发送的DHCP Discover、Offer、Request、Ack、Nak、Decline、Release、Inform报文时，提取报文中的源IP地址、源MAC地址，并且根据报文类型pAcketType以及对应的接收接口interface查询并更新缓存相关报文，如果未查询到，则在缓存中新增该报文。即：cache[pAcketType，srcMac，srcIP，interface]＝pkt。然后，记录收到该报文的时间戳t1，并将该报文发送给主执行体以及处于工作状态的从执行体。

当DHCPv4中继代理接收到主执行体发送的DHCP Offer、Ack、Nak消息时，将其透传发送给外部DHCP客户端设备；当DHCPv4中继代理接收到主执行体发送的DHCP Discover、Request、Decline、Release、Inform报文时，将其透传发送给外部DHCP服务端设备。

当DHCPv4中继代理接收到从执行体发送的DHCP消息时，对报文做丢弃处理。

在本申请中的一种具体实施方式中，拟态设备为DHCPv6服务器，相应地，根据拟态设备的类型和第一DHCP报文的类型，确定是否提取第一DHCP报文中的地址信息，若是，则根据地址信息、报文类型与接口信息，查询缓存信息，利用第一DHCP报文更新或新增缓存信息；根据第一DHCP报文的类型，确定是否将第一DHCP报文发送给拟态设备中的相应执行体，包括：

当DHCPv6服务器代理接收到外部客户端发送的DHCPv6Solicit(请求给予)、Request(请求)、Confirm(确认)、Release(释放)、Renew(续订)、Rebind(重新绑定)、Inform(通告)、Decline(拒绝)、Information-Request(请求信息)报文时，提取报文中的源IPv6地址、源MAC地址，并且根据报文类型pAcketType以及对应的接收接口interface查询并更新缓存相关报文，如果未查询到，则在缓存中新增该报文。即：cache[pAcketType，srcMac，srcIP，interface]＝pkt，即缓存[报文类型、源MAC地址、源IP地址、接口名称]＝报文。然后，记录收到该报文的时间戳t1，并将该报文发送给主执行体以及处于工作状态的从执行体。

相应地，接收拟态设备中执行体发送的第二DHCP报文；若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则根据第二DHCP报文类型，确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，包括：

若第二DHCP报文为主执行体发送的，且第二DHCP报文为Advertise、Offer、Reconfigure，则将第二DHCP报文透传给相应外部设备；

若第二DHCP报文为从执行体发送的，且第二DHCP报文为Advertise、Reply、Reconfigure，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，如果没有查询到则丢弃第二DHCP报文。

在本申请中的一种具体实施方式中，拟态设备为DHCPv6服务器，还包括：

当拟态设备为DHCPv6服务器时，基于第一DHCP报文和第二DHCP报文，维护各个执行体的状态消息链表；基于状态消息链表，维护各个执行体的状态一致性。

DHCPv6服务器代理根据收到的报文更新各个执行体交互的状态，规则如下：

将客户端发送的和执行体回复的消息，根据消息类型填充到执行体状态消息的链表中：

1、收到客户端发送的Solicit，按照以下代码更新主执行体状态消息：

DHCPv6State[interface,srcMac,srcIP]＝{Solicit}；

代码含义：DHCPv6状态[接口名称、源MAC，源IP]＝{请求给予}。

2、收到主执行体发送的Advertise(公布)，按照以下代码更新主执行体状态消息：

DHCPv6State[interface,srcMac,srcIP]＝{Solicit，Advertise}。

3、收到客户端发送的Request，按照以下代码更新主执行体状态消息：

DHCPv6State[interface,srcMac,srcIP]＝{Solicit，Advertise，Request}。

4、收到主执行体发送的Reply(回复)，按照以下代码更新执行体状态消息：

DHCPv6State[interface,srcMac,srcIP]＝{Solicit，Advertise，Request，Reply}。

如收到新的消息类型并且与之前的消息类型重复，则，按照以下代码添加到执行体状态后面，如Request消息：

DHCPv6State[interface,srcMac,srcIP]＝{Solicit，Advertise，Request，Reply，Request}。

以此类推。

正常情况下，主执行体与其他working(在线)的执行体状态相同。上述过程中接收第一DHCP报文和第二DHCP报文的处理方式同前述实施方式，这里不再赘述，这里只描述了如何更新执行体状态消息的链表；

在本申请中的一种具体实施方式中，上述基于状态消息链表，维护各个执行体的状态一致性，包括：

新执行体上线时，获取主执行体对应的状态消息链表的最后两个状态信息；

利用两个状态信息，内生构造相应消息并发送给新执行体，以使得新执行体与各个执行体的状态保持一致。

当一个新的执行体服务器被调度上线后，查询主执行体的状态信息链表，判断链表中最后两个状态信息：

若为Request，Reply，首先内生构造Solicit消息发送给该执行体，待收到Advertise后，再内生构造Request消息发送给该执行体，触发与执行体的DHCP交互。更新执行体状态信息DHCPv6State[执行体ID，interface,srcMac,srcIP]＝{Solicit，Advertise，Request，Reply}。

若为Renew，Reply，首先内生构造Solicit消息发送给该执行体，待收到Offer后，再内生构造Request消息发送给该执行体，待收到Reply后，再内生构造Renew消息发送给该执行体，更新执行体状态信息DHCPv6State[执行体ID，interface,srcMac,srcIP]＝{Solicit，Advertise，Request，Reply，Renew,Reply}。

若为Rebind，Reply，首先内生构造Solicit消息发送给该执行体，待收到Offer后，再内生构造Request消息发送给该执行体，待收到Reply后，再内生构造Renew消息发送给该执行体，待收到Reply后，再内生构造Rebind消息发送给该执行体。更新执行体状态信息DHCPv6State[执行体ID，interface,srcMac,srcIP]＝{Solicit，Advertise，Request，Reply，Renew,Reply,Rebind,Reply}。

若为Decline(拒绝)，Reply，内生构造Decline消息发送给该执行体，触发与执行体的DHCP交互。更新执行体状态信息DHCPv6State[执行体ID，interface,srcMac,srcIP]＝{Decline，Reply}。

若为Release，Reply，内生构造Release消息发送给该执行体，触发与执行体的DHCP交互。更新执行体状态信息DHCPv6State[执行体ID，interface,srcMac,srcIP]＝{Release，Reply}。

最后，如果状态信息中包含Information-Request，按照以下代码内生构造相应报文发送给该执行体，触发与执行体的DHCP交互：

DHCPv6State[执行体ID，interface,srcMac,srcIP]＝{…，Information-Request，Reply}。

在本申请中的一种具体实施方式中，拟态设备为DHCPv6客户端设备，第一DHCP报文为外部服务器发送的Advertise、Reply或Reconfigure报文，确定提取第一DHCP报文中的地址信息；当DHCPv6客户端代理接收到主执行体发送的DHCP Solicit、Request、Confirm、Release、Renew、Rebind、Decline、Information-Request消息时，将其透传发送给外部DHCP服务器设备，并更新执行体的状态信息。

当DHCPv6客户端代理接收到主执行体发送的DHCP Solicit、Request、Confirm、Release、Renew、Rebind、Decline、Information-Request消息时，以下以Request为例，提取报文里面的transaction ID(交互标识)和消息类型，更新执行体的状态信息，DHCPClientv6[mainActor,transactionId,pktType＝Request]＝Reply_pAcket(即：DHCP客户端v6[主执行体，交互标识，消息类型＝请求]＝回复消息)，如果未收到Reply pAcket，则置为NULL(空)。

当DHCPv6客户端代理接收到Reply消息时，根据其中的transaction ID，查询DHCPClientv6状态信息的transaction ID，若匹配，则按照以下代码将该Reply报文缓存，并标记时间戳t1：

DHCPClientv6[actorId,interface,transactionId,pktType＝Request]＝Request-Reply，t1；

代码含义：DHCP客户端v6[从执行体标识,接口名称,交互标识,消息类型＝请求]＝请求-回复，时间1；

如果后续主执行体重新发起Request，则按照上述流程更新状态信息中的Reply和时间戳信息。

对于主执行体发送的Renew，Rebind消息，按照以下代码，统一按照上述流程生成或更新执行体状态信息：

DHCPClientv6[actorId,interface,transactionId,pktType＝Renew]＝Renew-Reply，t1；

DHCPClientv6[actorId,interface,transactionId,pktType＝Rebind]＝Rebind-Reply，t1。

对于主执行体发送的Solicit消息，若是回复Reply消息，按照以下代码，统一按照上述流程生成或更新执行体状态信息：

DHCPClientv6[actorId,interface,transactionId,pktType＝Solicit]＝Solicit-Reply，t1。

当DHCPv6客户端代理接收到从执行体发送的DHCPv6Solicit、Request、Confirm、Release、Renew、Rebind、Decline、Information-Request消息时，将根据消息类型做不同的处理：

当代理接收到DHCPv6Solicit，记录此时的transaction ID，和DUID(设备唯一标识符)。代理或者回复Advertise，或者回复Reply。若是前者，提取缓存的由外部服务器发给主执行体的Advertise报文，修改Advertise消息的transaction ID、DUID与记录的transaction ID、DUID匹配，然后发送Advertise给对应的执行体。若是后者，提取缓存的由外部服务器发给主执行体的Reply报文，记录报文中的时间戳为t1，获取当前时间戳t2，修改Reply消息的transaction ID、DUID与记录的transaction ID、DUID匹配。若报文有DHCP6OptIAAddress(DHCPv6选项身份联盟地址)部分(IP地址)，则修改该部分中的preferred life time(首选寿命)＝preferred life time-(t2-t1)，valid life time(有效寿命)＝valid life time-(t2-t1)，同时修改该部分中的T1＝1/2preferred lifetime，T2＝3/4preferred life time。T1、T2是DHCP6OptIAAddress部分中的时刻，也即DHCPv6协议中的预设的字段。

同样的，若报文有DHCP6OptIAPrefix(DHCPv6选项身份联盟前缀)部分(前缀地址)，同样按照上文公式修改该部分的preferred life time、valid life time、T1、T2。最后发送Reply消息给对应的执行体。

当接收到DHCPv6Request、DHCPv6Renew、DHCPv6Rebind时，记录此时的transaction ID、DUID，回复Reply。提取缓存的由外部服务器发给主执行体的Reply报文，记录报文中的时间戳为t1，获取当前时间戳t2，修改Reply消息的transaction ID、DUID与记录的transaction ID、DUID匹配。若报文有DHCP6OptIAAddress部分(IP地址)，则修改该部分中的preferred life time＝preferred life time-(t2-t1)，valid life time＝valid life time-(t2-t1)，同时修改该部分中的T1＝1/2preferred life time，T2＝3/4preferred life time。同样的，若报文有DHCP6OptIAPrefix部分(前缀地址)，同样按照上文公式修改该部分的preferred life time、valid life time、T1、T2。最后发送Reply消息给对应的执行体。

当DHCPv6客户端代理接收到从执行体发送的Confirm、Release、Decline、Information-Request消息时，在缓存中提取相应的Reply并按照上述方式内生构造Reply发送给对应的执行体。

当DHCPv6客户端代理接收到外部服务端发送的DHCPv6Advertise、Reply、Reconfigure(重新配置)消息时，提取报文中的源IPv6地址、源MAC地址，并且根据报文类型pAcketType以及对应的接收接口interface查询并更新缓存相关报文，如果未查询到，则在缓存中新增该报文。即：cache[pAcketType，srcMac，srcIPv6，interface]＝pkt。记录收到该报文的时间戳t1，并将该报文发送给主执行体以及处于工作状态的从执行体。

在本申请中的一种具体实施方式中，拟态设备为DHCPv6中继器，相应地，接收拟态设备中执行体发送的第二DHCP报文；若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则根据第二DHCP报文类型，确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，包括：

步骤一、若第二DHCP报文为主执行体发送的，且第二DHCP报文的类型为Relay-Forward，则将第二DHCP报文透传给相应服务器；

步骤二、若第二DHCP报文为从执行体发送的，则丢弃DHCP报文。

下面将上述两个步骤结合起来进行说明。

当DHCPv6中继代理接收到由外部客户端发送的DHCPv6Solicit、Request、Confirm、Release、Renew、Rebind、Decline、Information-Request报文时，提取报文中的源IPv6地址、源MAC地址，并且根据报文类型(pAcketType)以及对应的接收接口interface查询并更新缓存相关报文，如果未查询到，则在缓存中新增该报文。即：cache[pAcketType，srcMac，srcIPv6，interface]＝pkt。记录收到该报文的时间戳t1，并将该报文发送给主执行体以及处于工作状态的从执行体。当DHCPv6中继代理接收到由外部服务端发送的Relay-Reply报文(其中携带了转发给DHCPv6客户端的Advertise或者Reply或者Reconfigure报文)时，提取报文中的源IPv6地址、源MAC地址，并且根据报文类型(pAcketType)以及对应的接收接口(interface)查询并更新缓存相关报文，如果未查询到，则在缓存中新增该报文，即执行：cache[pAcketType，srcMac，srcIPv6，interface]＝pkt。记录收到该报文的时间戳t1，并将该报文发送给主执行体以及处于工作状态的从执行体。

当DHCPv6中继代理接收到主执行体发送的Relay-Forward中继转发)报文(其中携带了DHCPv6客户端请求报文)时，将其透传发送给外部DHCPv6服务端设备。

当DHCPv6中继代理接收到从执行体发送的DHCPv6消息时，对报文做丢弃处理。

相应于上面的方法实施例，本申请实施例还提供了一种应用于拟态设备的动态主机配置协议处理装置，下文描述的动态主机配置协议处理装置与上文描述的动态主机配置协议处理方法可相互对应参照。

拟态设备中具有多个异构冗余的执行体，参见图4所示，该装置包括以下单元：

对外接收单元101，用于接收外部设备发送的第一DHCP报文；

对外处理单元102，用于根据拟态设备的类型和第一DHCP报文的类型，确定是否提取第一DHCP报文中的地址信息，若是，则根据地址信息、报文类型与接口信息，查询缓存信息，利用第一DHCP报文更新或新增缓存信息；根据第一DHCP报文的类型，确定是否将第一DHCP报文发送给拟态设备中的相应执行体；

对内接收单元103，用于接收拟态设备中执行体发送的第二DHCP报文；

对内处理单元104，用于若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体。

应用本申请实施例所提供的装置，接收外部设备发送的第一DHCP报文；根据拟态设备的类型和第一DHCP报文的类型，确定是否提取第一DHCP报文中的地址信息，若是，则根据地址信息与接口信息，查询缓存信息，利用第一DHCP报文更新或新增缓存信息；根据第一DHCP报文的类型，确定是否将第一DHCP报文发送给拟态设备中的执行体；接收拟态设备中执行体发送的第二DHCP报文，若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则根据第二DHCP报文类型，确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体。

通过上述处理装置，能够针对外部设备发送的第一DHCP报文和拟态设备内部执行体发送的第二DHCP报文分别处理，处理时结合了拟态设备类型、报文类型、接口信息、缓存信息以及主、从执行体等信息，确保了拟态设备及外部设备之间的DHCP数据交互的有效性。

在本申请的一种具体实施方式中，拟态设备的类型包括：DHCPv4服务器、DHCPv4客户端设备、DHCPv4中继器、DHCPv6服务器、DHCPv6客户端和DHCPv6中继器。

在本申请的一种具体实施方式中，当拟态设备为DHCPv4服务器，第一DHCP报文类型为外部客户端发送的Discover、Request、Decline、Release或Inform报文，确定提取第一DHCP报文中的地址信息；

相应地，接收拟态设备中执行体发送的第二DHCP报文；若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，包括：

若第二DHCP报文为主执行体发送的，且第二DHCP报文类型为Offer、Ack、Nak时，将第二DHCP报文透传给外部DHCP客户端设备。

若第二DHCP报文为从执行体发送的，且第二DHCP报文类型为Offer或Nak报文，则根据接口信息查询缓存信息，对于相同的源MAC、源IP：

若缓存中同时存在Request和Decline，或同时存在Request和Release，或同时存在Request、Decline和Release报文，且Request报文的时间戳是最新的，或若缓存中只存在Request，则根据Request报文构造相应报文发送给从执行体，否则，丢弃第二DHCP报文；若缓存中存在Inform报文，则根据Inform报文构造相应的报文发送给从执行体；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型为Ack报文，则丢弃第二DHCP报文。

在本申请的一种具体实施方式中，新执行体上线时，遍历缓存信息；对于相同的源MAC、源IP和接口信息，根据缓存信息中的报文，内生构造相应报文并发送给新执行体，以与新执行体进行DHCP交互。

在本申请的一种具体实施方式中，当拟态设备为DHCPv4客户端设备，第一DHCP报文为外部服务器发送的Offer、Ack或Nak报文，确定提取第一DHCP报文中的地址信息；

相应地，接收拟态设备中执行体发送的第二DHCP报文；若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，包括：

若第二DHCP报文为主执行体发送的，且第二DHCP报文类型为Discover、Request、Decline、Release、Inform时，将第二DHCP报文透传给相应外部服务器设备；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型为Discover报文，则根据接口信息查询缓存信息，若缓存中存在Offer报文，则根据Offer报文构造相应的报文发送给从执行体；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型为Request报文，根据接口信息查询缓存信息，若缓存中存在Ack或Nak报文，则根据Ack或Nak报文构造相应的报文发送给从执行体；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型为Decline或者Release报文，则丢弃第二DHCP报文。

在本申请的一种具体实施方式中，当拟态设备为DHCPv4中继器时，第一DHCP报文为Discover、Offer、Request、Ack、Nak、Decline、Release或Inform报文，确定提取第一DHCP报文中的地址信息；

相应地，接收拟态设备中执行体发送的第二DHCP报文；若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，包括：

若第二DHCP报文为主执行体发送的，且第二DHCP报文的类型为Offer、Ack或Nak报文，则将第二DHCP报文透传给相应外部客户端设备；

若第二DHCP报文为主执行体发送的，且第二DHCP报文的类型为Discover、Request、Decline、Release或Inform报文，则将第二DHCP报文透传给相应外部服务器设备；

若第二DHCP报文为从执行体发送的，则丢弃第二DHCP报文。

在本申请的一种具体实施方式中，当拟态设备为DHCPv6服务器时，基于第一DHCP报文和第二DHCP报文，维护各个执行体的状态消息链表；基于状态消息链表，维护各个执行体的状态一致性。

在本申请的一种具体实施方式中，基于状态消息链表，维护各个执行体的状态一致性，包括：

新执行体上线时，获取主执行体对应的状态消息链表的最后两个状态信息；

利用两个状态信息，内生构造相应消息并发送给新执行体，以使得新执行体与各个执行体的状态保持一致。

在本申请的一种具体实施方式中，当拟态设备为DHCPv6客户端时，第一DHCP报文为外部服务器发送的Advertise、Reply或Reconfigure报文，确定提取第一DHCP报文中的地址信息；

相应地，接收拟态设备中执行体发送的第二DHCP报文；若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，包括：

若第二DHCP报文为主执行体发送的，且第二DHCP报文的类型为Solicit、Request、Confirm、Release、Renew、Rebind、Decline或Information-Request报文，则将其透传给相应外部服务器设备，并更新执行体的状态信息；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型为Solicit报文，则根据接口信息查询缓存信息，提取缓存的由外部服务器发给主执行体的Advertise报文，根据Advertise报文构造相应的报文发送给从执行体，或者，提取缓存的由外部服务器发给主执行体的Reply报文，根据Reply报文构造相应的报文发送给从执行体；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型为Request、Renew或Rebind报文，根据接口信息查询缓存信息，提取缓存的由外部服务器发给主执行体的Reply报文，则根据Reply报文构造相应的报文发送给从执行体；

若第二DHCP报文为从执行体发送的，且第二DHCP报文的类型Confirm、Release、Decline或Information-Request报文，根据接口信息查询缓存信息，提取缓存中相应的Reply报文并发送给对应的执行体。

在本申请的一种具体实施方式中，当拟态设备为DHCPv6中继器时，第一DHCP报文为外部客户端发送的DHCPv6Solicit、Request、Confirm、Release、Renew、Rebind、Decline、Information-Request报文，或者为外部服务端发送的Relay-Reply报文，确定提取第一DHCP报文中的地址信息；

相应地，若第二DHCP报文为主执行体发送的，则将第二DHCP报文透传给相应外部设备；若第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给从执行体，包括：

若第二DHCP报文为主执行体发送的，且第二DHCP报文的类型为Relay-Forward，则将第二DHCP报文透传给相应服务器；

若第二DHCP报文为从执行体发送的，则丢弃DHCP报文。

相应于上面的方法实施例，本申请实施例还提供了一种动态主机配置协议攻击防御方法，下文描述的一种动态主机配置协议攻击防御方法与上文描述的一种动态主机配置协议处理方法可相互对应参照。

在本申请实施例中，一种动态主机配置协议攻击防御方法，基于上述的动态主机配置协议处理方法，使得各个执行体输入相同的来自外部设备的DHCP报文，将各个执行体的输出结果进行拟态裁决，根据裁决结果发现并防御DHCP攻击。

基于上述DHCP处理方法，使得各个执行体输入相同的来自外部设备的DHCP报文，将各个执行体的输出结果进行拟态裁决，根据裁决结果发现并防御DHCP攻击。这样，基于DHCP协议的拟态设备能够在正常提供DHCP服务的情况下，有效预防DHCP攻击。

相应于上面的方法实施例，本申请实施例还提供了一种动态主机配置协议攻击防御装置，下文描述的一种动态主机配置协议攻击防御装置与上文描述的一种动态主机配置协议攻击防御方法可相互对应参照。

在本申请实施例中一种动态主机配置协议攻击防御装置，包括：

攻击防御模块，用于基于上述的动态主机配置协议处理方法，使得各个执行体输入相同的来自外部设备的DHCP报文，将各个执行体的输出结果进行拟态裁决，根据裁决结果发现并防御DHCP攻击。

相应于上面的方法实施例，本申请实施例还提供了一种拟态设备，下文描述的一种拟态设备与上文描述的一种动态主机配置协议处理方法可相互对应参照。

参见图5所示，该拟态设备包括：

存储器332，用于存储计算机程序；

处理器322，用于执行计算机程序时实现如上述动态主机配置协议处理方法的步骤或者如上述动态主机配置协议攻击防御方法的步骤。

具体的，请参考图6，图6为本实施例提供的一种拟态设备的具体结构示意图，该拟态设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processing units，CPU)322(例如，一个或一个以上处理器)和存储器332，存储器332存储有一个或一个以上的计算机程序342或数据344。其中，存储器332可以是短暂存储或持久存储。存储在存储器332的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对数据处理设备中的一系列指令操作。更进一步地，处理器322可以设置为与存储器332通信，在拟态设备301上执行存储器332中的一系列指令操作。

拟态设备301还可以包括一个或一个以上电源326，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口358，和/或，一个或一个以上操作系统341。

上文所描述的动态主机配置协议处理方法和/或动态主机配置协议攻击防御方法中的步骤可以由拟态设备的结构实现。

相应于上面的方法实施例，本申请实施例还提供了一种可读存储介质，下文描述的一种可读存储介质与上文描述的一种动态主机配置协议处理方法、一种动态主机配置协议攻击防御方法可相互对应参照。

一种可读存储介质，可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例的动态主机配置协议处理方法和/或动态主机配置协议攻击防御方法的步骤。

该可读存储介质具体可以为U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可存储程序代码的可读存储介质。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

本领域技术人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应该认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系属于仅仅用来将一个实体或者操作与另一个实体或者操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语包括、包含或者其他任何变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

Claims (15)

1.一种动态主机配置协议处理方法，其特征在于，应用于拟态设备，包括：

接收外部设备发送的第一DHCP报文；

根据所述拟态设备的类型和所述第一DHCP报文的类型，确定是否提取所述第一DHCP报文中的地址信息，若是，则根据地址信息、报文类型与接口信息，查询缓存信息，利用所述第一DHCP报文更新或新增缓存信息；根据所述第一DHCP报文的类型，确定是否将所述第一DHCP报文发送给所述拟态设备中的相应执行体；

接收所述拟态设备中执行体发送的第二DHCP报文；

若所述第二DHCP报文为主执行体发送的，则将所述第二DHCP报文透传给相应外部设备；若所述第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据所述第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给所述从执行体。

2.根据权利要求1所述的动态主机配置协议处理方法，其特征在于，所述拟态设备的类型包括：DHCPv4服务器、DHCPv4客户端设备、DHCPv4中继器、DHCPv6服务器、DHCPv6客户端和DHCPv6中继器。

3.根据权利要求2所述的动态主机配置协议处理方法，其特征在于，当所述拟态设备为DHCPv4服务器，所述第一DHCP报文类型为外部客户端发送的Discover、Request、Decline、Release或Inform报文，确定提取所述第一DHCP报文中的地址信息；

相应地，接收所述拟态设备中执行体发送的第二DHCP报文；若所述第二DHCP报文为主执行体发送的，则将所述第二DHCP报文透传给相应外部设备；若所述第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据所述第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给所述从执行体，包括：

若所述第二DHCP报文为主执行体发送的，且所述第二DHCP报文类型为Offer、Ack、Nak时，将所述第二DHCP报文透传给外部DHCP客户端设备。

若所述第二DHCP报文为从执行体发送的，且所述第二DHCP报文类型为Offer或Nak报文，则根据接口信息查询缓存信息，对于相同的源MAC、源IP：

若缓存中同时存在Request和Decline，或同时存在Request和Release，或同时存在Request、Decline和Release报文，且Request报文的时间戳是最新的，或若缓存中只存在Request，则根据Request报文构造相应报文发送给从执行体，否则，丢弃所述第二DHCP报文；若缓存中存在Inform报文，则根据Inform报文构造相应的报文发送给从执行体；

若所述第二DHCP报文为从执行体发送的，且所述第二DHCP报文的类型为Ack报文，则丢弃所述第二DHCP报文。

4.根据权利要求3所述的动态主机配置协议处理方法，其特征在于，还包括：

新执行体上线时，遍历缓存信息；对于相同的源MAC、源IP和接口信息，根据缓存信息中的报文，内生构造相应报文并发送给新执行体，以与所述新执行体进行DHCP交互。

5.根据权利要求2所述的动态主机配置协议处理方法，其特征在于，当所述拟态设备为DHCPv4客户端设备，所述第一DHCP报文为外部服务器发送的Offer、Ack或Nak报文，确定提取所述第一DHCP报文中的地址信息；

相应地，接收所述拟态设备中执行体发送的第二DHCP报文；若所述第二DHCP报文为主执行体发送的，则将所述第二DHCP报文透传给相应外部设备；若所述第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据所述第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给所述从执行体，包括：

若所述第二DHCP报文为主执行体发送的，且所述第二DHCP报文类型为Discover、Request、Decline、Release、Inform时，将第二DHCP报文透传给相应外部服务器设备；

若所述第二DHCP报文为从执行体发送的，且所述第二DHCP报文的类型为Discover报文，则根据接口信息查询缓存信息，若缓存中存在Offer报文，则根据Offer报文构造相应的报文发送给从执行体；

若所述第二DHCP报文为从执行体发送的，且所述第二DHCP报文的类型为Request报文，根据接口信息查询缓存信息，若缓存中存在Ack或Nak报文，则根据Ack或Nak报文构造相应的报文发送给所述从执行体；

若所述第二DHCP报文为从执行体发送的，且所述第二DHCP报文的类型为Decline或者Release报文，则丢弃所述第二DHCP报文。

6.根据权利要求2所述的动态主机配置协议处理方法，其特征在于，当所述拟态设备为DHCPv4中继器时，所述第一DHCP报文为Discover、Offer、Request、Ack、Nak、Decline、Release或Inform报文，确定提取第一DHCP报文中的地址信息；

相应地，接收所述拟态设备中执行体发送的第二DHCP报文；若所述第二DHCP报文为主执行体发送的，则将所述第二DHCP报文透传给相应外部设备；若所述第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据所述第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给所述从执行体，包括：

若所述第二DHCP报文为主执行体发送的，且所述第二DHCP报文的类型为Offer、Ack或Nak报文，则将第二DHCP报文透传给相应外部客户端设备；

若所述第二DHCP报文为主执行体发送的，且所述第二DHCP报文的类型为Discover、Request、Decline、Release或Inform报文，则将所述第二DHCP报文透传给相应外部服务器设备；

若所述第二DHCP报文为从执行体发送的，则丢弃所述第二DHCP报文。

7.根据权利要求2所述的动态主机配置协议处理方法，其特征在于，当所述拟态设备为DHCPv6服务器时，基于所述第一DHCP报文和所述第二DHCP报文，维护各个执行体的状态消息链表；基于所述状态消息链表，维护各个所述执行体的状态一致性。

8.根据权利要求7所述的动态主机配置协议处理方法，其特征在于，基于所述状态消息链表，维护各个所述执行体的状态一致性，包括：

新执行体上线时，获取所述主执行体对应的所述状态消息链表的最后两个状态信息；

利用两个所述状态信息，内生构造相应消息并发送给所述新执行体，以使得所述新执行体与各个所述执行体的状态保持一致。

9.根据权利要求2所述的动态主机配置协议处理方法，其特征在于，当所述拟态设备为DHCPv6客户端时，所述第一DHCP报文为外部服务器发送的Advertise、Reply或Reconfigure报文，确定提取第一DHCP报文中的地址信息；

相应地，接收所述拟态设备中执行体发送的第二DHCP报文；若所述第二DHCP报文为主执行体发送的，则将所述第二DHCP报文透传给相应外部设备；若所述第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据所述第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给所述从执行体，包括：

若所述第二DHCP报文为主执行体发送的，且所述第二DHCP报文的类型为Solicit、Request、Confirm、Release、Renew、Rebind、Decline或Information-Request报文，则将其透传给相应外部服务器设备，并更新执行体的状态信息；

若所述第二DHCP报文为从执行体发送的，且所述第二DHCP报文的类型为Solicit报文，则根据接口信息查询缓存信息，提取缓存的由外部服务器发给主执行体的Advertise报文，根据Advertise报文构造相应的报文发送给从执行体，或者，提取缓存的由外部服务器发给主执行体的Reply报文，根据Reply报文构造相应的报文发送给从执行体；

若所述第二DHCP报文为从执行体发送的，且所述第二DHCP报文的类型为Request、Renew或Rebind报文，根据接口信息查询缓存信息，提取缓存的由外部服务器发给主执行体的Reply报文，则根据Reply报文构造相应的报文发送给所述从执行体；

若所述第二DHCP报文为从执行体发送的，且所述第二DHCP报文的类型Confirm、Release、Decline或Information-Request报文，根据接口信息查询缓存信息，提取缓存中相应的Reply报文并发送给对应的执行体。

10.根据权利要求2所述的动态主机配置协议处理方法，其特征在于，当所述拟态设备为DHCPv6中继器时，所述第一DHCP报文为外部客户端发送的DHCPv6 Solicit、Request、Confirm、Release、Renew、Rebind、Decline、Information-Request报文，或者为外部服务端发送的Relay-Reply报文，确定提取所述第一DHCP报文中的地址信息；

相应地，若所述第二DHCP报文为主执行体发送的，则将所述第二DHCP报文透传给相应外部设备；若所述第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据所述第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给所述从执行体，包括：

若所述第二DHCP报文为主执行体发送的，且所述第二DHCP报文的类型为Relay-Forward，则将所述第二DHCP报文透传给相应服务器；

若所述第二DHCP报文为从执行体发送的，则丢弃所述DHCP报文。

11.一种动态主机配置协议处理装置，其特征在于，应用于拟态设备，所述拟态设备中具有多个异构冗余的执行体，所述装置包括：

对外接收单元，用于接收外部设备发送的第一DHCP报文；

对外处理单元，用于根据所述拟态设备的类型和所述第一DHCP报文的类型，确定是否提取所述第一DHCP报文中的地址信息，若是，则根据地址信息、报文类型与接口信息，查询缓存信息，利用所述第一DHCP报文更新或新增缓存信息；根据所述第一DHCP报文的类型，确定是否将所述第一DHCP报文发送给所述拟态设备中的相应执行体；

对内接收单元，用于接收所述拟态设备中执行体发送的第二DHCP报文；

对内处理单元，用于若所述第二DHCP报文为主执行体发送的，则将所述第二DHCP报文透传给相应外部设备；若所述第二DHCP报文为从执行体发送的，则确定是否进行丢弃，若否，则根据所述第二DHCP报文的接口信息查询缓存信息，并根据查询结果内生构造相应报文发送给所述从执行体。

12.一种动态主机配置协议攻击防御方法，其特征在于，基于权利要求1至10中任意一项所述的动态主机配置协议处理方法，使得各个执行体输入相同的来自外部设备的DHCP报文，将各个执行体的输出结果进行拟态裁决，根据裁决结果发现并防御DHCP攻击。

13.一种动态主机配置协议攻击防御装置，其特征在于，包括：

攻击防御模块，用于基于权利要求1至10中任意一项所述的动态主机配置协议处理方法，使得各个执行体输入相同的来自外部设备的DHCP报文，将各个执行体的输出结果进行拟态裁决，根据裁决结果发现并防御DHCP攻击。

14.一种拟态设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至10任一项所述动态主机配置协议处理方法的步骤或者如权利要求12所述动态主机配置协议攻击防御方法的步骤。

15.一种可读存储介质，其特征在于，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至10任一项所述动态主机配置协议处理方法的步骤或者如权利要求12所述动态主机配置协议攻击防御方法的步骤。