A server-side DDoS attack defense method and system for IoT devices

Abstract

The present invention relates to the field of DDoS attack defense technology, specifically to a server-side DDoS attack defense method and system for an Internet of Things device, comprising the following steps: real-time monitoring of the Internet of Things device, using a timing trigger mechanism, periodically sending a heartbeat request from the device to the server, recording the response time of each request, and storing it locally on the device to obtain a response time record. In the present invention, by real-time monitoring of the communication status of the Internet of Things device, the communication stability between the device and the server is improved, and by automatically identifying continuous response timeouts or failures, the potential attack risk is effectively warned, and the server switching action is triggered in time. Combined with the automatic switching mechanism of the preset backup address, the server address can be seamlessly switched when an attack occurs, reducing the risk of business interruption, and using a baseline behavior comparison method, by analyzing the signals and feedback between devices, abnormal behavior can be quickly identified, and the response speed and accuracy to potential attack patterns are enhanced.

Description

Technical Field

[0001] The present invention relates to the technical field of DDoS attack defense, and in particular to a server-side DDoS attack defense method and system for an Internet of Things device. Background Art

[0002] The DDoS attack defense technology field focuses on developing and implementing strategies to protect networks and servers from distributed denial of service (DDoS) attacks. DDoS attacks work by leveraging multiple network-connected devices (usually botnets controlled by hackers) to launch a large number of requests with the intention of overloading network services, servers, or infrastructure, making them inaccessible to legitimate users. Technology to defend against such attacks is critical, especially in the context of the rapid growth of Internet of Things (IoT) devices, which are often vulnerable to exploitation due to weak security measures.

[0003] Among them, the server-side DDoS attack defense method for IoT devices refers to a set of technical measures and methods designed specifically to protect servers or services for IoT devices. The main purpose is to ensure that IoT devices can operate stably and securely and prevent DDoS attacks from affecting the communication between IoT devices and servers. By implementing defense measures, the goal is to reduce the risk of service interruptions, protect data security, and ensure that users can continuously access IoT services, thereby supporting the reliability and trust of the IoT ecosystem.

[0004] Existing technologies have great limitations in DDoS defense of IoT devices, especially in the detection and response in the early stage of the attack, which makes it difficult to respond quickly after the attack spreads. Traditional technologies usually rely on centralized network protection systems, and rarely consider automatic anomaly detection and autonomous response capabilities at the device level. In the face of a large number of IoT devices and their wide distribution, it is difficult to ensure that the device can switch to the server in time when an attack occurs. Existing technologies often lack a flexible backup address switching mechanism, resulting in a long communication interruption time for the device after an attack, and the inability to recover quickly. In the analysis of communication data, the existing methods are limited to basic data packet filtering and frequency control for device behavior monitoring, and fail to deeply explore the behavioral differences between devices. Therefore, it is easy to make misjudgments or missed judgments when facing abnormal communications. In addition, policy adjustments usually rely on manual intervention, which makes it difficult to respond in real time, resulting in the inability of defense capabilities to quickly adapt to changes in attack patterns. Summary of the invention

[0005] The purpose of the present invention is to solve the shortcomings of the prior art and to propose a server-side DDoS attack defense method and system for an Internet of Things device.

[0006] In order to achieve the above object, the present invention adopts the following technical solution: a server-side DDoS attack defense method for an IoT device, comprising the following steps:

[0007] S1: Real-time monitoring of IoT devices. Using a timed trigger mechanism, periodically sending heartbeat requests from the device to the server, recording the response time of each request, and storing it locally on the device to obtain a response time record;

[0008] S2: Perform data anomaly detection through the response time record. If it is found that the response time exceeds the threshold or the heartbeat request fails for three consecutive times, the server status is marked as abnormal locally and an unstable mark record is generated;

[0009] S3: triggering a server switching mechanism according to the unstable mark record, automatically selecting the next available address from a preset backup server list, updating the server configuration of the device, re-establishing the data connection, and obtaining the server switching record;

[0010] S4: According to the server switching record, collect the communication data between IoT devices, analyze the signals sent by the devices and the received feedback one by one, compare the data with the pre-defined communication behavior baseline, identify abnormal behaviors through difference analysis, and generate behavior deviation analysis results;

[0011] S5: Based on the behavior deviation analysis results, monitor the real-time response of IoT devices, quickly locate and respond to abnormal behaviors, set warning thresholds to determine whether to trigger security alarms, execute defense measures, and form real-time defense action records;

[0012] S6: Based on the real-time defense action record, dynamically adjust and optimize the defense strategy in the cloud, continuously monitor the execution of all defense measures, record the strategy adjustment history data, and output the strategy optimization update record.

[0013] As a further solution of the present invention, the response time record includes a request timestamp record, a server response time record and a response delay record, the unstable mark record includes the number of consecutive failures, the abnormal response time and the abnormal time point, the server switching record includes the backup server address, the switching time and the connection status record, the behavior deviation analysis result includes the deviation type, the deviation degree analysis result and the associated device, the real-time defense action record includes the triggered defense measures, the execution time and the target IP, and the policy optimization update record includes the update measures, the implementation date and the evaluation results.

[0014] As a further solution of the present invention, the IoT device is monitored in real time, a timing trigger mechanism is adopted, a heartbeat request is periodically sent from the device to the server, the response time of each request is recorded, and the response time is stored locally on the device. The specific steps of obtaining the response time record are:

[0015] S101: Setting a timing trigger mechanism, sending a heartbeat request to the server using a network protocol at a fixed time interval, receiving and recording the server's response time to the heartbeat request, using a timestamp to record the actual time when each operation occurs, and generating a heartbeat response record;

[0016] S102: Based on the heartbeat response record, the recorded data is sorted, statistical analysis is performed to determine the time average value, maximum value and minimum value, and the data is stored in a structured data format to generate a response time analysis result;

[0017] S103: Based on the response time analysis result, modify the sending frequency of the heartbeat request by setting parameters, adjust and determine the optimal communication interval between the device and the server, reset the trigger frequency of the timer, and generate a response time record.

[0018] As a further solution of the present invention, data anomaly detection is performed through the response time record. If it is found that the response time exceeds the threshold or the heartbeat request fails for three consecutive times, the server status is marked as abnormal locally. The specific steps of generating an unstable mark record are:

[0019] S201: Perform time series data analysis based on the response time record to detect whether the response time of three consecutive data points exceeds a preset threshold, and check whether the heartbeat request fails, confirm whether the abnormal condition is met, and generate an abnormal detection result;

[0020] S202: Based on the anomaly detection result, record each detected abnormal event, including the actual time when the abnormality occurred and the corresponding response time, summarize the data, and generate a statistical record of the abnormal event;

[0021] S203: Using the abnormal event statistical record, locally mark the server status, and generate an unstable marking record for the timestamp of each marking record event and the associated response time data.

[0022] As a further solution of the present invention, according to the unstable mark record, the server switching mechanism is triggered, the next available address is automatically selected from the preset backup server list, the server configuration of the device is updated, and the data connection is re-established. The specific steps of obtaining the server switching record are:

[0023] S301: Based on the unstable mark record, a connectivity check is performed on the backup server list, the availability of each server address is tested one by one, the response time and connectivity status are verified through a network command, the first available server address with connectivity confirmation is selected, and a backup server selection record is generated;

[0024] S302: using the candidate server selection record, updating the network configuration of the device, opening the network configuration file, replacing the old server address with the newly selected address, saving and closing the configuration file, and generating a configuration update record;

[0025] S303: According to the configuration update record, initialize the data connection with the new server, send an initial heartbeat packet to detect the connection stability, record the time of connection establishment and the initial response result, and generate a server switching record.

[0026] As a further solution of the present invention, according to the server switching record, the communication data between the IoT devices is collected, the signals sent by the devices and the received feedback are analyzed one by one, the data is compared with the predefined communication behavior baseline, and the abnormal behavior is identified through difference analysis. The specific steps of generating the behavior deviation analysis result are as follows:

[0027] S401: Based on the server switching record, the communication data between IoT devices is captured, including the timestamp and data packet size of signal sending and feedback receiving, and the device ID and time are recorded for each data point to generate a communication data set record;

[0028] S402: Using the communication data set record, comparing with the predefined communication behavior baseline, calculating the deviation value of each data piece from the baseline one by one, marking the data whose deviation exceeds the set threshold, recording each marked data point and the corresponding deviation value, and generating a deviation marking record;

[0029] S403: Analyze the marked data points according to the deviation mark records, identify and record abnormal behaviors, including continuous data deviations or single large deviations, and generate behavior deviation analysis results.

[0030] As a further solution of the present invention, the deviation value of each piece of data from the baseline is calculated according to the formula:

[0031] ;

[0032] Calculate, where represents the deviation normalized value, Represents the behavior value of a single communication data record, represents the average communication behavior value in the predefined baseline, represents the standard deviation of communication behavior in a predefined baseline, Represents the total number of data points, represents the median absolute deviation, and is the weight coefficient, Used to balance the effect of sample size on standard deviation, Used to adjust the effect of the median absolute deviation in the calculation of the total deviation value.

[0033] As a further solution of the present invention, based on the behavior deviation analysis results, the real-time response of the IoT device is monitored, the abnormal behavior is quickly located and responded to, the warning threshold is set to determine whether a security alarm is triggered, and defense measures are executed to form a real-time defense action record. The specific steps are:

[0034] S501: Based on the behavior deviation analysis result, the IoT device is monitored and data is collected in real time, each piece of data is analyzed to check whether there is a behavior deviation, the deviation data is compared with the set warning threshold, whether an alarm is triggered, and an abnormal behavior monitoring record is generated;

[0035] S502: using the abnormal behavior monitoring record, when any data point exceeds the warning threshold, immediately triggering a security alarm, recording the alarm triggering time and the triggering device identifier, automatically starting a predetermined security measure, and generating a security alarm triggering record;

[0036] S503: According to the security alarm trigger record, record the defense measures taken after each alarm, including the type of measures and implementation time, and conduct a preliminary effect evaluation to generate a real-time defense action record.

[0037] As a further solution of the present invention, according to the real-time defense action record, the defense strategy is dynamically adjusted and optimized in the cloud, the execution of all defense measures is continuously monitored, the strategy adjustment history data is recorded, and the specific steps of outputting the strategy optimization update record are as follows:

[0038] S601: Based on the real-time defense action record, connect to the cloud server, upload the defense execution content of the device, filter and analyze the uploaded data, identify events of response time delay or defense failure, extract key performance indicators, and generate a defense performance analysis record;

[0039] S602: Using the defense performance analysis record, adjust the defense strategy parameters of the cloud, modify the trigger threshold and response protocol of the defense measures, optimize all modification operations according to the performance data, record the details of each strategy adjustment, and generate a strategy adjustment detail record;

[0040] S603: According to the strategy adjustment detail record, implement the new defense strategy, monitor the actual operation effect of the adjusted strategy, compare the defense effectiveness before and after the adjustment, record each key step and result evaluation in the optimization process, and generate a strategy optimization update record.

[0041] A server-side DDoS attack defense system for an IoT device, comprising:

[0042] The timing heartbeat detection module sets a timing trigger mechanism, sends a heartbeat request to the server at a fixed time interval, receives and records the server's response time to the heartbeat request, performs statistical analysis and stores it, adjusts and determines the optimal communication interval between the device and the server, resets the timer's trigger frequency, and generates a response time record;

[0043] The abnormal monitoring and analysis module performs time series data analysis through the response time records, confirms whether the abnormal conditions are met, records each detected abnormal event, performs local marking of the server status, and generates unstable marking records;

[0044] The standby server detection module performs a connectivity check on the standby server list based on the unstable mark record, tests the availability of each server address, verifies the response time and connectivity status, updates the network configuration of the device, and generates a configuration update record;

[0045] The connection stability test module updates the record according to the configuration, initializes the data connection with the new server, sends the initial heartbeat packet to detect the connection stability, captures the communication data between the IoT devices, and generates the communication data set record;

[0046] The behavior deviation analysis module calculates the deviation value of each data from the baseline based on the communication data set records and the predefined communication behavior baseline, marks the data whose deviation exceeds the set threshold, identifies and records abnormal behaviors, and generates behavior deviation analysis results;

[0047] The real-time defense trigger module analyzes each piece of data based on the behavior deviation analysis results to check whether there is a behavior deviation. When any data point exceeds the warning threshold, a security alarm is immediately triggered, and the defense measures taken after each alarm are recorded to generate a real-time defense action record.

[0048] Based on the real-time defense action records, the strategy optimization and update module connects to the cloud server, identifies events of response time delay or defense failure, extracts key performance indicators, modifies the trigger threshold and response protocol of the defense measures, monitors the actual operation effect of the adjusted strategy, and generates strategy optimization and update records.

[0049] Compared with the prior art, the advantages and positive effects of the present invention are:

[0050] In the present invention, by real-time monitoring of the communication status of IoT devices, the communication stability between the device and the server is improved, and by automatically identifying continuous response timeouts or failures, the potential attack risk is effectively warned, and the server switching action is triggered in time. Combined with the automatic switching mechanism of the preset backup address, the server address can be seamlessly switched when an attack occurs, reducing the risk of business interruption. A baseline behavior comparison method is adopted to quickly identify abnormal behaviors by analyzing the signals and feedback between devices one by one, and enhance the response speed and accuracy to potential attack modes. Based on the real-time response warning threshold judgment mechanism, defensive measures are quickly taken and the attack source is identified and responded to, effectively limiting the spread of the attack. Through the dynamic adjustment and optimization of the cloud defense strategy, the continuous improvement of the system defense capability is achieved, ensuring the long-term security protection of the device in a complex network environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 It is a schematic diagram of the steps of the present invention;

[0052] Figure 2 is a flow chart of the steps of S1 of the present invention;

[0053] Figure 3 is a flow chart of the steps of S2 of the present invention;

[0054] Figure 4 is a flow chart of the steps of S3 of the present invention;

[0055] Figure 5 is a flow chart of the steps of S4 of the present invention;

[0056] Figure 6 is a flow chart of the steps of S5 of the present invention;

[0057] Figure 7 is a flow chart of the steps of S6 of the present invention;

[0058] Figure 8 It is a system module diagram of the present invention. DETAILED DESCRIPTION

[0059] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0060] In the description of the present invention, it should be understood that the terms "length", "width", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside" and the like indicate positions or positional relationships based on the positions or positional relationships shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, in the description of the present invention, "multiple" means two or more, unless otherwise clearly and specifically defined.

[0061] See also Figure 1 , a server-side DDoS attack defense method for an IoT device, comprising the following steps:

[0062] S1: Real-time monitoring of IoT devices. Using a timed trigger mechanism, periodically sending heartbeat requests from the device to the server, recording the response time of each request, and storing it locally on the device to obtain a response time record;

[0063] S2: Data anomaly detection is performed through response time records. If the response time exceeds the threshold or the heartbeat request fails for three consecutive times, the server status is marked as abnormal locally and an unstable mark record is generated;

[0064] S3: According to the unstable mark record, the server switching mechanism is triggered, the next available address is automatically selected from the preset backup server list, the server configuration of the device is updated, and the data connection is re-established to obtain the server switching record;

[0065] S4: Collect communication data between IoT devices based on the server switching records, analyze the signals sent by the devices and the received feedback one by one, compare the data with the pre-defined communication behavior baseline, identify abnormal behaviors through difference analysis, and generate behavior deviation analysis results;

[0066] S5: Based on the results of behavioral deviation analysis, monitor the real-time response of IoT devices, quickly locate and respond to abnormal behaviors, set warning thresholds to determine whether to trigger security alarms, execute defense measures, and form real-time defense action records;

[0067] S6: Based on the real-time defense action records, dynamically adjust and optimize the defense strategy in the cloud, continuously monitor the execution of all defense measures, record the historical data of strategy adjustment, and output the strategy optimization update record.

[0068] Response time records include request timestamp records, server response time records and response delay records. Instability mark records include the number of consecutive failures, abnormal response time and abnormal time point. Server switching records include backup server address, switching time and connection status records. Behavioral deviation analysis results include deviation type, deviation degree analysis results and associated devices. Real-time defense action records include triggered defense measures, execution time and target IP. Policy optimization update records include update measures, implementation date and evaluation results.

[0069] See also Figure 2 , the specific steps of S1 are:

[0070] S101: Setting a timing trigger mechanism, sending a heartbeat request to the server using a network protocol at a fixed time interval, receiving and recording the server's response time to the heartbeat request, using a timestamp to record the actual time when each operation occurs, and generating a heartbeat response record;

[0071] Fixed time interval Send heartbeat requests and record the response time of each heartbeat request and timestamp , using the formula Calculating average response time In the formula, Represents the time interval for sending heartbeat requests. Representative The response time of each heartbeat, Representative The actual time when the operation occurred. Represents the total number of heartbeat requests. The device must Send a network request at any time and record the return time. If the time interval is set to 1 minute and the observation is 30 minutes, then , each The specific value can be obtained from the system log or network monitoring tool. For example, if the response time of 30 requests is 100ms, 120ms, 98ms, ..., 110ms respectively, the specific calculation process is as follows:

[0072] ;

[0073] The results show that the average response time in a given monitoring period is 106 milliseconds, which helps to understand the average performance of the server in a fixed time interval.

[0074] S102: Based on the heartbeat response record, the recorded data is sorted, statistical analysis is performed to determine the time average value, maximum value and minimum value, and the data is stored in a structured data format to generate a response time analysis result;

[0075] Based on the heartbeat response record, statistical analysis determines the average time , the maximum value , and the minimum , using the formula Calculate the time average. In the formula, Representative The actual timestamp of the operation. Represents the total number of operations. Through this calculation, we can understand the average time point of request sending during the entire test cycle. Assume that a request is sent once a minute in an hour, and a total of 60 requests are sent. The timestamp of each request starts from 9:00:00 and ends at 10:00:00. The converted UNIX timestamps are , , and so on, the last .

[0076] The process of calculating the time average is as follows:

[0077] ;

[0078] The UNIX timestamp 1617707430 converts to human-readable time as 9:30:30, indicating that the average timestamp falls in the middle of the entire monitoring period. This helps verify that the heartbeat mechanism is evenly distributed.

[0079] S103: Based on the response time analysis result, modify the sending frequency of the heartbeat request by setting parameters, adjust and determine the optimal communication interval between the device and the server, reset the trigger frequency of the timer, and generate a response time record;

[0080] Based on the response time analysis results, adjust the frequency of sending heartbeat requests by setting parameters , using the formula Calculate the new sending frequency. In the formula, represents the optimal communication period of the target, Represents the average response time calculated in the previous step to ensure that the heartbeat request cycle adapts to the response speed of the server. Set to 2 minutes (120 seconds), combined with the average response time obtained above is 106 milliseconds (0.106 seconds), the specific calculation process is as follows:

[0081] ;

[0082] The calculation results show that the frequency of sending heartbeat requests should be adjusted to approximately once every 120 seconds, slightly faster than once every two minutes, to compensate for the impact of response time. This helps ensure that communication with the server is carried out within the optimal time interval, thereby maintaining the stability and responsiveness of the network connection. The results show that the adjusted heartbeat frequency can better adapt to the processing capacity of the server, ensuring the timeliness and effectiveness of data communication.

[0083] See also Figure 3 , the specific steps of S2 are:

[0084] S201: Perform time series data analysis through response time records to detect whether the response time of three consecutive data points exceeds a preset threshold, and at the same time check whether the heartbeat request fails, confirm whether the abnormal condition is met, and generate an abnormal detection result;

[0085] By recording the response time, the response time of three consecutive data points is compared one by one. First, the response time data of each heartbeat request is compared. Read and analyze whether these three points exceed the preset threshold continuously The threshold is set based on the average response time of the previous cycle increased by 10% to cope with sudden fluctuations, and a comparison operation is performed on each data point ,The continuity check verifies whether the three conditions are met at the same time. If all three conditions are true, this series of points is marked as abnormal. In addition, it also checks whether the heartbeat request fails. This check is performed through the return status code of the network protocol. If the status code is not in the 200 series, it is considered a failure. These failure events and the corresponding timestamps are recorded to generate anomaly detection results.

[0086] S202: Based on the anomaly detection results, record each detected abnormal event, including the actual time when the abnormality occurred and the corresponding response time, summarize the data, and generate a statistical record of the abnormal event;

[0087] Based on the anomaly detection results, each time an abnormal event is detected, the system first records the exact time when the event occurred and the corresponding response time. Collecting data involves extracting timestamps from the anomaly detection log. and response time ,Data is organized ,involving data classification and labeling. Each abnormal event is regarded as a data point, including time and response time. All records are classified and counted. The total number of events and their time distribution are calculated. Data summary processing includes calculating the frequency distribution of abnormal events and the statistical summary of response time, such as the average response time and the variability of response time. The statistical records generated indicate the frequency and severity of the abnormalities, and generate abnormal event statistical records.

[0088] S203: Using the abnormal event statistics record, locally mark the server status, and generate an unstable mark record for the timestamp of each mark record event and the associated response time data;

[0089] Using the abnormal event statistics record, the server status is locally marked. The process involves identifying specific instances of response time anomalies and recording their timestamps. and associated response time data ,The data is extracted from the abnormal event statistical records.,The marking action is implemented by comparing and analyzing these data with the historical normal response time.,For each marking, the timestamp and response time data of the event are recorded and saved locally for future analysis and backtracking.,This marking record provides a data basis for system administrators and automatic monitoring tools to further analyze the stability and reliability of the server status and generate unstable marking records.

[0090] See also Figure 4 , the specific steps of S3 are:

[0091] S301: Based on the unstable mark record, a connectivity check is performed on the backup server list, the availability of each server address is tested one by one, the response time and connectivity status are verified through network commands, the first available server address with connectivity confirmation is selected, and a backup server selection record is generated;

[0092] Based on the unstable mark record, the system starts to check the connectivity of each server in the backup server list. First, the address of each backup server is obtained from the record, and then the response time and connectivity status of each server address are tested through network commands such as PING or HTTP requests. The response time of each server is recorded as , and check whether the response time meets the preset maximum response time For each test, the system records the server address, response time and connectivity status. If the server response time exceeds , the server is considered to be currently unavailable, and the test process continues until the first server address is found whose connectivity and response time are confirmed to meet the requirements. This address is selected as the alternative server and an alternative server selection record is generated.

[0093] S302: Use the candidate server selection record to update the network configuration of the device, open the network configuration file, replace the old server address with the newly selected address, save and close the configuration file, and generate a configuration update record;

[0094] Using the alternative server selection record, the system administrator starts to update the network configuration of the device. First, the network configuration file is opened, which contains multiple server addresses and related settings. The newly selected server address is extracted from the alternative server selection record, and this address is replaced with the old server address in the configuration file to ensure that the new server address is entered correctly. The replacement process includes searching for the old address string and overwriting it with the new address string. Once the replacement is completed, the changes are saved and the configuration file is closed. During the operation, the integrity and correctness of the file data are ensured to avoid file damage or format errors, and finally a configuration update record is generated.

[0095] S303: Initialize the data connection with the new server according to the configuration update record, send an initial heartbeat packet to detect the connection stability, record the time of connection establishment and the initial response result, and generate a server switching record;

[0096] According to the configuration update record, the system initializes the data connection with the new server and detects the stability of the connection by sending the initial heartbeat packet. First, the system configuration must be updated to the latest server address, and then the heartbeat packet is sent using the network protocol, and the sending time is recorded. And the initial response result of the server, the response result includes the response time The connection status is confirmed by the status code returned by the server. If the status code indicates success (such as HTTP 200), it is recorded as a successful connection. These records are used to evaluate the response efficiency and reliability of the new server and generate server switching records.

[0097] See also Figure 5 , the specific steps of S4 are:

[0098] S401: Based on the server switching record, the communication data between IoT devices is captured, including the timestamp and data packet size of signal sending and feedback receiving, and the device ID and time are recorded for each data point to generate a communication data set record;

[0099] Based on the server switching record, the system starts to capture the communication data between IoT devices. First, each data point includes the timestamp of signal sending and feedback receiving. Record and record the size of each data packet These data points include both the device ID and the specific time. The recording process of each data point involves capturing data packets from the network transport layer and parsing out relevant information. The network protocol analysis tool (Wireshark) is used in the parsing process. After each data packet is parsed, the relevant information is stored in the data set. This data set is further sorted by time and classified by device to generate a communication data set record for subsequent communication performance and stability analysis.

[0100] S402: Using the communication data set record, comparing with the predefined communication behavior baseline, calculating the deviation value of each data piece from the baseline one by one, marking the data whose deviation exceeds the set threshold, recording each marked data point and the corresponding deviation value, and generating a deviation marking record;

[0101] The deviation value of each data from the baseline is calculated according to the formula:

[0102] ;

[0103] Calculate, where represents the deviation normalized value, Represents the behavior value of a single communication data record, Represents the average communication behavior value in the predefined baseline, indicating the average behavior level of all data points. Represents the standard deviation of communication behavior in a predefined baseline, indicating the fluctuation range of the behavior of all data points. Represents the total number of data points and is used to adjust the calculation of the standard deviation to reflect the effect of the data sample size. Represents the median absolute deviation and is used to provide a robustness measure that complements the standard deviation and reduces the impact of outliers. and are weight coefficients, where It is used to balance the effect of sample size on standard deviation so that the formula can maintain consistency in calculation when the number of data points is different. Used to adjust the effect of the median absolute deviation in the calculation of the total deviation value to increase sensitivity to abnormal behavior.

[0104] Collect a communication data record set and obtain various values ​​through real-time monitoring.

[0105] The actual communication data value set It is 45.2, the latest data point obtained by direct monitoring from the communication server.

[0106] Predefined communication behavior baseline average , calculated using data from the past 30 days, with a value of 42.3.

[0107] Standard Deviation Calculated from the same data set, the value is 3.5, which represents the fluctuation of communication behavior in the past 30 days.

[0108] The median absolute deviation (MAD) is calculated as the average absolute deviation of the data points in the same period from the median and is 1.2.

[0109] Total number of data points The value is 1000, indicating the total number of communication records involved in the calculation.

[0110] Weight coefficient Set to 0.5 to adjust for the effect of sample size, ensuring that the standard deviation remains reasonably adjusted when the number of data points varies widely.

[0111] Weight coefficient It is set to 0.3 to increase sensitivity to abnormal behavior, ensuring that the analysis focuses more on data points that are significantly different from typical behavior.

[0112] Substitute specific values ​​for calculation:

[0113] ;

[0114] calculate Get the deviation value:

[0115] ;

[0116] Calculate the standard deviation adjustment in the denominator:

[0117] ;

[0118] Calculate the adjustment for MAD:

[0119] ;

[0120] The overall denominator is calculated as:

[0121] ;

[0122] Substituting the values ​​into the formula:

[0123] ;

[0124] The results show that the normalized value of the deviation of the observed data point from the predefined baseline is 0.748, reflecting the degree of deviation of the data point from the expected behavior. The threshold is set to 1.5 (0.748 < 1.5), indicating that although the data point shows a certain degree of deviation, it has not yet reached the level to be marked as abnormal. This numerical result is further used in the communication monitoring system to determine whether the data point is abnormal, and to make further data processing or early warning based on this.

[0125] S403: Analyze the marked data points according to the deviation mark records, identify and record abnormal behaviors, including continuous data deviations or single large deviations, and generate behavior deviation analysis results;

[0126] Based on the deviation mark record, the system analyzes the marked data points. First, it identifies specific abnormal behaviors, including continuous data deviations or single large deviations. The specific analysis method involves statistical analysis of the deviation values ​​of three or more consecutive data points in the deviation mark record. If the deviation of consecutive data points exceeds a preset critical threshold, , it is considered as a continuous anomaly. For a single large deviation, the system checks whether the deviation of any single data point exceeds the critical threshold. These inspection processes are completed using automated scripts. Finally, the identified abnormal behaviors are recorded and behavioral deviation analysis results are generated, which provide a basis for adjusting network configuration and improving data transmission strategies.

[0127] See also Figure 6 , the specific steps of S5 are:

[0128] S501: Based on the behavior deviation analysis results, the IoT devices are monitored and data collected in real time, each piece of data is analyzed to check whether there is a behavior deviation, the deviation data is compared with the set warning threshold, and whether an alarm is triggered, and an abnormal behavior monitoring record is generated;

[0129] Based on the results of behavioral deviation analysis, the system conducts real-time monitoring and data collection of IoT devices. First, the system regularly receives data from each device and analyzes each piece of data to check whether there is any behavioral deviation. This check includes the timestamp of the data point. and packet size Compare with historical records and calculate deviations , and compare this deviation with the set warning threshold Compare, if Exceed , the system records the data point as an anomaly. For each data point marked as an anomaly, the system records its device ID and timestamp. The data processing involved in this process uses real-time data stream analysis technology to ensure the real-time and accuracy of monitoring, and finally generates abnormal behavior monitoring records. These records provide necessary information for subsequent security analysis and response measures.

[0130] S502: Using abnormal behavior monitoring records, when any data point exceeds the warning threshold, a security alarm is immediately triggered, the alarm triggering time and the triggering device identifier are recorded, predetermined security measures are automatically initiated, and a security alarm triggering record is generated;

[0131] Using abnormal behavior monitoring records, when any data point exceeds the warning threshold, the system immediately triggers a security alarm. During the process, the system checks the deviation value of each received data point. If the deviation value exceeds the warning threshold, the system will immediately trigger a security alarm. Exceeding the threshold , the system automatically records the time when the event occurred and the trigger device identifier At the same time, the system automatically initiates the predetermined security measures related to the alarm, such as disconnecting the device from the network or sending an alarm to the management console. This automated processing ensures a quick response to potential security threats. After completing these operations, a security alarm trigger record is generated, which details the triggering details of the alarm and the specific content of the emergency measures.

[0132] S503: Based on the security alarm trigger record, record the defense measures taken after each alarm, including the type of measures and implementation time, and conduct a preliminary effect evaluation to generate a real-time defense action record;

[0133] Based on the security alarm trigger records, the system records the defense measures taken after each alarm, including the type of measures and implementation time. This involves extracting relevant information from the security alarm trigger records, identifying the implemented security measures such as automatically isolating the network, starting firewall enhancements, or sending emergency notifications to system administrators, and recording the specific implementation time of each measure. These records are subsequently used for effect evaluation. By comparing the system status before and after implementation and the frequency of security incidents, the system conducts a preliminary effect evaluation and generates real-time defense action records. The records show in detail the implementation status and initial effects of each measure, providing data support for further security policy adjustments.

[0134] See also Figure 7 , the specific steps of S6 are:

[0135] S601: Based on the real-time defense action record, connect to the cloud server, upload the defense execution content of the device, filter and analyze the uploaded data, identify the events of response time delay or defense failure, extract key performance indicators, and generate defense performance analysis records;

[0136] Based on the real-time defense action records, the system connects to the cloud server and uploads the defense execution content of the device. First, the system retrieves all real-time defense action records from the local database, including the timestamp of each record, the device ID, the type of defense measure implemented, and the corresponding execution results. Then, these data are sent to the cloud server through a secure and encrypted network connection. The cloud receives and performs preliminary data cleaning to eliminate any malformed or incomplete data items. Subsequently, the system screens and analyzes the uploaded data, paying special attention to those events with delayed response time or defense failure. For each event identified as a problem, key performance indicators are further extracted, such as delay time, cause of failure, and scope of impact. Finally, a defense performance analysis record is generated, which lists all key performance issues and corresponding data points in detail.

[0137] S602: Using the defense performance analysis record, adjust the cloud defense policy parameters, modify the trigger threshold and response protocol of the defense measures, optimize all modification operations according to the performance data, record the details of each policy adjustment, and generate a policy adjustment detail record;

[0138] Using the defense performance analysis records, the system adjusts the defense strategy parameters in the cloud. During the process, the system extracts key data from the defense performance analysis records, including response time delay, failure rate of defense measures, and related equipment and network conditions. Based on these data, the system calculates the trigger threshold of the defense measures and the optimal adjustment plan of the response protocol through algorithms. Before and after each adjustment, the system compares the threshold and protocol parameters to ensure that each modification is optimized based on actual performance data. The adjustment process is automatically performed using data analysis software to ensure that all modification operations are efficient and accurate. After the adjustment, the system records the specific details of each policy adjustment, including the adjusted parameters, performance comparison before and after the adjustment, and the reason for the adjustment, and generates a detailed record of the policy adjustment to provide a basis for future policy evaluation and further adjustment.

[0139] S603: Implement the new defense strategy according to the strategy adjustment details record, monitor the actual operation effect of the adjusted strategy, compare the defense effectiveness before and after the adjustment, record each key step and result evaluation in the optimization process, and generate a strategy optimization update record;

[0140] Based on the detailed records of policy adjustments, the system implements new defense policies and monitors the actual operating effects of the adjusted policies. First, the system deploys new policies to all relevant devices and network nodes to ensure that the configuration files of each node are updated to the latest version. Subsequently, the system collects the adjusted operating data through real-time data monitoring tools, including defense success rate, response time, and event processing efficiency, and compares the data with the data before adjustment to evaluate the effectiveness of the new policy. In addition, the system records each key step in the optimization process, such as policy deployment, data collection, and performance comparison. The evaluation results are obtained based on data analysis to generate policy optimization update records, which show in detail the effectiveness of the policy adjustment and any areas that need further optimization.

[0141] See also Figure 8 , a server-side DDoS attack defense system for IoT devices, comprising:

[0142] The timing heartbeat detection module sets a timing trigger mechanism, sends a heartbeat request to the server at a fixed time interval, receives and records the server's response time to the heartbeat request, performs statistical analysis and stores it, adjusts and determines the optimal communication interval between the device and the server, resets the timer's trigger frequency, and generates a response time record;

[0143] The anomaly monitoring and analysis module performs time series data analysis through response time records to confirm whether the anomaly conditions are met, records each detected anomaly event, performs local marking of the server status, and generates unstable marking records;

[0144] The standby server detection module performs connectivity checks on the standby server list based on unstable mark records, tests the availability of each server address, verifies the response time and connectivity status, updates the network configuration of the device, and generates configuration update records;

[0145] The connection stability test module updates records according to the configuration, initializes the data connection with the new server, sends the initial heartbeat packet to detect the connection stability, captures the communication data between IoT devices, and generates communication data set records;

[0146] The behavior deviation analysis module calculates the deviation value of each data from the baseline based on the communication data set records and the predefined communication behavior baseline, marks the data whose deviation exceeds the set threshold, identifies and records abnormal behaviors, and generates behavior deviation analysis results;

[0147] The real-time defense trigger module analyzes each piece of data based on the behavior deviation analysis results to check whether there is a behavior deviation. When any data point exceeds the warning threshold, a security alarm is immediately triggered, and the defense measures taken after each alarm are recorded to generate a real-time defense action record.

[0148] The strategy optimization and update module is based on real-time defense action records, connects to cloud servers, identifies events of response time delays or defense failures, extracts key performance indicators, modifies the trigger thresholds and response protocols of defense measures, monitors the actual operating effects of the adjusted strategies, and generates strategy optimization and update records.

[0149] The above are only preferred embodiments of the present invention and are not intended to limit the present invention in other forms. Any technician familiar with the profession may use the technical contents disclosed above to change or modify them into equivalent embodiments with equivalent changes and apply them to other fields. However, any simple modification, equivalent change and modification made to the above embodiments based on the technical essence of the present invention without departing from the technical solution of the present invention still falls within the protection scope of the technical solution of the present invention.

Claims

1. A method for defending against DDoS attacks on a server of an Internet of Things device, characterized in that: The following steps are involved: Real-time monitoring of IoT devices, using a timed trigger mechanism to periodically send heartbeat requests from the device to the server, record the response time of each request, and store it locally on the device to obtain a response time record; Data anomaly detection is performed through the response time record. If it is found that the response time exceeds the threshold or the heartbeat request fails for three consecutive times, the server status is marked as abnormal locally and an unstable marking record is generated; According to the unstable mark record, the server switching mechanism is triggered, the next available address is automatically selected from the preset backup server list, the server configuration of the device is updated, and the data connection is re-established to obtain the server switching record; According to the server switching record, the communication data between IoT devices is collected, the signals sent by the devices and the received feedback are analyzed one by one, the data is compared with the pre-defined communication behavior baseline, and abnormal behaviors are identified through difference analysis to generate behavior deviation analysis results; Based on the behavior deviation analysis results, monitor the real-time response of IoT devices, quickly locate and respond to abnormal behaviors, set warning thresholds to determine whether to trigger security alarms, execute defense measures, and form real-time defense action records; Based on the real-time defense action records, defense strategies are dynamically adjusted and optimized in the cloud, the execution of all defense measures is continuously monitored, historical data of strategy adjustments are recorded, and strategy optimization update records are output; According to the server switching record, the communication data between IoT devices is collected, the signals sent by the devices and the received feedback are analyzed one by one, the data is compared with the pre-defined communication behavior baseline, and abnormal behavior is identified through difference analysis. The specific steps of generating behavior deviation analysis results are as follows: Based on the server switching record, the communication data between IoT devices is captured, including the timestamp and data packet size of signal sending and feedback receiving, and the device ID and time are recorded for each data point to generate a communication data set record; Using the communication data set record, comparing with the predefined communication behavior baseline, calculating the deviation value of each data from the baseline one by one, marking the data whose deviation exceeds the set threshold, recording each marked data point and the corresponding deviation value, and generating a deviation mark record; According to the deviation mark record, analyze the marked data points, identify and record abnormal behaviors, including continuous data deviations or single large deviations, and generate behavior deviation analysis results; The deviation value of each data from the baseline is calculated according to the formula: ； Calculate, where represents the deviation normalized value, Represents the behavior value of a single communication data record, represents the average communication behavior value in the predefined baseline, represents the standard deviation of communication behavior in a predefined baseline, Represents the total number of data points, represents the median absolute deviation, and is the weight coefficient, Used to balance the effect of sample size on standard deviation, Used to adjust the effect of the median absolute deviation in the calculation of the total deviation value.

2. The method for defending against DDoS attacks on the server side of an IoT device according to claim 1, characterized in that: The response time record includes a request timestamp record, a server response time record and a response delay record; the unstable mark record includes the number of consecutive failures, abnormal response time and abnormal time point; the server switching record includes the backup server address, switching time and connection status record; the behavior deviation analysis result includes the deviation type, deviation degree analysis result and associated devices; the real-time defense action record includes the triggered defense measures, execution time and target IP; the strategy optimization update record includes the update measures, implementation date and evaluation results.

3. The method for defending against DDoS attacks on the server side of an IoT device according to claim 1, characterized in that: To monitor IoT devices in real time, a timing trigger mechanism is used to periodically send heartbeat requests from the device to the server, record the response time of each request, and store it locally on the device. The specific steps to obtain the response time record are: Set up a timing trigger mechanism, use the network protocol to send heartbeat requests to the server at fixed time intervals, receive and record the server's response time to the heartbeat request, use timestamps to record the actual time when each operation occurs, and generate heartbeat response records; Based on the heartbeat response record, the recorded data is sorted, statistical analysis is performed to determine the time average, maximum and minimum values, and the data is stored in a structured data format to generate a response time analysis result; Based on the response time analysis result, the sending frequency of the heartbeat request is modified by setting parameters, the optimal communication interval between the device and the server is adjusted and determined, the triggering frequency of the timer is reset, and the response time record is generated.

4. The method for defending against DDoS attacks on a server of an IoT device according to claim 1, wherein: Data anomaly detection is performed through the response time record. If it is found that the response time exceeds the threshold or the heartbeat request fails for three consecutive times, the server status is marked as abnormal locally. The specific steps for generating unstable marking records are: Through the response time record, time series data analysis is performed to detect whether the response time of three consecutive data points exceeds a preset threshold, and at the same time, whether the heartbeat request fails, confirm whether the abnormal condition is met, and generate an abnormal detection result; Based on the anomaly detection results, record each detected abnormal event, including the actual time when the abnormality occurred and the corresponding response time, summarize the data, and generate a statistical record of the abnormal event; The abnormal event statistical record is used to perform local marking of the server status, and an unstable marking record is generated for the timestamp of each marking record event and the associated response time data.

5. The method for defending against DDoS attacks on a server of an IoT device according to claim 1, characterized in that: According to the unstable mark record, the server switching mechanism is triggered, the next available address is automatically selected from the preset backup server list, the server configuration of the device is updated, and the data connection is re-established. The specific steps for obtaining the server switching record are: Based on the unstable mark record, a connectivity check is performed on the backup server list, the availability of each server address is tested one by one, the response time and connectivity status are verified through network commands, the first available server address with connectivity confirmation is selected, and a backup server selection record is generated; Adopting the candidate server selection record, updating the network configuration of the device, opening the network configuration file, replacing the old server address with the newly selected address, saving and closing the configuration file, and generating a configuration update record; According to the configuration update record, the data connection with the new server is initialized, an initial heartbeat packet is sent to detect the connection stability, the time of connection establishment and the initial response result are recorded, and a server switching record is generated.

6. The method for defending against DDoS attacks on the server side of an IoT device according to claim 1, characterized in that: Based on the behavior deviation analysis results, the specific steps of monitoring the real-time response of IoT devices, quickly locating and responding to abnormal behaviors, setting warning thresholds to determine whether to trigger security alarms, executing defense measures, and forming real-time defense action records are as follows: Based on the behavior deviation analysis results, the IoT devices are monitored and data collected in real time, each piece of data is analyzed to check whether there is a behavior deviation, the deviation data is compared with the set warning threshold, and whether an alarm is triggered to generate abnormal behavior monitoring records; By using the abnormal behavior monitoring record, when any data point exceeds the warning threshold, a security alarm is immediately triggered, the alarm triggering time and the triggering device identifier are recorded, predetermined security measures are automatically initiated, and a security alarm triggering record is generated; According to the security alarm trigger record, the defensive measures taken after each alarm are recorded, including the type of measures and the implementation time, and a preliminary effect evaluation is performed to generate a real-time defensive action record.

7. The method for defending against DDoS attacks on a server of an IoT device according to claim 1, characterized in that: According to the real-time defense action record, the defense strategy is dynamically adjusted and optimized in the cloud, the execution of all defense measures is continuously monitored, the strategy adjustment history data is recorded, and the specific steps of outputting the strategy optimization update record are as follows: Based on the real-time defense action record, connect to the cloud server, upload the defense execution content of the device, filter and analyze the uploaded data, identify events of response time delay or defense failure, extract key performance indicators, and generate defense performance analysis records; Using the defense performance analysis record, adjust the cloud defense strategy parameters, modify the trigger threshold and response protocol of the defense measures, optimize all modification operations according to the performance data, record the details of each strategy adjustment, and generate a strategy adjustment detail record; According to the detailed records of the strategy adjustment, implement the new defense strategy, monitor the actual operation effect of the adjusted strategy, compare the defense effectiveness before and after the adjustment, record each key step and result evaluation in the optimization process, and generate a strategy optimization update record.

8. A server-side DDoS attack defense system for an IoT device, characterized in that: According to the server-side DDoS attack defense method of an IoT device according to any one of claims 1 to 7, the system comprises: The timing heartbeat detection module sets a timing trigger mechanism, sends a heartbeat request to the server at a fixed time interval, receives and records the server's response time to the heartbeat request, performs statistical analysis and stores it, adjusts and determines the optimal communication interval between the device and the server, resets the timer's trigger frequency, and generates a response time record; The abnormal monitoring and analysis module performs time series data analysis through the response time records, confirms whether the abnormal conditions are met, records each detected abnormal event, performs local marking of the server status, and generates unstable marking records; The standby server detection module performs a connectivity check on the standby server list based on the unstable mark record, tests the availability of each server address, verifies the response time and connectivity status, updates the network configuration of the device, and generates a configuration update record; The connection stability test module updates the record according to the configuration, initializes the data connection with the new server, sends the initial heartbeat packet to detect the connection stability, captures the communication data between the IoT devices, and generates the communication data set record; The behavior deviation analysis module calculates the deviation value of each data from the baseline based on the communication data set records and the predefined communication behavior baseline, marks the data whose deviation exceeds the set threshold, identifies and records abnormal behaviors, and generates behavior deviation analysis results; The real-time defense trigger module analyzes each piece of data based on the behavior deviation analysis results to check whether there is a behavior deviation. When any data point exceeds the warning threshold, a security alarm is immediately triggered, and the defense measures taken after each alarm are recorded to generate a real-time defense action record; Based on the real-time defense action records, the strategy optimization and update module connects to the cloud server, identifies events of response time delay or defense failure, extracts key performance indicators, modifies the trigger threshold and response protocol of the defense measures, monitors the actual operation effect of the adjusted strategy, and generates strategy optimization and update records.

Images