Method, device and equipment for testing protocol flood attack function and storage medium

Abstract

This application discloses a testing method, apparatus, device, and storage medium for Internet Control Message Protocol (ICP) flood attack functionality, relating to the field of network security testing technology. The method includes: acquiring test parameters and generating test cases based on the test parameters; collecting baseline performance data of a target device; sending a traffic attack generated based on the test cases to the target device and collecting test performance data of the target device during the traffic attack; determining protection strategy optimization parameters based on the test performance data; writing the protection strategy optimization parameters into the target device for secondary testing and collecting optimized performance data of the target device during the secondary test; and comparing the optimized performance data with the baseline performance data to verify the optimization effect. This application improves the iteration efficiency and verification reliability of Internet Control Message Protocol (ICP) flood attack protection strategies.

Description

Technical Field

[0001] This application relates to the field of network security testing technology, and in particular to a testing method for protocol flood attack functionality. Background Technology

[0002] ICMP Flood (Internet Control Message Protocol Flood) is a typical denial-of-service (DoS / DDoS) attack. Attackers send a massive number of ICMP echo requests to the target server, exhausting the target device's bandwidth resources or system processing capacity, causing legitimate traffic to fail to respond normally; when the attack source is a botnet, it escalates into a distributed denial-of-service (DDoS) attack.

[0003] Currently, ICMP Flood-related technologies mainly focus on attack detection and defense, with a relative lack of methods and devices specifically designed for testing protective capabilities. In actual testing, engineers typically rely on manually writing scripts or using general-purpose attack tools to execute temporary, single attacks. Test parameters must be manually modified in the command line, making it difficult to achieve multi-dimensional combined testing and systematic coverage of various attack variants. After testing, the effectiveness of protection can only be judged by observing superficial phenomena such as slow response times of the target device, without systematically collecting performance indicators such as processor utilization, response time, and packet loss rate, making quantifiable evaluation difficult. Furthermore, the testing system and the protection system are independent of each other, requiring manual data analysis and strategy adjustments. The testing, analysis, optimization, and retesting processes lack automatic coordination, resulting in long closed-loop cycles and low iteration efficiency.

[0004] In summary, existing technologies lack a standardized closed-loop testing method that automatically connects attack testing, performance analysis, strategy optimization, and effect verification.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a testing method for protocol flood attack functionality, aiming to solve the technical problem that the existing technology lacks a standardized closed-loop testing method that automatically connects attack testing, performance analysis, strategy optimization and effect verification.

[0007] To achieve the above objectives, this application proposes a method for testing protocol flood attack functionality, the method comprising: Obtain test parameters and generate test cases based on the test parameters; Collect baseline performance data of the target device; Send a traffic attack based on the test case to the target device, and collect test performance data of the target device in the traffic attack; Based on the test performance data, determine the optimization parameters for the protection strategy; The optimized parameters of the protection strategy are written into the target device for secondary testing, and the optimized performance data of the target device in the secondary test is collected. The optimized performance data is compared with the baseline performance data to verify the optimization effect.

[0008] In one embodiment, determining the protection strategy optimization parameters based on the test performance data includes: The test performance data was analyzed to obtain the analysis results; Based on the analysis results, pinpoint the performance inflection point where the response time suddenly increases; Obtain the attack traffic rate corresponding to the performance inflection point; Calculate the traffic rate limiting threshold based on the attack traffic rate; Based on the analysis results, the optimization parameters of the protection strategy are determined, wherein the optimization parameters of the protection strategy include the traffic rate limiting threshold, the synchronization sequence number verification enable command, and the source address reverse path verification configuration.

[0009] In one embodiment, locating the performance inflection point of a sudden increase in response time based on the analysis results includes: The response delay sequence of the target device is extracted from the analysis results. The response delay sequence is composed of the response times corresponding to each acquisition time point arranged in chronological order. Perform point-by-point difference calculation on the response delay sequence to obtain the response delay difference between adjacent acquisition time points; Generate a response delay difference sequence based on the response delay difference; Traverse the response delay difference sequence and determine the collection time point corresponding to the first difference data point that exceeds the preset difference threshold as the performance inflection point.

[0010] In one embodiment, sending a traffic attack based on the test case to the target device includes: Based on the test cases, construct standard echo request data; Based on the test cases, construct malformed data, wherein the malformed data includes generating fragmented and superimposed packets and setting abnormal time-to-live packets; The source address is randomly generated based on the source address generation strategy parameters; The standard echo request data, the malformed data, and the randomly generated source address are sent to the target device.

[0011] In one embodiment, collecting the test performance data of the target device during the DDoS attack includes: Based on the test performance data, generate a curve showing the relationship between attack strength and device performance; A test report is generated based on the relationship curve. The test report includes a protection capability score and performance bottleneck location information. The test report is used to guide the generation of optimized parameters for the protection strategy.

[0012] In one embodiment, obtaining test parameters and generating test cases based on the test parameters includes: Obtain attack parameters, including packet sending rate, data packet size, source address range, malformed data ratio, and attack duration; The attack patterns are obtained, including direct flood attack pattern, address spoofing attack pattern, and malformed packet attack pattern; Based on the attack parameters and the attack pattern, structured test cases are generated.

[0013] In one embodiment, after the traffic attack ends, data on the recovery process of the target device continues to be collected; Based on the baseline performance data, the test performance data, the optimized performance data, and the recovery process data, a lifecycle performance change curve for the target device is generated; Based on the lifecycle performance change curve, the performance bottleneck of the target device is located, and the recovery capability of the target device from an attack state to a normal state is evaluated.

[0014] Furthermore, to achieve the above objectives, this application also proposes a testing apparatus for protocol flood attack functionality, the testing apparatus for protocol flood attack functionality comprising: The test case generation module is used to obtain test parameters and generate test cases based on the test parameters. The performance monitoring module is used to collect baseline performance data of the target device; An attack traffic generation module is used to send a traffic attack generated based on the test case to the target device and collect test performance data of the target device in the traffic attack. The strategy optimization analysis module is used to determine the optimization parameters of the protection strategy based on the test performance data. The strategy deployment module is used to write the protection strategy optimization parameters into the target device for secondary testing, and to collect the optimization performance data of the target device in the secondary test; The effect verification module is used to compare the optimized performance data with the baseline performance data to verify the optimization effect.

[0015] Furthermore, to achieve the above objectives, this application also proposes a test method device for protocol flood attack functionality, 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 test method for protocol flood attack functionality as described above.

[0016] 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 test method for the protocol flood attack function as described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: By adopting a standardized closed-loop testing process, the previously independent attack testing, performance analysis, strategy optimization, and effect verification stages are automatically integrated into one, solving the technical problems of existing technologies where the testing system and protection system are independent and lack standardized closed-loop testing methods. Compared with the existing technology that relies on manually writing scripts to execute a single attack and then manually analyzing data and adjusting strategies after the test, this application upgrades the testing process from a scattered, temporary operation to a standardized, automated closed-loop process. Testers no longer need to interrupt the process for manual analysis and deployment after the test; instead, the system automatically completes the entire process from data collection and analysis to strategy deployment and verification. This shortens the closed-loop cycle of testing, analysis, optimization, and verification, improves the iteration efficiency of protection strategies, and achieves objective verification of optimization effects through quantitative comparison of baseline data and optimized performance data, ensuring the scientific nature and credibility of the test results. Attached Figure Description

[0018] 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.

[0019] 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.

[0020] Figure 1 A flowchart illustrating the test method for the flood attack function of this application protocol, provided in Implementation Example 1; Figure 2 A flowchart illustrating the second embodiment of the test method for the flood attack function of this application protocol; Figure 3 A flowchart illustrating the test method for the flood attack function of this application protocol, provided in Implementation Example 3; Figure 4 This application demonstrates the function modules of the flood attack function test method, their connections, and functional diagrams. Figure 5 This is a schematic diagram of the module structure of the test device for the protocol flood attack function in the embodiments of this application; Figure 6 This is a schematic diagram of the hardware operating environment involved in the test method for the protocol flood attack function in the embodiments of this application.

[0021] 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

[0022] 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.

[0023] 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.

[0024] The main solution of this application embodiment is as follows: obtain test parameters, generate test cases based on the test parameters; collect baseline performance data of the target device; send a traffic attack generated based on the test cases to the target device, and collect test performance data of the target device in the traffic attack; determine protection strategy optimization parameters based on the test performance data; write the protection strategy optimization parameters into the target device for secondary testing, and collect the optimized performance data of the target device in the secondary test; compare the optimized performance data with the baseline performance data to verify the optimization effect.

[0025] In this embodiment, for ease of description, the following description will focus on the test system as the execution subject.

[0026] In existing technologies, testing the protocol flood attack function relies on engineers manually writing scripts or using general attack tools to execute temporary single attacks. After the test is completed, data needs to be manually analyzed and protection strategies need to be manually adjusted. The test system and the protection system are independent of each other, and there is a lack of a standardized closed-loop test method that automatically connects attack testing, performance analysis, strategy optimization and effect verification.

[0027] This application provides a solution that enables a testing system to execute the following standardized closed-loop testing process: acquiring test parameters and generating test cases; collecting baseline performance data of the target device before any attack is launched; sending attack traffic generated based on the test cases to the target device and collecting test performance data of the target device during the attack; determining protection strategy optimization parameters based on the test performance data; writing the protection strategy optimization parameters into the target device for secondary testing and collecting optimized performance data of the target device in the secondary test; and comparing the optimized performance data with the baseline performance data to verify the optimization effect. This achieves fully automated connection from attack testing to strategy optimization verification, improving the iteration efficiency and verification reliability of the protection strategy.

[0028] As can be seen from the above embodiments, this application, by adopting a standardized closed-loop testing process, automatically integrates the originally independent attack testing, performance analysis, strategy optimization, and effect verification stages into one, solving the technical problem in the prior art where the testing system and protection system are independent and lack standardized closed-loop testing methods. Compared with the prior art, which relies on manually writing scripts to execute a single attack and then manually analyzing data and adjusting strategies after the test, this application upgrades the testing process from a scattered, temporary operation to a standardized, automated closed-loop process. Testers no longer need to interrupt the process for manual analysis and deployment after the test; instead, the system automatically completes the entire process from data collection and analysis to strategy deployment and verification. This shortens the closed-loop cycle of testing, analysis, optimization, and verification, improves the iteration efficiency of protection strategies, and, through quantitative comparison of baseline data and optimized performance data, achieves objective verification of the optimization effect, ensuring the scientific nature and credibility of the test results.

[0029] 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 or testing system capable of performing the above functions. The following description uses a testing system as an example to illustrate this embodiment and the subsequent embodiments.

[0030] Based on this, embodiments of this application provide a method for testing the protocol flood attack function, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the test method for the flood attack function of this application protocol.

[0031] In this embodiment, the testing method for the protocol flood attack function includes steps S10 to S60: Step S10: Obtain test parameters and generate test cases based on the test parameters; It should be noted that test parameters refer to the configuration data set by the user before executing the test, used to control the generation method of attack traffic and the test execution process. Test parameters include, but are not limited to, packet sending rate, packet size, attack duration, source address generation strategy parameters, malformed data ratio, and attack mode. Test cases refer to structured test task description data generated based on the test parameters. They contain all the configuration information required for a single test execution and are used to drive the generation of attack traffic and control the test process.

[0032] Additionally, the step of obtaining test parameters and generating test cases based on the test parameters includes: receiving attack parameters and attack mode selections input by the user through a configuration interface or command-line interface; organizing and encapsulating the attack parameters and attack modes according to a preset data structure to generate a structured test case file containing parameter combination information; and storing the structured test case file in a storage medium for subsequent testing processes.

[0033] Understandably, in existing technologies, test parameters require testers to manually modify each item in scripts or command lines, making it impossible to achieve structured organization and reuse of parameters. This results in a cumbersome, error-prone, and difficult-to-trace test configuration process. Therefore, step S10 receives test parameters through a unified configuration entry point and automatically generates structured test cases. This avoids configuration errors and parameter omissions caused by manually modifying scripts, thereby improving the efficiency and accuracy of test configuration. At the same time, structured test cases facilitate storage, reuse, and traceability, providing a foundation for the reproducibility of test results.

[0034] Step S20: Collect baseline performance data of the target device; It should be noted that the target device refers to the object under test, which is the host or server targeted by an ICMP Flood attack. It can run any operating system and business services. Baseline performance data refers to performance metrics collected from the target device reflecting its normal operating status without any attack traffic being applied to it. Baseline performance data includes processor utilization, memory usage, network interface bandwidth utilization, echo response time, packet loss rate, and throughput. Baseline performance data serves as a benchmark for subsequent attack impact assessment and optimization effect verification.

[0035] In addition, before launching attack traffic, a monitoring connection is established with the target device through the performance monitoring function; according to the preset collection cycle, the performance indicators of the target device, such as processor utilization, memory usage, network interface bandwidth utilization, echo response time, packet loss rate and throughput, are continuously acquired; the collected performance indicator data is stored in the storage medium as baseline performance data.

[0036] Understandably, due to the lack of systematic data collection on the normal operating status of target devices in existing technologies, testers cannot quantitatively compare the performance during the attack with the normal state after the attack is completed. They can generally only judge whether the attack has caused an impact based on subjective experience. Therefore, step S20, which collects baseline performance data in advance before the attack is launched, can provide an objective quantitative reference benchmark for subsequent protection capability assessment and optimization effect verification, thereby improving the scientificity and credibility of the test conclusions.

[0037] Step S30: Send a traffic attack generated based on the test case to the target device, and collect the test performance data of the target device in the traffic attack; It should be noted that a traffic attack refers to ICMP flood traffic sent to a target device based on test cases and according to the configured attack parameters and attack modes. Traffic attacks include direct flood attacks, address spoofing attacks, and malformed packet attacks. Test performance data refers to performance metrics data reflecting the target device's operating status under attack conditions, collected in real time during the application of attack traffic. These metrics include processor utilization, memory usage, network interface bandwidth utilization, echo response time, packet loss rate, and throughput.

[0038] Additionally, based on the attack parameters and attack modes configured in the test cases, a mixed attack traffic consisting of standard echo request packets and malformed packets is constructed. Combined with source address randomization, the traffic is continuously sent to the target device according to the configured packet sending rate and attack duration. During the attack, test performance data of the target device is collected in real time.

[0039] Understandably, existing testing methods typically only construct a single type of standard echo request data packet, resulting in a limited range of simulated attack scenarios. This fails to cover various variant attack scenarios that may occur in real networks, such as address spoofing attacks and malformed packet attacks, and cannot simulate the combined use of multiple attack methods in a real attack within the same test process. Therefore, step S30, by simultaneously constructing standard and malformed data packets, combining source address randomization, and continuously sending packets according to the packet sending rate and duration configured in the test cases, can simulate various real attack scenarios, including direct flood attacks, address spoofing attacks, malformed packet attacks, and their combined attacks. This improves the coverage of test scenarios and the realism of test results. Furthermore, real-time collection of multi-dimensional performance indicators of the target device during the attack provides a comprehensive and objective data foundation for subsequent performance analysis and protection strategy optimization.

[0040] Step S40: Determine the protection strategy optimization parameters based on the test performance data; It should be noted that the protection strategy optimization parameters refer to a set of configuration parameters determined based on the analysis results of test performance data, used to adjust or enable the protection functions of the target device, with the aim of improving the target device's ability to resist attacks.

[0041] Furthermore, the test performance data is analyzed to pinpoint the performance inflection point where response time suddenly increases, obtain the attack traffic rate corresponding to this inflection point, calculate the traffic rate limiting threshold accordingly, and determine the optimization parameters of the protection strategy based on the analysis results. The specific implementation method for locating the performance inflection point can be found in Example 2.

[0042] Understandably, existing technologies cannot automatically determine protection thresholds based on collected test performance data after testing, nor can they recommend multiple types of protection strategies based on test data, resulting in a lack of systematic quantitative analysis methods for determining protection strategies. Therefore, step S40 analyzes the test performance data to locate performance inflection points, calculates traffic rate limiting thresholds based on the attack traffic rates corresponding to these inflection points, and determines whether to enable protection strategies such as Synchronous Sequence Number Verification (SYN Cookie) and Source Address Reverse Path Verification based on the analysis results. This enables automatic and accurate calculation of protection thresholds and intelligent recommendation of multiple protection strategies, achieving an optimal balance between protection effectiveness and business continuity.

[0043] Step S50: Write the protection strategy optimization parameters into the target device for secondary testing, and collect the optimization performance data of the target device in the secondary test; It should be noted that secondary testing refers to deploying the optimized protection strategy parameters to the target device and then launching attack traffic at the target device again to verify the actual protection effect of the optimized parameters. Optimized performance data refers to the performance index data of the target device collected during the secondary testing process, used to compare with baseline performance data to quantitatively evaluate the effectiveness of the optimized protection strategy parameters.

[0044] Additionally, the protection strategy optimization parameters determined in step S40 are automatically written into the target device using a remote communication protocol, which includes at least one of Secure Shell Protocol, Network Configuration Protocol, or Representational State Transmission Configuration Protocol. After successful writing, an ICMP Flood is automatically triggered again at the attack traffic rate corresponding to the performance inflection point. During the second attack, the optimized performance data of the target device is collected.

[0045] Understandably, in existing technologies, testing and protection systems typically operate independently. After testing, manual analysis of test data and manual adjustment of protection strategies are required. There is a lack of automatic coordination between the testing, analysis, optimization, and retesting stages, resulting in long closed-loop cycles and low iteration efficiency. Therefore, step S50 automatically writes optimization parameters into the target device via a remote communication protocol and automatically triggers a second attack based on the attack traffic rate corresponding to the performance inflection point, collecting optimized performance data. This achieves fully automated coordination from analysis to deployment to verification, significantly shortening the closed-loop cycle of testing, analysis, optimization, and verification, and improving the iteration efficiency of protection strategies.

[0046] Step S60: Compare the optimized performance data with the baseline performance data to verify the optimization effect.

[0047] It should be noted that the optimization effect refers to the degree of improvement in the performance of the target device under the same attack conditions after the deployment of optimized parameters of the protection strategy.

[0048] Additionally, baseline performance data is read from the storage medium; the optimized performance data is compared item by item with the baseline performance data, including comparing the packet loss rate changes before and after deploying the protection strategy optimization parameters; if the packet loss rate drops below a preset threshold, the optimization effect of the protection strategy optimization parameters is verified to be effective.

[0049] Understandably, due to the lack of a systematic mechanism for verifying the optimization effect in existing testing methods, testers can only manually execute the complete test again after adjusting the protection strategy and judge the effect based on experience, making it impossible to conduct standardized before-and-after comparisons and quantitative evaluations. Therefore, step S60, by quantitatively comparing the optimized performance data with the pre-collected baseline performance data, especially using packet loss rate as the core verification indicator, can objectively and accurately determine whether the protection strategy optimization has achieved the expected effect. This provides a clear data basis for deciding whether to accept the current optimization scheme or start the next round of optimization iterations, thereby realizing a complete closed loop of testing, analysis, optimization, and verification.

[0050] This embodiment achieves standardization of protocol flood attack function testing through a complete closed-loop testing process; First, test parameters are obtained and structured test cases are generated. Multiple test parameters, such as packet sending rate, packet size, source address generation strategy parameters, malformed data ratio, attack mode, and attack duration, are organized and encapsulated according to a preset data structure to form a standardized test configuration parameter template. This template defines the names, types, value ranges, and default values ​​of various test parameters, ensuring that testers use a consistent parameter configuration format when conducting tests at different times and on different devices, avoiding the inability to reuse test configurations due to inconsistent parameter naming or format differences.

[0051] Secondly, by standardizing the test execution process, the complete operational sequence and input-output relationships of each step, from test configuration, baseline collection, attack execution, performance monitoring, parameter determination, policy deployment to effect verification, are clearly defined. This test execution process does not depend on specific testing tools or specific network environments; testers only need to follow the process to execute each step sequentially to complete a standardized ICMP Flood functional test.

[0052] Finally, by storing test configuration information, test cases, baseline performance data, test performance data, optimized performance data, protection strategy optimization parameters, optimization effect verification results, and recovery process data completely in the storage medium, unified storage and management of test lifecycle data is achieved. Because all test inputs and outputs are fully recorded, highly consistent test results can be generated when the process is executed at different times, in different test environments, or by different testers under the same test configuration parameter template. When it is necessary to verify the validity of a test result or compare changes in protection capabilities at different points in time, historical test results stored in the storage medium can be directly retrieved and compared with the current test results for consistency analysis, thus ensuring the comparability and reproducibility of test results.

[0053] 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 the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step S40, determining the protection strategy optimization parameters based on the test performance data, includes steps S41-S43: Step S41: Analyze the test performance data to obtain analysis results, and locate the performance inflection point of sudden increase in response time based on the analysis results; It should be noted that the analysis results refer to the data processing results obtained after mathematically processing the test performance data, which can reflect the performance change trend and abrupt change characteristics of the target device. The performance inflection point refers to the critical point where, as the intensity of attack traffic gradually increases, the response time of the target device changes from a slow increase to a sudden and significant increase. This critical point marks the point at which the processing capacity of the target device begins to be unable to effectively cope with the current intensity of attack traffic.

[0054] Additionally, the response delay sequence of the target device is extracted from the test performance data. This response delay sequence is formed by arranging the echo response times corresponding to each acquisition time point in chronological order. Point-by-point difference calculations are performed on the response delay sequence to obtain the response delay difference between adjacent acquisition time points. A response delay difference sequence is generated based on these differences. The response delay difference sequence is traversed, and the acquisition time point corresponding to the first difference data point exceeding a preset difference threshold is determined as the performance inflection point. The preset difference threshold can be determined based on the statistical characteristic values ​​of the response time in the baseline performance data, for example, three times the standard deviation of the baseline response time.

[0055] Step S42: Obtain the attack traffic rate corresponding to the performance inflection point, and calculate the traffic rate limiting threshold based on the attack traffic rate. It should be noted that the attack traffic rate refers to the packet sending rate of attack traffic to the target device at the moment the performance inflection point occurs. The traffic rate limiting threshold is an upper limit configured on the target device or its front-end protection device to restrict the receiving rate of Internet Control Message Protocol echo request messages.

[0056] Additionally, based on the data collection time point corresponding to the performance inflection point, the packet sending rate corresponding to that time point is obtained from the test cases or attack execution records, and this rate is used as the attack traffic rate corresponding to the performance inflection point. Using this attack traffic rate as a benchmark, a preset security coefficient is multiplied to obtain the traffic rate limiting threshold. The security coefficient ranges from greater than 0 to less than or equal to 1, with a recommended range of 0.7 to 0.9. This value can be set according to the target device's service tolerance; a lower value indicates stricter protection. For example, when the attack traffic rate corresponding to the performance inflection point is 500 packets / second and the security coefficient is 0.8, the calculated traffic rate limiting threshold is 400 packets / second.

[0057] Step S43: Determine the optimization parameters of the protection strategy based on the analysis results.

[0058] It should be noted that the protection strategy optimization parameters include traffic rate limiting thresholds, synchronization sequence number verification enable commands, and source address reverse path verification configurations. The synchronization sequence number verification enable command is a configuration command used to activate the synchronization sequence number verification function on the target device. Once enabled, the target device will verify the validity of the synchronization sequence number for received connection requests. The source address reverse path verification configuration is a configuration parameter used to enable the source address reverse path verification function on the target device. Once enabled, the target device will perform a reverse path lookup on the source address of received packets to identify and discard attack packets with spoofed source addresses.

[0059] Furthermore, based on the sudden increase in the response delay difference sequence in the analysis results, the attack type is determined. If it is determined to be a malformed packet attack, the synchronization sequence number verification enable command is determined as one of the protection strategy optimization parameters; if it is determined to be an address spoofing attack, the source address reverse path verification configuration is determined as one of the protection strategy optimization parameters; the traffic rate limiting threshold is combined with the above-determined protection strategy optimization parameters to form the final set of protection strategy optimization parameters.

[0060] It is understandable that this embodiment analyzes test performance data to locate performance inflection points and calculates traffic rate limiting thresholds based on the attack traffic rates corresponding to these inflection points. Simultaneously, it intelligently recommends various protection strategies based on the analysis results, such as enabling synchronous sequence number verification commands or source address reverse path verification configurations. This solves the technical problems in existing technologies where protection thresholds cannot be automatically determined based on collected test performance data after testing, and where multiple types of protection strategies cannot be recommended based on test data. In particular, by extracting response latency sequences from test performance data and performing point-by-point differential calculations to locate performance inflection points, it solves the problem that existing technologies cannot accurately and automatically locate target device performance inflection points through differential calculations. This provides an objective basis for calculating protection thresholds, avoiding the problems of overly lenient threshold settings leading to ineffective protection or overly strict thresholds affecting normal business operations, thus achieving an optimal balance between protection effectiveness and business continuity.

[0061] Based on the first and second embodiments of this application, in this third embodiment, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S30, which involves sending a traffic attack generated based on the test case to the target device and collecting test performance data of the target device during the traffic attack, includes steps S31 to S33: Step S31: Based on the test cases, construct standard echo request data packets and malformed data packets; It should be noted that a standard echo request packet refers to an echo request packet conforming to the Internet Control Message Protocol (ICP) specification. Its type field value is 8, and its code field value is 0. It is used to initiate an echo request to the target device and is the basic data unit for simulating a direct flood attack. Malformed packets refer to packets that do not conform to standard protocol specifications or contain abnormal field values. Their purpose is to test the target device's ability to handle abnormal traffic, including at least one of fragmented packet overlay packets and time-to-live (TTL) aberration packets. Fragmented packet overlay packets are packets constructed by overlapping or colliding with each other during reassembly by the target device, causing abnormal processing by the target device. TTL aberration packets are packets with the TTL field in the header set to an abnormal value, meaning the packet should be discarded before reaching the target device. They are used to test whether the target device correctly filters TTL aberration packets.

[0062] Additionally, the packet size parameter, malformed data ratio parameter, and attack mode parameter are read from the test cases; according to the Internet Control Message Protocol specification, a packet header with the type field set to echo request is created, and preset content is filled into the packet data payload area according to the packet size parameter to generate a standard echo request packet of the specified size; when the attack mode parameter indicates that a malformed packet attack mode is included, at least one of the following construction operations is performed respectively: the same original packet is split into multiple fragment packets, the offset field of each fragment packet is set to have an overlapping range, and fragment overlay packets are generated; an echo request packet is created, and its time-to-live field is set to 1 or 0 to generate a time-to-live abnormal packet.

[0063] Step S32: Randomly generate a source address according to the source address generation strategy parameters, and send the standard echo request data packet and the malformed data packet to the target device; It should be noted that the source address generation strategy parameters are as described in step S10 of Example 1. Random source address generation refers to dynamically generating different source Internet Protocol addresses for each sent data packet according to the source address generation strategy parameters, in order to simulate the traffic characteristics from multiple different attack sources in a distributed denial-of-service attack.

[0064] Additionally, source address generation strategy parameters, packet sending rate parameters, and attack duration parameters are read from the test cases. When the source address generation strategy parameters indicate that source address randomization is enabled, a source address is randomly generated for each data packet to be sent according to a preset address generation rule. The preset address generation rule includes one of random selection within a specified address range, generation according to a specified mask, or completely random generation. The constructed standard echo request data packets and malformed data packets are replaced with randomly generated source addresses, respectively. The standard echo request data packets and malformed data packets are sent alternately according to the packet sending rate and the proportion of malformed data. The alternating sending operation is continuously executed during the attack duration.

[0065] Step S33: During the duration of the traffic attack, collect test performance data of the target device.

[0066] It should be noted that during the attack, through the monitoring connection established with the target device, the processor utilization, memory usage, network interface bandwidth utilization, echo response time, packet loss rate, and throughput of the target device are acquired in real time according to the preset collection cycle and stored in the storage medium as test performance data.

[0067] It is understandable that this embodiment, by simultaneously constructing standard echo request packets and malformed packets, combining source address randomization, and alternating transmission at the packet sending rate and duration configured in the test cases, solves the technical problem of existing testing methods that can only simulate a single attack scenario and cannot cover the mixed use of multiple attack variants such as malformed packet attacks and address spoofing attacks. Compared to the existing technology that can only construct standard echo request packets to simulate a single flood attack, this embodiment can simultaneously simulate multiple real-world attack scenarios such as direct flood attacks, malformed packet attacks, address spoofing attacks, and their mixed attacks. It covers diverse attack variants that may occur in real networks during the same testing process, thereby improving the coverage of test scenarios and the realism of test results.

[0068] For example, to help understand the function modules, connections, and implementation process of the flood attack function test method in this application, please refer to... Figure 4 , Figure 4 A simplified flowchart of a test method for protocol flood attack functionality is provided, specifically: Test Control Module: As the core control unit of the entire test system, it is responsible for the creation, management, scheduling, and monitoring of test tasks. The Test Control Module communicates with the Test Configuration Module, Attack Generation Module, Performance Monitoring Module, and Result Analysis Module, coordinating the collaborative work of these modules.

[0069] Test Configuration Module: Connects to the test control module, receiving user-inputted test parameter configuration information and generating test cases based on this information. The test configuration module provides a graphical user interface (GUI) or command-line interface (CLI), supporting user configuration of the following test parameters: Attack parameters: packet sending rate (packets / second), packet size (bytes), attack duration (seconds / minutes), total number of packets sent; Source IP policy: whether the source IP is randomly generated, the range of source IP addresses, and whether the source IP is forged; Target parameters: target IP address, target port; Message parameters: ICMP message type (Type 8 Echo Request, etc.), whether to construct a malformed message; Attack modes: direct flood attack mode, IP spoofing attack mode, malformed packet attack mode.

[0070] Attack Generation Module (Attack Machine): Connects to the test control module and sends ICMP Flood traffic to the target device based on the test cases generated by the test configuration module. The attack generation module internally includes: The packet construction submodule dynamically constructs ICMP packets according to configuration parameters. It supports the construction of standard ICMP EchoRequest packets as well as malformed ICMP packets (such as fragment overlay, TTL exception settings, etc.). Traffic sending submodule: Controls the sending rhythm of data packets according to the configured packet sending rate and duration, supporting high-concurrency traffic sending; Source IP Randomization Submodule: Supports randomizing source IP addresses to simulate distributed attack sources.

[0071] Performance monitoring module: Connects to the test control module and is used to collect real-time performance data of the target device during testing. The performance monitoring module establishes a monitoring connection with the target device, and the collected metrics include, but are not limited to: System resource metrics: CPU utilization, memory usage, and network interface bandwidth utilization; Network performance metrics: ICMP Echo Reply response time, packet loss rate, throughput; Application service metrics: response latency and availability status of business services on the target device.

[0072] Results Analysis Module: Connects the test control module and the performance monitoring module, and is used to analyze and process the collected performance indicator data to generate test reports. The results analysis module includes: The data analysis submodule cleans, statistically analyzes, and trends the raw data collected by the performance monitoring module, and calculates key indicator thresholds, inflection points, etc. The report generation submodule generates test reports in the form of charts and text, including attack strength-performance degradation curves, protection capability scores, system bottleneck locations, and other information. The strategy optimization suggestion submodule automatically generates protection strategy optimization suggestions based on the analysis results, such as suggesting adjusting the ICMP rate threshold, enabling synchronization sequence number verification, and configuring source IP reverse path verification.

[0073] Strategy Deployment Module: Connects the Result Analysis Module and the Target Protection Device. It is used to automatically or semi-automatically deploy the optimization suggestions generated by the Strategy Optimization Suggestion Submodule to the Target Protection Device, thereby achieving test-driven closed-loop optimization of the protection strategy.

[0074] Storage medium: Used to store test configuration information, test cases, performance monitoring data, test reports, and strategy optimization records, supporting the traceability and reproducibility of the testing process.

[0075] It should be noted that the target device, or the object under test, is the host or server targeted by an ICMP Flood attack. It can run any operating system and business services. The target protection device is optional, located in front of the target device or integrated with it, providing ICMP Flood protection (such as a firewall, anti-DDoS device, or intrusion prevention system). The policy deployment module of this invention is specifically optimized for this device.

[0076] It is understandable that the target device and the target protection device can be the same device. When the target device itself has protection capabilities, such as running a software firewall or having a built-in ICMP Flood protection module, the protection policy optimization parameters can be directly written into the target device itself. In this case, the target device serves as both the object under test and the carrier of the protection function. When the target device itself does not have protection capabilities, the target protection device is a hardware device or virtual device independent of the target device, deployed in front of the target device to filter and protect the traffic destined for the target device. The protection policy optimization parameters are then written into this target protection device.

[0077] Furthermore, in the testing environment of this invention, the test control module establishes a communication link with both the target device and the target protection device via a network connection. The performance monitoring module establishes a monitoring connection with the target device to collect baseline performance data, test performance data, optimized performance data, and recovery process data. The attack generation module establishes a test link with the target device to send attack traffic. The policy deployment module establishes a management connection with the target protection device to write protection policy optimization parameters into the target protection device. When the target device and the target protection device are the same device, the aforementioned test link and management connection point to the same physical device.

[0078] It is understood that this application does not restrict the physical form and deployment method of the target device and the target protection device. The testing methods provided in this application can be applied to physical machines, virtual machines, container instances, single-machine deployments or cluster deployments.

[0079] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the test method of the flood attack function of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0080] This application also provides a test device for protocol flood attack functionality; please refer to [reference needed]. Figure 5 The test device for the protocol flood attack function includes: Test case generation module 10 is used to obtain test parameters and generate test cases based on the test parameters. Performance monitoring module 20 is used to collect baseline performance data of the target device; The attack traffic generation module 30 is used to send a traffic attack generated based on the test case to the target device and collect the test performance data of the target device in the traffic attack. The strategy optimization analysis module 40 is used to determine the protection strategy optimization parameters based on the test performance data. The strategy deployment module 50 is used to write the protection strategy optimization parameters into the target device for secondary testing, and to collect the optimization performance data of the target device in the secondary test. The effect verification module 60 is used to compare the optimized performance data with the baseline performance data to verify the optimization effect.

[0081] The protocol flood attack testing device provided in this application, employing the protocol flood attack testing method described in the above embodiments, solves the technical problem in the prior art where testing and protection are independent, lacking a standardized closed-loop testing method that automatically connects attack testing, performance analysis, strategy optimization, and effect verification. Compared with the prior art, the beneficial effects of the protocol flood attack testing device provided in this application are the same as those of the protocol flood attack testing method provided in the above embodiments, and other technical features in the protocol flood attack testing device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0082] This application provides a test device for protocol flood attack functionality. The test device for protocol flood attack functionality 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 test method for protocol flood attack functionality in the above embodiment 1.

[0083] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a test device suitable for implementing the protocol flood attack function in the embodiments of this application. The test device for the protocol flood attack function in the embodiments of this application 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), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The test device shown for the protocol flood attack function is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0084] like Figure 6As shown, the test device for protocol flood attack functionality 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 read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the test device for protocol flood attack functionality. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the test equipment for protocol flooding attacks to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows test equipment with various systems for protocol flooding attacks, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0085] 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 ROM 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.

[0086] The protocol flood attack testing device provided in this application, employing the protocol flood attack testing method described in the above embodiments, solves the technical problem in the prior art where testing and protection are independent, lacking a standardized closed-loop testing method that automatically connects attack testing, performance analysis, strategy optimization, and effect verification. Compared with the prior art, the beneficial effects of the protocol flood attack testing device provided in this application are the same as those of the protocol flood attack testing method provided in the above embodiments, and other technical features in this protocol flood attack testing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0087] 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.

[0088] 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.

[0089] 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 test method for the protocol flood attack function in the above embodiments.

[0090] 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, 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, 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.

[0091] The aforementioned computer-readable storage medium may be included in the test equipment for the protocol flood attack function; or it may exist independently and not assembled into the test equipment for the protocol flood attack function.

[0092] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a test device for a protocol flood attack function, the test device for the protocol flood attack function causes the following: it acquires test parameters and generates test cases based on the test parameters; it collects baseline performance data of the target device; it sends a traffic attack generated based on the test cases to the target device and collects test performance data of the target device during the traffic attack; it determines protection strategy optimization parameters based on the test performance data; it writes the protection strategy optimization parameters into the target device for secondary testing and collects optimized performance data of the target device during the secondary test; and it compares the optimized performance data with the baseline performance data to verify the optimization effect.

[0093] 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).

[0094] 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.

[0095] 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.

[0096] 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 test method of the above-described protocol flood attack function. This solves the technical problem in the prior art where testing and protection are independent, and there is a lack of standardized closed-loop testing methods that automatically connect attack testing, performance analysis, strategy optimization, and effect verification. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the test method of the protocol flood attack function provided in the above embodiments, and will not be repeated here.

[0097] 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 of testing a protocol flood attack function, characterized by, The method includes: Obtain test parameters and generate test cases based on the test parameters; Collect baseline performance data of the target device; Send a traffic attack based on the test case to the target device, and collect test performance data of the target device in the traffic attack; Based on the test performance data, determine the optimization parameters for the protection strategy; The optimized parameters of the protection strategy are written into the target device for secondary testing, and the optimized performance data of the target device in the secondary test is collected. The optimized performance data is compared with the baseline performance data to verify the optimization effect.

2. The method of claim 1, wherein, The step of determining the protection strategy optimization parameters based on the test performance data includes: The test performance data was analyzed to obtain the analysis results; Based on the analysis results, pinpoint the performance inflection point where the response time suddenly increases; Obtain the attack traffic rate corresponding to the performance inflection point; Calculate the traffic rate limiting threshold based on the attack traffic rate; Based on the analysis results, the optimization parameters of the protection strategy are determined, wherein the optimization parameters of the protection strategy include the traffic rate limiting threshold, the synchronization sequence number verification enable command, and the source address reverse path verification configuration.

3. The method of claim 2, wherein, The process of locating the performance inflection point of sudden increase in response time based on the analysis results includes: The response delay sequence of the target device is extracted from the analysis results. The response delay sequence is composed of the response times corresponding to each acquisition time point arranged in chronological order. Perform point-by-point difference calculation on the response delay sequence to obtain the response delay difference between adjacent acquisition time points; Generate a response delay difference sequence based on the response delay difference; Traverse the response delay difference sequence and determine the collection time point corresponding to the first difference data point that exceeds the preset difference threshold as the performance inflection point.

4. The method of claim 1, wherein, Sending a traffic attack based on the test case to the target device includes: Based on the test cases, construct standard echo request data; Based on the test cases, construct malformed data, wherein the malformed data includes generating fragmented and superimposed packets and setting abnormal time-to-live packets; The source address is randomly generated based on the source address generation strategy parameters; The standard echo request data, the malformed data, and the randomly generated source address are sent to the target device.

5. The method of claim 1, wherein, The collection of test performance data of the target device during the DDoS attack includes: Based on the test performance data, generate a curve showing the relationship between attack strength and device performance; A test report is generated based on the relationship curve. The test report includes a protection capability score and performance bottleneck location information. The test report is used as the basis for generating the optimization parameters of the protection strategy.

6. The method of claim 1, wherein, The step of obtaining test parameters and generating test cases based on the test parameters includes: Obtain attack parameters, including packet sending rate, data packet size, source address range, malformed data ratio, and attack duration; The attack patterns are obtained, including direct flood attack pattern, address spoofing attack pattern, and malformed packet attack pattern; Based on the attack parameters and the attack pattern, structured test cases are generated.

7. The method of claim 1, wherein, After the DDoS attack ends, continue collecting data on the recovery process of the target device; Based on the baseline performance data, the test performance data, the optimized performance data, and the recovery process data, a lifecycle performance change curve for the target device is generated; Based on the lifecycle performance change curve, determine the performance change trend of the target device before, during, and after the attack, and evaluate the recovery capability of the target device from the attack state to the normal state.

8. A test apparatus for a protocol flood attack function, characterized by, The device includes: The test case generation module is used to obtain test parameters and generate test cases based on the test parameters. The performance monitoring module is used to collect baseline performance data of the target device; An attack traffic generation module is used to send a traffic attack generated based on the test case to the target device and collect test performance data of the target device in the traffic attack. The strategy optimization analysis module is used to determine the optimization parameters of the protection strategy based on the test performance data. The strategy deployment module is used to write the protection strategy optimization parameters into the target device for secondary testing, and to collect the optimization performance data of the target device in the secondary test; The effect verification module is used to compare the optimized performance data with the baseline performance data to verify the optimization effect.

9. A test device for protocol flood attack functionality, 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 a test method for the protocol flood attack functionality as described in any one of claims 1 to 7.

10. 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 test method for the protocol flood attack function as described in any one of claims 1 to 7.

Images