Dhcp processing method and apparatus, attack defense method and device, and medium

By introducing a DHCP proxy module into the mimicry device to process DHCP messages, and combining cached information and message type, the problems of poor DHCP data interaction and attack defense between the mimicry device and external devices are solved, thus achieving effective DHCP service and attack defense.

CN117061484BActive Publication Date: 2026-04-10PURPLE MOUNTAIN LAB +1
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
PURPLE MOUNTAIN LAB
Filing Date
2023-09-11
Publication Date
2026-04-10

AI Technical Summary

Technical Problem

In existing technologies, DHCP data exchange between mimicry devices and external devices is not efficient enough, and there is a lack of effective means to defend against DHCP attacks, making network devices vulnerable to attacks.

Method used

A DHCP proxy module is introduced into the mimicry device. By receiving and processing DHCP messages from external devices and internal executors, and by using cached information and message types for processing, the effectiveness of data interaction is ensured. Furthermore, a mimicry adjudication mechanism is used to identify and defend against DHCP attacks.

Benefits of technology

This technology enables mimicry devices to effectively prevent DHCP attacks while providing DHCP services normally, ensuring the effectiveness and security of DHCP data exchange.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117061484B_ABST
    Figure CN117061484B_ABST
Patent Text Reader

Abstract

The application discloses a DHCP processing method and device, an attack defense method and equipment, and a medium. The DHCP processing method can process a first DHCP message sent by an external device and a second DHCP message sent by an internal executor of a paratope device respectively. The processing is combined with information such as a paratope device type, a message type, interface information, cache information, and master and slave executors, thereby ensuring the effectiveness of DHCP data interaction between the paratope device and the external device. The dynamic host configuration protocol attack defense method is based on the above-mentioned DHCP processing method, so that each executor inputs the same DHCP message from the external device, the output results of each executor are paratope decided, and a DHCP attack is discovered and defended according to the decision result. In this way, the paratope device based on the DHCP protocol can effectively prevent the DHCP attack while normally providing the DHCP service.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, in particular to a DHCP processing method and device, an attack defense method, equipment and a medium. BACKGROUND

[0002] In recent years, with the continuous development of Internet communication technology, communication applications have been unprecedentedly popularized. Network security has become an important factor restricting the development of the Internet. Attacks on hosts will only cause a single point of the host to be attacked, while attacks on routers and other network devices may endanger the entire network.

[0003] DHCP (Dynamic Host Configuration Protocol) is usually applied in large local network environments, and its main function is to centrally manage and allocate IP (Internet Protocol) addresses, so that hosts in the network environment can dynamically obtain IP addresses, Gateway (gateway) addresses, DNS (Domain Name Server) server addresses and other information, and can improve the use rate of addresses. The DHCP protocol works using the UDP (User Datagram Protocol) protocol, and uses two IANA (Internet Number Assignment Agency) allocated ports: 67 (server side) and 68 (client side). The DHCP protocol function is an important part of the router device.

[0004] DHCP protocol is widely deployed on tens of thousands of routers and switches around the world. In the real world, IP address allocation and management is often carried out through the DHCP protocol, which can effectively avoid IP address conflicts. DHCP protocol security is an important part of network security and is also a necessary function of the router device.

[0005] Traditional network devices generally do not have firewalls, anti-virus and other related security protection means against malicious DHCP attacks, and have many potential vulnerabilities. In the real network environment, attackers use DHCP protocol vulnerabilities to launch attacks by forging a large number of false routing information and requesting addresses with a large number of fake MAC (Media Access Control Address) addresses, causing IP addresses in the DHCP server to be exhausted, so that normally running hosts cannot normally obtain IP addresses, seriously affecting the network. The emergence of paratope routers and other paratope network devices provides a new solution. Paratope devices introduce multiple heterogeneous redundant executors in their architecture to enhance the system's general robustness. By using different executors' strategies or periodic scheduling, the system presents uncertainty changes in characteristics, enhancing system security.

[0006] To sum up, how to solve the effectiveness of the DHCP data interaction between the quasimodo device and the external device is a technical problem that the technical personnel in the field urgently need to solve at present, so that the quasimodo device based on the DHCP protocol can effectively prevent DHCP attacks under the condition of normally providing DHCP services. SUMMARY

[0007] The purpose of the present application is to provide a DHCP processing method and device, an attack defense method, equipment and medium, which ensures the effectiveness of the DHCP data interaction between the quasimodo device and the external device and effectively prevents DHCP attacks.

[0008] To solve the above technical problems, the present application provides the following technical solutions:

[0009] A dynamic host configuration protocol processing method applied to a quasimodo device, comprising:

[0010] receiving a first DHCP message sent by an external device;

[0011] According to the type of the quasimodo device and the type of the first DHCP message, it is determined whether to extract the address information in the first DHCP message, if yes, according to the address information, the message type and the interface information, the cache information is queried, and the cache information is updated or added by using the first DHCP message; according to the type of the first DHCP message, it is determined whether to send the first DHCP message to the corresponding execution body in the quasimodo device;

[0012] receiving a second DHCP message sent by an execution body in the quasimodo device;

[0013] If the second DHCP message is sent by the master execution body, the second DHCP message is transmitted to the corresponding external device; if the second DHCP message is sent by the slave execution body, it is determined whether to discard, if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is constructed and sent to the slave execution body according to the query result.

[0014] A dynamic host configuration protocol processing device applied to a quasimodo device, the quasimodo device has a plurality of heterogeneous redundant execution bodies, and the device comprises:

[0015] An external receiving unit for receiving a first DHCP message sent by an external device;

[0016] An external processing unit is configured to determine whether to extract address information in the first DHCP packet according to a type of the quorum device and a type of the first DHCP packet, and if so, query cache information according to the address information, the type of the packet and interface information, and update or add cache information by using the first DHCP packet; and determine whether to send the first DHCP packet to a corresponding execution body in the quorum device according to the type of the first DHCP packet.

[0017] An internal receiving unit is configured to receive a second DHCP packet sent by an execution body in the quorum device.

[0018] An internal processing unit is configured to, if the second DHCP packet is sent by a master execution body, transmit the second DHCP packet to a corresponding external device; and if the second DHCP packet is sent by a slave execution body, determine whether to discard the second DHCP packet, and if not, query cache information according to interface information of the second DHCP packet, and send a corresponding packet to the slave execution body according to a query result.

[0019] A dynamic host configuration protocol attack defense method, based on the dynamic host configuration protocol processing method, makes each execution body input the same DHCP packet from an external device, makes each execution body output a result, makes each execution body output a result, and discovers and defends a DHCP attack according to a decision result.

[0020] A dynamic host configuration protocol attack defense device, comprising:

[0021] An attack defense module is configured to, based on the dynamic host configuration protocol processing method, make each execution body input the same DHCP packet from an external device, make each execution body output a result, make each execution body output a result, and discover and defend a DHCP attack according to a decision result.

[0022] A quorum device, comprising:

[0023] A memory is configured to store a computer program.

[0024] A processor is configured to, when executing the computer program, implement steps of the dynamic host configuration protocol processing method or steps of the dynamic host configuration protocol attack defense method.

[0025] A readable storage medium, on which a computer program is stored, the computer program, when executed by a processor, implements steps of the dynamic host configuration protocol processing method or steps of the dynamic host configuration protocol attack defense method.

[0026] The application provides a dynamic host configuration protocol processing method, which comprises the following steps: receiving a first DHCP message sent by an external device; determining whether to extract address information in the first DHCP message according to the type of a metasomate device and the type of the first DHCP message, if yes, querying cache information according to the address information and interface information, and updating or adding the cache information by using the first DHCP message; determining whether to send the first DHCP message to an executor in the metasomate device according to the type of the first DHCP message; receiving a second DHCP message sent by the executor in the metasomate device, if the second DHCP message is sent by a master executor, transmitting the second DHCP message to a corresponding external device; if the second DHCP message is sent by a slave executor, determining whether to discard the second DHCP message according to the type of the second DHCP message, if no, querying the cache information according to the interface information of the second DHCP message, and constructing a corresponding message according to the query result and sending the corresponding message to the slave executor.

[0027] Through the above processing method, the first DHCP message sent by the external device and the second DHCP message sent by the executor in the metasomate device can be processed respectively, and the processing is combined with the type of the metasomate device, the type of the message, the interface information, the cache information and the information of the master and slave executors, so that the effectiveness of the DHCP data interaction between the metasomate device and the external device is ensured.

[0028] The application also provides a dynamic host configuration protocol attack defense method, which is based on the above DHCP processing method, so that the executors input the same DHCP message from the external device, the output results of the executors are subjected to metasomate arbitration, and the DHCP attack is found and defended according to the arbitration result. In this way, the metasomate device based on the DHCP protocol can effectively prevent the DHCP attack while normally providing the DHCP service.

[0029] Correspondingly, the application also provides devices, equipment and readable storage media corresponding to the above dynamic host configuration protocol processing method and attack defense method, which have the above technical effects, and details are not described herein. BRIEF DESCRIPTION OF DRAWINGS

[0030] In order to more clearly illustrate the technical solutions in the application embodiments or the related art, the following will briefly introduce the drawings needed to be used in the embodiment or related art description. Obviously, the drawings in the following description only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0031] Figure 1 The embodiment of the application is a dynamic host configuration protocol processing method, and the implementation flowchart is shown in the figure.

[0032] Figure 2 Fig. 6 is a schematic diagram of an internal structure of a mimicry device according to an embodiment of the present application;

[0033] Figure 3 Fig. 7 is a schematic diagram of a DHCP proxy according to an embodiment of the present application;

[0034] Figure 4 Fig. 8 is a schematic diagram of a structure of a dynamic host configuration protocol processing device according to an embodiment of the present application;

[0035] Figure 5 Fig. 9 is a schematic diagram of a structure of a mimicry device according to an embodiment of the present application;

[0036] Figure 6 Fig. 10 is a schematic diagram of a specific structure of a mimicry device according to an embodiment of the present application. DETAILED DESCRIPTION

[0037] The core of the present application is to solve the effectiveness of the DHCP data interaction between the mimicry device and the external device and the DHCP attack. The protocol message interaction processing between the external device and each execution body in the mimicry device is realized by setting the DHCP proxy module in the mimicry device. The effective interaction communication between each execution body and the external device is realized. The DHCP proxy supports the basic receiving and sending function of the DHCP message, can copy and distribute the message sent by the external device to each execution body, supports IPv4 / IPv6 dual stack, can process DHCPv4 and DHCPv6 at the same time, supports execution body rotation, and can actively simulate the external device and the execution body to establish the DHCP relationship for each external device establishing the DHCP connection with the mimicry device after the execution body is online.

[0038] By introducing the DHCP proxy module in the mimicry device according to the message type for corresponding processing, the diversification of the DHCP protocol data can be ensured, and the effective implementation of the mimicry scheme in network defense is facilitated.

[0039] When the mimicry device is started, an execution body is specified as a main execution body for the interaction between the external device and the mimicry device. The DHCP proxy will transmit the DHCP message of the main execution body interacting with the outside world. The DHCP message of the internal other execution body can only interact with the DHCP proxy and is not sent to the external device. The external device cannot perceive the existence of the multiple execution bodies. The DHCP proxy can realize the consistency of the DHCP state of the other execution bodies with the main execution body, faces multiple execution bodies, supports the parallel running of multiple execution bodies, supports the online and offline of the execution body, and makes the DHCP state of the execution body consistent with the main execution body after the execution body is online.

[0040] The mimicry device introduces multiple heterogeneous redundant executors in its architecture, enhances the general robustness of the system, presents uncertain changes in characteristics through the strategy or periodic scheduling of different executors, and enhances the security of the system. Through the DHCP related decision mechanism, malicious behaviors such as DHCP attacks can be identified, greatly improving the ability of the mimicry device to respond to DHCP network attacks. In order to cooperate with the DHCP data interaction between the mimicry device and the external device, the DHCP protocol proxy component needs to be able to process different types of messages to ensure the effectiveness of message interaction.

[0041] In order to enable personnel in the technical field to better understand the scheme of the present application, the present application will be further described in detail below in combination with the drawings and specific embodiments. Obviously, the described embodiments are only part of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0042] For the convenience of understanding, the different messages in DHCPv4 are described in detail as follows:

[0043] Discover message (discovery message, same as Discover): the message used by the DHCP client when looking for the location of the DHCP server. When looking for the server, the DHCP client does not know the location of the server, so it sends a Discover discovery message in the form of broadcast in the local network. All DHCP servers receiving the message will send a response message (i.e. Offer message) to know the location of the server in the network.

[0044] Offer message (offer message, same as Offer): after receiving the Discover message, the DHCP server will look for a suitable IP address in the configured address pool, add the corresponding lease period and other configuration information, construct an Offer message, and send it to the DHCP client to inform the user that the server can provide the IP address. But this message only tells the DHCP client that it can provide an IP address, but the client still needs to detect whether the IP address is duplicated through ARP.

[0045] Request message: DHCP client can receive many Offer messages, so it must select one of them. Usually, the first Offer message is selected as the target server, and a broadcast Request message is sent to the server to announce the selection. The IP address is expected to be allocated. In addition, when the address lease period reaches 50%, the DHCP client sends a unicast Request message to the DHCP server to renew the lease. If no ACK message is received, the Request message is sent again to request lease renewal when the lease period reaches 87.5%.

[0046] Ack message: After receiving the Request message, the DHCP server searches for the corresponding lease record according to the MAC address carried in the Request message. If a record is found, an Ack message is sent to inform the user that the allocated IP address can be used.

[0047] Nak message: If the DHCP server does not find a corresponding lease record after receiving the Request message, or for some reason cannot normally allocate an address, it sends a Nak message to the DHCP client to inform the user that it cannot allocate an appropriate IP address.

[0048] Release message: When the DHCP client no longer needs to use the allocated IP address (usually when the client is powered off, offline, etc.), it actively sends a Release message to the DHCP server to inform the server that the user no longer needs the allocated IP address and requests the DHCP server to release the corresponding IP address.

[0049] Decline message: After receiving the DHCP server Ack message, the DHCP client detects address conflict or cannot use the allocated address due to other reasons, and sends a Decline message to the DHCP server to inform the server that the allocated IP address is not available, so as to obtain a new IP address.

[0050] Inform message: If the DHCP client needs to obtain more detailed configuration information from the DHCP server, it sends an Inform message to the DHCP server. After receiving the message, the DHCP server searches for the corresponding lease and sends an Ack message to the DHCP client with the configuration information.

[0051] Please refer to Figure 1 , Figure 1 is a flow chart of a dynamic host configuration protocol processing method in an embodiment of the present application. The method can be applied to a paratopic device, which has a plurality of heterogeneous redundant executors. Specifically, the executors in the paratopic device include a master executor and a slave executor. Specifically, in actual applications, for the convenience of implementing the dynamic host configuration protocol processing method, a DHCP proxy can be set in the paratopic device, that is, the steps of the dynamic host configuration protocol processing method are implemented in the DHCP proxy. Please refer to Figure 2 , Figure 2 is a schematic diagram of the internal structure of a paratopic device in an embodiment of the present application. That is, in the paratopic device, the DHCP proxy has a DHCP interaction path with the master executor and the slave executors (executor 1, executor 2, and executor N) in the paratopic device.

[0052] The method includes the following steps:

[0053] S101, receiving a first DHCP message sent by an external device.

[0054] In the present application, in order to distinguish, the DHCP message (dynamic host configuration protocol message) sent by other devices outside the paratopic device is referred to as the first DHCP message, and the DHCP message sent by the executors inside the paratopic device is referred to as the second DHCP message. In this text, the first and the second are only used to indicate whether the source of the DHCP message obtained by the paratopic device is internal or external, and are not limited by priority, sequence, etc.

[0055] In the present application, the paratopic device can be a server, a client, or a relay between the server and the client, and accordingly, the external device can also be a corresponding server, a client, or a relay. That is, the types of the paratopic device include a DHCPv4 server, a DHCPv4 client device, a DHCPv4 relay, a DHCPv6 server, a DHCPv6 client, and a DHCPv6 relay.

[0056] Specifically, please refer to Figure 3 , Figure 3For a DHCP proxy in an embodiment of the present application, the DHCP proxy can be specifically a DHCPv4 server proxy (correspondingly, the analog device is a DHCPv4 server), a DHCPv4 client proxy (correspondingly, the analog device is a DHCPv4 client device), a DHCPv4 relay proxy (correspondingly, the analog device is a DHCPv4 relay), a DHCPv6 server proxy (correspondingly, the analog device is a DHCPv6 server), a DHCPv6 client proxy (correspondingly, the analog device is a DHCPv6 client device), a DHCPv6 relay proxy (correspondingly, the analog device is a DHCPv6 relay), and further a DHCPv6 PD proxy (correspondingly, the analog device is a DHCPv6 PD device), etc.

[0057] S102, according to the type of the analog device and the type of the first DHCP message, it is determined whether to extract the address information in the first DHCP message, if yes, according to the address information, the message type and the interface information, the cache information is queried, and the cache information is updated or added by using the first DHCP message; according to the type of the first DHCP message, it is determined whether to send the first DHCP message to the corresponding executor in the analog device;

[0058] From the above, it can be known that the DHCP message itself includes different types, according to different DHCP senders, for example, server sending, client sending or relay sending. According to the type of the external device and the type of the first DHCP message, it is determined whether to extract the address information in the first DHCP message, if yes, according to the address information, the message type and the interface information, the cache information is queried, and the cache information is updated or added by using the first DHCP message; according to the type of the first DHCP message, it is determined whether to send the first DHCP message to the corresponding executor in the analog device;

[0059] S103, receiving the second DHCP message sent by the executor in the analog device;

[0060] When the analog device is a server, the executor inside the analog device executes the operation performed by the server, thereby generating a corresponding server-side DHCP message; when the analog device is a client device, the executor inside the analog device executes the operation performed by the client, thereby generating a corresponding client-side DHCP message; when the analog device is a relay, the executor inside the analog device executes the operation performed by the relay, thereby generating a corresponding relay-side DHCP message.

[0061] S104, if the second DHCP message is sent by the master executor, the second DHCP message is transparently transmitted to the corresponding external device; if the second DHCP message is sent by the slave executor, it is determined whether to discard, if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is constructed according to the query result and sent to the slave executor.

[0062] For the processing of the second DHCP message (the second dynamic host configuration protocol message), two cases of sending by the master and slave executors need to be processed respectively.

[0063] In this paper, the corresponding external device can be any one of a server, a relay and a client.

[0064] That is, in this application, the DHCP proxy can be specifically as follows:

[0065] DHCPv4 server proxy: when the mimic device manages and allocates IPv4 addresses as a DHCPv4 server, it is responsible for processing the DHCPv4 information sent by the external client and the DHCPv4 message issued by each executor in the internal, and realizes the consistency of the DHCPv4 server state of each executor in the non-attack state.

[0066] DHCPv4 client proxy: when the mimic device requests the DHCPv4 server to allocate addresses as a DHCPv4 client, it is responsible for processing the DHCPv4 message sent by the external server and the DHCPv4 message issued by each executor in the internal, and realizes the consistency of the DHCPv4 client state of each executor in the non-attack state.

[0067] DHCPv4 relay proxy: the mimic device realizes the function of processing and forwarding DHCPv4 information between different subnets and physical network segments as a DHCPv4 relay. It is responsible for processing the DHCPv4 message sent by the external server and client and the DHCPv4 message issued by each executor in the internal, and realizes the consistency of the DHCPv4 relay state of each executor in the non-attack state.

[0068] DHCPv6 server proxy: the mimic device manages and allocates IPv6 addresses or prefixes as a DHCPv6 server, and allocates DNS (domain name server), NIS (network information service), SNTP (simple network time protocol) server and other network configuration parameters. It is responsible for processing the DHCPv6 information sent by the external client and the DHCPv6 information issued by each executor in the internal, and realizes the consistency of the DHCPv6 server state of each executor in the non-attack state.

[0069] DHCPv6 PD (Prefix Delegation) server agent: when the mimic device allocates appropriate IPv6 address prefix to downstream devices as a DHCPv6 PD server, it is responsible for processing the DHCPv6 information sent by external clients and the DHCPv6 information issued by internal executors, and realizing the consistency of the DHCPv6 PD server state of each executor in a non-attack state.

[0070] DHCPv6 client agent: when the mimic device requests external DHCPv6 server to allocate address as a DHCPv6 client, it is responsible for processing the DHCPv6 information sent by external servers and the DHCPv6 information issued by internal executors, and realizing the consistency of the DHCPv6 client state of each executor in a non-attack state.

[0071] DHCPv6 PD client agent: when the mimic device requests external DHCPv6 PD server to allocate address prefix as a DHCPv6 PD client, it is responsible for processing the DHCPv6 information sent by external PD servers and the DHCPv6 information issued by internal executors, and realizing the consistency of the DHCPv6 PD client state of each executor in a non-attack state.

[0072] DHCPv6 relay agent: when the server and the client are not in the same network segment, the DHCPv6 relay needs to be used to complete the acquisition of IPv6 address / prefix and other network configuration parameters. The mimic device realizes the function of processing and forwarding DHCPv6 information between different IPv6 network segments as a DHCPv6 relay. It is responsible for processing the DHCPv6 packets sent by external servers and clients and the DHCPv6 packets issued by internal executors, and realizing the consistency of the DHCPv6 relay state of each executor in a non-attack state.

[0073] The method provided in the embodiment of the application is applied in the mimic device, comprising:

[0074] receive a first DHCP message sent by an external device; determine whether to extract address information in the first DHCP message according to a type of the paragenesis device and a type of the first DHCP message, if yes, query cache information according to the address information and interface information, and update or add the cache information by using the first DHCP message; determine whether to send the first DHCP message to an executor in the paragenesis device according to the type of the first DHCP message; receive a second DHCP message sent by the executor in the paragenesis device, if the second DHCP message is sent by a master executor, transmit the second DHCP message to a corresponding external device; if the second DHCP message is sent by a slave executor, determine whether to discard according to the type of the second DHCP message, if no, query the cache information according to interface information of the second DHCP message, and construct a corresponding message according to a query result and send the corresponding message to the slave executor.

[0075] Through the above processing method, the first DHCP message sent by the external device and the second DHCP message sent by the executor in the paragenesis device can be processed respectively, and the processing is combined with the type of the paragenesis device, the type of the message, the interface information, the cache information, and the information of the master and slave executors, thereby ensuring the effectiveness of the DHCP data interaction between the paragenesis device and the external device.

[0076] It should be noted that based on the above embodiment, the application embodiment also provides a corresponding improvement scheme. The steps in the preferred / improved embodiment are mutually referenced, and the corresponding beneficial effects can also be mutually referenced. In the preferred / improved embodiment, the above steps are not described one by one.

[0077] In a specific embodiment in the application, the paragenesis device is a DHCPv4 server, whether to extract address information in the first DHCP message is determined according to the type of the paragenesis device and the type of the first DHCP message, if yes, the cache information is queried according to the address information and the interface information, and the cache information is updated or added by using the first DHCP message; whether to send the first DHCP message to a corresponding executor in the paragenesis device is determined according to the type of the first DHCP message;

[0078] If the first DHCP message is a Discover, Request, Decline, Release, or Inform message sent by an external client, the source IP address and the source MAC address in the message are extracted, the cache information is queried according to the address information, the type of the message, and the interface information, if the corresponding message is queried, the cache information is updated, if not, the first DHCP message is added in the cache, a timestamp of receiving the message is recorded, and the message is sent to the master executor and the slave executor;

[0079] Note that the slave here is a slave in a working state;

[0080] Correspondingly, a second DHCP message sent by an executor in the pan- synthetic device is received; if the second DHCP message is sent by a master executor, the second DHCP message is transparently transmitted to a corresponding external device; if the second DHCP message is sent by a slave executor, it is determined whether to discard, if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is endogenously constructed and sent to the slave executor according to the query result, including:

[0081] If the second DHCP message is sent by the master executor, and the type of the second DHCP message is Offer, Ack or Nak, the second DHCP message is transparently transmitted to the external DHCP client device.

[0082] If the second DHCP message is sent by the slave executor, and the type of the second DHCP message is Offer or Nak message, the cache information is queried according to the interface information, and for the same source MAC and source IP:

[0083] If there are Request and Decline, or Request and Release, or Request, Decline and Release messages in the cache, and the timestamp of the Request message is the latest, or if there is only Request in the cache, the corresponding message is constructed and sent to the slave executor according to the Request message, otherwise, the second DHCP message is discarded; if there is an Inform message in the cache, the corresponding message is constructed and sent to the slave executor according to the Inform message;

[0084] If the second DHCP message is sent by the slave executor, and the type of the second DHCP message is Ack message, the second DHCP message is discarded.

[0085] For ease of description, the above steps will be described in combination.

[0086] When the pan- synthetic device is used as a DHCPv4 server to manage and allocate IPv4 addresses, it is responsible for processing DHCPv4 messages sent by external clients and DHCPv4 messages issued by each executor in the device, and realizing the consistency of the state of each executor in the DHCPv4 server under non-attack state. For DHCPv4 messages from external devices, the DHCPv4 client related address information is cached, the key value of each neighbor in the related address information is composed of the external device IP address and the external device MAC address, and it is determined whether to forward the message to each executor in the pan- synthetic device according to the message type; for DHCPv4 messages from each executor in the pan- synthetic device, it is determined whether to forward the message to the external device according to the message type.

[0087] When the DHCPv4 server agent receives the DHCP Discover, Request, Decline, Release, Inform message sent by the external client, the source IP address and source MAC address in the message are extracted, and the cache related message is queried and updated according to the address information, message type (pAcketType) and corresponding receiving interface (interface). If it is not queried, the message is added to the cache. That is: cache[pAcketType, srcMac, srcIP, interface] = pkt, that is: cache[message type, source MAC address, source IP address, interface name] = message. Then, the time stamp t1 (time) of receiving the message is recorded, and the message is sent to the master executor and the slave executor in the working state.

[0088] When the DHCPv4 server agent receives the DHCP Offer, Ack, Nak message sent by the master executor, it is transmitted to the external DHCP client device.

[0089] When the DHCPv4 server agent receives the DHCP Offer, Ack, Nak message sent by the slave executor, different processing will be done according to the message type, as follows:

[0090] For the DHCP Offer message from the slave executor, the related information in the cache is queried according to the interface information. For the same source MAC and source IP, if Request, Decline, Release exist at the same time in the cache, or Request, Decline exist at the same time, or Request and Release exist at the same time, the time stamp information of the cache is compared. If the time stamp of the Request cache is the latest, the corresponding message is constructed and sent to the corresponding executor. If only Request exists in the cache, the corresponding message is also constructed and sent to the slave executor according to the Request message; which slave executor sends the DHCP Offer message, the corresponding message is constructed and fed back to which slave executor. Otherwise, the message is discarded. If Inform information is found in the cache, the corresponding message is constructed and sent to the corresponding executor.

[0091] Construction: extract the request (here, the request message) in the cache, and modify the necessary fields. After modification, it is sent to the corresponding executor.

[0092] That is, the corresponding reply message is retrieved from the cache (this message is the first DHCP message sent by the client), modified, and then sent (reply) to the slave executor that sent the DHCP Offer message.

[0093] For DHCP NAK messages from slave executors, the relevant information in the cache is queried based on the interface information. For the same source MAC and source IP, if the cache contains Request, Decline, and Release messages simultaneously, or Request and Decline messages simultaneously, or Request and Release messages simultaneously, the cache timestamp information is compared. If the timestamp of the Request message in the cache is the most up-to-date, the corresponding message is constructed and sent to the corresponding executor. If the cache only contains Request messages, a corresponding message is also constructed based on the Request message and sent to the slave executor. Otherwise, the message is discarded. If Inform information is found in the cache, a new message is constructed and sent to the corresponding executor.

[0094] For DHCP Ack messages from slave executors, the messages are discarded.

[0095] In one specific embodiment of this application, the mimicry device is a DHCPv4 server. When a new executor appears, the following steps can be performed to ensure that the states of all executors are consistent:

[0096] Step 1: When a new executor comes online, iterate through the cached information;

[0097] Step 2: For the same source MAC, source IP and interface information, construct the corresponding message based on the message in the cache information and send it to the new executor to perform DHCP interaction with the new executor.

[0098] Among them, endogenous construction, which means internal production, refers to the internal self-construction. In other words, the cached Discover message is extracted (copied), the necessary fields are modified, and then it is sent to the new executor.

[0099] Specifically, when an executor comes online, all information in the cache is traversed. For the same source MAC, source IP, and interface information, a Discover message is automatically constructed based on the Discover messages stored in the cache and sent to the executor, triggering DHCP interaction with the executor. Subsequent DHCP Offer, Nak, and Ack messages are processed according to the same procedure.

[0100] In one specific embodiment in the present application, the mimic device is a DHCPv4 client device, and accordingly, according to the type of the mimic device and the type of the first DHCP message, it is determined whether to extract the address information in the first DHCP message, if yes, according to the address information, the message type and the interface information, the cache information is queried, and the cache information is updated or newly added by using the first DHCP message; according to the type of the first DHCP message, it is determined whether to send the first DHCP message to the corresponding execution body in the mimic device, including:

[0101] If the first DHCP message is the Offer, Ack, Nak message sent by the external server, the source IP address and the source MAC address in the message are extracted, the cache information is queried according to the address information, the message type and the interface information, if the corresponding message is queried, the cache information is updated, if not queried, the first DHCP message is newly added in the cache, the time stamp of receiving the message is recorded, and the message is sent to the master execution body and the slave execution body in the working state;

[0102] Correspondingly, the second DHCP message sent by the execution body in the mimic device is received; if the second DHCP message is sent by the master execution body, the second DHCP message is transparently transmitted to the corresponding external device; if the second DHCP message is sent by the slave execution body, according to the type of the second DHCP message, it is determined whether to discard, if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is constructed and sent to the slave execution body according to the query result, including:

[0103] If the second DHCP message is sent by the master execution body, and the type of the second DHCP message is Discover, Request, Decline, Release, Inform, the second DHCP message is transparently transmitted to the external DHCP server device;

[0104] If the second DHCP message is sent by the slave execution body, and the type of the second DHCP message is Discover message, the cache information is queried according to the interface information, if there is an Offer message in the cache, the corresponding message is constructed and sent to the slave execution body according to the Offer message;

[0105] If the second DHCP message is sent by the slave execution body, and the type of the second DHCP message is Request message, the cache information is queried according to the interface information, if there is an Ack or Nak message in the cache, the corresponding message is constructed and sent to the slave execution body according to the Ack or Nak message.

[0106] For the convenience of description, the above steps will be described in combination.

[0107] When the DHCPv4 client agent receives the DHCP Offer, Ack, Nak message sent by the external server, the source IP address and source MAC address in the message are extracted, and the cache related message is queried and updated according to the message type (pAcketType) and the corresponding receiving interface (interface). If it is not queried, the message is added to the cache, that is: cache[pAcketType, srcMac, srcIP, interface] = pkt (pkt is the message). Then, the time stamp t1 of receiving the message is recorded, and the message is sent to the main executor.

[0108] When the DHCPv4 client agent receives the DHCP Discover, Request, Decline, Release, Inform message sent by the main executor, it is transmitted to the external DHCP server device.

[0109] When the DHCPv4 client agent receives the DHCP Discover, Request, Decline, Release, Inform message sent by the slave executor, different processing is done according to the message type:

[0110] For the DHCP Discover message from the slave executor, the cache related information is queried according to the interface information. If there is DHCP Offer information in the cache, the corresponding Offer message is modified and constructed and sent to the corresponding executor. In the message, the xid (request identification) is modified to be consistent with the xid in the Discover message from the slave executor.

[0111] For the DHCP Request message from the slave executor, the cache related information is queried according to the interface information, and the DHCP Ack, Nak information in the cache is queried according to the MAC address in the Request. If it is hit, the corresponding Ack or Nak message is extracted and modified and sent to the slave executor. In the message, the xid is modified to be consistent with the xid in the DHCP Request message received from the slave executor, the current time stamp t2 is obtained, and the lease time option is modified to:

[0112] lease time = lease time - (t2-t1).

[0113] For the DHCP Decline or Release message from the slave executor, the message is discarded. The slave executor will use the Discover message to initiate a new round of DHCP interaction process. The specific processing is shown in the above steps.

[0114] In an embodiment of the present application, the mimic device is a DHCPv4 relay agent, and accordingly, when the DHCPv4 relay agent receives a DHCP Discover, Offer, Request, Ack, Nak, Decline, Release, Inform message sent by an external client or server, the source IP address and the source MAC address in the message are extracted, and the cache related message is queried and updated according to the message type pAcketType and the corresponding receiving interface interface. If no query is found, the message is newly added in the cache. That is, cache[pAcketType, srcMac, srcIP, interface] = pkt. Then, the time stamp t1 of receiving the message is recorded, and the message is sent to the master executor and the slave executor in the working state.

[0115] When the DHCPv4 relay agent receives a DHCP Offer, Ack, Nak message sent by the master executor, it is transmitted to the external DHCP client device. When the DHCPv4 relay agent receives a DHCP Discover, Request, Decline, Release, Inform message sent by the master executor, it is transmitted to the external DHCP server device.

[0116] When the DHCPv4 relay agent receives a DHCP message sent by the slave executor, the message is discarded.

[0117] In an embodiment of the present application, the mimic device is a DHCPv6 server, and accordingly, according to the type of the mimic device and the type of the first DHCP message, it is determined whether to extract the address information in the first DHCP message. If yes, the cache information is queried according to the address information, the message type and the interface information, and the cache information is updated or newly added by using the first DHCP message. According to the type of the first DHCP message, it is determined whether to send the first DHCP message to the corresponding executor in the mimic device, including:

[0118] When the DHCPv6 server agent receives a DHCPv6 Solicit (request for giving), Request, Confirm, Release, Renew, Rebind, Inform, Decline, Information-Request message sent by an external client, the source IPv6 address and the source MAC address in the message are extracted, and the cache related message is queried and updated according to the message type pAcketType and the corresponding receiving interface interface. If no query is found, the message is newly added in the cache. That is, cache[pAcketType, srcMac, srcIP, interface] = pkt, that is, cache [message type, source MAC address, source IP address, interface name] = message. Then, the time stamp t1 of receiving the message is recorded, and the message is sent to the master executor and the slave executor in the working state.

[0119] Correspondingly, a second DHCP message sent by the executor of the mimetic device is received; if the second DHCP message is sent by the master executor, the second DHCP message is transparently transmitted to the corresponding external device; if the second DHCP message is sent by the slave executor, it is determined whether to discard according to the type of the second DHCP message; if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is constructed according to the query result and sent to the slave executor, including:

[0120] If the second DHCP message is sent by the master executor, and the second DHCP message is Advertise, Offer, Reconfigure, the second DHCP message is transparently transmitted to the corresponding external device.

[0121] If the second DHCP message is sent by the slave executor, and the second DHCP message is Advertise, Reply, Reconfigure, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is constructed according to the query result and sent to the slave executor, and if no query is found, the second DHCP message is discarded.

[0122] In a specific embodiment of the present application, the mimetic device is a DHCPv6 server, further comprising:

[0123] When the mimetic device is a DHCPv6 server, the state message chain table of each executor is maintained based on the first DHCP message and the second DHCP message; the state consistency of each executor is maintained based on the state message chain table.

[0124] The DHCPv6 server agent updates the state of each executor interaction according to the received message, and the rules are as follows:

[0125] The message sent by the client and the reply of the executor is filled into the linked list of the executor state message according to the message type:

[0126] 1. When receiving the Solicit sent by the client, the main executor state message is updated according to the following code:

[0127] DHCPv6State[interface,srcMac,srcIP] = {Solicit};

[0128] Code meaning: DHCPv6 state [interface name, source MAC, source IP] = {request to give}.

[0129] 2. When receiving the Advertise sent by the main executor, the main executor state message is updated according to the following code:

[0130] DHCPv6State[interface,srcMac,srcIP] = {Solicit, Advertise}.

[0131] 3. When receiving the Request sent by the client, the main executor state message is updated according to the following code:

[0132] DHCPv6State[interface,srcMac,srcIP] = {Solicit, Advertise, Request}.

[0133] 4. When receiving the Reply sent by the main executor, the executor state message is updated according to the following code:

[0134] DHCPv6State[interface,srcMac,srcIP] = {Solicit, Advertise, Request, Reply}.

[0135] If a new message type is received and repeated with the previous message type, it is added to the back of the executor state according to the following code, such as the Request message:

[0136] DHCPv6State[interface,srcMac,srcIP] = {Solicit, Advertise, Request, Reply, Request}.

[0137] And so on.

[0138] Normally, the master execution body and other working (online) execution body state is the same. The first DHCP message and the second DHCP message received in the above process are processed in the same way as the previous embodiment, which will not be described here. Only how to update the execution body state message chain table is described here;

[0139] In a specific embodiment of the present application, the above state message chain table is used to maintain the consistency of the state of each execution body, including:

[0140] When a new execution body is online, the last two state information of the state message chain table corresponding to the master execution body is obtained;

[0141] Using the two state information, the corresponding message is endogenously constructed and sent to the new execution body, so that the state of the new execution body is consistent with that of each execution body.

[0142] When a new execution body server is scheduled online, the state information chain table of the master execution body is queried, and the last two state information in the chain table is judged:

[0143] If it is Request, Reply, first endogenously construct Solicit message and send it to the execution body, and after receiving Advertise, endogenously construct Request message and send it to the execution body, triggering DHCP interaction with the execution body. Update the execution body state information DHCPv6State [execution body ID, interface, srcMac, srcIP] = {Solicit, Advertise, Request, Reply}.

[0144] If it is Renew, Reply, first endogenously construct Solicit message and send it to the execution body, and after receiving Offer, endogenously construct Request message and send it to the execution body, and after receiving Reply, endogenously construct Renew message and send it to the execution body, update the execution body state information DHCPv6State [execution body ID, interface, srcMac, srcIP] = {Solicit, Advertise, Request, Reply, Renew, Reply}.

[0145] If Rebind, Reply, first endogenously construct Solicit message sent to the executor, after receiving the Offer, then endogenously construct Request message sent to the executor, after receiving the Reply, then endogenously construct Renew message sent to the executor, after receiving the Reply, then endogenously construct Rebind message sent to the executor. Update the executor state information DHCPv6State [executor ID, interface, srcMac, srcIP] = {Solicit, Advertise, Request, Reply, Renew, Reply, Rebind, Reply}.

[0146] If Decline (decline), Reply, endogenously construct Decline message sent to the executor, trigger the DHCP interaction with the executor. Update the executor state information DHCPv6State [executor ID, interface, srcMac, srcIP] = {Decline, Reply}.

[0147] If Release, Reply, endogenously construct Release message sent to the executor, trigger the DHCP interaction with the executor. Update the executor state information DHCPv6State [executor ID, interface, srcMac, srcIP] = {Release, Reply}.

[0148] Finally, if the state information contains Information-Request, endogenously construct the corresponding message according to the following code and send it to the executor to trigger the DHCP interaction with the executor:

[0149] DHCPv6State [executor ID, interface, srcMac, srcIP] = {…, Information-Request, Reply}.

[0150] In a specific embodiment of the present application, the mimic device is a DHCPv6 client device, the first DHCP message is an Advertise, Reply or Reconfigure message sent by an external server, and the address information in the first DHCP message is determined and extracted; when the DHCPv6 client agent receives the DHCP Solicit, Request, Confirm, Release, Renew, Rebind, Decline, Information-Request messages sent by the main executor, it transmits them to the external DHCP server device, and updates the state information of the executor.

[0151] When the DHCPv6 client agent receives the DHCP Solicit, Request, Confirm, Release, Renew, Rebind, Decline, Information-Request message sent by the main executor, the following takes Request as an example, extracts the transaction ID (interaction identification) and message type in the message, updates the state information of the executor, DHCPClientv6[mainActor, transactionId, pktType = Request] = Reply_pAcket (i.e. DHCP client v6 [main executor, interaction identification, message type = request] = reply message), if no Reply pAcket is received, it is set to NULL (empty).

[0152] When the DHCPv6 client agent receives the Reply message, according to the transaction ID in it, the transaction ID of the DHCPClientv6 state information is queried, if it matches, the Reply message is cached according to the following code and the time stamp t1 is marked:

[0153] DHCPClientv6[actorId, interface, transactionId, pktType = Request] = Request-Reply, t1;

[0154] Code meaning: DHCP client v6 [from executor identification, interface name, interaction identification, message type = request] = request-reply, time 1;

[0155] If the subsequent main executor reinitiates Request, the Reply and time stamp information in the state information are updated according to the above process.

[0156] For the Renew, Rebind message sent by the main executor, according to the following code, the executor state information is generated or updated according to the above process:

[0157] DHCPClientv6[actorId, interface, transactionId, pktType = Renew] = Renew-Reply, t1;

[0158] DHCPClientv6[actorId, interface, transactionId, pktType = Rebind] = Rebind-Reply, t1.

[0159] For the Solicit message sent by the main executor, if it is a reply Reply message, according to the following code, the executor state information is uniformly generated or updated according to the above process:

[0160] DHCPClientv6 [actorId, interface, transactionId, pktType = Solicit] = Solicit-Reply, t1.

[0161] When the DHCPv6 client agent receives the DHCPv6 Solicit, Request, Confirm, Release, Renew, Rebind, Decline, Information-Request message sent from the executor, different processing will be done according to the message type:

[0162] When the agent receives the DHCPv6 Solicit, record the transaction ID and DUID (Device Unique Identifier) at this time. The agent either replies with Advertise or Reply. If it is the former, extract the cached Advertise message sent by the external server to the main executor, modify the transaction ID and DUID of the Advertise message to match the recorded transaction ID and DUID, and then send the Advertise to the corresponding executor. If it is the latter, extract the cached Reply message sent by the external server to the main executor, record the timestamp in the message as t1, get the current timestamp t2, modify the transaction ID and DUID of the Reply message to match the recorded transaction ID and DUID. If the message has a DHCP6OptIAAddress (DHCPv6 Option Identity Alliance Address) part (IP address), modify the preferred life time in this part = preferred life time-(t2-t1), valid life time = valid life time-(t2-t1), and at the same time modify T1 = 1 / 2preferred lifetime, T2 = 3 / 4preferred life time in this part. T1 and T2 are the times in the DHCP6OptIAAddress part, that is, the preset fields in the DHCPv6 protocol.

[0163] Similarly, if the message has a DHCP6 Opt IA Prefix (DHCPv6 option identity association prefix) part (prefix address), the preferred life time, valid life time, T1, and T2 of this part are modified according to the above formula. Finally, a Reply message is sent to the corresponding executor.

[0164] When a DHCPv6Request, DHCPv6Renew, or DHCPv6Rebind is received, the transaction ID and DUID at this time are recorded, and a Reply is returned. The cached Reply message sent by the external server to the host executor is extracted, the timestamp in the message is recorded as t1, the current timestamp t2 is obtained, the transaction ID and DUID of the Reply message are modified to match the recorded transaction ID and DUID. If the message has a DHCP6 Opt IA Address part (IP address), the preferred life time=preferred life time-(t2-t1) and valid life time=valid life time-(t2-t1) in this part are modified, and T1=1 / 2preferred life time and T2=3 / 4preferred life time in this part are modified. Similarly, if the message has a DHCP6 Opt IA Prefix part (prefix address), the preferred life time, valid life time, T1, and T2 of this part are modified according to the above formula. Finally, a Reply message is sent to the corresponding executor.

[0165] When the DHCPv6 client agent receives a Confirm, Release, Decline, or Information-Request message sent from the executor, the corresponding Reply is extracted from the cache and a Reply is constructed according to the above method and sent to the corresponding executor.

[0166] When the DHCPv6 client agent receives the DHCPv6 Advertise, Reply, Reconfigure (reconfiguration) message sent by the external server, the source IPv6 address and the source MAC address in the message are extracted, and the cache related message is queried and updated according to the message type pAcketType and the corresponding receiving interface interface. If it is not queried, the message is added to the cache. That is: cache[pAcketType, srcMac, srcIPv6, interface] = pkt. The time stamp t1 of receiving the message is recorded, and the message is sent to the main executor and the slave executor in the working state.

[0167] In a specific embodiment of the present application, the mimic device is a DHCPv6 relay, and accordingly, the second DHCP message sent by the executor in the mimic device is received; if the second DHCP message is sent by the main executor, the second DHCP message is transparently transmitted to the corresponding external device; if the second DHCP message is sent by the slave executor, it is determined whether to discard according to the type of the second DHCP message; if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is endogenously constructed and sent to the slave executor according to the query result, including:

[0168] Step one, if the second DHCP message is sent by the main executor and the type of the second DHCP message is Relay-Forward, the second DHCP message is transparently transmitted to the corresponding server.

[0169] Step two, if the second DHCP message is sent by the slave executor, the DHCP message is discarded.

[0170] The above two steps will be combined for description.

[0171] When the DHCPv6 relay agent receives a DHCPv6 Solicit, Request, Confirm, Release, Renew, Rebind, Decline, Information-Request message sent by an external client, the source IPv6 address and the source MAC address in the message are extracted, and the cache related message is queried and updated according to the message type (pAcketType) and the corresponding receiving interface (interface), and if it is not queried, the message is newly added in the cache, that is, cache[pAcketType, srcMac, srcIPv6, interface] = pkt. The time stamp t1 of receiving the message is recorded, and the message is sent to the master executor and the slave executor in the working state. When the DHCPv6 relay agent receives a Relay-Reply message (carrying an Advertise or Reply or Reconfigure message forwarded to the DHCPv6 client) sent by an external server, the source IPv6 address and the source MAC address in the message are extracted, and the cache related message is queried and updated according to the message type (pAcketType) and the corresponding receiving interface (interface), and if it is not queried, the message is newly added in the cache, that is, cache[pAcketType, srcMac, srcIPv6, interface] = pkt. The time stamp t1 of receiving the message is recorded, and the message is sent to the master executor and the slave executor in the working state.

[0172] When the DHCPv6 relay agent receives a Relay-Forward message (carrying a DHCPv6 client request message) sent by the master executor, it is transmitted to the external DHCPv6 server device.

[0173] When the DHCPv6 relay agent receives a DHCPv6 message sent by the slave executor, the message is discarded.

[0174] Corresponding to the above method embodiment, the embodiment of the application also provides a dynamic host configuration protocol processing device applied to a mimetic device. The dynamic host configuration protocol processing device described below can be mutually corresponding and referred to the dynamic host configuration protocol processing method described above.

[0175] The mimetic device has a plurality of heterogeneous redundant executors, as shown in Figure 4 The device includes the following units:

[0176] The external receiving unit 101 is configured to receive a first DHCP message sent by an external device;

[0177] The external processing unit 102 is configured to determine whether to extract address information in the first DHCP packet according to the type of the quasispecies device and the type of the first DHCP packet, and if so, query cache information according to the address information, the type of the packet and the interface information, and update or add cache information by using the first DHCP packet; and determine whether to send the first DHCP packet to a corresponding execution body in the quasispecies device according to the type of the first DHCP packet.

[0178] The internal receiving unit 103 is configured to receive a second DHCP packet sent by an execution body in the quasispecies device.

[0179] The internal processing unit 104 is configured to, if the second DHCP packet is sent by a master execution body, transparently transmit the second DHCP packet to a corresponding external device; if the second DHCP packet is sent by a slave execution body, determine whether to discard, if not, query cache information according to interface information of the second DHCP packet, and internally generate and send a corresponding packet to the slave execution body according to the query result.

[0180] The device provided by the embodiment of the present application receives a first DHCP packet sent by an external device; determines whether to extract address information in the first DHCP packet according to the type of the quasispecies device and the type of the first DHCP packet, and if so, queries cache information according to the address information and the interface information, and updates or adds cache information by using the first DHCP packet; determines whether to send the first DHCP packet to an execution body in the quasispecies device according to the type of the first DHCP packet; receives a second DHCP packet sent by an execution body in the quasispecies device, and if the second DHCP packet is sent by a master execution body, transparently transmits the second DHCP packet to a corresponding external device; if the second DHCP packet is sent by a slave execution body, determines whether to discard according to the type of the second DHCP packet, and if not, queries cache information according to interface information of the second DHCP packet, and internally generates and sends a corresponding packet to the slave execution body according to the query result.

[0181] The processing device can process the first DHCP packet sent by the external device and the second DHCP packet sent by the execution body in the quasispecies device respectively, and combines the type of the quasispecies device, the type of the packet, the interface information, the cache information and the information of the master and slave execution bodies during processing, thereby ensuring the effectiveness of the DHCP data interaction between the quasispecies device and the external device.

[0182] In a specific embodiment of the present application, the type of the quasispecies device includes a DHCPv4 server, a DHCPv4 client device, a DHCPv4 relay, a DHCPv6 server, a DHCPv6 client and a DHCPv6 relay.

[0183] In an embodiment of the present application, when the mimic device is a DHCPv4 server, the first DHCP message type is a Discover, Request, Decline, Release or Inform message sent by an external client, and the address information in the first DHCP message is determined to be extracted;

[0184] Correspondingly, the second DHCP message sent by the executor in the receiving mimic device is received; if the second DHCP message is sent by the master executor, the second DHCP message is transparently transmitted to the corresponding external device; if the second DHCP message is sent by the slave executor, it is determined whether to discard, if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is constructed according to the query result and sent to the slave executor, including:

[0185] If the second DHCP message is sent by the master executor, and the second DHCP message type is Offer, Ack or Nak, the second DHCP message is transparently transmitted to the external DHCP client device.

[0186] If the second DHCP message is sent by the slave executor, and the second DHCP message type is Offer or Nak message, the cache information is queried according to the interface information, and for the same source MAC and source IP:

[0187] If there are Request and Decline, or Request and Release, or Request, Decline and Release messages in the cache at the same time, and the timestamp of the Request message is the latest, or if there is only Request in the cache, the corresponding message is constructed according to the Request message and sent to the slave executor, otherwise, the second DHCP message is discarded; if there is an Inform message in the cache, the corresponding message is constructed according to the Inform message and sent to the slave executor;

[0188] If the second DHCP message is sent by the slave executor, and the type of the second DHCP message is Ack message, the second DHCP message is discarded.

[0189] In an embodiment of the present application, when the new executor is online, the cache information is traversed; for the same source MAC, source IP and interface information, the corresponding message is constructed according to the message in the cache information and sent to the new executor to interact with the new executor.

[0190] In an embodiment of the present application, when the mimic device is a DHCPv4 client device, the first DHCP message is an Offer, Ack or Nak message sent by an external server, and the address information in the first DHCP message is determined to be extracted;

[0191] Accordingly, the second DHCP message sent by the execution body in the pan- species device is received; if the second DHCP message is sent by the main execution body, the second DHCP message is transparently transmitted to the corresponding external device; if the second DHCP message is sent by the slave execution body, it is determined whether to discard, if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is endogenously constructed according to the query result and sent to the slave execution body, including:

[0192] If the second DHCP message is sent by the main execution body, and the type of the second DHCP message is Discover, Request, Decline, Release, Inform, the second DHCP message is transparently transmitted to the corresponding external server device;

[0193] If the second DHCP message is sent by the slave execution body, and the type of the second DHCP message is Discover message, the cache information is queried according to the interface information, if there is an Offer message in the cache, the corresponding message is constructed according to the Offer message and sent to the slave execution body;

[0194] If the second DHCP message is sent by the slave execution body, and the type of the second DHCP message is Request message, the cache information is queried according to the interface information, if there is an Ack or Nak message in the cache, the corresponding message is constructed according to the Ack or Nak message and sent to the slave execution body;

[0195] If the second DHCP message is sent by the slave execution body, and the type of the second DHCP message is Decline or Release message, the second DHCP message is discarded.

[0196] In a specific embodiment of the present application, when the pan- species device is a DHCPv4 relay, the first DHCP message is a Discover, Offer, Request, Ack, Nak, Decline, Release or Inform message, and the address information in the first DHCP message is determined to be extracted;

[0197] Accordingly, the second DHCP message sent by the execution body in the pan- species device is received; if the second DHCP message is sent by the main execution body, the second DHCP message is transparently transmitted to the corresponding external device; if the second DHCP message is sent by the slave execution body, it is determined whether to discard, if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is endogenously constructed according to the query result and sent to the slave execution body, including:

[0198] If the second DHCP message is sent by the main executor and the type of the second DHCP message is Offer, Ack or Nak message, the second DHCP message is transparently transmitted to the corresponding external client device;

[0199] If the second DHCP message is sent by the main executor and the type of the second DHCP message is Discover, Request, Decline, Release or Inform message, the second DHCP message is transparently transmitted to the corresponding external server device;

[0200] If the second DHCP message is sent by the slave executor, the second DHCP message is discarded.

[0201] In an embodiment of the present application, when the mimetic device is a DHCPv6 server, based on the first DHCP message and the second DHCP message, a state message chain table of each executor is maintained; based on the state message chain table, the state consistency of each executor is maintained.

[0202] In an embodiment of the present application, based on the state message chain table, the state consistency of each executor is maintained, comprising:

[0203] When a new executor is online, the last two state information of the state message chain table corresponding to the main executor is obtained;

[0204] Using the two state information, a corresponding message is endogenously constructed and sent to the new executor, so that the state of the new executor is consistent with that of each executor.

[0205] In an embodiment of the present application, when the mimetic device is a DHCPv6 client, the first DHCP message is Advertise, Reply or Reconfigure message sent by the external server, and the address information in the first DHCP message is determined to be extracted;

[0206] Correspondingly, the second DHCP message sent by the executor in the mimetic device is received; if the second DHCP message is sent by the main executor, the second DHCP message is transparently transmitted to the corresponding external device; if the second DHCP message is sent by the slave executor, it is determined whether to discard, if not, the cache information is queried according to the interface information of the second DHCP message, and a corresponding message is endogenously constructed and sent to the slave executor according to the query result, comprising:

[0207] If the second DHCP message is sent by the master execution body and the type of the second DHCP message is Solicit, Request, Confirm, Release, Renew, Rebind, Decline or Information-Request message, the second DHCP message is transmitted to the corresponding external server device, and the state information of the execution body is updated.

[0208] If the second DHCP message is sent by the slave execution body and the type of the second DHCP message is Solicit message, the cache information is queried according to the interface information, the Advertise message sent by the external server to the master execution body is extracted from the cache, and the corresponding message is constructed according to the Advertise message and sent to the slave execution body, or the Reply message sent by the external server to the master execution body is extracted from the cache, and the corresponding message is constructed according to the Reply message and sent to the slave execution body.

[0209] If the second DHCP message is sent by the slave execution body and the type of the second DHCP message is Request, Renew or Rebind message, the cache information is queried according to the interface information, the Reply message sent by the external server to the master execution body is extracted from the cache, and the corresponding message is constructed according to the Reply message and sent to the slave execution body.

[0210] If the second DHCP message is sent by the slave execution body and the type of the second DHCP message is Confirm, Release, Decline or Information-Request message, the cache information is queried according to the interface information, the corresponding Reply message in the cache is extracted and sent to the corresponding execution body.

[0211] In a specific embodiment of the present application, when the mimic device is a DHCPv6 relay, the first DHCP message is a DHCPv6 Solicit, Request, Confirm, Release, Renew, Rebind, Decline, Information-Request message sent by an external client, or a Relay-Reply message sent by an external server, and the address information in the first DHCP message is determined to be extracted.

[0212] Correspondingly, if the second DHCP message is sent by the master execution body, the second DHCP message is transmitted to the corresponding external device; if the second DHCP message is sent by the slave execution body, it is determined whether to discard, if not, the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is constructed according to the query result and sent to the slave execution body, including:

[0213] If the second DHCP message is sent by the main executor and the type of the second DHCP message is Relay-Forward, the second DHCP message is transmitted to the corresponding server;

[0214] If the second DHCP message is sent by the slave executor, the DHCP message is discarded.

[0215] Corresponding to the above method embodiments, the embodiments of the application also provide a dynamic host configuration protocol attack defense method. The dynamic host configuration protocol attack defense method described below can be mutually corresponding with reference to the dynamic host configuration protocol processing method described above.

[0216] In the embodiments of the application, a dynamic host configuration protocol attack defense method is based on the dynamic host configuration protocol processing method described above, so that the same DHCP message from the external device is input into each executor, the output results of each executor are quorum decided, and the DHCP attack is discovered and defended according to the decision result.

[0217] Based on the DHCP processing method, the same DHCP message from the external device is input into each executor, the output results of each executor are quorum decided, and the DHCP attack is discovered and defended according to the decision result. In this way, the quorum device based on the DHCP protocol can effectively prevent the DHCP attack while normally providing the DHCP service.

[0218] Corresponding to the above method embodiments, the embodiments of the application also provide a dynamic host configuration protocol attack defense device. The dynamic host configuration protocol attack defense device described below can be mutually corresponding with reference to the dynamic host configuration protocol attack defense method described above.

[0219] In the embodiments of the application, a dynamic host configuration protocol attack defense device includes:

[0220] The attack defense module is configured to, based on the dynamic host configuration protocol processing method described above, input the same DHCP message from the external device into each executor, quorum decide the output results of each executor, and discover and defend the DHCP attack according to the decision result.

[0221] Corresponding to the above method embodiments, the embodiments of the application also provide a quorum device. The quorum device described below can be mutually corresponding with reference to the dynamic host configuration protocol processing method described above.

[0222] Referring to Figure 5 The quorum device includes:

[0223] The memory 332 is configured to store a computer program.

[0224] The processor 322 is configured to execute the computer program to implement the steps of the dynamic host configuration protocol processing method or the steps of the dynamic host configuration protocol attack defense method.

[0225] Specifically, refer to Figure 6 , Figure 6 A specific structural diagram of a metadevice is provided for the embodiment. The metadevice can have great differences due to different configurations or performances, and can include one or more processors (central processing units, CPUs) 322 (for example, one or more processors) and a memory 332 storing one or more computer programs 342 or data 344. The memory 332 can be temporary storage or persistent storage. The programs stored in the memory 332 can include one or more modules (not shown in the figure), and each module can include a series of instruction operations in the data processing device. Further, the processor 322 can be configured to communicate with the memory 332 and execute the series of instruction operations in the memory 332 on the metadevice 301.

[0226] The metadevice 301 can further include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341.

[0227] The steps of the dynamic host configuration protocol processing method and / or the dynamic host configuration protocol attack defense method described above can be implemented by the structure of the metadevice.

[0228] Corresponding to the method embodiments above, the embodiment of the present application further provides a readable storage medium. The readable storage medium described below can be mutually corresponding with reference to the dynamic host configuration protocol processing method and the dynamic host configuration protocol attack defense method described above.

[0229] A readable storage medium, the readable storage medium storing a computer program, the computer program being executed by a processor to implement the steps of the dynamic host configuration protocol processing method and / or the dynamic host configuration protocol attack defense method of the method embodiments.

[0230] The readable storage medium can be a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various readable storage media that can store program codes.

[0231] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0232] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0233] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0234] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "include," "contain," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0235] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for processing Dynamic Host Configuration Protocol (DHCP), characterized in that, Applications in mimicry devices, including: Receive the first DHCP message sent by an external device; Based on the type of the mimicry device and the type of the first DHCP message, determine whether to extract the address information from the first DHCP message. If so, query the cache information based on the address information, message type, and interface information, and update or add the cache information using the first DHCP message. Based on the type of the first DHCP message, determine whether to send the first DHCP message to the corresponding execution entity in the mimicry device. Receive the second DHCP message sent by the executor in the mimicry device; If the second DHCP message is sent by the master executor, then the second DHCP message is forwarded to the corresponding external device; if the second DHCP message is sent by the slave executor, then it is determined whether to discard it. If not, then the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is automatically constructed and sent to the slave executor according to the query result.

2. The Dynamic Host Configuration Protocol (DHCP) processing method according to claim 1, characterized in that, The types of mimicry devices include: DHCPv4 server, DHCPv4 client device, DHCPv4 repeater, DHCPv6 server, DHCPv6 client and DHCPv6 repeater.

3. The Dynamic Host Configuration Protocol (DHCP) processing method according to claim 2, characterized in that, When the mimicry device is a DHCPv4 server, and the first DHCP message type is a Discover, Request, Decline, Release, or Inform message sent by an external client, it is determined to extract the address information from the first DHCP message; Accordingly, the system receives a second DHCP message sent by an executor in the mimicry device; if the second DHCP message is sent by the master executor, it forwards the second DHCP message to the corresponding external device; if the second DHCP message is sent by the slave executor, it determines whether to discard it; if not, it queries the cache information based on the interface information of the second DHCP message, and constructs a corresponding message based on the query result and sends it to the slave executor, including: If the second DHCP message is sent by the main execution entity and the type of the second DHCP message is Offer, Ack, or Nak, then the second DHCP message is forwarded to the external DHCP client device. If the second DHCP message is sent from the executor and the second DHCP message type is an Offer or Nak message, then query the cache information based on the interface information. For the same source MAC and source IP: If the cache contains both Request and Decline, or both Request and Release, or both Request, Decline, and Release messages, and the timestamp of the Request message is the latest, or if the cache only contains Request, then construct the corresponding message based on the Request message and send it to the slave executor; otherwise, discard the second DHCP message. If the cache contains an Inform message, then construct the corresponding message based on the Inform message and send it to the slave executor. If the second DHCP message is sent from the executor and the type of the second DHCP message is an Ack message, then the second DHCP message is discarded.

4. The Dynamic Host Configuration Protocol (DHCP) processing method according to claim 3, characterized in that, Also includes: When a new executor comes online, it iterates through the cached information; for the same source MAC, source IP and interface information, it constructs the corresponding message based on the message in the cached information and sends it to the new executor to perform DHCP interaction with the new executor.

5. The Dynamic Host Configuration Protocol (DHCP) processing method according to claim 2, characterized in that, When the mimicry device is a DHCPv4 client device, and the first DHCP message is an Offer, Ack, or Nak message sent by an external server, it is determined to extract the address information from the first DHCP message; Accordingly, the system receives a second DHCP message sent by an executor in the mimicry device; if the second DHCP message is sent by the master executor, it forwards the second DHCP message to the corresponding external device; if the second DHCP message is sent by the slave executor, it determines whether to discard it; if not, it queries the cache information based on the interface information of the second DHCP message, and constructs a corresponding message based on the query result and sends it to the slave executor, including: If the second DHCP message is sent by the main executor and the type of the second DHCP message is Discover, Request, Decline, Release, or Inform, then the second DHCP message will be forwarded to the corresponding external server device. If the second DHCP message is sent by the slave executor and the type of the second DHCP message is a Discover message, then query the cache information according to the interface information. If an Offer message exists in the cache, then construct the corresponding message according to the Offer message and send it to the slave executor. If the second DHCP message is sent by the slave executor and the type of the second DHCP message is a Request message, query the cache information according to the interface information. If there is an Ack or Nak message in the cache, construct the corresponding message according to the Ack or Nak message and send it to the slave executor. If the second DHCP message is sent from the executor and the type of the second DHCP message is Decline or Release, then the second DHCP message is discarded.

6. The Dynamic Host Configuration Protocol (DHCP) processing method according to claim 2, characterized in that, When the mimicry device is a DHCPv4 repeater, the first DHCP message is a Discover, Offer, Request, Ack, Nak, Decline, Release, or Inform message, and the address information in the first DHCP message is determined to be extracted. Accordingly, the system receives a second DHCP message sent by an executor in the mimicry device; if the second DHCP message is sent by the master executor, it forwards the second DHCP message to the corresponding external device; if the second DHCP message is sent by the slave executor, it determines whether to discard it; if not, it queries the cache information based on the interface information of the second DHCP message, and constructs a corresponding message based on the query result and sends it to the slave executor, including: If the second DHCP message is sent by the master executor and the type of the second DHCP message is Offer, Ack or Nak message, then the second DHCP message is forwarded to the corresponding external client device. If the second DHCP message is sent by the main executor and the type of the second DHCP message is Discover, Request, Decline, Release or Inform message, then the second DHCP message is forwarded to the corresponding external server device. If the second DHCP message is sent from the executor, then the second DHCP message is discarded.

7. The Dynamic Host Configuration Protocol (DHCP) processing method according to claim 2, characterized in that, When the mimicry device is a DHCPv6 server, a state message chain is maintained for each executor based on the first DHCP message and the second DHCP message; and the state consistency of each executor is maintained based on the state message chain.

8. The Dynamic Host Configuration Protocol (DHCP) processing method according to claim 7, characterized in that, Based on the aforementioned status message chain, maintaining the state consistency of each of the executors includes: When a new executor comes online, the last two status information items of the status message chain corresponding to the main executor are obtained; Using the two states, a corresponding message is intrinsically constructed and sent to the new executor so that the state of the new executor is consistent with that of the other executors.

9. The Dynamic Host Configuration Protocol (DHCP) processing method according to claim 2, characterized in that, When the mimicry device is a DHCPv6 client, the first DHCP message is an Advertise, Reply, or Reconfigure message sent by an external server, and the address information in the first DHCP message is determined to be extracted. Accordingly, the system receives a second DHCP message sent by an executor in the mimicry device; if the second DHCP message is sent by the master executor, it forwards the second DHCP message to the corresponding external device; if the second DHCP message is sent by the slave executor, it determines whether to discard it; if not, it queries the cache information based on the interface information of the second DHCP message, and constructs a corresponding message based on the query result and sends it to the slave executor, including: If the second DHCP message is sent by the main executor, and the type of the second DHCP message is Solicit, Request, Confirm, Release, Renew, Rebind, Decline, or Information-Request, then it is forwarded to the corresponding external server device, and the status information of the executor is updated. If the second DHCP message is sent by the slave executor and the type of the second DHCP message is a Solicit message, then query the cache information according to the interface information, extract the cached Advertise message sent by the external server to the master executor, construct the corresponding message according to the Advertise message and send it to the slave executor; or, extract the cached Reply message sent by the external server to the master executor, construct the corresponding message according to the Reply message and send it to the slave executor. If the second DHCP message is sent by the slave executor and the type of the second DHCP message is Request, Renew or Rebind message, query the cache information according to the interface information, extract the cached Reply message sent by the external server to the master executor, and then construct the corresponding message according to the Reply message and send it to the slave executor. If the second DHCP message is sent from the executor, and the type of the second DHCP message is Confirm, Release, Decline, or Information-Request, query the cache information according to the interface information, extract the corresponding Reply message from the cache, and send it to the corresponding executor.

10. The Dynamic Host Configuration Protocol (DHCP) processing method according to claim 2, characterized in that, When the mimicry device is a DHCPv6 repeater, the first DHCP message is a DHCPv6 Solicit, Request, Confirm, Release, Renew, Rebind, Decline, or Information-Request message sent by an external client, or a Relay-Reply message sent by an external server, and the address information in the first DHCP message is determined to be extracted. Accordingly, if the second DHCP message is sent by the master executor, then the second DHCP message is forwarded to the corresponding external device; if the second DHCP message is sent by the slave executor, then it is determined whether to discard it. If not, then the cache information is queried according to the interface information of the second DHCP message, and the corresponding message is internally constructed according to the query result and sent to the slave executor, including: If the second DHCP message is sent by the master execution entity and the type of the second DHCP message is Relay-Forward, then the second DHCP message will be forwarded to the corresponding server. If the second DHCP message is sent from the executor, then the DHCP message is discarded.

11. A dynamic host configuration protocol processing device, characterized in that, Applied to mimicry devices, the mimicry device having multiple heterogeneous and redundant actuators, the device includes: The external receiving unit is used to receive the first DHCP message sent by an external device. The external processing unit is used to determine whether to extract the address information from the first DHCP message based on the type of the mimicry device and the type of the first DHCP message. If so, it queries the cache information based on the address information, message type, and interface information, and updates or adds the cache information using the first DHCP message. It also determines whether to send the first DHCP message to the corresponding execution entity in the mimicry device based on the type of the first DHCP message. The internal receiving unit is used to receive the second DHCP message sent by the executor in the mimicry device; The internal processing unit is configured to, if the second DHCP message is sent by the master executor, then forward the second DHCP message to the corresponding external device; if the second DHCP message is sent by the slave executor, then determine whether to discard it; if not, then query the cache information according to the interface information of the second DHCP message, and construct the corresponding message based on the query result and send it to the slave executor.

12. A method for defending against Dynamic Host Configuration Protocol (DHCP) attacks, characterized in that, Based on the Dynamic Host Configuration Protocol processing method according to any one of claims 1 to 10, each executor inputs the same DHCP message from an external device, performs a mimicry adjudication on the output results of each executor, and detects and defends against DHCP attacks based on the adjudication results.

13. A dynamic host configuration protocol attack defense device, characterized in that, include: An attack defense module is used to process the Dynamic Host Configuration Protocol (DHCP) according to any one of claims 1 to 10, such that each executor inputs the same DHCP message from an external device, performs a mimicry adjudication on the output results of each executor, and detects and defends against DHCP attacks based on the adjudication results.

14. A mimicry device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the Dynamic Host Configuration Protocol (DHCP) processing method as described in any one of claims 1 to 10 or the steps of the DHCP attack defense method as described in claim 12 when executing the computer program.

15. A readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed by a processor, implements the steps of the Dynamic Host Configuration Protocol (DHCP) processing method as described in any one of claims 1 to 10 or the steps of the DHCP attack defense method as described in claim 12.

Citation Information

Patent Citations

  • Open shortest path first message processing method and mimicry equipment

    CN112187865A

  • Label synchronization method, system and device and computer readable storage medium

    CN115941769A