An edge-computing-based Xinchuang server abnormal traffic detection system and method

Abstract

The application discloses an abnormal traffic detection system and method of a signal creation server based on edge computing, and belongs to the technical field of network security, and comprises the following steps: implanting a honeypot instruction interface module in the kernel layer of an edge signal creation server, dynamically generating and periodically updating a camouflage control port based on terminal equipment types; capturing traffic based on detection model parameters issued by a platform, determining suspicious traffic in combination with the camouflage port information, and automatically generating false response data containing a trap field; monitoring the operation of an attack party on the trap response, extracting core features of attack behaviors when tampering or targeted instructions are detected, and marking new features with a matching degree lower than a threshold as features to be warehoused; and a security management platform trains and updates detection model parameters through a federal learning algorithm and issues the detection model parameters to all edge servers. The application realizes active trapping, feature self-evolution and distributed collaborative defense, and improves the detection capability for unknown attacks.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of network security, and in particular relates to a signal creation server abnormal traffic detection system and method based on edge computing. BACKGROUND

[0002] With the popularization of edge computing technology, edge servers, as key nodes between terminal devices and core clouds, bear functions such as data forwarding, local computing and device control, and the security protection thereof directly affects the stability of the entire signal creation system. The current edge server abnormal traffic detection mainly has the following pain points: the traditional method depends on a preset rule library or traffic feature matching, and can only identify known attacks, and has weak detection capability for unknown attacks such as zero-day vulnerability attacks, and has obvious detection lag; the traffic type of the edge node is complex, and the traditional detection model based on an abnormal threshold value is easy to determine normal device interaction traffic as abnormal, or to miss attack traffic disguised as normal instructions; the existing detection scheme is developed based on a general server architecture, and is not optimized for domestic chips, operating systems and industrial control protocols under the signal creation system, and has insufficient compatibility and running efficiency; the honeypot deployed on the existing edge node is mainly static simulation, and has weak interaction, and it is difficult to induce attackers to expose deep attack behaviors, and the attack behaviors cannot be updated in combination with the detection model, and the defense capability cannot be continuously evolved. In view of the above problems, an abnormal traffic detection method that can combine the low-delay characteristics of edge computing, adapt to the signal creation environment, and has the active interaction and self-evolution capability is urgently needed. SUMMARY

[0003] In view of the deficiencies of the prior art, the application provides a signal creation server abnormal traffic detection system and method based on edge computing, a honeypot instruction interface module is implanted in the kernel layer of the edge signal creation server, a pseudo control port is dynamically generated and periodically updated based on the type of the terminal device; the traffic is captured based on the detection model parameters issued by the platform, the suspicious traffic is determined in combination with the pseudo port information, and the false response data containing the trap field is automatically generated; the operation of the attacker on the trap response is monitored, when the tampering or targeted instruction is detected, the core features of the attack behavior are extracted, and the new features with a matching degree lower than a threshold value are marked as to-be-warehoused features; the security management platform trains and updates the detection model parameters through a federated learning algorithm and issues the detection model parameters to all edge servers. The application realizes active trapping, feature self-evolution and distributed collaborative defense, and improves the detection capability for unknown attacks.

[0004] To achieve the above object, the application provides the following technical scheme:

[0005] A signal creation server abnormal traffic detection method based on edge computing, comprising:

[0006] The edge server implants a honeypot instruction interface module in the kernel layer, and the honeypot instruction interface module dynamically generates a disguised control port based on the type of terminal equipment connected to the edge node and updates the identification information of the disguised control port at a preset period;

[0007] The traffic monitoring module of the edge server captures access traffic in real time based on the detection model parameters issued by the Xinyuan security management platform, determines suspicious traffic by combining the disguised port and the identification information after filtering the authenticated legal traffic, and generates false response data containing a preset trap field automatically when detecting suspicious traffic;

[0008]

[0009] The suspicious traffic sender's operation on the trap response is monitored, and if the trap field is tampered with or targeted instructions are detected, the core features of the attack behavior are extracted, and the core features with a matching degree lower than a preset matching threshold in the known attack feature library are marked as features to be entered into the library;

[0010] The edge server encrypts and uploads the features to be entered into the library to the Xinyuan security management platform, the platform trains the detection model parameters through a federated learning algorithm, and issues the updated detection model parameters to all edge Xinyuan servers;

[0011] The honeypot instruction interface module dynamically generates a disguised control port based on the type of terminal equipment connected to the edge node, comprising:

[0012] The honeypot instruction interface module obtains the types of all connected terminal equipment by listening to the network registration signaling of the edge node or actively scanning the connected equipment, and outputs a list of connected equipment types;

[0013] Based on each type of equipment in the connected equipment type list, a pre-configured equipment protocol specification library is queried to extract the corresponding standard service port number range, and a device-port range mapping list is generated; the equipment protocol specification library defines the communication protocol followed by each type of equipment and the corresponding standard service port number range;

[0014] Local network port scanning is performed on each standard service port number range in the generated device-port range mapping list, the current occupation state of each port is detected and recorded, and a port state detail table containing all ports and their states is output; the occupation state includes two types: used or unused;

[0015] A preset port generation algorithm is called, which takes the port state detail table as input, randomly selects a port from the set of all ports marked as unused in the table, and defines the port as a disguised control port;

[0016] ​Bind the dynamically generated fake control port to the corresponding terminal device type in the device-port range mapping list to generate a port-device association record, and write or update the generated port-device association record to the local port mapping table;

[0017] The method of updating the identification information of the disguised control port according to a preset period includes:

[0018] The system sets an update cycle and starts the corresponding timer. When the timer reaches the preset update cycle, a port update event is automatically triggered. The port update event initializes a list of ports to be updated.

[0019] The system iterates through each valid record in the local port mapping table. For each valid record, the system extracts its current masquerading control port and records it as an old masquerading control port to be deactivated.

[0020] For each valid record, the system calls the port generation algorithm to generate a new fake control port for the device type, and uses the generated new fake control port to update the corresponding valid record in the local port mapping table;

[0021] The system pairs the old masquerading control ports to be deactivated with the newly generated masquerading control ports to form a port update record, and adds the port update record to the initialized list of ports to be updated;

[0022] After all valid records have been traversed and updated, the system will encapsulate the complete list of ports to be updated into a port update notification and send the port update notification to the traffic monitoring module.

[0023] The traffic monitoring module receives port update notifications and iterates through the list of ports to be updated in the port update notifications. For each port update record in the list of ports to be updated, it performs the following operations: adds the new spoofed control ports it contains to its internal real-time monitoring rule base, and removes the corresponding old spoofed control ports to be invalidated from the real-time monitoring rule base.

[0024] The traffic monitoring module of the edge IT innovation server captures access traffic in real time based on the detection model parameters issued by the IT innovation security management platform. After filtering the authenticated legitimate traffic, it combines the spoofed port and identification information to determine suspicious traffic, including:

[0025] The edge IT innovation server receives encrypted detection model parameters from the IT innovation security management platform, decrypts them locally, and loads the decrypted detection model parameters into the traffic monitoring module. The traffic monitoring module uses the decrypted detection model parameters to initialize its traffic analysis engine.

[0026] After initialization, the traffic analysis engine intercepts all incoming access traffic in real time through hook functions in the system kernel layer. The traffic monitoring module extracts the source address, destination port and protocol type of each intercepted access traffic and combines them to form the basic traffic characteristics of the access traffic.

[0027] The traffic analysis engine matches basic traffic characteristics with a whitelist of legitimate devices pre-stored locally on the edge IT innovation server. If the basic traffic characteristics completely match any record in the whitelist, the basic traffic is determined to be legitimate traffic and allowed to pass, and the current detection ends. Otherwise, the basic traffic is marked as traffic to be detected.

[0028] The traffic monitoring module of the edge IT innovation server captures access traffic in real time based on the detection model parameters issued by the IT innovation security management platform. After filtering the authenticated legitimate traffic, it determines suspicious traffic by combining the spoofed port and identification information. It also includes:

[0029] For the generated traffic to be detected, the traffic analysis engine compares its destination port with all active masquerading control ports in the local port mapping table;

[0030] When the comparison result is a port match, that is, the destination port of the traffic to be detected is a spoofed control port, the traffic to be detected is marked as suspicious traffic accessing the honeypot port;

[0031] For suspicious traffic accessing the honeypot port, the traffic analysis engine performs parallel analysis of instruction semantics and format syntax:

[0032] The instruction semantic analysis is as follows: parsing the payload content of suspicious traffic accessing the honeypot port, detecting whether it contains device control instructions, and outputting the instruction semantic analysis results;

[0033] The format syntax analysis is as follows: using the loaded detection model parameters to perform syntax analysis on the instruction format of suspicious traffic accessing the honeypot port, identifying whether there are local anomalies, and outputting the format syntax analysis results;

[0034] The traffic analysis engine makes a comprehensive judgment based on the semantic analysis results and the format syntax analysis results of the instructions: if the traffic to be detected meets any two or more of the following three conditions: accessing the honeypot instruction interface, carrying device control instructions, or having local anomalies in the instruction format, then the traffic to be detected is officially marked as high-risk suspicious traffic. Once it is determined to be high-risk suspicious traffic, the traffic monitoring module immediately triggers a false response.

[0035] Specifically, the automatic generation of false response data containing preset trap fields when suspicious traffic is detected includes:

[0036] Once the traffic to be detected is identified as high-risk or suspicious, the system parses the protocol header of the high-risk or suspicious traffic to identify the type of device protocol it uses.

[0037] Based on the parsed device protocol type, a preset trap field library is queried and a trap field template corresponding to the device protocol type is selected from it; the trap field template consists of strings or code segments that have no actual device control meaning but strictly conform to the syntax and structure of the device protocol specification;

[0038] The system extracts the session 5-tuple information of the high-risk and suspicious traffic, and associates the session 5-tuple information with the device protocol type to form complete session context information; the session 5-tuple information includes source IP, destination IP, source port, destination port, and protocol;

[0039] Based on the generated session context information, a globally unique trap identifier is generated by combining the current timestamp with a hash algorithm; the trap identifier is generated by combining the timestamp, the source IP address hash value, and the device protocol type.

[0040] The selected trap field templates and trap identifiers are combined and populated to construct a complete fake response payload;

[0041] Based on the identified device protocol type and the bound session 5-tuple information, a simulated protocol header conforming to the protocol specification is constructed; the content of the simulated protocol header simulates a normal, legitimate device response.

[0042] The generated simulated protocol header is encapsulated with the constructed fake response payload to assemble the final fake response data packet;

[0043] The generated trap identifier is bound to the session 5-tuple information, and this binding relationship is recorded in the trap monitoring registry.

[0044] The assembled fake response packet is sent to the source address of the high-risk, suspicious traffic, and a response monitoring thread is started for this session based on the records in the trap monitoring registry.

[0045] Specifically, the monitoring of suspicious traffic senders' responses to traps, if detecting tampering of the trap field or targeted instructions, extracts the core features of the attack behavior and marks core features with a matching degree lower than a preset matching degree threshold in the known attack feature database as features to be added to the database, including:

[0046] After the fake response packet is successfully sent, the system immediately activates the response monitoring thread that was pre-created for the session. The response monitoring thread reads the corresponding trap monitoring task from the trap monitoring registry, obtains the trap identifier, target IP address and device protocol type contained therein, and integrates them into the attack session context.

[0047] The response monitoring thread captures all network packets from the target IP address in the attack session context, records the arrival time of the first network packet as the trap response reception time, and arranges all captured network packets in chronological order to form the attacker's operation sequence.

[0048] The system performs deep analysis on the attacker's operation sequence to detect whether there are malicious operations; the malicious operations include tampering behavior and targeted instructions; the tampering behavior refers to whether the attacker has modified or replayed the previously sent trap field; the targeted instructions refer to whether the attacker has sent new control instructions constructed based on the trap response content;

[0049] Once any malicious operation is identified, the behavioral feature quantification process is triggered; the behavioral feature quantification process takes the attacker's operation sequence and attack session context as input and performs quantitative analysis.

[0050] In the behavioral feature quantification process, the operations of calculating behavioral indicators and encapsulating feature vectors are performed. The process of calculating behavioral indicators is as follows: using feature extraction algorithms to analyze the attacker's operation sequence, and calculating three behavioral indicators: operation frequency deviation, instruction entropy value, and protocol violation index. The process of encapsulating feature vectors is as follows: combining the calculated three behavioral indicators with the device protocol type and attacker IP address in the attack session context, adding a timestamp, and encapsulating them together into a standard core feature vector.

[0051] The system will calculate the similarity between the generated core feature vector and all features in the locally stored known attack feature library. If the calculated highest similarity is lower than the preset matching threshold, the feature is determined to be a newly emerging attack mode, and the core feature vector is officially marked as a feature to be added to the library.

[0052] Assign a unique feature ID to the tagged feature to be added to the database, and encapsulate the feature ID, feature extraction time, and summary information of associated high-risk and suspicious traffic into a complete feature record to be added to the database.

[0053] Specifically, the method further includes:

[0054] Set up an anomaly alarm mechanism on the edge IT innovation server; when high-frequency suspicious traffic or model verification failure is detected, alarm information is automatically generated and reported to the platform; the platform adjusts the federated learning training frequency or issues emergency update parameters based on the alarm information.

[0055] An abnormal traffic detection system for domestically developed servers based on edge computing includes: a honeypot command interface module, a traffic monitoring module, a fake response generation module, an attack behavior analysis module, a feature management module, and a model management platform;

[0056] The honeypot instruction interface module is used to actively construct a dynamically changing decoy environment at the kernel layer to attract and expose attack behaviors.

[0057] The traffic monitoring module is used to analyze network traffic in real time and identify attack traffic;

[0058] The fake response generation module is used to actively deceive suspicious traffic, inducing attackers to expose their attack intentions and behavioral characteristics;

[0059] The attack behavior analysis module is used to monitor the attacker's interaction with the trap and extract attack characteristics from it.

[0060] The feature management module is used for localized processing of attack features;

[0061] The model management platform is used to aggregate threat intelligence from various edge nodes, collaboratively train and distribute global detection models.

[0062] Compared with the prior art, the beneficial effects of the present invention are:

[0063] This invention proposes an abnormal traffic detection method for domestic IT servers based on edge computing. By using dynamic honeypot interfaces and trap fields to induce attacks, it transforms traditional passive detection into active identification, improving the detection rate of unknown attacks and shortening the attack identification delay. An attack is only identified when the attacker performs targeted operations on the trap fields, effectively eliminating false triggers from normal devices and reducing the false alarm rate. Through an edge-platform collaborative model iteration mechanism, the detection model can adapt to new attack methods in real time without the need for manual updates to the rule base, thus reducing operation and maintenance costs.

[0064] This invention proposes an abnormal traffic detection method for domestic IT servers based on edge computing. By dynamically deploying a fake control port at the kernel layer and actively sending false responses, a highly efficient proactive trapping and defense system is constructed. This method dynamically generates fake ports based on the terminal device type and periodically updates the identification information, making the attack surface constantly changing and difficult to detect. By combining the collaborative analysis of the traffic monitoring module and the honeypot interface, suspicious traffic accessing the fake port and carrying abnormal commands can be accurately identified. When preset conditions are triggered, the system automatically generates trap response data that conforms to the protocol specifications, realizing proactive trapping and in-depth monitoring of attack behavior.

[0065] This invention proposes an abnormal traffic detection system for domestically developed IT servers based on edge computing. By extracting the operational characteristics of attackers' responses to traps, it intelligently identifies unknown attack patterns. A federated learning mechanism is used to encrypt and upload the unknown attack characteristics discovered by edge nodes to the security management platform. After multi-node collaborative training, updated detection model parameters are generated and distributed globally. This architecture not only protects the data privacy of each edge node but also achieves the collaborative evolution of defense capabilities, improving the detection efficiency of new unknown attacks and the overall protection level of the system. Attached Figure Description

[0066] Figure 1 This is a schematic diagram of an abnormal traffic detection method for domestic IT innovation servers based on edge computing according to the present invention;

[0067] Figure 2 This is an architecture diagram of an abnormal traffic detection system for domestic IT servers based on edge computing, according to the present invention. Detailed Implementation

[0068] Example 1:

[0069] Please see Figure 1 The present invention provides an embodiment of an abnormal traffic detection method for domestic IT innovation servers based on edge computing. The method includes steps S1 to S5:

[0070] S1: The edge IT innovation server has a honeypot command interface module implanted in the kernel layer. The honeypot command interface module dynamically generates a fake control port based on the type of terminal device connected to the edge node, and updates the identification information of the fake control port according to a preset period.

[0071] S2: The traffic monitoring module of the edge IT innovation server captures access traffic in real time based on the detection model parameters issued by the IT innovation security management platform. After filtering the authenticated legitimate traffic, it combines the spoofed port and identification information to determine suspicious traffic.

[0072] S3: When suspicious traffic is detected, automatically generate fake response data containing preset trap fields;

[0073] The trap field has no actual device control significance but conforms to the device protocol specification and can only be identified by the detection system.

[0074] S4: Monitor the actions of suspicious traffic senders in response to traps. If the trap field is tampered with or targeted instructions are detected, extract the core features of the attack behavior and mark the core features that match the known attack feature library with a lower than the preset matching threshold as features to be added to the library.

[0075] S5: The edge server encrypts and uploads the features to be added to the database to the domestic IT innovation security management platform. The platform trains the detection model parameters through federated learning algorithm and distributes the updated detection model parameters to all edge domestic IT innovation servers.

[0076] Furthermore, the specific steps for encrypting and uploading the features to be added to the database to the domestic IT security management platform include:

[0077] (1) The edge server obtains the marked features to be added to the database and encapsulates them into a complete feature data package to be uploaded; the features to be added to the database include core feature vectors, unique feature IDs and associated high-risk and suspicious traffic metadata;

[0078] (2) The edge server retrieves the pre-stored public key of the domestic IT security management platform. The public key of the domestic IT security management platform is published and distributed to each edge server by the platform on a regular basis. The server uses the public key of the domestic IT security management platform to perform asymmetric encryption operation on the generated feature data packet to be uploaded, and generates an encrypted feature payload in ciphertext form. The asymmetric encryption is the prior art in this field and is not an inventive solution of this application. It will not be described in detail here.

[0079] (3) The edge server uses its own private key to perform digital signature calculation on the generated encrypted feature payload to generate a unique digital signature. This digital signature is used to verify data integrity and confirm data source during transmission, and to prevent tampering and spoofing. The calculation of the digital signature is the prior art in this field and is not an inventive solution of this application. It will not be described in detail here.

[0080] (4) The edge server initiates a network connection request to the information technology innovation security management platform. The two parties complete two-way identity authentication by exchanging digital certificates. After authentication, they negotiate encryption parameters and establish a secure encrypted channel protected by the transport layer security protocol.

[0081] (5) The edge server uploads the encrypted feature payload and digital signature to the domestic IT innovation security management platform through the established secure encrypted channel. After receiving the data, the domestic IT innovation security management platform verifies the signature and decrypts it. After successful processing, it returns a receipt to the edge server. The receipt contains the unique feature ID of the corresponding feature.

[0082] (6) After receiving the successful receipt, the edge server updates the status of the corresponding feature record to be uploaded to the local feature database according to the unique feature ID in the receipt. This status update indicates that the feature upload task has been successfully completed.

[0083] Furthermore, the specific steps the platform takes to train the detection model parameters using the federated learning algorithm include:

[0084] (1) After receiving the encrypted feature payload and digital signature uploaded by the edge server, the IT innovation security management platform uses its own private key to decrypt the encrypted feature payload and successfully restore the feature data packet to be uploaded. Then, the IT innovation security management platform uses the public key corresponding to the sending edge server to verify the attached digital signature to ensure that the data has not been tampered with during the transmission process.

[0085] (2) After the security verification is passed, the information technology innovation security management platform will store the feature data to be uploaded from the feature data packet into a centralized, temporary global feature buffer pool. This buffer pool is used to aggregate newly discovered attack features from all edge servers.

[0086] (3) The IT innovation security management platform continuously monitors the status of the global feature buffer pool. When the number of new features accumulated in the pool reaches a preset capacity threshold or a preset fixed training time window, the IT innovation security management platform automatically triggers a new round of federated learning training cycle.

[0087] (4) At the start of the triggered federated learning training cycle, the information technology innovation security management platform obtains the latest version of the global detection model currently in production environment from the model repository and extracts its model parameters as the initial global model parameters for this round of federated learning;

[0088] (5) Randomly select a candidate set from the registered edge server nodes, encrypt the initial global model parameters, and securely send them to these selected edge servers;

[0089] (6) Each selected edge server uses its own stored historical traffic feature dataset to train the received initial global model parameters locally. After training, each server calculates the update amount of the model parameters, i.e., the local model gradient.

[0090] (7) Each edge server encrypts the calculated local model gradient and sends it back to the IT innovation security management platform. After receiving the gradients of all participating nodes, the IT innovation security management platform uses a clustering algorithm to integrate all local model gradients to obtain the global gradient update. The clustering algorithm is existing technology in this field and is not an inventive solution of this application. It will not be described in detail here.

[0091] (8) The information technology innovation security management platform uses the global gradient update amount to iteratively optimize the initial global model parameters, thereby generating the updated global model parameters;

[0092] (9) The IT innovation security management platform will evaluate the updated global model parameters on an isolated, accurately labeled verification dataset to ensure that the detection accuracy of the new model is improved compared to the old model and that there is no performance degradation.

[0093] (10) After the performance verification is passed, the information technology innovation security management platform assigns a new version number to the updated global model parameters and calculates its hash value. Then, it packages and generates a formal new version detection model parameter package. Finally, it stores this package in the model repository, overwrites the old version, and prepares to distribute it to the whole network. The hash value calculation adopts a hash algorithm. The hash algorithm is the existing technology in this field and is not an inventive solution of this application. It will not be described in detail here.

[0094] Furthermore, the specific steps for distributing the updated detection model parameters to all edge IT innovation servers include:

[0095] (1) The IT innovation security management platform retrieves the prepared new version detection model parameter package from the model repository. For registered edge servers with different hardware architectures or software versions, the platform generates corresponding differential update packages. These packages contain only the difference data between the old and new versions to minimize the amount of data transmitted. Subsequently, the IT innovation security management platform uses its own private key to digitally sign each differential update package and generate a corresponding digital signature to ensure the integrity of the package content and the authenticity of its source.

[0096] (2) The IT innovation security management platform broadcasts all signed differential update packages and their digital signatures to all registered edge IT innovation servers on the entire network through the built-in content distribution network. The broadcast information includes the target version identifier. The traffic monitoring module of each edge server listens to the broadcast channel and only receives and downloads the differential update packages and corresponding digital signatures that match its own configuration. The broadcast process is the existing technology in this field and is not an inventive solution of this application, so it will not be described in detail here.

[0097] (3) After receiving the complete differential update packet, the edge server uses the preset platform public key to verify its digital signature, confirming that the data packet has not been tampered with and that the source is trustworthy. After the verification is passed, the server decrypts the differential update packet and uses the differential update algorithm to merge the difference data in the differential update packet with the existing old version detection model parameters to restore the complete new version detection model parameters. The differential update algorithm is the prior art in this field and is not an inventive solution of this application. It will not be described in detail here.

[0098] (4) Load the reconstructed new version of the detection model parameters into the running traffic analysis engine and replace the original, outdated detection logic.

[0099] In summary, the core of this application lies in combining the localization advantages of edge computing, honeypot trapping mechanisms, and the collaborative optimization capabilities of federated learning to construct an abnormal traffic detection system based on trapping, identification, verification, and iteration. Edge IT servers, located close to terminal devices, can accurately simulate the terminal environment by dynamically generating spoofed ports, enhancing the ability to trap targeted attacks. Traffic filtering and suspicious behavior determination are achieved based on the detection model parameters of the IT security management platform, ensuring the uniformity of the detection benchmark. The design of the trap field not only conforms to protocol specifications to confuse attackers but also achieves secondary verification of attack behavior through unique identification. Federated learning resolves the contradiction between edge node data privacy protection and global model optimization, enabling the detection capability to continuously evolve with updated attack characteristics. In principle, this aligns with the precise and dynamic detection requirements of IT servers for abnormal traffic in edge computing scenarios. In terms of implementation logic, the detection environment is pre-built by embedding a honeypot instruction interface module in the kernel layer, and the dynamically updated spoofed ports provide bait for subsequent identification. Then, the traffic monitoring module performs traffic filtering and suspicious judgment based on the parameters issued by the platform to achieve preliminary screening of abnormal traffic. When suspicious traffic appears, a fake response containing a trap field is generated, and the attacker's operation on the trap is used to complete the deep verification of the attack behavior. Subsequently, the core attack features are extracted and unknown features are filtered out to solve the problem of identifying new attack patterns. Finally, global model updates are achieved through encrypted upload and federated learning, and the updates are distributed to edge nodes to form a closed-loop logic from edge local detection to central global optimization, which fully covers the entire process of abnormal traffic detection from environment preparation, identification and verification to continuous optimization.

[0100] The method further includes:

[0101] Set up an anomaly alarm mechanism on the edge IT innovation server; when high-frequency suspicious traffic or model verification failure is detected, alarm information is automatically generated and reported to the platform; the platform adjusts the federated learning training frequency or issues emergency update parameters based on the alarm information.

[0102] The honeypot command interface module dynamically generates a fake control port based on the type of terminal device connected to the edge node, including:

[0103] A1: The honeypot command interface module obtains the types of all currently connected terminal devices by listening to the network registration signaling of edge nodes or actively scanning connected devices, and outputs a list of connected device types;

[0104] A2: Based on each device type in the list of connected device types, query the pre-configured device protocol specification library, extract the corresponding standard service port number range, and generate a device-port range mapping list; the device protocol specification library defines the communication protocol followed by each device type and its corresponding standard service port number range;

[0105] Furthermore, the specific steps of A2 include:

[0106] (1) The system receives the list of connected device types and creates a blank device port range mapping list;

[0107] (2) The system retrieves a device type to be processed from the list of connected device types and sends it to the pre-configured device protocol specification library for querying;

[0108] (3) The system performs an exact match query in the device protocol specification library using the currently retrieved device type to be processed. After the query is successful, the system extracts the range of standard service port numbers bound to the device type from the device protocol specification library.

[0109] (4) The system combines the successfully queried device type with its corresponding standard service port number range to form a complete mapping entry. Then, this mapping entry is added as a new record to the device port range mapping list.

[0110] (5) After the addition is completed, the system performs a status check to see if all device types in the list of connected device types have been processed and added to the mapping list;

[0111] If there are still unprocessed device types in the list, the system will automatically return to the beginning of the core loop and continue processing the next device type until all device types in the list have been processed.

[0112] (6) When the system confirms that all device types in the connected device type list have been processed, that is, the list has been traversed, the final output is a fully populated device port range mapping list, and the device port range mapping list accurately records the standard port range that each device type should use in the current network environment.

[0113] A3: Perform a local network port scan on each standard service port number range in the generated device-port range mapping list, detect and record the current occupancy status of each port, and output a detailed port status table containing all ports and their statuses; the occupancy status includes two types: used and unused.

[0114] Furthermore, the specific steps in A3 include:

[0115] (1) The system receives the device-port range mapping list, creates a blank structured data container, and defines it as a port status detail table to receive all the scan results of this process;

[0116] (2) The system enters the main loop and extracts one unprocessed device record from the device-port range mapping list in sequence. The device record contains the device type and its corresponding standard service port number range. The system parses this port range and generates a set of ports to be scanned containing all independent port numbers in the range.

[0117] (3) The system enters a nested sub-loop, obtains the next port number to be detected from the set of ports to be scanned, and initiates a precise connection probe to the port to be detected on the local host through the kernel network stack. The system listens for network response within the set timeout period and determines the port occupancy status based on whether a valid response is received: if a response is received, it is marked as used; if no response is received or a rejection signal is received, it is marked as unused.

[0118] (4) Combine the currently detected port number with its determined occupancy status into a standardized port status record, and then write the standardized port status record as a new entry into the port status details table.

[0119] (5) After processing a single port, the system checks whether there are any remaining undetected ports in the current device's set of ports to be scanned. If there are, it immediately returns to the starting point of the nested sub-loop to continue processing; if all ports of the current device have been processed, it exits the nested sub-loop.

[0120] (6) The system then checks whether there are any unprocessed device records in the device-port range mapping list. If there are, it returns to the starting point of the main processing loop to continue processing the next device record; if all device records have been processed, the main loop is terminated.

[0121] (7) The system outputs a fully populated port status table, which accurately records the real-time occupancy status of all ports in the mapping list in the current network environment.

[0122] A4: Call the preset port generation algorithm. The port generation algorithm takes the port status details table as input, randomly selects a port from all the ports marked as unused in its internal set, and defines it as the fake control port.

[0123] A5: Bind the dynamically generated fake control port to the corresponding terminal device type in the device-port range mapping list, generate a port-device association record, and write or update the generated port-device association record to the local port mapping table.

[0124] The method of updating the identification information of the disguised control port according to a preset period includes:

[0125] B1: The system sets an update cycle and starts the corresponding timer. When the timer reaches the preset update cycle, a port update event is automatically triggered. The port update event initializes a list of ports to be updated.

[0126] B2: The system iterates through each valid record in the local port mapping table. For each valid record, the system extracts its current masquerading control port and records it as an old masquerading control port to be deactivated.

[0127] B3: For each valid record, the system calls the port generation algorithm to generate a new fake control port for the device type, and uses the generated new fake control port to update the corresponding valid record in the local port mapping table. The port generation algorithm is as described in A4.

[0128] B4: The system pairs the old masquerading control ports to be deactivated with the newly generated masquerading control ports to form a port update record, and adds the port update record to the initialized list of ports to be updated;

[0129] The port update record contains three basic fields: the old masquerading control port information field, the new masquerading control port information field, and the operation timestamp field.

[0130] B5: After all valid records have been traversed and updated, the system will encapsulate the complete list of ports to be updated into a port update notification and send the port update notification to the traffic monitoring module.

[0131] Furthermore, the specific steps of B5 include:

[0132] (1) The system verifies the integrity and readiness of the port list to be updated, confirms that all valid records have been traversed and processed, checks the end identifier of the port list to be updated, verifies the consistency between the update time of the last record and the current update cycle, and ensures that the list data is in an encapsulated state.

[0133] (2) Based on the confirmed list of ports to be updated, create a basic framework for port update notification. The basic framework for port update notification consists of a notification header and a notification body. The header reserves metadata storage space, and the body is designed as a container for the list data.

[0134] (3) The system extracts the key attributes of the port list to be updated, including the total number of records in the list, the final update timestamp and the list checksum, and combines the attributes with the update cycle identifier to form a complete set of metadata, and fills it into the notification header;

[0135] (4) The system migrates all records in the port list to be updated to the notification subject in sequence to obtain the overall notification data. During the migration process, data format conversion is performed to ensure that each port update record conforms to the transmission protocol specification, while maintaining the original data order and correlation.

[0136] (5) The system performs digital signature calculation on the overall notification data, adds a data serialization identifier, sets the notification validity period, and generates the final transmittable port update notification data packet;

[0137] (6) The system detects the communication link status of the traffic monitoring module. If the link is not activated, the system initiates a secure connection request, completes two-way authentication and encryption parameter negotiation, and establishes a secure transmission channel.

[0138] (7) The system sends port update notification data packets through the established secure transmission channel. The transmission adopts an acknowledgment and retransmission mechanism. The system continuously monitors the transmission status and automatically triggers the retransmission process in case of timeout until a successful reception response is received.

[0139] (8) The system receives the reception confirmation signal returned by the traffic monitoring module, updates the local port update task status to delivered, and records the exact delivery timestamp and transmission session identifier.

[0140] (9) After the confirmation notification is successfully delivered, the system will transfer the transmitted port list data to the historical archive, clear the current list storage space, and initialize the list data structure.

[0141] B6: The traffic monitoring module receives port update notifications and iterates through the list of ports to be updated in the port update notifications. For each port update record in the list of ports to be updated, it performs the following operations: adds the new spoofed control ports it contains to its internal real-time monitoring rule base, and removes the corresponding old spoofed control ports to be deactivated from the real-time monitoring rule base.

[0142] It should be noted that in the process of updating the identification information of the fake port according to the preset period, the periodic event is taken as the starting point. The existing configuration is traversed to identify the objects that need to be updated. Then, the operations of recording the old port, generating the new port, and updating the mapping table are executed in sequence. All changes are summarized and archived. Finally, the change set is synchronized to the detection module through the notification mechanism to ensure that its monitoring rules are consistent with the latest configuration, forming a complete automated closed loop of planning-execution-recording-synchronization.

[0143] The traffic monitoring module of the edge IT innovation server captures access traffic in real time based on the detection model parameters issued by the IT innovation security management platform. After filtering the authenticated legitimate traffic, it combines the spoofed port and identification information to determine suspicious traffic, including:

[0144] C1: The edge IT innovation server receives encrypted detection model parameters from the IT innovation security management platform, decrypts them locally, and loads the decrypted detection model parameters into the traffic monitoring module. The traffic monitoring module uses the decrypted detection model parameters to initialize its traffic analysis engine.

[0145] Furthermore, the specific steps of C1 include:

[0146] (1) The edge IT innovation server starts the detection model parameter receiving and loading process, including: receiving encrypted data packets from the IT innovation security management platform through a secure communication link, wherein the encrypted data packets contain detection model parameters and metadata encrypted with the server's public key; the server calls the local cryptography service module, uses the paired private key to decrypt the encrypted data packets, and generates decrypted data blocks; the system performs integrity verification and signature verification on the decrypted data blocks, confirms that the data is not damaged or tampered with, and outputs the verified valid parameter data;

[0147] (2) The system parses and verifies the valid parameter data, and extracts the set of structured detection model parameters, including core configuration items such as feature extraction weights, classifier thresholds and protocol analysis rules;

[0148] (3) After receiving the set of parameters of the structured detection model, the flow monitoring module pauses the data processing pipeline of the current flow analysis engine, saves the running status and clears the temporary buffer.

[0149] (4) The system loads the new detection model parameters into the dedicated storage area of ​​the traffic analysis engine according to the predetermined memory mapping structure. The loading process adopts a transactional write mechanism to ensure the atomicity of parameter updates and prevent system inconsistency caused by partial updates.

[0150] Among them, the transactional write mechanism refers to writing the calculation results before the most recently successfully saved checkpoint to the external system.

[0151] (5) The traffic analysis engine reinitializes its internal state machine and analysis algorithm based on the new detection model parameters, rebuilds the feature extraction pipeline and calibrates the detection threshold. The system injects standard test traffic samples to verify the detection accuracy and processing performance of the engine under the new detection model parameters. It outputs a normal engine instance. After the verification is passed, the traffic analysis engine resumes full traffic processing service. The system records the parameter update timestamp and version identifier to complete the complete closed loop from parameter reception to service recovery, making the traffic analysis engine ready for real-time traffic analysis.

[0152] C2: After initialization, the traffic analysis engine intercepts all incoming access traffic in real time through hook functions in the system kernel layer. The traffic monitoring module extracts the source address, destination port and protocol type of each intercepted access traffic and combines them to form the basic traffic characteristics of the access traffic. The hook functions are existing technology in this field and are not an inventive solution of this application, so they will not be described in detail here.

[0153] C3: The traffic analysis engine matches the basic traffic characteristics with the legal device whitelist pre-stored locally on the edge IT innovation server. If the basic traffic characteristics completely match any record in the whitelist, the basic traffic is determined to be legal traffic and allowed to pass and the current detection ends. Otherwise, the basic traffic is marked as traffic to be detected.

[0154] Furthermore, the specific steps of C3 include:

[0155] (1) The traffic analysis engine obtains basic traffic characteristics, which include three core characteristics: source address, destination port and protocol type. At the same time, the traffic analysis engine loads a locally pre-stored legitimate device whitelist database. The legitimate device whitelist is a structured database indexed by device identifiers, which records the legitimate network characteristics of all authorized devices.

[0156] (2) The traffic analysis engine initializes the legitimate device whitelist query cursor and reads the first whitelist record from the legitimate device whitelist. Each whitelist record contains predefined standard fields such as device identifier, authorized port range and license protocol type;

[0157] (3) The traffic analysis engine will precisely match the source address field of the basic traffic characteristics with the device identifier in the current whitelist record. If the match is successful, it will continue to verify whether the destination port is within the set of permitted ports in the record. If the port verification is successful, it will check whether the traffic protocol type is included in the list of allowed protocol types.

[0158] (4) Generate a matching status identifier based on the feature matching execution result: when all three feature fields pass the verification, it is marked as a complete match; if any feature verification fails, it is marked as a single-item matching failure.

[0159] (5) When a single matching failure occurs, the system moves the whitelist query cursor of the legitimate device to the next whitelist record and repeats the feature matching until a complete matching status is obtained or all whitelist records are traversed.

[0160] (6) If any whitelist record is found to be in a complete match state during the traversal, the system immediately generates a valid traffic adjudication result; if a complete match state is not obtained after the traversal is completed, a traffic adjudication result to be detected is generated.

[0161] (7) For the adjudication results of legitimate traffic, the engine performs a fast release operation and terminates the current detection pipeline; for the adjudication results of traffic to be detected, the engine adds a deep detection identifier and forwards the traffic to the subsequent analysis module;

[0162] (8) The traffic analysis engine updates real-time monitoring metrics and records the complete timeline, key feature summary, adjudication conclusion and handling action of this match in the audit log.

[0163] C4: For the generated traffic to be detected, the traffic analysis engine compares its destination port with all active masquerading control ports in the local port mapping table;

[0164] When the comparison result is a port match, that is, the destination port of the traffic to be detected is a spoofed control port, the traffic to be detected is marked as suspicious traffic accessing the honeypot port;

[0165] C5: For suspicious traffic accessing the honeypot port, the traffic analysis engine performs parallel analysis of instruction semantics and format syntax.

[0166] The instruction semantic analysis is as follows: parsing the payload content of suspicious traffic accessing the honeypot port, detecting whether it contains device control instructions, and outputting the instruction semantic analysis results;

[0167] The format syntax analysis is as follows: using the loaded detection model parameters to perform syntax analysis on the instruction format of suspicious traffic accessing the honeypot port, identifying whether there are local anomalies, and outputting the format syntax analysis results;

[0168] Furthermore, the process of format syntax analysis includes:

[0169] (1) The parser first obtains the syntax rule base and the abnormal pattern base from the loaded detection model parameters, which include protocol syntax specifications, field structure definitions and abnormal pattern features. At the same time, the parser receives suspicious traffic data packets that access the honeypot port.

[0170] (2) The parser parses the instruction sequence from the payload content according to the protocol type of the suspicious traffic data packet, performs layered processing on the instruction sequence according to the protocol specification, separates the core components such as instruction header, instruction body and check field, and generates a structured instruction field sequence.

[0171] (3) The parser uses the specifications in the syntax rule base to compare the instruction field sequence item by item: first, it verifies the conformity of the instruction header format, including the accuracy of field length, identifier position and type identifier; then it checks the conformity of the instruction body structure, including the correctness of field order, delimiter usage and nesting level, outputs the syntax matching results, and identifies the compliant and non-compliant fields.

[0172] (4) Based on the matching of syntax rules, the parser performs deep semantic analysis on the instruction field, detects the rationality of the field value, including the validity of the numerical range, the legality of the enumeration value and the standardization of the string encoding, verifies the logical relationship between fields, checks whether there are contradictory parameter combinations, and outputs the semantic check results, including details of semantic anomalies.

[0173] (5) The parser uses the feature patterns in the exception pattern library to perform local anomaly scanning on the instruction format, detects suspicious features such as unconventional field combinations, abnormal field intervals, and redundant padding data, and evaluates the severity of each abnormal feature through a weighted scoring mechanism, outputting a list of abnormal features and their corresponding scores.

[0174] (6) The parser integrates the grammar matching results, semantic inspection results and abnormal feature list to calculate the overall abnormal confidence score. The score is based on the number of grammar violations, the severity of semantic abnormalities and the density of abnormal pattern matching. The pre-trained evaluation model generates a quantified abnormal probability and outputs the abnormal confidence score as the core indicator.

[0175] Furthermore, the evaluation model is constructed based on a logistic regression model, which is existing technology in this field and is not an inventive solution of this application, so it will not be described in detail here.

[0176] (7) The parser integrates all intermediate results and encapsulates them into format parsing results. The intermediate results include syntax matching results, semantic check results, anomaly feature list and anomaly confidence score. The format parsing results include basic compliance status, detailed anomaly entries, comprehensive anomaly score and anomaly location information.

[0177] C6: The traffic analysis engine comprehensively judges the results of instruction semantic analysis and format syntax analysis. If the traffic to be detected meets any two or more of the following three conditions: accessing the honeypot instruction interface, carrying device control instructions, or having local anomalies in the instruction format, then the traffic to be detected will be officially marked as high-risk suspicious traffic. Once it is determined to be high-risk suspicious traffic, the traffic monitoring module will immediately trigger a false response.

[0178] It is important to note that this process begins with the synchronization of the core detection model, followed by the collection and initial screening of all traffic, i.e., whitelist filtering. Then, suspicious objects are compared by port and analyzed by command and format. Finally, threats are determined and a response is initiated through a comprehensive decision based on multiple conditions. The entire process, from data updates to decision-making on specific data packets, forms a complete detection system.

[0179] When suspicious traffic is detected, the system automatically generates false response data containing preset trap fields, including:

[0180] D1: When the traffic to be detected is determined to be high-risk and suspicious, the system parses the protocol header of the high-risk and suspicious traffic to identify the type of device protocol it uses.

[0181] D2: Based on the parsed device protocol type, query the preset trap field library and select the trap field template corresponding to the device protocol type; the trap field template consists of strings or code segments that have no actual device control meaning but strictly conform to the syntax and structure of the device protocol specification;

[0182] D3: The system extracts the session 5-tuple information of the high-risk suspicious traffic and associates the session 5-tuple information with the device protocol type to form complete session context information; the session 5-tuple information is source IP, destination IP, source port, destination port, and protocol;

[0183] The session context information includes a specific encoding of the timestamp and hash fragments of protocol characteristics, which are used to enhance the uniqueness of the payload and subsequent tracing capabilities.

[0184] D4: Based on the formed session context information, a globally unique trap identifier is generated by combining the current timestamp with a hash algorithm; the trap identifier is generated by combining the timestamp, the source IP address hash value and the device protocol type. The hash algorithm is existing technology in this field and is not an inventive solution of this application, so it will not be described in detail here.

[0185] D5: Combine and populate the selected trap field template with the trap identifier to construct a complete fake response payload;

[0186] Furthermore, the specific steps of D5 include:

[0187] (1) The system receives the trap field template and performs structured parsing on it. The parsing process identifies the fixed content blocks and variable insertion points in the trap field template. The fixed content blocks contain protocol standard fields and predefined misleading data. The variable insertion points are protocol compliance positions reserved specifically for dynamic data.

[0188] (2) The system performs protocol compatibility processing on the globally unique trap identifier, including: converting the identifier in format according to the current protocol specification, generating adapted identifier data that meets the requirements of the protocol field type, and ensuring that it can fully match the data type and length limit of the target protocol. The format conversion includes hexadecimal encoding, Base64 encoding or binary format conversion.

[0189] (3) According to the hierarchical structure of the network protocol stack, the data filling operation is performed starting from the application layer, including: inserting formatted identifier data into the instruction response field position of the application layer template, while maintaining the integrity and correctness of the necessary fields of the protocol, and ensuring that the original protocol semantic structure is not destroyed during the filling process.

[0190] (4) Within the extended field area permitted by the protocol, the system embeds processed session context information;

[0191] (5) After data filling is completed, the system performs a comprehensive protocol compliance check on the constructed payload, verifying the integrity of fields, the correctness of data format, and the compliance of length specifications, to ensure that the generated payload fully complies with standard specifications at the protocol level.

[0192] (6) While maintaining protocol compliance, implement lightweight feature obfuscation on the payload by means of adjusting field order, randomly adding filler and mixing encoding methods, etc., to increase the difficulty of analysis for attackers while maintaining protocol functionality;

[0193] (7) According to the algorithm specified in the protocol, recalculate the checksum or message authentication code of the entire payload, update the corresponding field in the payload with the new check value, and ensure that the integrity of the payload can be verified during the transmission process;

[0194] (8) The fully processed payload is finally encapsulated to generate a complete false response payload that meets the transmission requirements. The complete false response payload not only meets the protocol specification requirements, but also contains complete tracking identifiers and obfuscation features.

[0195] D6: Based on the identified device protocol type and the bound session 5-tuple information, construct a simulated protocol header that conforms to the protocol specification; the content of the simulated protocol header simulates a normal, legitimate device response;

[0196] Furthermore, the specific steps of D6 include:

[0197] (1) The system extracts the corresponding protocol standard definition from the protocol specification library based on the identified device protocol type;

[0198] (2) The system receives the bound session 5-tuple information, performs logical conversion of address and port, swaps the source and destination addresses in the original session, and interchanges the source and destination ports to generate a 5-tuple mapping result that conforms to the response logic, which serves as the basic network identifier for constructing the protocol packet header.

[0199] (3) Based on the protocol standard definition, the system fills in the basic fields of the packet header: sets fixed attributes such as protocol version identifier, packet header length indicator, and service type parameter; configures the corresponding control flag bits according to the protocol type; sets reasonable life cycle parameters to ensure the compliance of network transmission;

[0200] (4) The system generates corresponding status indication information according to the protocol type: for connection-oriented protocols, a reasonable sequence number mechanism is created; for application layer protocols, the correct status response code is configured; the interaction state of normal devices is simulated to ensure the integrity of the protocol process;

[0201] (5) Analyze the communication characteristics of legitimate devices, reproduce these characteristic parameters in the protocol header, configure flow control parameters such as window size and data packet length limit that conform to the device characteristics; embed characteristic data such as device type identifier and version information to enhance the authenticity of the protocol header;

[0202] (6) Conduct a comprehensive compliance check on the constructed protocol header, verify whether the value range of each field meets the standard, whether the logical relationship between the fields is reasonable, and whether the length constraint meets the requirements, so as to ensure the technical standardization of the protocol header;

[0203] (7) The verified protocol headers of each layer are encapsulated in the order of the network protocol stack to generate the final simulated protocol header. The simulated protocol header is highly consistent with the response of the legitimate device in terms of technical specifications and characteristics. The network protocol stack is the existing technology in this field and is not an inventive solution of this application. It will not be described in detail here.

[0204] D7: Encapsulate the generated simulated protocol header with the constructed fake response payload to assemble the final fake response data packet;

[0205] D8: Bind the generated trap identifier to the session 5-tuple information and record this binding relationship in the trap monitoring registry;

[0206] D9: Send the assembled fake response packet to the source address of the high-risk suspicious traffic, and start a response monitoring thread for this session based on the records in the trap monitoring registry.

[0207] It is important to note that this process begins with the confirmation of the threat, i.e., the identification of high-risk and suspicious traffic. The deceptive content is precisely customized by identifying the threat's protocol, and a unique identifier, i.e., a trap identifier, is assigned to this interaction. Subsequently, a highly deceptive data packet is synthesized through a dedicated engine, and a monitoring task is registered before it is sent out. Finally, the trap is sent out and the listening is initiated.

[0208] The monitoring of suspicious traffic senders' responses to traps, if detecting tampering with the trap field or targeted instructions, extracts the core features of the attack behavior and marks core features with a matching degree lower than a preset matching degree threshold in the known attack feature database as features to be added to the database, including:

[0209] E1: After the fake response packet is successfully sent, the system immediately activates the response monitoring thread that was pre-created for the session. The response monitoring thread reads the corresponding trap monitoring task from the trap monitoring registry, obtains the trap identifier, target IP address and device protocol type contained therein, and integrates them into the attack session context.

[0210] E2: The response monitoring thread captures all network packets from the target IP address in the attack session context, records the arrival time of the first network packet as the trap response reception time, and arranges all captured network packets in chronological order to form the attacker's operation sequence;

[0211] E3: The system performs deep analysis on the attacker's operation sequence to detect whether there are malicious operations; the malicious operations include tampering behavior and targeted instructions; the tampering behavior refers to whether the attacker has modified or replayed the previously sent trap field; the targeted instructions refer to whether the attacker has sent new control instructions constructed based on the trap response content;

[0212] E4: Once any malicious operation is detected, the behavior feature quantification process is triggered; the behavior feature quantification process takes the attacker's operation sequence and attack session context as input and performs quantitative analysis. The quantitative analysis process is existing technology in this field and is not an inventive solution of this application, so it will not be described in detail here.

[0213] E5: In the behavioral feature quantification process, the operations of calculating behavioral indicators and encapsulating feature vectors are performed; the process of calculating behavioral indicators is as follows: using a feature extraction algorithm to analyze the attacker's operation sequence, and calculating three behavioral indicators: operation frequency deviation, instruction entropy value, and protocol violation index; the process of encapsulating feature vectors is as follows: combining the calculated three behavioral indicators with the device protocol type and attacker IP address in the attack session context, adding a timestamp, and encapsulating them together into a standard core feature vector. The feature extraction algorithm is existing technology in this field and is not an inventive solution of this application, so it will not be described in detail here.

[0214] Furthermore, the instruction entropy value is calculated based on the information entropy theory, which is existing technology in this field and is not an inventive solution of this application, and will not be elaborated here.

[0215] Furthermore, the protocol violation index is the ratio of the number of protocol violations to the total number of operations, and the specific number is obtained through statistics.

[0216] E6: The system will calculate the similarity between the generated core feature vector and all features in the locally stored known attack feature library. If the calculated highest similarity is lower than the preset matching threshold, the feature is determined to be a newly emerging attack mode, and the core feature vector is officially marked as a feature to be added to the library. The similarity calculation method is the existing technology in this field and is not an inventive solution of this application, so it will not be described in detail here.

[0217] E7: Assign a unique feature ID to the marked feature to be added to the database, and encapsulate the feature ID, feature extraction time, and summary information of associated high-risk and suspicious traffic into a complete feature record to be added to the database.

[0218] It is important to note that, based on the confirmation of high-risk and suspicious traffic, the attack background is determined through protocol parsing, and then the deceptive content is customized and bound to the session context. Subsequently, a unique tracking identifier is generated for this interaction, and the payload and simulated packet header are constructed separately, finally assembling a complete deceptive data packet. Before sending the data packet, a monitoring task is pre-registered to ensure that the trap can immediately enter the monitoring state after activation, forming a complete logic of analysis, customization, construction, registration, sending, and monitoring.

[0219] Example 2:

[0220] Please see Figure 2 Another embodiment of the present invention provides: an abnormal traffic detection system for domestically developed IT servers based on edge computing, comprising:

[0221] Honeypot command interface module, traffic monitoring module, fake response generation module, attack behavior analysis module, feature management module, and model management platform;

[0222] The honeypot instruction interface module is used to actively build a dynamically changing decoy environment at the kernel level to attract and expose attack behaviors;

[0223] The traffic monitoring module is used to analyze network traffic in real time and accurately identify potential attack traffic;

[0224] The fake response generation module is used to actively deceive suspicious traffic, enticing attackers to further expose their attack intentions and behavioral characteristics;

[0225] The attack behavior analysis module is used to monitor the attacker's interaction with the trap and extract attack characteristics from it;

[0226] The signature management module is used to process attack signatures locally and prepare for the reporting of unknown threats.

[0227] The model management platform is used to aggregate threat intelligence from various edge nodes, collaboratively train and distribute more powerful global detection models.

[0228] The honeypot command interface module includes: a dynamic port generation unit, a port periodic update unit, and a port mapping unit;

[0229] The dynamic port generation unit is used to extract port ranges from the protocol specification based on the type of connected terminal device, and to randomly create unencrypted masquerading control ports using a port generation algorithm.

[0230] The port periodic update unit is used to trigger port update events according to a preset period, regenerate the fake port and update the local mapping table, and mark the old port as invalid.

[0231] The port mapping unit is used to store and maintain the association between the currently active masquerading control port and the type of device it emulates.

[0232] The traffic monitoring module includes: a parameter loading unit, a feature extraction unit, and a whitelist filtering unit;

[0233] The parameter loading unit is used to receive and decrypt the detection model parameters issued by the domestic IT security management platform and load them into the analysis engine.

[0234] The feature extraction unit is used to intercept all access traffic through kernel-level hook functions and extract basic traffic features such as source address, destination port, and protocol type.

[0235] The whitelist filtering unit is used to match traffic characteristics with the whitelist of legitimate devices, quickly filter out legitimate traffic, and output the traffic to be detected.

[0236] The fake response generation module includes: a protocol parsing unit, a trap template matching unit, a response building engine unit, and a monitoring and registration unit;

[0237] The protocol parsing unit is used to identify the device protocol type used by suspicious traffic;

[0238] The trap template matching unit is used to select the corresponding trap field template from the preset trap field library according to the protocol type.

[0239] The response building engine generates unique trap identifiers and combines trap field templates to simulate the protocol headers of legitimate device responses, assembling them into complete fake response packets.

[0240] The monitoring registration unit is used to bind trap identifiers with session information and register them in the trap monitoring registry, providing a basis for subsequent monitoring.

[0241] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the present invention. All of these variations are within the protection scope of the present invention.

Claims

1. A method for detecting abnormal traffic on a domestically developed IT server based on edge computing, characterized in that, include: The edge IT innovation server has a honeypot command interface module embedded in the kernel layer. The honeypot command interface module dynamically generates a fake control port based on the type of terminal device connected to the edge node, and updates the identification information of the fake control port according to a preset period. The traffic monitoring module of the edge IT innovation server captures access traffic in real time based on the detection model parameters issued by the IT innovation security management platform. After filtering the authenticated legitimate traffic, it combines the spoofed port and identification information to determine suspicious traffic. When suspicious traffic is detected, fake response data containing preset trap fields is automatically generated; Monitor the actions of suspicious traffic senders in response to traps. If the trap field is tampered with or targeted instructions are detected, extract the core features of the attack behavior and mark the core features that match the known attack feature library with a lower than preset matching threshold as features to be added to the library. The edge server encrypts and uploads the features to be added to the database to the domestic IT innovation security management platform. The platform trains the detection model parameters through federated learning algorithm and distributes the updated detection model parameters to all edge domestic IT innovation servers. The honeypot command interface module dynamically generates a fake control port based on the type of terminal device connected to the edge node, including: The honeypot command interface module obtains the types of all currently connected terminal devices by listening to the network registration signaling of edge nodes or actively scanning connected devices, and outputs a list of connected device types. For each device type in the list of connected device types, the pre-configured device protocol specification library is queried to extract its corresponding standard service port number range, and a device-port range mapping list is generated; the device protocol specification library defines the communication protocol followed by each device type and its corresponding standard service port number range. Perform a local network port scan on each standard service port number range in the generated device-port range mapping list, detect and record the current occupancy status of each port, and output a detailed port status table containing all ports and their statuses; the occupancy status includes two types: used and unused. A preset port generation algorithm is invoked. The port generation algorithm takes a detailed port status table as input, randomly selects a port from all ports marked as unused within the table, and defines it as a fake control port. Bind the dynamically generated fake control port to the corresponding terminal device type in the device-port range mapping list to generate a port-device association record, and write or update the generated port-device association record to the local port mapping table; The method of updating the identification information of the disguised control port according to a preset period includes: The system sets an update cycle and starts the corresponding timer. When the timer reaches the preset update cycle, a port update event is automatically triggered. The port update event initializes a list of ports to be updated. The system iterates through each valid record in the local port mapping table. For each valid record, the system extracts its current masquerading control port and records it as an old masquerading control port to be deactivated. For each valid record, the system calls the port generation algorithm to generate a new fake control port for the device type, and uses the generated new fake control port to update the corresponding valid record in the local port mapping table; The system pairs the old masquerading control ports to be deactivated with the newly generated masquerading control ports to form a port update record, and adds the port update record to the initialized list of ports to be updated; After all valid records have been traversed and updated, the system will encapsulate the complete list of ports to be updated into a port update notification and send the port update notification to the traffic monitoring module. The traffic monitoring module receives port update notifications and iterates through the list of ports to be updated in the port update notifications. For each port update record in the list of ports to be updated, it performs the following operations: adds the new spoofed control ports it contains to its internal real-time monitoring rule base, and removes the corresponding old spoofed control ports to be invalidated from the real-time monitoring rule base. The traffic monitoring module of the edge IT innovation server captures access traffic in real time based on the detection model parameters issued by the IT innovation security management platform. After filtering the authenticated legitimate traffic, it combines the spoofed port and identification information to determine suspicious traffic, including: The edge IT innovation server receives encrypted detection model parameters from the IT innovation security management platform, decrypts them locally, and loads the decrypted detection model parameters into the traffic monitoring module. The traffic monitoring module uses the decrypted detection model parameters to initialize its traffic analysis engine. After initialization, the traffic analysis engine intercepts all incoming access traffic in real time through hook functions in the system kernel layer. The traffic monitoring module extracts the source address, destination port and protocol type of each intercepted access traffic and combines them to form the basic traffic characteristics of the access traffic. The traffic analysis engine matches basic traffic characteristics with a whitelist of legitimate devices pre-stored locally on the edge IT innovation server. If the basic traffic characteristics completely match any record in the whitelist, the basic traffic is determined to be legitimate traffic and allowed to pass, and the current detection ends. Otherwise, the basic traffic is marked as traffic to be detected. The traffic monitoring module of the edge IT innovation server captures access traffic in real time based on the detection model parameters issued by the IT innovation security management platform. After filtering the authenticated legitimate traffic, it determines suspicious traffic by combining the spoofed port and identification information. It also includes: For the generated traffic to be detected, the traffic analysis engine compares its destination port with all active masquerading control ports in the local port mapping table; When the comparison result is a port match, that is, the destination port of the traffic to be detected is a spoofed control port, the traffic to be detected is marked as suspicious traffic accessing the honeypot port; For suspicious traffic accessing the honeypot port, the traffic analysis engine performs parallel analysis of instruction semantics and format syntax: The instruction semantic analysis is as follows: parsing the payload content of suspicious traffic accessing the honeypot port, detecting whether it contains device control instructions, and outputting the instruction semantic analysis results; The format syntax analysis is as follows: using the loaded detection model parameters to perform syntax analysis on the instruction format of suspicious traffic accessing the honeypot port, identifying whether there are local anomalies, and outputting the format syntax analysis results; The traffic analysis engine comprehensively judges the results of instruction semantic analysis and format syntax analysis: if the traffic to be detected meets any two or more of the following three conditions: accessing honeypot instruction interface, carrying device control instructions, or having local anomalies in instruction format, then the traffic to be detected is officially marked as high-risk suspicious traffic. Once it is determined to be high-risk suspicious traffic, the traffic monitoring module immediately triggers a false response.

2. The method for detecting abnormal traffic on a domestically developed IT server based on edge computing as described in claim 1, characterized in that, When suspicious traffic is detected, the system automatically generates false response data containing preset trap fields, including: Once the traffic to be detected is identified as high-risk or suspicious, the system parses the protocol header of the high-risk or suspicious traffic to identify the type of device protocol it uses. Based on the parsed device protocol type, a preset trap field library is queried and a trap field template corresponding to the device protocol type is selected from it; the trap field template consists of strings or code segments that have no actual device control meaning but strictly conform to the syntax and structure of the device protocol specification; The system extracts the session 5-tuple information of the high-risk suspicious traffic and associates the session 5-tuple information with the device protocol type to form complete session context information; The session 5-tuple information consists of source IP, destination IP, source port, destination port, and protocol; Based on the generated session context information, a globally unique trap identifier is generated by combining a hash algorithm with the current timestamp; The trap identifier is generated by combining a timestamp, a source IP address hash value, and a device protocol type. The selected trap field templates and trap identifiers are combined and populated to construct a complete fake response payload; Based on the identified device protocol type and the bound session 5-tuple information, a simulated protocol header conforming to the protocol specification is constructed; the content of the simulated protocol header simulates a normal, legitimate device response. The generated simulated protocol header is encapsulated with the constructed fake response payload to assemble the final fake response data packet; The generated trap identifier is bound to the session 5-tuple information, and this binding relationship is recorded in the trap monitoring registry. The assembled fake response packet is sent to the source address of the high-risk, suspicious traffic, and a response monitoring thread is started for this session based on the records in the trap monitoring registry.

3. The method for detecting abnormal traffic on a domestically developed IT server based on edge computing as described in claim 2, characterized in that, The monitoring of suspicious traffic senders' responses to traps, if detecting tampering with the trap field or targeted instructions, extracts the core features of the attack behavior and marks core features with a matching degree lower than a preset matching degree threshold in the known attack feature database as features to be added to the database, including: After the fake response packet is successfully sent, the system immediately activates the response monitoring thread that was pre-created for the session. The response monitoring thread reads the corresponding trap monitoring task from the trap monitoring registry, obtains the trap identifier, target IP address and device protocol type contained therein, and integrates them into the attack session context. The response monitoring thread captures all network packets from the target IP address in the attack session context, records the arrival time of the first network packet as the trap response reception time, and arranges all captured network packets in chronological order to form the attacker's operation sequence. The system performs deep analysis on the attacker's operation sequence to detect whether there are malicious operations; the malicious operations include tampering behavior and targeted instructions; the tampering behavior refers to whether the attacker has modified or replayed the previously sent trap field; the targeted instructions refer to whether the attacker has sent new control instructions constructed based on the trap response content; Once any malicious operation is identified, the behavioral feature quantification process is triggered; the behavioral feature quantification process takes the attacker's operation sequence and attack session context as input and performs quantitative analysis. In the behavioral feature quantification process, the operations of calculating behavioral indicators and encapsulating feature vectors are performed. The process of calculating behavioral indicators is as follows: using feature extraction algorithms to analyze the attacker's operation sequence, and calculating three behavioral indicators: operation frequency deviation, instruction entropy value, and protocol violation index. The process of encapsulating feature vectors is as follows: combining the calculated three behavioral indicators with the device protocol type and attacker IP address in the attack session context, adding a timestamp, and encapsulating them together into a standard core feature vector. The system will calculate the similarity between the generated core feature vector and all features in the locally stored known attack feature library. If the calculated highest similarity is lower than the preset matching threshold, the feature is determined to be a newly emerging attack mode, and the core feature vector is officially marked as a feature to be added to the library. Assign a unique feature ID to the tagged feature to be added to the database, and encapsulate the feature ID, feature extraction time, and summary information of associated high-risk and suspicious traffic into a complete feature record to be added to the database.

4. The method for detecting abnormal traffic on a domestically developed IT server based on edge computing as described in claim 3, characterized in that, The method further includes: Set up an anomaly alarm mechanism on the edge IT innovation server; when high-frequency suspicious traffic or model verification failure is detected, alarm information is automatically generated and reported to the platform; the platform adjusts the federated learning training frequency or issues emergency update parameters based on the alarm information.

5. An edge computing-based abnormal traffic detection system for domestically developed IT servers, used to implement the edge computing-based abnormal traffic detection method for domestically developed IT servers as described in any one of claims 1-4, characterized in that, include: Honeypot command interface module, traffic monitoring module, fake response generation module, attack behavior analysis module, feature management module, and model management platform; The honeypot instruction interface module is used to actively construct a dynamically changing decoy environment at the kernel layer to attract and expose attack behaviors. The traffic monitoring module is used to analyze network traffic in real time and identify attack traffic; The fake response generation module is used to actively deceive suspicious traffic, inducing attackers to expose their attack intentions and behavioral characteristics; The attack behavior analysis module is used to monitor the attacker's interaction with the trap and extract attack characteristics from it. The feature management module is used for localized processing of attack features; The model management platform is used to aggregate threat intelligence from various edge nodes, collaboratively train and distribute global detection models.

Images