An intelligent security device risk early warning method and system based on the Internet of Things

Abstract

A kind of intelligent security device risk early warning method and system based on Internet of Things, in the method, gateway equipment stores flow characteristic mapping table, by capturing and analyzing the data packet sent by Internet of Things equipment, the real-time flow rate is calculated, and the current service state is inferred according to mapping table. Request verification device authorized service state to service state management server. When the inferred service state corresponds to higher flow and the authorized state corresponds to lower flow, it is determined that the device may have an anomaly, a communication blocking instruction is generated and the data packets subsequently sent by the device are discarded, thereby realizing the early warning and protection of abnormal flow. Improve the detection accuracy and early warning timeliness of high concealment risk of Internet of Things security system.

Description

Technical Field

[0001] This application belongs to the field of communication control, and in particular relates to a risk warning method and system for intelligent security equipment based on the Internet of Things. Background Technology

[0002] In complex network environments, intelligent security monitoring systems have become a crucial infrastructure for ensuring regional security. These systems typically consist of numerous devices, including intelligent image acquisition equipment, access control units, and various environmental sensors. These devices are aggregated to a central management platform via an IoT gateway, utilizing edge computing and data analytics for real-time status monitoring. To ensure system stability, related technologies generally employ anomaly detection mechanisms based on traffic baselines. The core working principle is: the system continuously collects network traffic characteristics (such as data transmission rate and packet sending frequency) from each terminal under standard operating conditions to construct a historical behavior baseline; when the real-time monitored traffic data exceeds this baseline and surpasses a preset threshold, the system confirms an anomaly and triggers a response mechanism.

[0003] However, during the initial unauthorized access of IoT terminal devices, external intervention parties often exploit the logical characteristics of the device firmware to implement low-frequency and slow data transmission. Unauthorized data packets are often disguised as device status synchronization signals or heartbeat maintenance commands that conform to communication protocol specifications, and their transmission frequency is strictly controlled, ensuring that the overall data transmission characteristics remain within a preset normal traffic fluctuation range. Since related technologies primarily rely on significant abrupt changes in traffic statistical characteristics as the core criterion for judgment, it is difficult to distinguish between random network jitter and covert penetration behavior when dealing with minute amounts of unauthorized data integrated into stable business background noise. This limits the sensitivity in identifying minute abnormal loads hidden within the normal business fluctuation range, thereby reducing the accuracy and timeliness of IoT security systems in warning of highly covert risks and increasing the security vulnerabilities of the system under long-term covert penetration. Summary of the Invention

[0004] This application provides a risk warning method and system for smart security devices based on the Internet of Things (IoT), which can improve the detection accuracy and timely warning of highly concealed risks in IoT security systems.

[0005] In the first aspect, this application provides a risk warning method for smart security devices based on the Internet of Things, which pre-stores a traffic feature mapping table in the local storage space of the network gateway device. The traffic feature mapping table contains the correspondence between multiple network traffic statistical feature value ranges and multiple service status identifiers. Capture network data packets sent by the target IoT device through the network gateway device; Extract the header information of network data packets and count the real-time traffic rate within a preset time window; Traverse the traffic feature mapping table to determine the target network traffic statistical feature value range to which the real-time traffic rate value belongs; Read the service status identifier corresponding to the target network traffic statistics feature value range in the traffic feature mapping table, and mark the service status identifier as the inferred service status; Send a status verification request to the business status management server. The status verification request carries the unique device identifier of the target IoT device. Receive the authorized service status returned by the service status management server. The authorized service status is determined by the service status management server based on the control instruction record corresponding to the device's unique identifier. If the business status is inferred to belong to the preset first business status set, then determine whether the authorized business status belongs to the preset second business status set. The traffic rate value corresponding to the preset first business status set is higher than the traffic rate value corresponding to the preset second business status set. If the authorized service status belongs to the preset second service status set, a communication blocking instruction is generated for the target IoT device. According to the communication blocking command, discard any subsequent network data packets sent by the target IoT device.

[0006] By adopting the above technical solution and pre-storing a traffic feature mapping table in the network gateway device, real-time analysis and status inference of network traffic of IoT devices can be performed. When a mismatch is detected between the real-time traffic rate value of an IoT device and its authorized service status, a communication blocking command is generated promptly and a data packet is dropped. This risk warning method based on the matching degree of traffic features and service status can reduce the risk of abnormal traffic generated after IoT devices are maliciously controlled. Since this method performs traffic monitoring and anomaly handling at the gateway level, it does not require modification of the hardware and software configuration of the IoT device itself, reducing deployment and maintenance costs. By comparing and verifying the inferred service status with the authorized service status, the accuracy of abnormal traffic detection is improved, and the possibility of false alarms is reduced. At the same time, hierarchical processing based on a preset set of service statuses enables the system to distinguish different types of traffic anomalies, improving the accuracy of risk warning and the targeting of processing.

[0007] In conjunction with some implementation methods of the first aspect, in some implementation methods, the header information of network data packets is extracted and the real-time traffic rate value within a preset time window is statistically analyzed, specifically including: Identify the source IP address, destination IP address, source port, and destination port of network data packets to confirm that the network data packets belong to the uplink data sent by the target IoT device; Read the length field in the network packet header to obtain the data length of the network packet; The current time is used as the end time of the preset time window, and the start time of the preset time window is determined by going back a preset duration. Filter out all network data packets belonging to the target IoT device captured between the start and end times of a preset time window; The total data volume is obtained by summing the lengths of all filtered network data packets, and then the total data volume is divided by the duration of a preset time window to calculate the real-time traffic rate value within the preset time window.

[0008] By employing the above technical solution, and by identifying the source and destination addresses and port information of network data packets, combined with a traffic statistics method within a preset time window, accurate calculation of uplink data traffic on IoT devices is achieved. Accumulating data packet lengths and calculating the average rate within a fixed time window makes traffic rate statistics more accurate and stable. This method reduces resource consumption for traffic statistics by extracting and accumulating the data packet length field. Using a sliding time window for traffic rate calculation improves the real-time performance and continuity of traffic monitoring. The traffic statistics method based on a preset time window enables the system to more accurately capture sudden changes in traffic, improving the sensitivity of abnormal traffic detection. This accurate traffic statistics method provides a reliable data foundation for subsequent state inference and improves the accuracy of risk warnings.

[0009] In conjunction with some implementation methods of the first aspect, in some implementation methods, receiving the authorized service status returned by the service status management server specifically includes: Receive the response message returned by the business status management server in response to the status verification request; The response message is parsed, and the status field data is extracted. The status field data is obtained by the business status management server querying the preset device shadow database based on the device's unique identifier, obtaining the last legal control command record received by the device at the current moment, and converting it according to the working mode indicated by the legal control command record. The status field data is determined as the authorized business status.

[0010] By adopting the above technical solution, the authorized business status is obtained based on the latest control command record in the device shadow database by parsing the response message returned by the business status management server. This method ensures the validity and timeliness of the authorized business status and improves the reliability of status verification. Since the authorized business status is determined based on the legitimate control commands actually received by the IoT device, it can more accurately reflect the actual working status of the device. Recording the device's control command history in the device shadow database improves the accuracy of business status tracing. This status confirmation mechanism based on control command records reduces the risk of abnormal traffic caused by illegal control commands and enhances the security of the entire system.

[0011] In conjunction with some implementations of the first aspect, in some implementations, according to a communication blocking instruction, subsequent network data packets sent by the target IoT device are discarded, specifically including: If it is determined that the inferred business status belongs to the preset sudden business type, the network data packets sent by the target IoT device are stored in a temporary buffer queue, and a status synchronization timer is started to suspend the execution of the communication blocking command. When the state synchronization timer is running, a state reconfirmation request is sent to the business state management server. If the updated authorized service status is received from the service status management server before the status synchronization timer expires, and the updated authorized service status is consistent with the inferred service status, then the network data packets in the temporary buffer queue are released and normal forwarding is restored. If the state synchronization timer times out and no authorized service state consistent with the inferred service state is received, the temporary buffer queue is cleared and a communication blocking instruction is executed to discard subsequently sent network data packets.

[0012] By adopting the above technical solution, and setting up a temporary buffer queue and a state synchronization timer, a caching and secondary confirmation mechanism for bursty traffic is implemented. While waiting for state synchronization, the system temporarily stores data packets to prevent normal traffic from being misjudged and incorrectly dropped. When the updated authorized service state is received and matches the inferred service state, the cached data is released and normal forwarding resumes, improving the system's tolerance to normal bursty traffic. If state consistency cannot be confirmed before the timer expires, the cache is cleared promptly and communication is blocked, reducing the risk of continuous transmission of abnormal traffic. This processing method with caching and secondary confirmation mechanisms improves the system's accuracy in identifying bursty traffic, reduces the probability of mistakenly affecting normal traffic, and also enhances the timeliness of handling abnormal traffic.

[0013] In conjunction with some implementations of the first aspect, in some implementations, the network data packets sent by the target IoT device are stored in a temporary buffer queue, specifically including: Determine the preset maximum burst throughput and preset duration of the state synchronization timer corresponding to the inferred business state; The dynamic capacity threshold of the temporary buffer queue for this burst is calculated based on the product of the preset maximum burst throughput and the preset duration. Upon receiving each network data packet sent by the target IoT device, the current temporary buffer queue data filling rate and the total amount of cached data are calculated in real time. If the data filling rate does not exceed the preset maximum burst throughput and the total amount of cached data does not reach the dynamic capacity threshold, then network packets will be written to a temporary buffer queue. If the data filling rate exceeds the preset maximum burst throughput, or the total amount of cached data reaches the dynamic capacity threshold, the target IoT device is determined to be in an abnormal traffic attack state. The steps to stop writing network packets to a temporary buffer queue and directly execute a communication blocking command to discard subsequently sent network packets.

[0014] By adopting the above technical solution, a dynamic capacity threshold for the temporary buffer queue is calculated by setting a preset maximum burst throughput rate and a preset duration for the state synchronization timer, and the data filling rate and the total amount of cached data are monitored in real time. When the data filling rate exceeds the preset maximum burst throughput rate or the total amount of cached data reaches the dynamic capacity threshold, the device is promptly identified as being in an abnormal traffic attack state and communication is blocked. This buffer control mechanism based on dynamic thresholds improves the accuracy of identifying abnormal traffic attacks, reduces misjudgments caused by normal business bursts, and lowers the risk of gateway resources being exhausted by abnormal traffic. Because of the use of dynamic capacity thresholds, the system can flexibly adjust the buffer strategy according to the burst characteristics of different business types, improving the adaptability of the protection mechanism to different business scenarios, while reducing resource waste caused by fixed thresholds.

[0015] In conjunction with some implementations of the first aspect, in some implementations, if an updated authorized service status is received from the service status management server before the state synchronization timer expires, and the updated authorized service status is consistent with the inferred service status, then the network data packets in the temporary buffer queue are released and normal forwarding is restored. Specifically, this includes: Upon receiving an updated authorized service status that matches the inferred service status, the forwarding of data in the temporary buffer queue is paused. Based on the protocol feature model corresponding to the updated authorized service status, a packet-by-packet consistency check is performed on each network data packet cached in the temporary buffer queue. If the protocol characteristics of any network data packet in the temporary buffer queue do not match the protocol characteristic model, it is determined that the target IoT device is engaging in traffic hijacking attacks. Remove unmatched network packets from the temporary buffer queue and only release and forward valid network packets.

[0016] By adopting the above technical solution, before releasing data packets in the temporary buffer queue, a packet-by-packet consistency check is performed based on the protocol feature model corresponding to the authorized service status, and only data packets that pass the check are forwarded. By performing protocol-level feature matching on the temporarily buffered data packets, the detection accuracy of traffic-hidden attacks is improved. Because protocol feature verification is performed after confirming the legitimacy of the service status, the system can identify abnormal traffic initiated by attackers using legitimate services as cover, reducing the possibility of missed detections due to relying solely on traffic rate judgment. This multi-layered verification mechanism enhances the protection system's ability to identify complex attack methods and reduces security risks caused by traffic hidden attacks.

[0017] In conjunction with some implementation methods of the first aspect, in some implementation methods, based on the protocol feature model corresponding to the updated authorized service state, a packet-by-packet consistency check is performed on each network data packet cached in the temporary buffer queue, specifically including: The protocol feature model is analyzed to obtain the offset position information of key fields and their corresponding preset value ranges; Based on the offset position information, read the field value of each network packet in the temporary buffer queue at the corresponding position; If the field value exceeds the preset range, it is determined that the protocol characteristics of the network data packet do not match the protocol characteristic model. If the field value does not exceed the preset value range, it is determined that the protocol characteristics of the network data packet match the protocol characteristic model.

[0018] By employing the above technical solution, the system obtains the offset positions and preset value ranges of key fields by parsing the protocol feature model, enabling precise protocol feature matching of data packets. The system directly reads the field values ​​at specified positions in the data packet and compares them with the preset range, improving the efficiency of protocol feature verification. This offset-based fast matching method reduces the computational overhead of the protocol parsing process and lowers the processing latency of data packet detection. Because it uses preset value ranges for comparison, the system can flexibly configure feature rules for different protocols, improving the versatility of the protocol feature verification mechanism and enabling the protection system to adapt to more types of IoT devices and protocol standards.

[0019] Secondly, embodiments of this application provide an IoT-based intelligent security equipment risk warning system, which includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and one or more processors call the computer instructions to cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0020] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a system, cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Fourthly, embodiments of this application provide a computer program product that, when run on a system, causes the system to execute the method described in any possible implementation of the first aspect.

[0022] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. This application provides a risk warning method for IoT-based intelligent security devices. By pre-storing a traffic feature mapping table in the network gateway device, the network traffic of IoT devices can be analyzed and its status inferred in real time. When a mismatch is detected between the real-time traffic rate value of an IoT device and its authorized service status, a communication blocking command is generated promptly and a data packet is dropped. This risk warning method based on the matching degree of traffic features and service status can reduce the risk of abnormal traffic generated after IoT devices are maliciously controlled. Since this method performs traffic monitoring and anomaly handling at the gateway level, it does not require modification of the hardware and software configuration of the IoT device itself, reducing deployment and maintenance costs. By comparing and verifying the inferred service status with the authorized service status, the accuracy of abnormal traffic detection is improved, and the possibility of false alarms is reduced. At the same time, hierarchical processing based on a preset set of service statuses enables the system to distinguish different types of traffic anomalies, improving the accuracy of risk warning and the targeting of processing.

[0023] 2. This application provides a risk warning method for IoT-based intelligent security devices. By setting up a temporary buffer queue and a status synchronization timer, it implements a caching and secondary confirmation mechanism for sudden traffic surges. While waiting for status synchronization, the system temporarily stores data packets to prevent normal traffic from being misjudged and incorrectly discarded. When the received updated authorized service status matches the inferred service status, the cached data is released and normal forwarding resumes, improving the system's tolerance to normal sudden traffic surges. If status consistency cannot be confirmed before the timer expires, the cache is cleared and communication is blocked, reducing the risk of continuous abnormal traffic transmission. This processing method with caching and secondary confirmation mechanisms improves the system's accuracy in identifying sudden traffic surges, reduces the probability of mishandling normal traffic, and also enhances the timeliness of handling abnormal traffic.

[0024] 3. This application provides a risk warning method for IoT-based intelligent security devices. Before releasing data packets in the temporary buffer queue, a packet-by-packet consistency check is performed based on the protocol feature model corresponding to the authorized service status, and only data packets that pass the check are forwarded. By performing protocol-level feature matching on the temporarily buffered data packets, the detection accuracy of traffic-hidden attacks is improved. Since protocol feature verification is performed after confirming the legitimacy of the service status, the system can identify abnormal traffic initiated by attackers using legitimate services as cover, reducing the possibility of missed detections due to relying solely on traffic rate judgment. This multi-layered verification mechanism enhances the protection system's ability to identify complex attack methods and reduces the security risks caused by traffic hidden attacks. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a risk warning method for smart security devices based on the Internet of Things, as described in an embodiment of this application.

[0026] Figure 2 This is another flowchart illustrating a risk warning method for IoT-based smart security devices in this application embodiment.

[0027] Figure 3 This is another flowchart illustrating a risk warning method for IoT-based smart security devices in this application embodiment.

[0028] Figure 4 This is a schematic diagram of the physical device structure of a smart security equipment risk warning system based on the Internet of Things provided in this application embodiment. Detailed Implementation

[0029] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0030] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0031] The following example is used in conjunction with Figure 1 This application describes a risk warning method for smart security devices based on the Internet of Things (IoT) in its embodiments: Please see Figure 1 This is a flowchart illustrating a risk warning method for IoT-based smart security devices in an embodiment of this application.

[0032] S101. Pre-store the traffic feature mapping table in the local storage space of the network gateway device; The system pre-stores a traffic feature mapping table in the local storage space of the network gateway device. This table contains the correspondence between multiple network traffic statistical feature value ranges and multiple service status identifiers. The network gateway device refers to the hardware facility deployed at the edge of the IoT sensing layer and network layer. It is not limited to traditional routers or switches, but can also be a smart gateway with edge computing capabilities, an industrial control gateway, or a home security base station. Local storage space refers to the non-volatile storage media integrated within the network gateway device, such as flash memory, solid-state drives (SSDs), or embedded multimedia cards (eMMC), used to persistently store critical configuration data. The traffic feature mapping table is a predefined data structure used to describe the correlation between network behavior and business logic. This table contains multiple network traffic statistical feature value ranges. These ranges are continuous numerical ranges measured in data transmission rates (such as bps or pps), and different ranges should not overlap or have a clear priority division. Service status identifiers are codes or tags used to uniquely represent the current operating mode of the IoT device, such as standby mode, HD streaming mode, firmware upgrade mode, or heartbeat mode. The traffic feature mapping table establishes a deterministic lookup mechanism, meaning that for any given traffic statistical feature value, a unique corresponding service status identifier can be found in the table. When multiple thresholds are involved, such as the upper and lower limits of traffic corresponding to different service statuses, there is a strict logical relationship between these thresholds. Typically, the value range corresponding to high bandwidth consumption services (such as video streaming) is significantly higher than that of low bandwidth consumption services (such as heartbeat packets). The system pre-stores the traffic feature mapping table in the local storage space of the network gateway device, meaning that this mapping relationship is loaded during the initialization phase before device operation or through the remote configuration distribution phase, providing static benchmark data for subsequent real-time matching.

[0033] The first approach uses static configuration file loading technology. System administrators or security operations personnel manually identify traffic baselines for different business scenarios based on the specifications and historical operational data of the target IoT devices, and compile these baselines into configuration files in JSON, XML, or YAML format. During the startup process, the network gateway device loads this configuration file through a file system read interface and parses it into an in-memory hash map or search tree structure. This method is simple to implement, highly deterministic, and suitable for scenarios with a single device type and a fixed business model. The second approach uses dynamic synchronization technology based on cloud delivery. The network gateway device maintains a persistent connection with the cloud management platform via IoT protocols such as MQTT or CoAP. The cloud platform maintains a massive database of device traffic characteristics and pushes corresponding traffic characteristic mapping table binary data packets to the gateway based on the device model. After receiving the data, the gateway device uses an embedded database (such as SQLite) or a key-value storage engine (such as LevelDB) to write the data to its local storage space. This method supports remote updates and can flexibly respond to changes in traffic characteristics caused by device firmware upgrades.

[0034] S102. Capture network data packets sent by the target IoT device through the network gateway device; Target IoT devices refer to specific terminals included in the monitoring scope of a security system, such as smart cameras, infrared sensors, and smart locks. These devices are typically located on the downlink side of the gateway in the network topology. Network data packets refer to data units transmitted at the network layer, typically containing an IP header, TCP / UDP header, and application layer payload. Capture refers to the process by which the network gateway device obtains copies of data packets or directly intercepts and analyzes them during packet forwarding using specific technical means. After transmission by the network gateway device, it is clear that the data flow is primarily uplink traffic, i.e., traffic flowing from IoT devices to cloud servers or user terminals. This step is the data input foundation for the entire risk warning method, requiring the gateway device to have the ability to fully or sample and monitor the traffic flowing through its network interface. During this process, the system needs to handle high-concurrency network throughput to ensure that complete data samples for analysis are obtained without affecting the performance of normal business forwarding.

[0035] The first method is zero-copy capture based on kernel bypass technology. Using the DPDK (DataPlane Development Kit) or a similar fast packet processing framework, the gateway device can directly take over packet capture at the network card driver layer, bypassing the cumbersome processing flow of the operating system kernel protocol stack. By allocating a large ring buffer in user space, the network card directly DMA (Direct Memory Access) the received packets into user space memory. This method significantly reduces CPU interrupt overhead and memory copy counts, enabling line-rate packet capture, which is particularly suitable for high-bandwidth video surveillance gateways. The second method is filtering capture based on operating system kernel hooks. In Linux systems, the Netfilter framework can be used, attaching custom kernel modules to the PREROUTING or FORWARD chain at the IP layer, or using the eBPF (Extended Berkeley Packet Filter) program. When a packet passes through the gateway protocol stack, the hook function is triggered, and the system filters packets belonging to the target IoT device according to preset filtering rules (such as source MAC address or source IP address), and clones a copy to pass to the user-space analysis process. This approach offers high development flexibility, requires no special hardware support, and can leverage the kernel's existing connection tracking (Conntrack) functionality for assistance in identification.

[0036] S103. Extract the header information of network data packets and calculate the real-time traffic rate value within a preset time window; The system extracts the header information of network data packets and calculates the real-time traffic rate within a preset time window. Specifically, this includes: identifying the source IP address, destination IP address, source port, and destination port of the network data packets to confirm that the network data packets belong to the uplink data sent by the target IoT device; reading the length field in the network data packet header to obtain the data length of the network data packets; using the current time as the end time of the preset time window and counting backwards for a preset duration to determine the start time of the preset time window; filtering out all network data packets belonging to the target IoT device captured between the start and end times of the preset time window; summing the data lengths of all filtered network data packets to obtain the total data volume, and dividing the total data volume by the duration of the preset time window to calculate the real-time traffic rate within the preset time window.

[0037] Extracting packet header information involves parsing the captured raw binary data stream to extract control information from the network and transport layers. This includes the source IP address (identifying the sender), destination IP address (identifying the receiver), source port (identifying the sending process), destination port (identifying the receiving service), and packet length. This information constitutes the five-tuple characteristic of the network flow, serving as the basis for identifying device identity and service type. A preset time window refers to a time period used for statistics, which can be a fixed-length time slice (e.g., 1 second) or a sliding time window. The real-time traffic rate value is the ratio of the total amount of data transmitted within this time window to the duration, reflecting the current communication activity of the device. The system confirms that the data packet belongs to the uplink data sent by the target IoT device by identifying information such as the source IP address. This is to eliminate interference from downlink control commands or broadcast storms on the statistical results. Reading and summing the length field is the fundamental physical quantity for calculating traffic. Backtracking the preset duration to determine the start time indicates the use of a sliding window or real-time truncation statistical logic, ensuring the timeliness of the rate calculation.

[0038] First, there's identification and filtering. The system utilizes a lightweight implementation of Deep Packet Inspection (DPI) technology to quickly parse Ethernet frame headers, IP headers, and TCP / UDP headers. Packet ownership is confirmed by comparing the source IP address with a locally maintained list of device IPs or by parsing DHCP Snooping entries. For encrypted traffic (such as HTTPS), although the payload cannot be read, the packet header information is still visible in plaintext, sufficient for traffic statistics. Second, there's the construction of time windows and rate calculation. The first calculation method is a statistical algorithm based on a fixed time bucket. The system maintains an array of counters indexed by timestamps in memory. Whenever a packet belonging to the target device is captured, its data length is accumulated into the corresponding second-level counter based on the current system timestamp. When time advances to the next second, the accumulated value of the previous second becomes the real-time rate for that second. This method is simple to implement and has extremely low memory usage. The second calculation method is a precise statistical algorithm based on a sliding window. The system maintains a First-In-First-Out (FIFO) queue, which stores the arrival timestamp and length of each data packet within the most recent preset time interval (e.g., the past 5 seconds). Whenever a new data packet arrives, it is enqueued, and older data packets from the head of the queue that arrived before the start time are removed. The real-time rate is obtained by calculating the sum of the lengths of all data packets in the queue and dividing by the window duration. This method more smoothly reflects traffic fluctuations and avoids the jagged edges caused by fixed time buckets.

[0039] S104. Traverse the traffic feature mapping table to determine the target network traffic statistical feature value range to which the real-time traffic rate value belongs. The target network traffic statistical characteristic numerical range refers to the specific range found in the mapping table that contains the current real-time traffic rate value. For example, if the real-time rate is 500kbps, and the mapping table has three ranges: [0-10kbps], [11kbps-1Mbps], and [1Mbps-10Mbps], then the second range is the target range. This step is essentially a numerical matching and classification process, discretizing the continuously changing analog quantity (traffic rate) into predefined logical ranges. The process of determining the range must strictly follow the mathematical interval inclusion relationship, usually handled as left-closed and right-open or closed intervals. The assignment of boundary values ​​must be clearly defined during system design to prevent matching failures or ambiguities under boundary conditions.

[0040] The specific method for traversing the mapping table and determining the target interval depends primarily on the data structure organization of the mapping table in memory. The first method is a linear scan algorithm. If the number of entries in the traffic feature mapping table is small (e.g., less than 20), the system can store all intervals in a simple array or linked list. Upon obtaining the real-time traffic rate value, the system starts from the first element of the array and sequentially checks if the rate value is greater than or equal to the lower limit of the interval and less than or equal to the upper limit. Once a matching interval is found, the search stops immediately, and that interval is returned as the target interval. This method has the most intuitive code implementation and a high CPU cache hit rate with negligible performance loss for small datasets. The second method is a binary search algorithm. If the intervals in the mapping table are pre-sorted by numerical value and are continuous without gaps, the system can store the critical values ​​of all intervals in an ordered array. Using binary search, the system can quickly locate the insertion position of the real-time traffic rate value in O(log N) time complexity, thus determining its corresponding interval. This method significantly reduces the number of comparisons and improves matching efficiency compared to linear scan when the mapping table has many entries.

[0041] S105. Read the service status identifier corresponding to the target network traffic statistics feature value range in the traffic feature mapping table, and mark the service status identifier as the inferred service status. Business status identifiers are labels defined in the mapping table, designed for human-readable or system-processable use. For example, Status_ID_01 represents standby, and Status_ID_02 represents video upload. Inferred business status is the device's operating mode inferred by the system based on current objective traffic patterns. It's called inference because this status is based solely on traffic characteristics and hasn't been verified by the control plane, making it susceptible to forgery or anomalies. The tagging operation involves assigning the acquired business status identifier to a state variable associated with the target IoT device in system memory, or appending it to the metadata of the data stream for subsequent calls. This process abstracts the traffic rate of the physical world into business semantics in the logical world.

[0042] The specific methods and technologies for implementing this step mainly involve memory data access and state management mechanisms. The first method is direct mapping based on associative arrays. In memory, the traffic feature mapping table is constructed as a key-value pair structure with the interval ID or interval object as the key and the business state identifier as the value. After determining the target interval, the system directly retrieves the value through the key. After retrieval, the system updates a field named `inferred_state` in the device's Session Control Block. This field is an enumerated variable that stores the current inferred state. This method is atomic and fast. The second method is streaming processing based on metadata tagging. In the network packet processing pipeline, the system does not maintain global state variables but instead constructs a context structure containing raw data packets and analysis results. When a business state identifier is found, it is written as a tag into a specific field of this structure. This tagged structure is passed to subsequent verification modules along with the processing flow. This method is suitable for stateless or streaming computing architectures and facilitates parallel processing.

[0043] S106. Send a status verification request to the business status management server; The system sends a status verification request to the business status management server, and the status verification request carries the unique device identifier of the target IoT device.

[0044] The business status management server, located in the cloud or local control center, holds control over IoT devices and their expected behaviors. It typically runs an IoT Device Management Platform (DMP) or business logic middleware. A status verification request is an active query initiated by the gateway device to verify the device's current status with an authoritative source. The core information carried in this request is the target IoT device's unique identifier, which is usually the device's MAC address, IMEI number, serial number (SN), or UUID generated during registration on the IoT platform. This unique identifier is used to accurately locate the specific device in the server's massive device database. Sending the request means that the gateway device, as a client, transmits data to the business status management server, which acts as the server, via network protocols. This step signifies that the risk warning logic has moved from single-point traffic analysis to a level of edge-cloud collaborative verification.

[0045] S107. Receive the authorized service status returned by the service status management server; The system receives the authorized service status returned by the service status management server. The authorized service status is determined by the service status management server based on the control command record corresponding to the device's unique identifier. Specifically, the system receives the response message returned by the service status management server in response to the status verification request; parses the response message, extracts the status field data, which is obtained by the service status management server querying the preset device shadow database based on the device's unique identifier to obtain the last valid control command record received by the device at the current moment, and converts it according to the working mode indicated by the valid control command record; and finally determines the status field data as the authorized service status.

[0046] The specific methods and technologies for sending requests to the business status management server depend on the communication protocol stack used by the system. The first method is a RESTful API call based on the HTTP / HTTPS protocol. The network gateway device acts as an HTTP client, constructing a JSON message containing the device's unique identifier and sending a POST request to a specific URL exposed by the business status management server (e.g., / api / v1 / device / verify_status). This method is highly versatile, easily integrated with existing web service architectures, and the HTTPS protocol ensures the security of the transmission channel. The second method is asynchronous message publishing based on the MQTT protocol. The network gateway device connects to the MQTT Broker via a persistent connection and publishes a message containing the device ID to a specific topic (e.g., sys / gateway / verify_request). The business status management server subscribes to this topic and processes the message upon receipt. This method is suitable for IoT environments with limited bandwidth or unstable networks, and because it maintains a persistent connection, the communication overhead is lower than frequently establishing HTTP connections, resulting in faster response times.

[0047] S108. If it is inferred that the business status belongs to the preset first business status set, then determine whether the authorized business status belongs to the preset second business status set. If the business state is inferred to belong to the preset first business state set, then it is determined whether the authorized business state belongs to the preset second business state set. The traffic rate value corresponding to the preset first business state set is higher than the traffic rate value corresponding to the preset second business state set. The authorized business state refers to the state that the device should be in, as determined by the business state management server based on the legal instructions recorded by the system. It is the truth standard for judging whether the device behavior is normal. Control instruction records refer to the history of remote operations issued by the user through a mobile APP, web console, or automated scenarios, such as turning on video or turning off the PTZ. The Device Shadow database is a virtual data copy maintained by the server to store the desired state and reported state of the device. The system receives the response message and parses out the state field data. This data is obtained by the server querying the Device Shadow database to obtain the last legal control instruction received at the current moment and converting it according to the working mode indicated by the instruction (e.g., if the instruction is to turn on recording, then the mode is recording mode). This step ensures that the benchmark data used for comparison is generated based on the user's true intent and the system's legal control logic.

[0048] First, there's the receiving and parsing of response messages. The first approach is to process JSON-formatted responses. After receiving an HTTP 200 OK response or MQTT payload, the gateway device uses a JSON parsing library (such as cJSON or Jackson) to extract predefined fields (e.g., "authorized_status": "Status_ID_02"). When generating this response, the server first queries the command log table in a relational database (such as MySQL), finds the latest command in reverse chronological order, and then maps it to a status code through the business logic engine. The second approach is to process Protocol Buffers (Protobuf) serialized data. To improve transmission efficiency, the server returns a binary stream. The gateway uses pre-generated Protobuf stub codes to deserialize the data and directly read object properties. The server may use an in-memory database such as Redis as the storage medium for device shadows to achieve millisecond-level fast query responses. Next is the state transition logic. The server not only performs simple queries but also needs to perform logical deductions. For example, if a user issues a command to enable motion detection, the server needs to confirm that the device is online by checking the device's current heartbeat report before returning the motion detection mode as an authorized status; otherwise, it may return offline or command being issued.

[0049] S109. If the authorized service status belongs to the preset second service status set, then generate a communication blocking instruction for the target IoT device. The first preset service state set typically includes high-risk, high-traffic-consumption, or sensitive service states, such as high-definition video streaming, firmware OTA downloads, and batch log uploads. These states correspond to higher traffic rates. The second preset service state set typically includes low-risk, low-traffic-consumption, or silent service states, such as standby / hibernation, heartbeat maintenance, and text-only alarm reporting. These states correspond to lower traffic rates. The judgment logic is: if traffic analysis infers that the device is currently in a high-traffic state (belonging to the first set), but server verification indicates that the device should be in a low-traffic state (belonging to the second set), it means that the device's behavior is seriously deviating from the authorized intent. This deviation usually suggests that the device has been controlled by a botnet (used for DDoS attacks) or is being illegally intercepted for video streaming. The threshold relationship here is reflected in the difference in set attributes; the average traffic characteristics of the first set are significantly higher than those of the second set.

[0050] The specific methods and techniques for implementing this step mainly involve set operations and conditional judgment logic. The first method is set judgment based on bitmasks. The system assigns a unique binary bit to each business state. The first and second business state sets are pre-computed as two integer masks. Determining whether a business state belongs to the first set only requires a bitwise AND operation (Current_State&Set1_Mask!=0). Similarly, determining whether the authorization state belongs to the second set also involves bitwise operations. This method executes at the CPU instruction level, is highly efficient, and suitable for embedded gateways. The second method is lookup judgment based on hash sets. The system maintains two HashSet objects in memory, storing all state ID strings contained in the first and second sets respectively. After obtaining the inferred state and authorization state, the `contains()` method of the HashSet is called for a boolean value judgment. The pseudocode is: `if(Set1.contains(inferred)&&Set2.contains(authorized))`.

[0051] S110. According to the communication blocking instruction, discard the network data packets subsequently sent by the target IoT device.

[0052] The trigger condition is that the logical judgment in step S108 is true, confirming the abnormal situation of high flow and low configuration: the device is actually sending a large amount of data (inferred state in the first set), but theoretically it should be running silently or at low speed (authorized state in the second set). A communication blocking command is a control signal or rule configuration generated by the system to cut off the network access permissions of a target IoT device. This command targets a specific IoT device, typically locked by its IP address or MAC address. Generating the command does not mean immediate execution, but rather constructing an operation object to be executed. This object contains the object to be blocked, the type of blocking (e.g., complete blocking or blocking only uplink), the duration of the blocking, and the reason code for triggering the blocking.

[0053] The specific methods and techniques for generating communication blocking commands mainly depend on the gateway's data plane control interface. One method is to generate firewall rule objects. The system constructs a rule string specific to LinuxNetfilter / iptables, such as iptables-IFORWARD-s<Device_IP> -jDROP. Alternatively, if nftables are used, the corresponding nft instruction structure is generated. This instruction object is placed in an execution queue, waiting for the execution module to call the system command. The second approach is to generate SDN (Software-Defined Networking) flow table instructions. If the gateway supports OpenFlow or P4 protocols, the system generates a Flow Mod message instructing the data plane to match the device's source MAC address and set the action to Drop. This instruction is a binary packet conforming to the SDN protocol standard, ready to be sent to the underlying switching ASIC or virtual switch (such as Open vSwitch).

[0054] In the above embodiments, by pre-storing a traffic feature mapping table in the network gateway device, the network traffic of IoT devices can be analyzed and its status inferred in real time. When a mismatch is detected between the real-time traffic rate value of an IoT device and its authorized service status, a communication blocking command is generated promptly and a data packet discarding operation is performed. This risk warning method based on the matching degree of traffic features and service status can reduce the risk of abnormal traffic generated after IoT devices are maliciously controlled. Since this method performs traffic monitoring and anomaly handling at the gateway level, it does not require modification of the hardware and software configuration of the IoT device itself, reducing deployment and maintenance costs. By comparing and verifying the inferred service status with the authorized service status, the accuracy of abnormal traffic detection is improved, and the possibility of false alarms is reduced. At the same time, hierarchical processing based on a preset set of service statuses enables the system to distinguish different types of traffic anomalies, improving the accuracy of risk warning and the targeting of processing.

[0055] The above embodiments describe a basic risk warning process. However, in real-world applications, IoT devices may experience sudden business demands, which often generate high traffic rates. To avoid misjudging normal sudden business demands as abnormal traffic and causing service interruptions, a specialized processing mechanism needs to be designed. The following section will discuss this further. Figure 2 Another method for risk warning of smart security devices based on the Internet of Things is described in the embodiments of this application: Please see Figure 2 This is another flowchart illustrating a risk warning method for IoT-based smart security devices in this application embodiment.

[0056] S201. If it is determined that the inferred business status belongs to the preset sudden business type, the network data packets sent by the target IoT device are stored in a temporary buffer queue, and the status synchronization timer is started to suspend the execution of the communication blocking command. If the inferred service state is determined to be a pre-defined burst service type, the network data packets sent by the target IoT device are stored in a temporary buffer queue. This includes: determining the pre-defined maximum burst throughput and the pre-defined duration of the state synchronization timer corresponding to the inferred service state; calculating the dynamic capacity threshold of the temporary buffer queue for this burst based on the product of the pre-defined maximum burst throughput and the pre-defined duration; upon receiving each network data packet sent by the target IoT device, calculating the current data filling rate and the total amount of cached data in the temporary buffer queue in real time; if the data filling rate does not exceed the pre-defined maximum burst throughput and the total amount of cached data does not reach the dynamic capacity threshold, then the network data packet is written to the temporary buffer queue; if the data filling rate exceeds the pre-defined maximum burst throughput or the total amount of cached data reaches the dynamic capacity threshold, then the target IoT device is determined to be in an abnormal traffic attack state; stopping the writing of network data packets to the temporary buffer queue and directly executing a communication blocking command to discard subsequently sent network data packets. The state synchronization timer is then started, and the execution of the communication blocking command is paused.

[0057] Inferring business status refers to the operating mode that the system might be in, as analyzed based on current traffic characteristics. Pre-defined bursty business types refer to a special type of business mode predefined in the system. These services generate short periods of high traffic during normal operation, such as over-the-air (OTA) firmware upgrades, historical video playback, alarm recording uploads, or batch log synchronization. These business types are characterized by traffic rates far exceeding those of regular heartbeat or standby states, but are considered legitimate activities. A temporary buffer queue is a dedicated storage area in memory or high-speed storage media used to temporarily hold network data packets instead of immediately forwarding or discarding them. A status synchronization timer is a countdown logic unit used to limit the maximum time the system waits for cloud confirmation. The preset maximum burst throughput is the highest instantaneous transmission rate allowed for this bursty business type. The dynamic capacity threshold is the maximum amount of data allowed to be stored in the temporary buffer queue; it is not a fixed value but is dynamically calculated based on business characteristics. The logic of this step is to establish an observation period. When the system detects high traffic suspected of being a bursty business, it does not immediately classify it as an attack and block it. Instead, it first buffers the data packets and starts a timer to buy time for subsequent cloud status confirmation. During this period, the communication blocking command is temporarily suspended, meaning the system is in a pending intermediate state. When multiple thresholds are involved, the preset maximum burst throughput rate is used to limit the instantaneous rate, and the dynamic capacity threshold is used to limit the total backlog. Together, they constitute the boundary constraints on burst traffic, and exceeding either one will result in an anomaly.

[0058] First, the system performs dynamic capacity threshold calculation and queue initialization. After identifying the inferred service status (such as firmware download), the system reads the preset maximum burst throughput (e.g., 10Mbps) and the preset duration (e.g., 5 seconds) of the status synchronization timer corresponding to that status from the local configuration database. The system uses the multiplication unit to calculate the product of the two (10Mbps * 5s = 50Mb) and sets this product as the dynamic capacity threshold for this session. Second, the system performs real-time packet processing and threshold verification. The first implementation is based on a combination of a ring buffer and a token bucket algorithm. The system allocates a fixed-size ring buffer in memory as a temporary buffer queue. Whenever a packet is received, the system first uses the token bucket algorithm to calculate the instantaneous fill rate of the current data stream. If the required number of tokens exceeds the bucket's capacity (i.e., exceeds the preset maximum burst throughput), or if the space already used in the buffer plus the length of the new packet exceeds the dynamic capacity threshold, an overflow interrupt is triggered, the packet is discarded, and a blocking command is issued. Conversely, if the verification passes, the packet is copied into the ring buffer via memory, and the write pointer and the total cached data counter are updated. The second implementation is based on a linked list and a time window accumulation method. The system uses a linked list structure to dynamically manage memory blocks. When receiving data packets, the system calculates the filling rate by counting the total amount of data received within the current sliding time window (e.g., the most recent second). Simultaneously, a global variable is maintained to record the total number of bytes in all data packets in the linked list. If the calculated rate is less than or equal to the preset maximum burst throughput, and the total number of bytes in the linked list is less than or equal to the dynamic capacity threshold, the data packet is appended to the end of the linked list. If either condition is not met, the system immediately stops the appending operation, calls the firewall interface to block the packet, and releases the memory occupied by the linked list.

[0059] S202. When the state synchronization timer is running, send a state reconfirmation request to the business state management server; The state synchronization timer operation refers to the time window from when the timer is started in step S201 until the timer reaches zero or is manually stopped. The state reconfirmation request is a special request, distinct from regular heartbeats or periodic checks. It has high priority and a clear purpose: to inquire with the server whether the sudden surge in traffic generated by the current device is authorized. The business state management server is a cloud or local central node that holds the device's true business logic and control permissions. The purpose of sending this request is to utilize this buffer time to eliminate the information asymmetry between the gateway's local inference and the actual state in the cloud. This is because the gateway can only see network layer traffic characteristics, while the server knows the application layer business instructions (e.g., the user just clicked the firmware update button). This step is the core interaction in the entire cache-confirmation mechanism, determining how cached data is subsequently processed.

[0060] The specific methods and technologies for sending status reconfirmation requests to the business status management server mainly depend on the communication protocol and system architecture. The first method uses an RPC call based on an out-of-band control channel. If the gateway device supports multi-channel communication, the system utilizes a control channel independent of the data transmission channel (e.g., a dedicated management VLAN or a separate MQTT control topic) to construct a remote procedure call (RPC) request containing the device ID, inferred business status code, and current timestamp. This request is marked as Urgent and sent directly to the server's API interface. Upon receiving it, the server prioritizes querying the device shadow or command queue and immediately returns the result. This method avoids control signaling being overwhelmed by congested data traffic. The second method uses a piggybacking mechanism based on existing long-lived connections. Most IoT gateways maintain WebSocket or TCP long-lived connections with the cloud. The system constructs a lightweight status query message and inserts it into the head of the current connection's send queue. This message contains a unique transaction ID used to associate subsequent server responses with this buffered event. The system utilizes an underlying keep-alive mechanism to ensure connection survival and quickly delivers requests to the server through this channel. This approach eliminates the need to establish new connections, reduces handshake overhead, and results in faster response times.

[0061] S203. If, before the state synchronization timer expires, the updated authorized service status is received from the service status management server, and the updated authorized service status is consistent with the inferred service status, then the network data packets in the temporary buffer queue are released and normal forwarding is restored. Before the state synchronization timer expires, it means the system is still within the allowed waiting window, and the server response received at this time is valid. The updated authorized service state refers to the state the device should be in, as returned by the server based on the latest control command record (e.g., a recently issued OTA command). Consistency judgment compares the state inferred locally by the gateway (e.g., firmware download) with the state returned by the server. If they match, it indicates that the high-speed traffic captured was indeed a legitimate business request, not a malicious attack. Releasing the temporary buffer queue means retrieving data packets stored in memory or disk sequentially. Restoring normal forwarding means re-injecting these retrieved data packets into the network protocol stack's transmission path, directing them to their original destination, and removing the temporary control measures on the device, allowing subsequent new data packets to pass directly. This step demonstrates the system's ability to correct false alarms, ensuring service continuity.

[0062] The specific methods and techniques for releasing the temporary buffer queue and restoring normal forwarding mainly involve packet re-injection and state machine switching. The first method is packet replay based on the kernel protocol stack. The system traverses the temporary buffer queue (e.g., a linked list). For each cached packet structure (e.g., sk_buff in Linux), the system restores its original network interface index and routing information. Then, it calls the kernel's send function (e.g., dev_queue_xmit) to put the packet back into the network card driver's send queue. After all cached packets have been processed, the system updates the IoT device's state flag from pending verification to authorized burst and disables the state synchronization timer, preventing subsequent traffic from triggering the buffer logic. The second method is pointer passing based on zero-copy technology. If the S201 uses a zero-copy buffer based on shared memory or DPDK, the release operation does not require actual data movement. The system only needs to move the pointer descriptor of the memory block storing the packet from the temporary buffer ring to the forwarding ring (TXRing) and notify the network card hardware to send. Simultaneously, the system updates the flow table rules, removes the blocking action for that flow, and restores line-rate forwarding. This approach can significantly reduce CPU load in high-traffic burst scenarios and avoid processing bottlenecks caused by the release operation itself.

[0063] S204. If the state synchronization timer times out and no authorized service state consistent with the inferred service state is received, then clear the temporary buffer queue and execute the communication blocking instruction to discard subsequently sent network data packets.

[0064] A state synchronization timer timeout means the observation period given by the system has ended, but no permission has been received from the server. This could be because the server explicitly returned an inconsistent state (e.g., the server believes the device should be in standby), or because a network failure has resulted in no response. In this case, for security reasons, the system must take defensive measures. Clearing the temporary buffer queue means deleting all data packets that were temporarily saved to avoid misjudgment, releasing the memory resources they occupied. Executing the communication blocking command means officially taking effect the blocking rules, discarding all subsequent data packets generated by the target IoT device. This step reflects the security-first design principle: when the legitimacy of traffic cannot be confirmed, it is better to block the service than to prevent potential attacks from continuing.

[0065] The specific methods and techniques for clearing the queue and executing blocking mainly involve memory reclamation and Access Control List (ACL) configuration. The first method is immediate memory release and blacklist activation. When a timer interrupt triggers a timeout event, the system immediately locks the temporary buffer queue, traverses all nodes in the queue, calls memory release functions (such as kfree or free) to return the memory blocks, and sets the queue's head and tail pointers to null. Immediately afterwards, the system calls the firewall configuration interface to issue a DROP rule targeting the device's source IP or MAC address, setting the rule's effective time to permanent or a longer penalty period. Simultaneously, the system generates a high-priority security alarm log, recording the blocking reason, the amount of data dropped, and the device ID. The second method is batch reset and hardware flow table update. For gateways using hardware acceleration, the system sends a Flush command to the hardware buffer management unit. The hardware logic instantly resets the read / write pointers of the specified queue within a clock cycle, achieving rapid clearing. Simultaneously, the system writes a new flow table entry to the switching chip's TCAM (Tri-State Content Addressable Memory), matching the device's traffic characteristics and setting the action field to Discard. This approach ensures the atomicity and real-time nature of the blocking operation, preventing any loopholes from penetrating the defense during processing.

[0066] In the above embodiments, a caching and secondary confirmation mechanism for bursty traffic is implemented by setting up a temporary buffer queue and a state synchronization timer. While waiting for state synchronization, the system temporarily stores data packets to prevent normal traffic from being misjudged and incorrectly dropped. When the received updated authorized service state matches the inferred service state, the cached data is released and normal forwarding resumes, improving the system's tolerance to normal bursty traffic. If state consistency cannot be confirmed before the timer expires, the cache is cleared and communication is blocked in a timely manner, reducing the risk of continuous transmission of abnormal traffic. This processing method with caching and secondary confirmation mechanisms improves the system's accuracy in identifying bursty traffic, reduces the probability of mistakenly affecting normal traffic, and also enhances the timeliness of handling abnormal traffic.

[0067] The above embodiments achieve initial identification of bursty traffic through temporary buffer queues and state synchronization timers. However, in some attack scenarios, attackers may use the normal service status of the device as cover to smuggle abnormal data packets into legitimate traffic. To counter such complex attack methods, the system needs to perform more in-depth feature analysis at the protocol level. The following section combines... Figure 3 This application describes yet another method for risk warning of smart security devices based on the Internet of Things: Please see Figure 3 This is another flowchart illustrating a risk warning method for IoT-based smart security devices in this application.

[0068] S301. Upon receiving an updated authorized service status that is consistent with the inferred service status, suspend forwarding of data in the temporary buffer queue. The updated authorized business status is the exact status instruction returned by the business status management server after verification. It represents the task that the cloud-approved device should currently perform (e.g., video playback in progress). Consistency confirmation means that local inference matches cloud authorization, which usually means that the traffic is legitimate at the business logic level. The temporary buffer queue is the storage space previously used to cache burst traffic. Pausing forwarding means that even if the business status has been confirmed as legitimate, the system does not immediately release the data packets in the queue, but maintains the queue frozen or preserves its state, preventing data packets from entering the network sending interface. The logical significance of this step is that it switches the system's processing flow from coarse-grained control based on state to fine-grained control based on content. Before this, the pause was to wait for authorization; after this, the pause is to wait for deep inspection. This is a seamless transition in security mechanisms, preventing potential smuggled attack traffic from escaping by taking advantage of the time difference at the moment of status confirmation.

[0069] The first approach is a state machine-based flag control technique. The system maintains a global state machine object for the IoT device in memory. When the authorization status returned by the server is received and verified, the system does not directly call the send function. Instead, it atomically updates the device's processing status flag from Waiting for Authorization (WAIT_AUTH) to PENDING_INSPECTION. When the network forwarding thread polls the temporary buffer queue, it first checks this flag. Once the flag is detected as PENDING_INSPECTION, the forwarding thread suspends the send operation for that queue and triggers a semaphore or event notification to wake up the Deep Packet Inspection (DPI) module for processing. The second approach is a logical transfer technique based on queue ownership. After receiving a consistent authorization status, the system performs a pointer swap operation. The system logically transfers the pointer handles pointing to the head and tail of the temporary buffer queue from the jurisdiction of the network layer forwarding module to the security inspection engine module. At the underlying implementation level, this can be achieved by modifying the Owner ID field in the queue descriptor. At this point, the network interface controller (NIC) driver can no longer access the queue, thus physically pausing forwarding. At the same time, the system starts a high-priority detection task, which takes over the read permissions of the queue to ensure that data does not flow to the external network before the detection is completed.

[0070] S302. Based on the protocol feature model corresponding to the updated authorized service status, perform packet-by-packet consistency verification on each network data packet cached in the temporary buffer queue. The system performs packet-by-packet consistency verification on each network data packet cached in the temporary buffer queue based on the protocol feature model corresponding to the updated authorized service status. Specifically, this includes: parsing the protocol feature model to obtain the offset position information of key fields and their corresponding preset value ranges; reading the field value at the corresponding position of each network data packet in the temporary buffer queue based on the offset position information; if the field value exceeds the preset value range, it is determined that the protocol feature of the network data packet does not match the protocol feature model; if the field value does not exceed the preset value range, it is determined that the protocol feature of the network data packet matches the protocol feature model. The protocol feature model is a predefined description file of the legal data packet structure for specific service types (such as RTSP video streams, MQTT control commands, and HTTP firmware downloads). It is not limited to standard network protocol headers but focuses more on the service characteristics of application layer payloads. Key fields are specific byte sequences defined in the model that can characterize the legality of the service, such as frame header identifiers in video streams and opcodes in control commands. The offset position information indicates the byte distance of the key field relative to the start position of the data packet. The preset value range is the range or enumeration set of legal values ​​allowed for this field. Packet-by-packet consistency verification refers to the system traversing the temporary buffer queue and independently performing a read-compare-determine logic for each data packet. When multiple thresholds are involved, the offset is the location threshold, and the value range is the determination threshold; together, they constitute the compliance constraint on the data packet content. The purpose of this step is to verify whether the content of the data packet truly conforms to the specifications of that business type, given the known business type, thereby identifying abnormal payloads disguised as legitimate business operations.

[0071] First, the model is loaded and parsed. Based on the updated authorized business status (e.g., camera PTZ control), the system retrieves and loads the corresponding protocol feature model from a local high-speed hash table. The system parses the model, extracting metadata for N key fields that need to be verified, including the byte offset, data length, data type, and valid preset value range (Range / Set) for each field. Second, offset-based field reading and comparison. The first implementation is based on zero-copy direct memory access. For each data packet in the queue, the system directly calculates the absolute address of the key field in physical memory based on its memory address and the offset position information in the model. The system uses pointer casting to read the byte value of the corresponding length at that address. Then, it compares the read value with the preset value range (e.g., greater than or equal to the minimum value and less than or equal to the maximum value). If all key fields fall within the range, it is marked as a match; otherwise, it is marked as a mismatch. The second implementation is based on bitmasks and a pattern matching engine. For complex protocol features, the system converts the offset and preset value range into a set of binary masks and matching patterns. The system loads specific segments of the data packet into the CPU's registers and uses bitwise AND, OR, and XOR instructions to perform parallel verification on multiple flag bits or fields at once. This method is particularly suitable for checking the validity of flag bit combinations in the protocol header. If the operation result matches the expected pattern, the protocol feature is determined to match; otherwise, it is not.

[0072] S303. If the protocol characteristics of any network data packet in the temporary buffer queue do not match the protocol characteristic model, it is determined that the target IoT device has traffic-smuggling attack behavior. A mismatch occurs when the field value read from S302 exceeds the preset range, or when the data packet structure does not conform to the definition of the protocol feature model. Traffic piggybacking refers to an attacker inserting malicious control commands, data theft code, or covert channel data into normal business data streams (such as consecutive video frames). This type of attack is extremely stealthy because its traffic statistics (rate, frequency) are often indistinguishable from normal business traffic. The judgment logic in this step adopts a zero-tolerance or specific trigger principle: if at least one data packet in the temporary buffer queue fails the protocol feature model verification, the system determines that the device's current communication session has been compromised or exploited. This means the device may have been compromised or is currently under a man-in-the-middle attack. This determination will trigger subsequent security response procedures, escalating a simple anomaly suspicion into a confirmed attack event.

[0073] S304. Remove unmatched network packets from the temporary buffer queue and only release and forward verified network packets.

[0074] Removal refers to permanently deleting specific data packets deemed mismatched from memory and reclaiming the resources they occupy. Release and forwarding refers to removing valid data packets from their pause state and pushing them into the network transmission queue. This step differs from the full blockade of S204; it performs a scrubbing operation. The system assumes that in a smuggling attack, most traffic (such as video background streams) is still legitimate business data, and the attacker has only mixed in a small number of malicious packets. Therefore, to ensure service availability, the system does not interrupt the entire connection but rather precisely removes the lesions like surgery. This requires the system to have extremely high packet manipulation capabilities to ensure that after removing intermediate nodes, the remaining data packets can be reconnected and sent correctly, maintaining the continuity of the data flow.

[0075] The first method is a node removal technique based on a doubly linked list. Temporary buffer queues are typically organized as doubly linked lists. The system traverses the list, and for nodes marked as mismatched, performs a standard linked list deletion operation: the predecessor node's `next` pointer is set to the successor node, the successor node's `prev` pointer is set to the predecessor node, and then the memory block of the current node is released. For nodes marked as matching, the system retains them in the linked list. After processing, the system submits the entire cleaned linked list to the network card driver's transmit ring (TX Ring) for forwarding.

[0076] The second approach is a data transfer technique based on building a new queue. The system creates a new, empty send queue. While traversing the temporary buffer queue, if a data packet passes verification, the system moves or copies its memory descriptor to the new queue; if verification fails, the data packet is discarded. After traversal, the old queue is destroyed, and the new queue is committed for transmission. This method avoids the concurrency issues that may arise from frequently modifying pointers on the original linked list.

[0077] In the above embodiments, before releasing data packets in the temporary buffer queue, a packet-by-packet consistency check is performed based on the protocol feature model corresponding to the authorized service state, and only data packets that pass the check are forwarded. By performing protocol-level feature matching on the temporarily buffered data packets, the detection accuracy of traffic-hidden attacks is improved. Since protocol feature verification is performed after confirming the legitimacy of the service state, the system can identify abnormal traffic initiated by attackers using legitimate services as cover, reducing the possibility of missed detections that may result from relying solely on traffic rate for judgment. This multi-layered verification mechanism enhances the protection system's ability to identify complex attack methods and reduces the security risks caused by traffic hidden attacks.

[0078] The system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 4 This is a schematic diagram of the physical device structure of an IoT-based intelligent security equipment risk warning system provided in an embodiment of this application.

[0079] It should be noted that, Figure 4 The structure of the system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0080] like Figure 4 As shown, the system includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 402 or a program loaded from storage portion 408 into Random Access Memory (RAM) 403, such as executing the methods described in the above embodiments. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0081] The following components are connected to I / O interface 405: input section 406 including a camera, infrared sensor, etc.; output section 407 including a liquid crystal display (LCD) and speakers, etc.; storage section 408 including a hard disk, etc.; and communication section 409 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. Communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from it can be installed into storage section 408 as needed.

[0082] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the various functions defined in the present invention.

[0083] It should be noted that the computer-readable medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. The transmitted data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.

[0084] 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 the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may 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.

[0085] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the system described in the above embodiments; or it may exist independently and not assembled into the system. The storage medium carries one or more computer programs that, when executed by a processor of a system, cause the system to implement the methods provided in the above embodiments.

[0086] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0087] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0088] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0089] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A risk early warning method for intelligent security devices based on the Internet of Things, characterized in that, include: A traffic feature mapping table is pre-stored in the local storage space of the network gateway device. The traffic feature mapping table contains the correspondence between multiple network traffic statistical feature value ranges and multiple service status identifiers. Any network traffic statistical feature value in the multiple network traffic statistical feature value ranges corresponds to a unique service status identifier. Capture network data packets sent by the target IoT device through the network gateway device; Extract the header information of the network data packets and count the real-time traffic rate value within a preset time window; Traverse the traffic feature mapping table to determine the target network traffic statistical feature value range to which the real-time traffic rate value belongs; Read the service status identifier corresponding to the target network traffic statistics feature value range in the traffic feature mapping table, and mark the service status identifier as the inferred service status; Send a status verification request to the business status management server, wherein the status verification request carries the device unique identifier of the target IoT device; The authorized service status returned by the service status management server is received. The authorized service status is determined by the service status management server based on the control instruction record corresponding to the device's unique identifier. If the inferred service status belongs to a preset first service status set, then determine whether the authorized service status belongs to a preset second service status set, where the average traffic rate value of the preset first service status set is higher than the average traffic rate value of the preset second service status set. If the authorized service status belongs to the preset second service status set, a communication blocking instruction is generated for the target IoT device; According to the communication blocking instruction, the network data packets subsequently sent by the target IoT device are discarded.

2. The method according to claim 1, characterized in that, The step of extracting the header information of the network data packets and calculating the real-time traffic rate value within a preset time window specifically includes: Identify the source IP address, destination IP address, source port, and destination port of the network data packet to confirm that the network data packet belongs to the uplink data sent by the target IoT device; Read the length field in the header of the network data packet to obtain the data length of the network data packet; The current time is taken as the end time of the preset time window, and the start time of the preset time window is determined by going back a preset time. Filter out all network data packets belonging to the target IoT device captured between the start and end times of the preset time window; The total data volume is obtained by summing the lengths of all filtered network data packets, and then the total data volume is divided by the duration of the preset time window to calculate the real-time traffic rate value within the preset time window.

3. The method according to claim 1, characterized in that, Receiving the authorized service status returned by the service status management server specifically includes: Receive the response message returned by the service status management server in response to the status verification request; The response message is parsed, and status field data is extracted. The status field data is obtained by the service status management server querying the preset device shadow database based on the device's unique identifier to obtain the last legitimate control command record received by the device at the current moment, and converting according to the working mode indicated by the legitimate control command record. The status field data is determined as the authorized service status.

4. The method according to claim 1, characterized in that, The step of discarding subsequent network data packets sent by the target IoT device according to the communication blocking instruction specifically includes: If it is determined that the inferred service status belongs to a preset burst service type, the network data packets sent by the target IoT device are stored in a temporary buffer queue, and a status synchronization timer is started to suspend the execution of the communication blocking command. The preset burst service type is a predefined service mode that generates short-term high traffic during normal operation, including at least firmware online upgrade, historical video playback, alarm recording upload or log batch synchronization. When the state synchronization timer is running, a state reconfirmation request is sent to the service state management server. The state reconfirmation request is a special request with high priority used to inquire whether the sudden high traffic behavior generated by the current device is authorized. If, before the state synchronization timer expires, the updated authorized service status is received from the service status management server, and the updated authorized service status is consistent with the inferred service status, then the network data packets in the temporary buffer queue are released and normal forwarding is restored. If the state synchronization timer times out and no authorized service state consistent with the inferred service state is received, the temporary buffer queue is cleared and the communication blocking instruction is executed to discard subsequently sent network data packets.

5. The method according to claim 4, characterized in that, The step of storing the network data packets sent by the target IoT device into a temporary buffer queue specifically includes: Determine the preset maximum burst throughput corresponding to the inferred service state and the preset duration of the state synchronization timer; Based on the product of the preset maximum burst throughput and the preset duration, the dynamic capacity threshold of the temporary buffer queue for this burst is calculated. Upon receiving each network data packet sent by the target IoT device, the current data filling rate of the temporary buffer queue and the total amount of cached data are calculated in real time. If the data filling rate does not exceed the preset maximum burst throughput and the total amount of cached data does not reach the dynamic capacity threshold, then the network data packet is written into the temporary buffer queue. If the data filling rate exceeds the preset maximum burst throughput, or the total amount of cached data reaches the dynamic capacity threshold, then the target IoT device is determined to be in an abnormal traffic attack state. The steps include stopping the writing of the network data packets to the temporary buffer queue and directly executing the communication blocking instruction to discard subsequently sent network data packets.

6. The method according to claim 4, characterized in that, If, before the state synchronization timer expires, an updated authorized service status is received from the service status management server, and the updated authorized service status is consistent with the inferred service status, then the network data packets in the temporary buffer queue are released and normal forwarding is restored. The method further includes: Upon receiving the updated authorized service status that is consistent with the inferred service status, the forwarding of data in the temporary buffer queue is suspended. Based on the protocol feature model corresponding to the updated authorized service status, a packet-by-packet consistency check is performed on each network data packet cached in the temporary buffer queue. If the protocol characteristics of any network data packet in the temporary buffer queue do not match the protocol characteristic model, it is determined that the target IoT device is engaging in traffic hijacking attacks. Remove unmatched network packets from the temporary buffer queue, and only release and forward network packets that have passed verification.

7. The method according to claim 6, characterized in that, The step of performing packet-by-packet consistency verification on each network data packet cached in the temporary buffer queue based on the protocol feature model corresponding to the updated authorized service status specifically includes: The protocol feature model is parsed to obtain the offset position information of key fields and their corresponding preset value ranges. The key fields are specific byte sequences defined in the protocol feature model that can characterize the legality of the service, including at least the frame header identifier in the video stream and the opcode in the control command. Based on the offset position information, read the field value of each network data packet in the temporary buffer queue at the corresponding position; If the field value exceeds the preset value range, it is determined that the protocol characteristics of the network data packet do not match the protocol characteristic model. If the field value does not exceed the preset value range, then it is determined that the protocol characteristics of the network data packet match the protocol characteristic model.

8. A risk early warning system for intelligent security equipment based on the Internet of Things, characterized in that, The system includes: One or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the system, the system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the system, the system performs the method as described in any one of claims 1-7.

Images