Server anomaly detection method, system and device, storage medium and program product

Abstract

The invention discloses a server anomaly detection method, system and device, a storage medium and a program product, and relates to the technical field of computer network security, and the method comprises the steps: simulating a client behavior through a DHCP server by using a pre-created virtual client instance, constructing a DHCP Discover message, and broadcasting the DHCP Discover message through a local area network; monitoring and receiving a DHCP OFFER (Dynamic Host Configuration Protocol OFFER) response message returned for the DHCP Discover message in the network; analyzing the response message to obtain key data, and performing legality verification on the response message; and when a verification result meets a preset violation condition, determining a target abnormal server which sends the response message according to the key data. According to the scheme, the DHCP server simulates the client behavior to actively initiate the DHCP Discover message, and the response result is subjected to validity verification, so that the unauthorized DHCP service behavior can be effectively identified, and the illegal DHCP server in the local area network can be accurately positioned.

Description

Technical Field

[0001] This application relates to the field of computer network security technology, and in particular to server anomaly detection methods, systems, devices, storage media, and program products. Background Technology

[0002] Dynamic Host Configuration Protocol (DHCP) is a core technology for IP address allocation within an enterprise intranet. Its basic principle is as follows: electronic devices with operating systems typically have a DHCP client installed. After the electronic device starts up, this client broadcasts an IP address request to the intranet. The DHCP server on the intranet receives and processes this broadcast message, then assigns an IP address to the client. After obtaining this IP address, the client can then access the intranet normally.

[0003] However, because DHCP does not integrate an authentication mechanism in its standardized protocol, client devices within an enterprise default to trusting the first DHCP server that responds to them. This vulnerability allows attackers to quickly deploy their own DHCP server on the internal network via physical access or software tools, assigning malicious network parameters to clients and causing network anomalies. Summary of the Invention

[0004] The main purpose of this application is to provide a server anomaly detection method, system, device, storage medium, and program product, which aims to solve the technical problem of how to identify illegal DHCP servers in a local area network.

[0005] To achieve the above objectives, this application proposes a server anomaly detection method, which is applied to a DHCP server and includes: Simulate client behavior using a pre-created virtual client instance, construct a DHCP Discover message, and broadcast it within the broadcast domain. Listen for and receive DHCP OFFER response messages returned in response to the DHCP Discover message within the broadcast domain; Parse the DHCP OFFER response message to obtain key data, and verify the validity of the DHCP OFFER response message; When the verification result meets the preset violation conditions, the target abnormal server that sent the DHCP OFFER response message is determined based on the key data.

[0006] In one embodiment, the step of simulating client behavior using a pre-created virtual client instance, constructing a DHCPDiscover message, and broadcasting it within the broadcast domain includes: The trigger time for the current detection is determined based on the preset active detection cycle; When the trigger time is reached, a pre-created virtual client instance simulates client behavior and generates a DHCP Discover message; Add a preset field identifier to the DHCP Discover message; The DHCP Discover message containing the preset field identifier is broadcast through the broadcast domain to which the DHCP Discover message belongs.

[0007] In one embodiment, before the step of determining the trigger time of the current detection according to a preset active detection period, the method further includes: According to the random jitter mechanism, a random jitter value is added to the active detection period to obtain a preset active detection period, wherein the random jitter value is generated within the preset random jitter range.

[0008] In one embodiment, the steps of parsing the DHCP OFFER response message, obtaining key data, and verifying the legitimacy of the DHCP OFFER response message include: Analyze the DHCP Offer response message and extract key data; Determine whether the key data meets the preset violation conditions.

[0009] In one embodiment, the key data includes the response source IP address, response source MAC address, assigned IP address, gateway address, DNS server address, and lease duration. The step of determining whether the key data meets the preset violation conditions includes: If the IP address or MAC address of the response source is not in the preset trusted server list, the critical data is deemed to be in violation; and / or If the assigned IP address does not belong to the authorized network segment, the critical data is deemed to be in violation; and / or If the gateway address or the DNS server address is a preset malicious address or an unauthorized address, then the critical data is deemed to be in violation; and / or If the rental period is less than a preset threshold, the key data is deemed to be in violation.

[0010] In one embodiment, the step of determining the target abnormal server that sent the DHCP OFFER response message based on the key data when the verification result meets the preset violation conditions includes: When the verification result meets the preset violation conditions, the target abnormal server that sent the DHCP OFFER response message is determined based on the response source MAC address and response source IP address parsed from the DHCP OFFER response message, and the corresponding security response mechanism is triggered.

[0011] Furthermore, to achieve the above objectives, this application also proposes a server anomaly detection system, which includes: The simulation module is used to simulate client behavior using pre-created virtual client instances, construct DHCPDiscover messages, and broadcast them within the broadcast domain. The monitoring module is used to monitor and receive DHCP OFFER response messages returned in response to the DHCP Discover message within the broadcast domain; The verification module is used to parse the DHCP OFFER response message, obtain key data, and verify the legality of the DHCP OFFER response message. The identification module is used to determine the target abnormal server that sent the DHCP OFFER response message based on the key data when the verification result meets the preset violation conditions.

[0012] In addition, to achieve the above objectives, this application also proposes a server anomaly detection device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the server anomaly detection method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the server anomaly detection method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the server anomaly detection method described above.

[0015] This application proposes a server anomaly detection method, system, device, storage medium, and program product. The method includes: creating a virtual client instance; using the virtual client instance to simulate client behavior, constructing a DHCPDiscover message and broadcasting it over a local area network; listening to and receiving response messages returned by the DHCP Discover message in the network, and verifying the legitimacy of the response messages; and triggering a corresponding security response mechanism when the verification result meets preset violation conditions. This solution, by simulating client behavior on the DHCP server to actively initiate DHCP Discover messages and verifying the legitimacy of the response results, can effectively identify unauthorized DHCP service behavior, thereby accurately locating illegal DHCP servers within the local area network. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the server anomaly detection method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the server anomaly detection method of this application; Figure 3 This is a simplified flowchart illustrating the server anomaly detection method provided in Embodiment 2 of this application; Figure 4 This is a schematic diagram of the module structure of the server anomaly detection system according to an embodiment of this application; Figure 5 This is a schematic diagram of the hardware operating environment involved in the server anomaly detection method in this application embodiment.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is as follows: a virtual client instance is created by a DHCP server; the virtual client instance is used to periodically simulate client behavior, construct a DHCP Discover message and broadcast it in the broadcast domain; the response messages returned in response to the DHCP Discover message in the broadcast domain are listened to and received, and the legality of the response messages is verified; when the verification result meets the preset violation conditions, the target abnormal server is identified and the corresponding security response mechanism is triggered.

[0023] In this embodiment, for ease of description, the following description uses a legitimate DHCP server as the executing entity.

[0024] Because existing DHCP protocols do not integrate authentication mechanisms in their standardized protocols (RFC2131), client devices within an enterprise default to trusting the first DHCP server that responds to them. This vulnerability allows attackers to quickly deploy their own DHCP servers on the internal network via physical access or software tools (such as ISC DHCP Server, dnsmasq, etc.), assigning malicious network parameters (such as incorrect IPs, fake gateways, etc.) to clients, thereby causing network anomalies.

[0025] This application provides a server anomaly detection method, system, device, storage medium, and program product. The method involves a DHCP server periodically simulating client behavior using a pre-created virtual client instance, constructing DHCP Discover messages, and broadcasting them within its broadcast domain. It then listens for and receives DHCPOFFER response messages returned in response to the DHCP Discover messages within the broadcast domain; parses these response messages to obtain key data; and verifies the validity of the response messages. When the verification result meets preset violation conditions, the target abnormal server that sent the response message is determined based on the key data. This method, by simulating client behavior to actively initiate DHCP Discover messages and verifying the validity of the response results, can identify illegal IP allocation behavior in real time, thereby accurately locating illegal DHCP servers within the local area network.

[0026] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions. The following description uses a personal computer as an example to illustrate this embodiment and the subsequent embodiments.

[0027] Based on this, embodiments of this application provide a server anomaly detection method, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the server anomaly detection method of this application.

[0028] In this embodiment, the server anomaly detection method includes steps S10 to S40: Step S10: Simulate client behavior using a pre-created virtual client instance, construct a DHCP Discover message, and broadcast it within the broadcast domain. It should be noted that the DHCP Discover message refers to a broadcast request message conforming to the RFC 2131 protocol specification. Its opcode (OP) field is 1 (BOOTREQUEST), its message type (Option 53) is 1 (Discover), and each DHCP Discover message carries a randomly generated virtual MAC address (formatted as 00:1A:XX:XX:XX, where XX is a random hexadecimal number) and a unique transaction ID to avoid confusion with real clients. In this embodiment, the message also includes a preset field identifier (e.g., Option 43 field identifier) ​​to indicate to other legitimate DHCP servers in the network that the request is a probe message.

[0029] Because existing technologies lack an active detection mechanism for unauthorized DHCP services within a local area network, and client devices default to trusting the first responding server, which can easily lead to security risks such as illegal IP allocation and gateway hijacking, this embodiment creates a virtual client instance within a legitimate DHCP server to perform standard DHCP client behavior and actively initiate detection requests to identify whether other illegal or unauthorized DHCP servers exist in the network.

[0030] A virtual client instance refers to a logical entity created within a legitimate DHCP server. This entity mimics the behavior of a standard DHCP client protocol stack, possessing the ability to construct and send DHCP request messages, listen for response messages, and parse network parameters. This virtual client instance does not correspond to an actual physical terminal and does not participate in normal business communication; it is solely used to actively detect the presence of unauthorized DHCP servers within the local area network.

[0031] Understandably, since the existing technology cannot identify the probe behavior in the network environment and responds to all Discover requests by default, executing step S10 can actively trigger the response of unauthorized devices, while the legitimate server will not respond after recognizing the preset field identifier, thereby achieving covert detection and preliminary screening of abnormal service response sources.

[0032] In one feasible embodiment, step S10 may include steps S11 to S14: Step S11: Determine the trigger time for the current detection based on the preset active detection cycle; It should be noted that the preset active probing period refers to a pre-configured time interval T, used to control the frequency at which virtual client instances initiate probing requests. In this embodiment, the active probing period T can be set to 30 seconds. Periodic probing ensures timely detection while avoiding the waste of network resources caused by broadcasting.

[0033] Specifically, during the initialization phase, the system starts a timed task module. This module generates probe scheduling events based on the timer service provided by the operating system, with a time interval T. Whenever the previous probe process is completed, the timed task module starts timing and generates a trigger signal when the countdown ends, which serves as the basis for generating the DHCPDiscover message in step S12.

[0034] Step S12: When the trigger time is reached, a pre-created virtual client instance simulates client behavior and generates a DHCP Discover message; Specifically, when the trigger detection time is reached, the virtual client instance constructs a DHCP Discover message conforming to the RFC 2131 protocol specification in user space by calling the raw socket interface provided by the operating system. This includes: setting the opcode field to 1, the hardware address type to 1, the hardware address length to 6, and the hop count to 0; generating a 32-bit unsigned integer for the transaction ID using the system's secure random number generator; filling the client hardware address with a pre-generated virtual MAC address; setting the client IP address, allocation IP address, server IP address, and gateway IP address to 0.0.0.0; and reserving space in the message options area for subsequent steps to add preset field identifiers. This construction method ensures that the generated DHCP Discover message can be correctly parsed by a standard DHCP server while avoiding confusion with the real client process.

[0035] Step S13: Add a preset field identifier to the DHCP Discover message; It should be noted that the preset field identifier refers to specific data content embedded in the DHCP Discover message option field, which is used to indicate to other legitimate DHCP servers in the network that the request is a probe message, thereby triggering their silent processing strategy.

[0036] Since existing illegitimate or unauthorized DHCP servers typically cannot recognize custom vendor information fields and will respond to all received Discover requests indiscriminately, while legitimate DHCP servers can identify the preset field identifier through pre-configured policies and choose not to respond, this embodiment adds a preset field identifier, such as the Option 43 field identifier, to the DHCP Discover message. This causes unauthorized devices to return a DHCP OFFER response, while legitimate servers actively ignore the request, thereby effectively avoiding redundant response messages in the broadcast domain and significantly reducing network load and log interference.

[0037] Step S14: Broadcast the DHCP Discover message containing the preset field identifier through the broadcast domain to which the DHCP Discover message belongs.

[0038] Specifically, the virtual client instance sends the constructed DHCP Discover message to the link-layer broadcast address through the raw socket interface provided by the operating system, and ensures that the DHCP Discover message is received by all devices within its broadcast domain according to the preset IP-layer destination address. Because this message carries a preset identifier field, legitimate DHCP servers will choose to ignore it silently according to the pre-configured security policy, while unauthorized DHCP servers, unable to recognize this identifier, will return a DHCP Offer response message, thus providing a data basis for subsequent identification of abnormal servers.

[0039] The above steps demonstrate a technical solution that deploys a virtual client instance within a legitimate DHCP server and proactively sends a DHCP Discover probe message carrying a preset identifier to its broadcast domain. Because legitimate DHCP servers will silently ignore the request after recognizing this identifier, while unauthorized or illegally connected DHCP servers typically cannot recognize such custom identifiers and will indiscriminately return a DHCP OFFER response, the system will only receive a response message when an abnormal DHCP service exists on the network. This provides a reliable data input foundation for subsequent abnormal server identification while avoiding interference with normal network services.

[0040] Step S20: Listen for and receive DHCPOFFER response messages returned in the broadcast domain in response to the DHCP Discover message; Specifically, after sending the DHCP Discover message packet, the legitimate DHCP server simulates a virtual client instance, opens UDP port 68, binds it to the local network interface, listens for link layer broadcast traffic through raw sockets, captures all UDP packets with destination address 255.255.255.255 and destination port 68, and parses out the DHCP Offer response from them.

[0041] Step S30: Parse the DHCP OFFER response message, obtain key data, and verify the legality of the DHCP OFFER response message; Understandably, because the existing DHCP protocol lacks an authentication mechanism, any device can respond to the request, which makes it easy for illegal servers to cause risks such as man-in-the-middle attacks. Therefore, executing step S30 can identify and intercept DHCP responses with illegal configurations, thus ensuring network communication security.

[0042] In one feasible embodiment, step S30 may include steps S31-S32: Step S31: Parse the DHCP Offer response message and extract key data; It should be noted that the key data includes, but is not limited to, the response source IP address, the response source MAC address, the assigned IP address, the gateway address, the DNS list, and the lease duration.

[0043] Specifically, all captured DHCP Offer response messages are decoded field by field. First, it is verified whether the opcode is 2 and the message type is 2. Then, the key fields mentioned above are extracted according to the preset standard format and stored in a structured temporary detection record for subsequent legal verification.

[0044] Step S32: Determine whether the key data meets the preset violation conditions.

[0045] It should be understood that, because the Dynamic Host Configuration Protocol (DHCP) itself lacks a server-side authentication mechanism, attackers can forge response messages to tamper with network parameters, induce clients to access malicious network administrators or DNS servers, and then carry out man-in-the-middle attacks, data theft, or phishing attacks. At the same time, unauthorized devices may cause IP conflicts or network interruptions due to misconfiguration. Therefore, executing step S32 can automatically verify the compliance of response messages based on multi-dimensional rules, accurately identify the source of abnormal DHCP service responses, and achieve proactive defense against unauthorized devices and interception of security risks.

[0046] In another feasible embodiment, step S32 may further include steps S321 to S324: Step S321: If the IP address or MAC address of the response source is not in the preset trusted server list, then the critical data is determined to be in violation; and / or Step S322: If the assigned IP address does not belong to the authorized network segment, then the critical data is determined to be in violation; and / or Step S323: If the gateway address or the DNS server address is a preset malicious address or an unauthorized address, then the critical data is determined to be in violation; and / or Step S324: If the rental period is less than a preset threshold, the key data is determined to be in violation.

[0047] Specifically, the trusted server list is pre-configured by the network administrator and contains the IP address and MAC address mapping relationship of authorized DHCP servers. The system achieves fast lookup through hash table or database index. When a DHCP Offer response message is received, if the source IP address or source MAC address of the response does not match any record in the list, it is determined to be an unauthorized server and a violation mark is triggered.

[0048] The authorized network segment is the subnet range within which the network plan allows the allocation of IP addresses; if the IP address specified in the DHCP Offer response message does not belong to this range, it indicates an unauthorized act and is judged as a violation.

[0049] The malicious or unauthorized addresses include known attack IPs, phishing gateways, and illegal DNS servers. Matching these addresses to a list obtained from a local policy database or dynamic threat intelligence interface identifies them as potential security threats and marks them as violations.

[0050] The preset threshold is a time value of not less than 60 seconds, preferably 120 seconds. Since the lease period of legitimate DHCP services is usually set to several hours to several days, while attackers often use extreme lease periods (such as 10 to 30 seconds) to quickly hijack client connections, when the lease duration is detected to be less than this threshold, it can be highly suspected that it is a malicious DHCP service and is judged as a violation.

[0051] When the extracted key data meets at least one of the above-mentioned violation conditions, the response is determined to be a violation. Therefore, this solution can proactively discover and identify unauthorized DHCP servers in the network, and induce responses from unauthorized devices through probe messages carrying specific identifiers. Furthermore, by performing rule-based verification on parameters such as the response source address, assigned IP, gateway, DNS, and lease period of the response message, its violation attributes can be accurately determined, thereby achieving rapid location and alarm of potential security threats, and ensuring the security and stability of network communication.

[0052] Step S40: When the verification result meets the preset violation conditions, determine the target abnormal server that sent the DHCP OFFER response message based on the key data.

[0053] In this embodiment, when the legality verification module in step S30 determines that the key data in the DHCP Offer response message is in violation, the system uses the response source MAC address and response source IP address in the DHCP Offer response message as unique identifiers to determine the target abnormal DHCP server that sent the abnormal response. Simultaneously, the system activates an alarm mechanism, generates a structured security event log, and pushes alarm information to the network administrator via the local console, email, SMS, or API interface, indicating that unauthorized DHCP service activity exists and requires further action.

[0054] The method described above creates a virtual client instance within the DHCP server, simulates client behavior using this virtual client instance, constructs a DHCP Discover message, and broadcasts it over the local area network (LAN). It then listens for and receives response messages returned by the DHCP Discover message on the network, verifying the validity of these response messages. When the verification result meets preset violation conditions, the target abnormal server is identified based on the corresponding response message. This scheme, by simulating client behavior to proactively initiate DHCP Discover messages and verifying the validity of the response results, effectively identifies unauthorized DHCP service behavior, thereby accurately locating illegal DHCP servers within the LAN.

[0055] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Before step S11, the server anomaly detection method further includes step S011: Step S011: According to the random jitter mechanism, a random jitter value is added to the active detection period to obtain a preset active detection period, wherein the random jitter value is generated within the preset random jitter range.

[0056] Traditional fixed-period detection methods are highly predictable and easily circumvented by attackers through traffic analysis. This allows unauthorized DHCP servers to start services outside the detection interval to evade detection, thus reducing the effectiveness of security protection. Therefore, in this embodiment, a jitter mechanism is introduced to add a [-] to the base period for each detection interval. ,+ Random jitter values ​​within a certain range disrupt the temporal regularity of detection behavior, enhance the concealment and unpredictability of the detection process, and prevent attackers from predicting detection patterns.

[0057] Specifically, the random jitter mechanism involves superimposing a random jitter value onto the base detection period T. Generate the actual detection interval. The basic detection period can be configured to any value between 60 seconds and 600 seconds, preferably 300 seconds; the random jitter value... The pseudo-random number is generated by the system's built-in system and uses the current system timestamp as a seed to ensure that each result is independent and unpredictable. The jitter range is expressed as a percentage of the base period, set to ±5% to ±20%, preferably ±10%. That is, for a base period of 300 seconds, the actual detection interval (i.e., the actual active probe period) is randomly distributed between 270 seconds and 330 seconds.

[0058] By employing the methods described above, while maintaining a reasonable detection density, the temporal sequence characteristics of detection behavior are geodeticly disrupted, preventing potential attackers from establishing accurate detection models through long-term traffic monitoring and thus preventing them from evading detection using time windows. Furthermore, the system automatically calculates the trigger time for the next detection after each detection operation, forming a continuous and dynamic detection scheduling strategy, further enhancing the system's anti-evasion capabilities.

[0059] For example, to help understand the implementation flow of the server anomaly detection method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 3 , Figure 3 A simplified flowchart of a server anomaly detection method is provided, specifically: A virtual client instance is created within a legitimate DHCP server to actively probe for the existence of unauthorized DHCP services on the network. This virtual client periodically generates virtual DHCP Discover messages according to a preset active probe period T (T=30 seconds by default).

[0060] Each DHCP Discover message carries a randomly generated virtual MAC address (in the format 00:1A:XX:XX:XX, where the last four hexadecimal digits are randomly generated by the system) and a unique transaction ID to ensure its uniqueness in the network and avoid confusion with real clients.

[0061] To further enhance the stealth and evasion resistance of the detection behavior, a random jitter mechanism (such as a fluctuation range of ±10%) can be introduced into the basic active detection period T, so that the actual detection time is randomly distributed in the interval [0.9T, 1.1T], breaking the temporal regularity of the detection behavior and preventing attackers from predicting the detection timing through traffic analysis and implementing evasion.

[0062] Furthermore, a custom identification field is added to the constructed DHCP Discover message, such as by adding Option43= or a vendor-specific selected field to carry a preset identifier. Legitimate DHCP servers are pre-configured with policies that, upon recognizing this identifier, silently discard the corresponding request without returning a response. This effectively reduces redundant communication and network load within the broadcast domain, while ensuring that other legitimate DHCP servers are not interfered with.

[0063] After sending a DHCP Discover message, the virtual client instance immediately opens UDP port 68 to listen for all DHCP Offer responses. If a DHCP Offer response is received, it parses and records key data from the response message, including but not limited to the source IP address, server MAC address, assigned IP address, gateway address, DNS list, and lease duration.

[0064] Subsequently, the above data is validated for legality based on preset security policies to determine whether any violations exist. For example, the source IP or MAC address of the response is not on the authorized DHCP server whitelist; the assigned IP address does not belong to the preset authorized network segment; the gateway or DNS address is a known malicious address or a non-compliant configuration; the lease duration is shorter than the preset threshold, which is suspected to be an attack.

[0065] Once any violation condition is detected, the system determines that the response comes from an abnormal DHCP server and triggers a security alarm mechanism. It generates a structured log event and pushes an alarm message to the network administrator via email, SMS, or API interface, indicating that there is unauthorized DHCP service activity and further action is required.

[0066] In summary, this solution proposes a malicious DHCP server detection method based on active probing. By integrating an active probing module into legitimate DHCP servers, it periodically simulates client behavior, continuously broadcasting DHCP Discover messages carrying specific identifiers to stimulate potential DHCP service responses in the network. After sending the DHCP Discover message, it monitors and captures the returned DHCP Offer response messages in real time, analyzes their key data, and performs multi-dimensional legitimacy checks based on preset security policies. If the response content is found to be outside the authorized scope or exhibits abnormal characteristics, it is determined to be an illegal IP allocation behavior, immediately triggering a security alarm, achieving accurate identification and rapid response to malicious DHCP servers. Furthermore, adding a random element to the continuous probing time effectively prevents attackers from discovering patterns. In addition, introducing a specific identifier field into the DHCP Discover message prevents legitimate DHCP servers from responding to the probe message, reducing network load.

[0067] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the server anomaly detection method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0068] This application also provides a server anomaly detection system; please refer to [reference needed]. Figure 4 The server anomaly detection system includes: Simulation module 10 is used to simulate client behavior using a pre-created virtual client instance, construct a DHCPDiscover message, and broadcast it within its broadcast domain; The listening module 20 is used to listen for and receive DHCP OFFER response messages returned in response to the DHCP Discover message within the broadcast domain; The verification module 30 is used to parse the DHCP OFFER response message, obtain key data, and verify the legality of the DHCP OFFER response message; The identification module 40 is used to determine the target abnormal server that sent the DHCP OFFER response message based on the key data when the verification result meets the preset violation conditions.

[0069] The server anomaly detection system provided in this application, employing the server anomaly detection method described in the above embodiments, can solve the technical problem of identifying illegal DHCP servers in a local area network. Compared with the prior art, the beneficial effects of the server anomaly detection system provided in this application are the same as those of the server anomaly detection method provided in the above embodiments, and other technical features of the server anomaly detection system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0070] This application provides a server anomaly detection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the server anomaly detection method in the above embodiment 1.

[0071] The following is for reference. Figure 5The diagram illustrates a structural schematic suitable for implementing a server anomaly detection device according to embodiments of this application. The server anomaly detection device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The server anomaly detection device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0072] like Figure 5 As shown, the server anomaly detection device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the server anomaly detection device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the server anomaly detection device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows server anomaly detection devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0073] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0074] The server anomaly detection device provided in this application, employing the server anomaly detection method described in the above embodiments, can solve the technical problem of how to identify illegal DHCP servers in a local area network. Compared with the prior art, the beneficial effects of the server anomaly detection device provided in this application are the same as those of the server anomaly detection method provided in the above embodiments, and other technical features of this server anomaly detection device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0075] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0076] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0077] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the server anomaly detection method in the above embodiments.

[0078] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0079] The aforementioned computer-readable storage medium may be included in the server anomaly detection device; or it may exist independently and not be assembled into the server anomaly detection device.

[0080] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the server anomaly detection device, the server anomaly detection device: simulates client behavior using a pre-created virtual client instance within a legitimate DHCP server, constructs a DHCP Discover message, and broadcasts it over the local area network; listens for and receives DHCP OFFER response messages returned in response to the DHCP Discover message in the network; parses the response message, obtains key data, and verifies the legitimacy of the response message; when the verification result meets the preset violation conditions, it determines the target abnormal server that sent the response message based on the key data.

[0081] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0082] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0083] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0084] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described server anomaly detection method, thereby solving the technical problem of how to identify illegal DHCP servers in a local area network. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the server anomaly detection method provided in the above embodiments, and will not be repeated here.

[0085] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the server anomaly detection method described above.

[0086] The computer program product provided in this application can solve the technical problem of how to identify illegal DHCP servers in a local area network. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the server anomaly detection method provided in the above embodiments, and will not be repeated here.

[0087] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for detecting server anomalies, characterized in that, The server anomaly detection method is applied to a Dynamic Host Configuration Protocol (DHCP) server. The server anomaly detection method includes: Simulate client behavior using a pre-created virtual client instance, construct a DHCP Discover message, and broadcast it within the broadcast domain. Listen for and receive DHCP OFFER response messages returned in response to the DHCP Discover message within the broadcast domain; Parse the DHCP OFFER response message to obtain key data, and verify the validity of the DHCP OFFER response message; When the verification result meets the preset violation conditions, the target abnormal server that sent the DHCP OFFER response message is determined based on the key data.

2. The server anomaly detection method as described in claim 1, characterized in that, The steps of simulating client behavior using a pre-created virtual client instance, constructing a DHCP Discover message, and broadcasting it within the broadcast domain include: The trigger time for the current detection is determined based on the preset active detection cycle; When the trigger time is reached, a pre-created virtual client instance simulates client behavior and generates a DHCPDiscover message; Add a preset field identifier to the DHCP Discover message; The DHCP Discover message containing the preset field identifier is broadcast through the broadcast domain to which the DHCP Discover message belongs.

3. The server anomaly detection method as described in claim 2, characterized in that, Before the step of determining the trigger time of the current detection according to the preset active detection cycle, the method further includes: According to the random jitter mechanism, a random jitter value is added to the active detection period to obtain a preset active detection period, wherein the random jitter value is generated within the preset random jitter range.

4. The server anomaly detection method as described in claim 2, characterized in that, The steps of parsing the DHCP OFFER response message, obtaining key data, and verifying the validity of the DHCP OFFER response message include: Parse the DHCP OFFER response message and extract key data; Determine whether the key data meets the preset violation conditions.

5. The server anomaly detection method as described in claim 4, characterized in that, The key data includes the response source IP address, response source MAC address, assigned IP address, gateway address, DNS server address, and lease duration. The step of determining whether the key data meets the preset violation conditions includes: If the IP address or MAC address of the response source is not in the preset trusted server list, the critical data is deemed to be in violation; and / or If the assigned IP address does not belong to the authorized network segment, the critical data is deemed to be in violation; and / or If the gateway address or the DNS server address is a preset malicious address or an unauthorized address, then the critical data is deemed to be in violation; and / or If the rental period is less than a preset threshold, the key data is deemed to be in violation.

6. The server anomaly detection method as described in any one of claims 1 to 5, characterized in that, The step of determining the target abnormal server that sent the DHCP OFFER response message based on the key data when the verification result meets the preset violation conditions includes: When the verification result meets the preset violation conditions, the target abnormal server that sent the DHCP OFFER response message is determined based on the response source MAC address and response source IP address parsed from the DHCP OFFER response message, and the corresponding security response mechanism is triggered.

7. A server anomaly detection system, characterized in that, The server anomaly detection system includes: The simulation module is used to simulate client behavior using pre-created virtual client instances, construct DHCP Discover messages, and broadcast them within the broadcast domain. The monitoring module is used to monitor and receive DHCPOFFER response messages returned in response to the DHCP Discover message within the broadcast domain; The verification module is used to parse the DHCP OFFER response message, obtain key data, and verify the legality of the DHCP OFFER response message. The identification module is used to determine the target abnormal server that sent the DHCP OFFER response message based on the key data when the verification result meets the preset violation conditions.

8. A server anomaly detection device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the server anomaly detection method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the server anomaly detection method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the server anomaly detection method as described in any one of claims 1 to 6.

Images