Methods for monitoring threats, tools, media for data transmission, and electronic devices for blockchain-based hosts.

Abstract

The present disclosure relates to the technical field of computers, and in particular to a blockchain-based host security monitoring method and apparatus, a computer readable medium and an electronic device. The host security monitoring method in the embodiments of the present disclosure comprises: monitoring traffic data of a host in network communication, and determining whether the traffic data is malicious traffic; if the traffic data is malicious traffic, obtaining security state information of the host, and saving the security state information to a security state blockchain; generating an invasion log corresponding to the malicious traffic, and saving the invasion log and the security state information to a log storage blockchain. The method has the advantages of high monitoring accuracy and good reliability.

Description

Blockchain-based host security monitoring methods, devices, media, and electronic equipment

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 201911149432.8, filed on November 21, 2019, entitled "Blockchain-based Host Security Monitoring Method, Apparatus, Medium and Electronic Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of computer technology, and in particular to a blockchain-based host security monitoring method, a blockchain-based host security monitoring device, a computer-readable medium, and an electronic device. Background Technology

[0004] With the continuous development of computer and internet technologies, while enterprises enjoy the benefits of internet development, they are also constantly suffering from cyberattacks, which have brought varying degrees of impact to their business, assets, and image. Cybersecurity issues are receiving increasing attention. Moreover, in recent years, cyberattacks have evolved from individual, solo operations to team collaborations, and from focusing on system vulnerabilities to focusing on business vulnerabilities. Therefore, large enterprises face more complex targeted threat attacks (Advanced Persistent Threats, APTs).

[0005] Detecting attack behavior, reconstructing attack paths, determining the scope of the attack, and obtaining attack forensics have become the most pressing concerns for enterprises when facing security attacks. However, in today's large organizations, the internal network topology is complex, and security intrusion detection devices are mainly distributed across various network nodes and the edge. While they can detect attack behavior, they cannot determine whether the attacker successfully compromised the target host, or whether the attack, if successful, used covert channels to cause even greater impact. Therefore, network security devices have detection blind spots. In addition, attackers may delete log records after compromising a host, which can hinder vulnerability impact investigation. Therefore, how to conduct accurate and reliable host security monitoring is a pressing issue that needs to be addressed.

[0006] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art.

[0007] Summary of the Invention

[0008] The purpose of this disclosure is to provide a blockchain-based host security monitoring method, a blockchain-based host security monitoring device, a computer-readable medium, and an electronic device, thereby overcoming, to at least a certain extent, the technical problems such as poor security monitoring accuracy and monitoring vulnerabilities caused by the limitations and defects of related technologies.

[0009] According to one aspect of this disclosure, a blockchain-based host security monitoring method is provided. The method includes: monitoring the traffic data of a host in network communication and determining whether the traffic data is malicious traffic; if the traffic data is malicious traffic, obtaining the security status information of the host and saving the security status information to a security status blockchain; generating an intrusion log corresponding to the malicious traffic and saving the intrusion log and the security status information to a log storage blockchain.

[0010] This disclosure also discloses a blockchain-based host security monitoring device, which includes: a traffic data monitoring unit configured to monitor the traffic data of a host in network communication and determine whether the traffic data is malicious traffic; a security status storage unit configured to obtain the security status information of the host when the traffic data is determined to be malicious traffic and save the security status information to a security status blockchain; and a log storage unit configured to generate an intrusion log corresponding to the malicious traffic and save the intrusion log and the security status information to a log storage blockchain.

[0011] This disclosure also discloses an electronic device, comprising: one or more processors; and one or more machine-readable media having instructions stored thereon, which, when executed by the one or more processors, cause the electronic device to perform the following steps: monitoring traffic data of a host in network communication and determining whether the traffic data is malicious traffic; if the traffic data is malicious traffic, acquiring the security status information of the host and saving the security status information to a security status blockchain; generating an intrusion log corresponding to the malicious traffic and saving the intrusion log and the security status information to a log storage blockchain.

[0012] This disclosure also discloses one or more machine-readable media having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the following steps: listen to traffic data of a host in network communication and determine whether the traffic data is malicious traffic; if the traffic data is malicious traffic, obtain the security status information of the host and save the security status information to a security status blockchain; generate an intrusion log corresponding to the malicious traffic and save the intrusion log and the security status information to a log storage blockchain.

[0013] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0015] Figure 1 schematically illustrates a flowchart of the steps of a blockchain-based host security monitoring method in some embodiments of this disclosure.

[0016] Figure 2 schematically illustrates a flowchart of the steps for determining traffic data attributes in some embodiments of this disclosure.

[0017] Figure 3 schematically illustrates a flowchart of the steps for extracting features from traffic data in some embodiments of this disclosure.

[0018] Figure 4 schematically illustrates a flowchart of the steps for obtaining host security status information in some embodiments of this disclosure.

[0019] Figure 5 schematically illustrates a flowchart of the steps for determining host security status information in some embodiments of this disclosure.

[0020] Figure 6 schematically illustrates a flowchart of the steps for storing security status information based on blockchain in some embodiments of this disclosure.

[0021] Figure 7 schematically illustrates a flowchart of the steps for storing logs based on blockchain in some embodiments of this disclosure.

[0022] Figure 8 schematically illustrates a block diagram of a blockchain-based host security monitoring device in some embodiments of this disclosure.

[0023] Figure 9 schematically illustrates the overall architecture of a host security monitoring system provided in this disclosure.

[0024] Figure 10 schematically illustrates the detection and judgment principle of the security detection model.

[0025] Figure 11 schematically illustrates the blockchain network principle of the log storage module.

[0026] Figure 12 schematically illustrates the host security monitoring process based on the host security monitoring system.

[0027] Figure 13 schematically illustrates a program product according to an embodiment of the present disclosure.

[0028] Figure 14 schematically illustrates a module diagram of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0029] To make the above-mentioned objectives, features and advantages of this disclosure more apparent and understandable, the disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] In the related technologies disclosed herein, the security status of a host can be monitored through two methods: traffic analysis or local scanning.

[0031] Traffic analysis involves deploying an intrusion detection system (IDS) in a bypass of the network backbone. This system analyzes network packets and matches them against predefined attack success characteristics. If a match is found, the target host is considered compromised, the attack log is logged, and an alert is issued. While this method can detect intrusions on the network backbone, it becomes problematic when attackers establish a covert channel with compromised internal hosts to attack LAN assets. In such cases, the IDS cannot detect the attack traffic, making it impossible to determine the scope of the attack or the attacker's subsequent attack path. Furthermore, traffic analysis relies on malicious traffic signatures, making it difficult to identify zero-day attacks, time-based attacks, and business-related attacks.

[0032] Local scanning involves installing a client-side detection program on the host machine. Based on custom rules, the program periodically scans the client and sends alerts when it detects abnormal file activity, user activity, log activity, network activity, or process activity. The backend stores these alert logs. This method can be deployed on all hosts for comprehensive security monitoring. However, the detection rules are somewhat outdated, and it can only detect known intrusions, not determine the attacker's subsequent attack paths.

[0033] In addition, both of the above security monitoring methods use traditional log storage technology, which poses risks such as log tampering and loss.

[0034] Host security status monitoring technologies based on traffic analysis, local scanning, or other methods all employ centralized management, only obtaining the current security status of network assets at the central node. There is a lack of a unified and reliable communication and interconnection mechanism between hosts, making it impossible to ascertain the security status of communicating partners. Because detection primarily occurs at network backbone nodes or only at the host's own security status, it fails to monitor malicious traffic connections and attacks within the local area network, resulting in detection blind spots. Furthermore, due to the lack of a unified and reliable log synchronization and storage technology, existing technologies cannot simultaneously meet the needs of detecting attack behavior, reconstructing attack paths, determining the scope of attack impact, and attack forensics.

[0035] To address the problems existing in the above-mentioned related technologies, this disclosure provides a blockchain-based host security monitoring method. Figure 1 schematically illustrates a flowchart of the steps of the blockchain-based host security monitoring method in some embodiments of this disclosure. As shown in Figure 1, the method mainly includes the following steps:

[0036] Step S110. Monitor the network traffic data of the host and determine whether the traffic data is malicious.

[0037] The current host under security monitoring can communicate with other hosts on the Internet through wired or wireless communication links. This step listens to the traffic data of the current host during network communication and uses traffic analysis to determine whether the traffic data of the current communication is malicious traffic with attack behavior or carrying abnormal files.

[0038] Step S120. If the traffic data is malicious, obtain the host's security status information and save the security status information to the security status blockchain.

[0039] Based on the judgment result in step S110, if the monitored traffic data is determined to be malicious traffic, then the current host is at risk of being maliciously intruded upon. The host's security status information reflects whether the host has been successfully intruded upon by malicious traffic. If the current host is successfully intruded upon, then the files, users, logs, network, processes, and other related content of the current host may show abnormalities. Conversely, if the malicious traffic fails to intrude upon the current host, then the relevant content of the current host will be in a normal state. The host's security status information can be represented by two security status indicators: "secure" and "intrusion," where "intrusion" indicates that the host has been successfully intruded upon. As one of the nodes in the security status blockchain network, the current host can save its security status information to the security status blockchain, enabling other nodes in the security status blockchain network to obtain the current host's security status in a timely and accurate manner.

[0040] Step S130. Generate an intrusion log corresponding to the malicious traffic, and save the intrusion log and security status information to the log storage blockchain.

[0041] For intrusions detected by malicious traffic, corresponding intrusion logs can be generated. Saving the intrusion logs along with the host's security status information to the log storage blockchain enables shared storage of intrusion activities and results, allowing other nodes in the log storage blockchain network to effectively trace the historical records of security monitoring.

[0042] In the blockchain-based host security monitoring method provided in this disclosure, the impact of network attacks on enterprises can be determined by quickly and accurately identifying the current security status of the host; the historical security status of the host can be traced by establishing host status information based on a state machine; the attack path can be reconstructed by identifying the source of intrusion at the host level, thereby improving the enterprise's emergency response capabilities; and the separation of responsibilities between host status identification and log storage, based on the decentralized and non-repudiable characteristics of blockchain, can ensure the non-repudiation and integrity of the logs.

[0043] This disclosure can utilize a pre-trained machine learning model to determine the attributes of traffic data. Figure 2 schematically illustrates a flowchart of the steps for determining the attributes of traffic data in some embodiments of this disclosure. As shown in Figure 2, based on the above embodiments, the step S110 of determining whether the traffic data is malicious traffic may include the following steps:

[0044] Step S210. Perform feature extraction on the traffic data to obtain the traffic characteristics of the traffic data.

[0045] Traffic characteristics of traffic data can include communication data characteristics related to the communication content and source host characteristics related to the source host. The source host is another host in the network that communicates data with the current host. Source host characteristics can include the source host's current security status information and its historical security status information. The source host's current and historical security status information can be obtained directly from the security status blockchain.

[0046] Step S220. Input the traffic features into a pre-trained support vector machine model to identify the data type of the traffic data through the support vector machine model. The data type includes normal traffic and malicious traffic.

[0047] Support Vector Machines (SVMs) are a type of generalized linear classifier that performs binary classification on data using supervised learning. Their decision boundary is the hyperplane with the maximum margin calculated from the training samples. SVMs use a hinge loss function to calculate empirical risk and incorporate a regularization term into the solution system to optimize structural risk, making them sparsity- and robust classifiers. Pre-trained SVM models can analyze and calculate extracted traffic features, classifying the corresponding traffic data into normal or malicious traffic based on the analysis results.

[0048] Figure 3 schematically illustrates a flowchart of the steps for extracting features from traffic data in some embodiments of this disclosure. As shown in Figure 3, based on the above embodiments, step S210, extracting features from the traffic data to obtain traffic features, may include the following steps:

[0049] Step S310. Obtain application layer protocol traffic from the traffic data, and extract features from the application layer protocol traffic to obtain the protocol traffic features of the application layer protocol traffic.

[0050] Application layer protocols define how application processes running on different end systems exchange messages. Examples include File Transfer Protocol (FTP) and Hypertext Transfer Protocol (HTTP). By extracting features from application layer protocol traffic, various protocol traffic characteristics can be obtained, such as network address, port, protocol type, connection time, packet length, and packet content.

[0051] Step S320. When a file object exists in the application layer protocol traffic, perform feature extraction on the file object to obtain the file object features.

[0052] In addition to request and response messages, application layer protocol traffic can also carry file objects for file transfer. If file objects are detected in the application layer protocol traffic, this step can isolate them and extract their features to obtain the corresponding file object characteristics. File object characteristics may include, for example, file name, file format, and file size.

[0053] Step S330. Run the file object in the host's sandbox and determine the file running characteristics related to the host based on the running results.

[0054] A sandbox is a security mechanism that provides an isolated environment for running file objects. A sandbox can strictly control the resources that a file object can access during runtime; for example, it can provide disk and memory space that is reclaimed after use. Within a sandbox, network access, access to the real system, and reading from input devices are typically prohibited or strictly limited, and all changes made within the sandbox will not cause any loss to the operating system. This step runs the isolated file object within the host's sandbox, allowing for safe and reliable monitoring of the file object's execution process. The results of this execution are then used to determine host-related file execution characteristics. These characteristics may include, for example, the host's CPU state, memory state, and network egress traffic status.

[0055] Step S340. Determine the traffic characteristics of the traffic data based on protocol traffic characteristics, file object characteristics, and file execution characteristics.

[0056] When file objects are present in the application layer protocol traffic, the protocol traffic features, file object features, and file execution features extracted in the above steps can be combined to form the traffic features of the traffic data. If the application layer protocol traffic does not carry file objects, the traffic features of the corresponding traffic data can be directly determined based on the protocol traffic features.

[0057] If the monitored traffic data is determined to be malicious based on traffic characteristics, this malicious traffic may lead to malicious attacks such as intrusion into the host, thus affecting the host's security status to some extent. Figure 4 schematically illustrates a flowchart of the steps for obtaining host security status information in some embodiments of this disclosure. As shown in Figure 4, based on the above embodiments, obtaining host security status information in step S120 may include the following steps:

[0058] Step S410. Obtain the host's operating status data.

[0059] Step S420. Determine the host's security status information based on the running status data and malicious traffic.

[0060] The host's operational status data is obtained by collecting local information from the current host. Based on the analysis of the operational status data and malicious traffic, the current host's security status information can be determined. Figure 5 schematically illustrates a flowchart of the steps for determining host security status information in some embodiments of this disclosure. As shown in Figure 5, based on the above embodiments, step S420, determining the host's security status information based on the operational status data and malicious traffic, may include the following steps:

[0061] Step S510. Extract features from the running status data to obtain the host's status features.

[0062] By extracting features from the runtime status data, we can obtain various status data such as host CPU utilization, memory usage, network traffic volume, and root privilege users.

[0063] Step S520. Determine the traffic characteristics corresponding to malicious traffic.

[0064] Traffic characteristics corresponding to malicious traffic can include various features such as protocol traffic characteristics, file object characteristics, and file execution characteristics obtained through feature extraction in the above embodiments.

[0065] Step S530. Input the state features and traffic features into the pre-trained random forest model to obtain the host's security state information.

[0066] Random forest models are classifiers that use multiple decision trees to train and predict samples. This step utilizes a random forest model to analyze state and traffic characteristics to determine the host's security status information. Taking binary classification as an example, this step can categorize the host's security status information into two types: "secure" and "intrusion."

[0067] By using blockchain technology to store the security status information of a host, data sharing can be achieved across multiple nodes in the blockchain network while ensuring the accuracy of the information. Figure 6 schematically illustrates a flowchart of the steps for storing security status information based on blockchain in some embodiments of this disclosure. As shown in Figure 6, based on the above embodiments, step S120, which involves saving the security status information to the security status blockchain, may include the following steps:

[0068] Step S610. Store the host's network address and security status information in the block body of the current security status block to be reached for consensus.

[0069] Each security state block in the security state blockchain consists of two data storage areas: a block header and a block body. The block body stores all the data recorded in the current security state block, such as the host's network address and security state information. The block header stores the link information between the current security state block and the previous security state block. Using the data stored in the block header, all security state blocks can be linked one by one to form a complete security state blockchain.

[0070] Step S620. When the block generation conditions are met, obtain the block header data of the previous secure state block in the secure state blockchain, and calculate the parent block hash value based on the block header data.

[0071] When certain block generation conditions are met, this step can obtain the block header data of the previous secure state block (i.e., the most recently generated new secure state block) in the secure state blockchain network. Based on this block header data, the parent block hash value of the current secure state block can be calculated. For example, the SHA256 algorithm can be used to hash the block header data of the previous secure state block to obtain a hash value, which can then be used as the parent block hash value of the current secure state block. The block generation conditions in this step can be a time threshold since the creation of the previous secure state block, or a data volume threshold in the block body of the current secure state block, or any other preset conditions used to trigger the generation of a new block. This embodiment does not impose any special limitations on these conditions.

[0072] Step S630. Calculate the hash value of the block body of the current secure block based on the data stored in the block body of the current secure block.

[0073] The block body of the current secure state block stores the network addresses and security status information of hosts formed over a period of time. Based on the data stored in the block body, this step can obtain a hash value as the block body hash value of the current secure state block. Taking hash encoding as an example, all network addresses and security status information in the block body can be stored in the block body in the form of a Merkle tree. Specifically, the network addresses and security status information can be stored in the leaf nodes of the Merkle tree. The network addresses and security status information stored in every two adjacent leaf nodes are combined and hashed again to obtain the hash value stored in a child node. By using this method of combining the hash values ​​stored in child nodes in pairs and performing hash operations layer by layer upwards, a root node hash value can be obtained. This root node hash value can be used as the block body hash value of the current secure state block.

[0074] Step S640. Store the parent block hash value, the block body hash value, and the current time timestamp in the block header of the currently secure block.

[0075] After calculating the parent block hash value and the block body hash value in steps S620 and S630 respectively, this step generates a timestamp based on the current time. This timestamp is used to record the generation time of the block in the current secure state. Then, the parent block hash value, the block body hash value, and the timestamp can be stored together in the block header of the block in the current secure state.

[0076] Step S650. Broadcast the current secure state block to the secure state blockchain network to perform consensus authentication of the current secure state block, and connect the current secure state blockchain to the secure state blockchain when the authentication is successful.

[0077] After saving the block header data, this step broadcasts the current secure state block, consisting of the block header and block body, to the secure state blockchain network. Following consensus authentication, all or some of the blockchain nodes in the secure state blockchain network save the current secure state block, thus completing the process of adding the current secure state block to the secure state blockchain.

[0078] Figure 7 schematically illustrates a flowchart of the steps for saving logs based on a blockchain in some embodiments of this disclosure. As shown in Figure 7, based on the above embodiments, step S130, saving the intrusion log and security status information to the log storage blockchain, may include the following steps:

[0079] Step S710. Store the host's network address, intrusion log, and security status information in the block body of the current log storage block awaiting consensus.

[0080] Each log storage block in a log storage blockchain consists of two data storage areas: a block header and a block body. The block body stores all the data recorded in the current log storage block, such as the host's network address, intrusion logs, and security status information. The block header stores the link information between the current log storage block and the previous log storage block. Using the data stored in the block header, all log storage blocks can be linked one by one to form a complete log storage blockchain.

[0081] Step S720. When the block generation conditions are met, obtain the block header data of the previous log storage block in the log storage blockchain, and calculate the parent block hash value based on the block header data.

[0082] When certain block generation conditions are met, this step can obtain the block header data of the previous log storage block (i.e., the most recently generated new log storage block) in the log storage blockchain network. Based on this block header data, the parent block hash value of the current log storage block can be calculated. For example, the SHA256 algorithm can be used to hash the block header data of the previous log storage block to obtain a hash value, which can then be used as the parent block hash value of the current log storage block. The block generation conditions in this step can be a time threshold since the creation of the previous log storage block, or a data volume threshold in the block body of the current log storage block, or any other preset conditions used to trigger the generation of a new block. This embodiment does not impose any special limitations on these conditions.

[0083] Step S730. Calculate the block body hash value of the current log storage block based on the data stored in the block body of the current log storage block.

[0084] The block body of the current log storage block stores the network addresses, intrusion logs, and security status information of hosts formed within a certain period. Based on the data stored in the block body, this step can obtain a hash value as the block body hash value of the current log storage block. Taking hash encoding as an example, all network addresses, intrusion logs, and security status information in the block body can be stored in the block body in the form of a Merkle tree. Specifically, the network addresses, intrusion logs, and security status information can be stored in the leaf nodes of the Merkle tree. The network addresses, intrusion logs, and security status information stored in every two adjacent leaf nodes are combined and hashed again to obtain the hash value stored in a child node. By using this method of combining the hash values ​​stored in child nodes in pairs and performing hash operations layer by layer upwards, a root node hash value can be obtained. This root node hash value can be used as the block body hash value of the current log storage block.

[0085] Step S740. Save the parent block hash value, the block body hash value, and the current time timestamp in the block header of the current log storage block.

[0086] After calculating the parent block hash value and the block body hash value in steps S720 and S730 respectively, this step can generate a timestamp based on the current time. This timestamp is used to record the generation time of the current log storage block. Then, the parent block hash value, the block body hash value, and the timestamp can be stored together in the block header of the current log storage block.

[0087] Step S750. Broadcast the current log storage block to the log storage blockchain network to perform consensus authentication of the current log storage block, and connect the current log storage blockchain to the log storage blockchain when the authentication is successful.

[0088] After saving the block header data, this step broadcasts the current log storage block, consisting of the block header and block body, to the log storage blockchain network. Following consensus authentication, all or some of the blockchain nodes in the log storage blockchain network save the current log storage block, thus completing the process of adding the current log storage block to the log storage blockchain.

[0089] It should be noted that although the above exemplary embodiments describe the steps of the method in this disclosure in a specific order, this does not require or imply that these steps must be performed in that specific order, or that all steps must be performed to achieve the desired result. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0090] Figure 8 schematically illustrates a block diagram of a blockchain-based host security monitoring device in some embodiments of this disclosure. As shown in Figure 8, the host security monitoring device 800 mainly includes:

[0091] The traffic data monitoring unit 810 is configured to monitor the traffic data of the host in network communication and determine whether the traffic data is malicious.

[0092] The security status storage unit 820 is configured to obtain the security status information of the host and save the security status information to the security status blockchain if the traffic data is malicious.

[0093] Log storage unit 830 is configured to generate intrusion logs corresponding to malicious traffic and save the intrusion logs and security status information to the log storage blockchain.

[0094] In some embodiments of this disclosure, based on the above embodiments, the traffic data monitoring unit 810 may further include:

[0095] The traffic feature extraction unit is configured to extract features from traffic data to obtain the traffic features of the traffic data;

[0096] The first model prediction unit is configured to input traffic features into a pre-trained support vector machine model to identify the data type of traffic data, including normal traffic and malicious traffic.

[0097] In some embodiments of this disclosure, based on the above embodiments, the traffic feature extraction unit may further include:

[0098] The protocol traffic feature extraction unit is configured to acquire application layer protocol traffic in traffic data and extract features from the application layer protocol traffic to obtain the protocol traffic features of the application layer protocol traffic.

[0099] The file object feature extraction unit is configured to extract features from the file object when a file object exists in the application layer protocol traffic in order to obtain the file object features of the file object.

[0100] The file execution feature extraction unit is configured to run file objects in the host's sandbox and determine the file execution features related to the host based on the execution results.

[0101] The first traffic characteristic determination unit is configured to determine the traffic characteristics of traffic data based on protocol traffic characteristics, file object characteristics, and file execution characteristics.

[0102] In some embodiments of this disclosure, based on the above embodiments, the security state preservation unit 820 may include:

[0103] The running status data acquisition unit is configured to acquire the running status data of the host.

[0104] The security status information determination unit is configured to determine the security status information of the host based on the running status data and malicious traffic.

[0105] In some embodiments of this disclosure, based on the above embodiments, the security status information determination unit may include:

[0106] The status feature extraction unit is configured to extract features from the running status data to obtain the status features of the host.

[0107] The second traffic feature determination unit is configured with traffic features corresponding to malicious traffic;

[0108] The second model prediction unit is configured to input state features and traffic features into a pre-trained random forest model to obtain the host's security state information.

[0109] In some embodiments of this disclosure, based on the above embodiments, the security state preservation unit 820 further includes:

[0110] The first block body storage unit is configured to store the host's network address and security status information in the block body of the current security status block pending consensus;

[0111] The first parent block hash value generation unit is configured to obtain the block header data of the previous secure state block in the secure state blockchain when the block generation conditions are met, and calculate the parent block hash value based on the block header data.

[0112] The first block body hash value generation unit is configured to calculate the block body hash value of the block in the current security state based on the data stored in the block body of the current block;

[0113] The first block header storage unit is configured to store the parent block hash value, the block body hash value, and the current time timestamp in the block header of the currently secure block;

[0114] The first blockchain connection unit is configured to broadcast the current secure state block to the secure state blockchain network for consensus authentication of the current secure state block, and connect the current secure state blockchain to the secure state blockchain when the authentication is successful.

[0115] In some embodiments of this disclosure, based on the above embodiments, the log storage unit 830 may include:

[0116] The second block body storage unit is configured to store the host's network address, intrusion logs, and security status information in the block body of the current log storage block pending consensus.

[0117] The second parent block hash value generation unit is configured to obtain the block header data of the previous log storage block in the log storage blockchain when the block generation conditions are met, and calculate the parent block hash value based on the block header data.

[0118] The second block body hash value generation unit is configured to calculate the block body hash value of the current log storage block based on the data stored in the block body of the current log storage block;

[0119] The second block header storage unit is configured to store the parent block hash value, the block body hash value, and the current time timestamp in the block header of the current log storage block;

[0120] The second blockchain connection unit is configured to broadcast the current log storage block to the log storage blockchain network for consensus authentication of the current log storage block, and connect the current log storage blockchain to the log storage blockchain when the authentication is successful.

[0121] The specific details of the aforementioned blockchain-based host security monitoring device have been described in detail in the corresponding blockchain-based host security monitoring method, so they will not be repeated here.

[0122] The following describes the details of the blockchain-based host security monitoring method and the blockchain-based host security monitoring device in the above embodiments of this disclosure, using a specific application scenario as an example.

[0123] Figure 9 schematically illustrates the overall architecture of a host security monitoring system provided in this disclosure. As shown in Figure 9, the host security monitoring system 900 mainly includes three parts: a security management center 910, a local intrusion detection module 920, and a log storage module 930.

[0124] The security management hub 910 is mainly responsible for the management and maintenance of the local intrusion detection module 920, distributing the manually trained and optimized machine learning detection model, and retrieving logs from the log storage module 930 and displaying the log results.

[0125] The local intrusion detection module 920 is deployed on the operating system of each host under system monitoring. It is the end node of the host security monitoring system. The local intrusion detection module 920 performs periodic scanning and real-time traffic monitoring on the current host. It is responsible for identifying attack behavior, recording attack logs and timestamps, maintaining host security status identifiers, and calculating hashes of host security status, logs, and timestamps.

[0126] The local intrusion detection module 920 mainly includes four sub-modules: local information acquisition module 921, local traffic monitoring module 922, intrusion judgment module 923, and host security status identification module 924. The host security status includes "secure" and "intrusion," with intrusion referring to the successful intrusion of the host.

[0127] The local information collection module 921 is responsible for collecting various status information of the local client.

[0128] The local traffic monitoring module 922 is responsible for real-time monitoring of the communication traffic of the current host.

[0129] The intrusion detection module 923 uses a security detection model to make judgments on the results of local information collection and traffic sniffing, and then takes further action.

[0130] Figure 10 schematically illustrates the detection and judgment principle of the security detection model. As shown in Figure 10, the local traffic monitoring module 922 obtains the network traffic dataset 1010 by listening to the communication traffic of the current host, and then extracts the application layer protocol traffic features from the traffic data to obtain protocol traffic features. If the traffic data contains files, the files are extracted, executed in the sandbox, and the file object features of the file itself and the file execution features after the file is executed are extracted.

[0131] The protocol traffic characteristics mainly include: source host network address, source host port, destination host network address, destination host port, protocol type, connection time, request packet length, request packet content, response packet length, response packet content, the number of packets identical to the current packet in the previous p communication connections, the source host's security status flags in the previous q connections, and the source host's current security status flag. p and q are preset values; for example, p can be 50 and q can be 5.

[0132] File object characteristics and file execution characteristics can mainly include: file name, file hash, user execution permissions, CPU status, memory status, hard disk read / write status, network egress traffic status, system user changes, whether it contains a daemon process, daemon process name, shell command execution records, and host firewall configuration changes.

[0133] The traffic characteristics of the above traffic data can be input into the intrusion judgment module 923, and then the support vector machine model 1020 will determine whether the currently monitored traffic data is normal traffic or malicious traffic based on the characteristics of the traffic data.

[0134] If the traffic data is determined to be normal, then the current determination result is output as safe.

[0135] If the traffic data is determined to be malicious, it is necessary to further determine whether the current host has been successfully compromised under the attack of this malicious traffic.

[0136] The local information acquisition module 921 can obtain the host's local feature dataset 1030 by collecting local information. By extracting features from the local feature dataset 1030, status features related to the running status data can be obtained.

[0137] The main characteristics of runtime status data can include: CPU utilization, memory usage, network traffic, root privileges users, changes in system users, link locations of major command files, hashes of major command files, the last s logins of all users, and the last t shell execution records for each user. 's' and 't' are preset values; for example, 's' can be 5 and 't' can be 100.

[0138] The current host's status characteristics and the malicious traffic characteristics are input into the intrusion judgment module 923. Then, the random forest model 1040 determines whether the current host has been successfully intruded based on the status characteristics and traffic characteristics, and outputs the corresponding judgment result.

[0139] The host security status identification module 924 can identify the current host security status based on the judgment result of the intrusion judgment module 923. When attack traffic or host behavior characteristics are found to match the intrusion rules, the host status is marked as "intrusion" and the log recording function is enabled. When it is found that an intruding host sends malicious traffic to the host but fails to intrude, only the log recording function is enabled.

[0140] When a host is compromised, the current state is marked as compromised. The current host timestamp, security status identifier, and hash (timestamp + host IP + host security status) are written into the security status blockchain corresponding to the local intrusion detection module 920. The current host timestamp, security status identifier, intrusion log, and hash (timestamp + host IP + intrusion log + host security status) are reported to the log storage module 930, which then writes them into the log storage blockchain.

[0141] The security status blockchain mainly maintains the security identification information of the host, ensuring that each host knows the security status identification of the other host when communicating. When the local intrusion detection module 920 detects that a host with a security status identification of "intrusion" initiates a connection to the host, it can analyze the communication traffic between the two parties and report the attack behavior to the log storage module.

[0142] Intrusion logs for attacking network traffic can be divided into two main levels: intrusion behavior and successful intrusion. The level of intrusion logs reported to the log storage module 930 can be adjusted by setting thresholds.

[0143] The log storage module 930 serves as the information aggregation point for the host security monitoring system 900, employing blockchain technology to store logs reported by clients. Compared to the security status blockchain, the log storage blockchain adds intrusion logs. By transferring intrusion log storage from the client to the log storage blockchain, the client's load is effectively reduced, ensuring the non-repudiation and integrity of information.

[0144] As shown in Figure 11, the log storage module 930 includes multiple log storage nodes 931 that constitute a blockchain network. Each log storage node is deployed on a log server, and these nodes jointly maintain the log storage blockchain.

[0145] The local intrusion detection module 920 randomly selects n log storage nodes 931 that can communicate normally and sends intrusion logs to them, where n>=2, to prevent log loss due to a single point of failure in the log recording module. After receiving the data, the log storage module nodes verify the data, and if the verification is successful, write it to the log storage blockchain.

[0146] Figure 12 schematically illustrates the host security monitoring process based on a host security monitoring system. As shown in Figure 12, this monitoring process mainly includes the following steps:

[0147] Step S1201. Obtain host communication traffic.

[0148] Step S1202. Obtain the local status of the host.

[0149] Step S1203. Preprocess the host communication traffic to determine file objects and other traffic.

[0150] Step S1204. Execute the file object and extract features in the sandbox.

[0151] Step S1205. Input the features of other traffic and the features obtained from the executable file object into the support vector machine model.

[0152] Step S1206. Determine whether the current communication traffic data is malicious based on the output of the support vector machine. If it is not malicious traffic, end the process; if it is malicious traffic, proceed to step S1207.

[0153] Step S1207. Input the characteristics of malicious traffic and the characteristics of the host's local state into the random forest model.

[0154] Step S1208. Determine whether the current host has been successfully compromised based on the output of the random forest model. If the compromise fails, the process ends; if the compromise is successful, proceed to steps S1209 and S1210.

[0155] Step S1209. Record the timestamp, hash, and host state, save them to the secure state blockchain, and end the process.

[0156] Step S1210. Record the timestamp, log, hash, and host status, save them to the log storage blockchain, and end the process.

[0157] This disclosure endows every asset in an organization with intrusion detection capabilities, which can significantly improve the organization's intrusion detection capabilities, enable more comprehensive monitoring of the historical status information of the organization's assets, and quickly and reliably record intrusion logs for attack behaviors, helping the organization to determine the scope of attack impact in a timely manner, improve the organization's emergency response capabilities, ensure the organization's business continuity, and at the same time, the reliable logs ensure the effectiveness of forensics.

[0158] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0159] In exemplary embodiments of this disclosure, a computer-readable medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the methods described above. In some possible embodiments, various aspects of this disclosure can also be implemented as a program product comprising program code; the program product may be stored on a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive) or on a network; when the program product is run on a computing device (such as a personal computer, server, terminal device, or network device), the program code is used to cause the computing device to perform the method steps in the exemplary embodiments described above.

[0160] Referring to Figure 13, the program product 1300 for implementing the above-described method according to an embodiment of the present disclosure may employ a portable compact disk read-only memory (CD-ROM) and include program code, and may run on a computing device (e.g., a personal computer, server, terminal device, or network device). However, the program product of the present disclosure is not limited thereto. In this exemplary embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0161] The program product can be any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium.

[0162] A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of a readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0163] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0164] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, or any suitable combination thereof.

[0165] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing devices can be connected to the user's computing device via any type of network (including local area networks (LANs) or wide area networks (WANs); or they can be connected to external computing devices, for example, via the Internet using an Internet service provider.

[0166] In an exemplary embodiment of this disclosure, an electronic device is also provided, the electronic device including at least one processor and at least one memory for storing executable instructions of the processor; wherein the processor is configured to perform the method steps of the exemplary embodiments described above in this disclosure by executing the executable instructions.

[0167] The electronic device 1400 in this exemplary embodiment will now be described with reference to FIG14. The electronic device 1400 is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0168] Referring to Figure 14, the electronic device 1400 is presented in the form of a general-purpose computing device. The components of the electronic device 1400 may include, but are not limited to: at least one processing unit 1410, at least one storage unit 1420, a bus 1430 connecting different system components (including the processing unit 1410 and the storage unit 1420), and a display unit 1440.

[0169] The storage unit 1420 stores program code, which can be executed by the processing unit 1410, causing the processing unit 1410 to perform the method steps in the above exemplary embodiments of this disclosure.

[0170] Storage unit 1420 may include readable media in the form of volatile storage units, such as random access memory unit 1421 (RAM) and / or cache memory unit 1422, and may further include read-only memory unit 1423 (ROM).

[0171] Storage unit 1420 may also include a program / utility 1424 having a set (at least one) of program modules 1425, such program modules including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0172] Bus 1430 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0173] Electronic device 1400 can also communicate with one or more external devices 1500 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that allow a user to interact with electronic device 1400, and / or with any device that enables electronic device 1400 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 1450. Furthermore, electronic device 1400 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1460. As shown in Figure 14, network adapter 1460 can communicate with other modules of electronic device 1400 via bus 1430. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 1400, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0174] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0175] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0176] The features, structures, or characteristics described above can be combined in any suitable manner in one or more embodiments, and the features discussed in the various embodiments are interchangeable where possible. In the above description, numerous specific details are provided to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of the specific details, or other methods, components, materials, etc., can be employed. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.

Claims

1. The threat monitoring method for blockchain hosts includes: - Monitoring host traffic on the communication network and determining whether the traffic is malicious; - Responding if the traffic is found to be malicious by acknowledging the host's security state and logging the security state information in the blockchain security state; and - Creating an intrusion event log corresponding to the malicious traffic and logging the intrusion event log, including the security state information, in the blockchain event log storage.

2. The threat monitoring method for blockchain hosts under Claim 1, where traffic is determined to be malicious, includes: - Performing traffic feature classification to recognize the traffic characteristics of the traffic;- Feeding traffic attribute values ​​into a pre-learned support vector machine model to identify the data types of the traffic data. The support vector machine model contains data types that include normal traffic and malicious traffic.

3. Threat monitoring method for blockchain-based hosts under claim 2, where traffic attribute recognition operations to recognize traffic attributes include: - Recognizing protocol traffic in the application layer from traffic data and performing protocol traffic attribute recognition in the application layer to recognize protocol traffic attributes from the protocol traffic in the application layer; - Responding when a file object is found in the protocol traffic in the application layer and performing object file attribute recognition to recognize the file object attributes of the file object; - Executing the file object within the host's sandbox and determining the file data management attributes associated with the host based on the results of the operation;and - defining the traffic attributes of traffic data based on the protocol traffic attributes, object file attributes, and file data management attributes.

4. Threat monitoring method for blockchain hosts under claim 1, where the recognition of the host's security state information includes: - recognizing the host's operational state information; and - defining the host's security state information based on malicious operational state information and traffic.

5. Threat monitoring method for blockchain hosts under claim 4, where the determination of the host's security state information based on malicious operational state information and traffic includes: - performing operational state attribute classification to recognize the host's state attributes; and - defining traffic attributes corresponding to malicious traffic;And - feeding state attribute and traffic attribute values ​​into a pre-learned random forest model to recognize the host's security state information.

6. Threat monitoring method for blockchain hosts under claim 1, where security state logging in the blockchain security state includes: - logging the host's network ID and security state information into the block body of the current security state block for regulatory validation; - recognizing the block header information of the previous security state block in the security state blockchain and recognizing the main block's hash value by calculating it based on the block header information to meet the block creation conditions; - calculating the hash value of the block body of the current security state block based on the information logged in the block body of the current block; - logging the main block's hash value, the block body's hash value, and the current time timestamp into the block header of the current security state block;And - publish the current security state block to the security state blockchain network to perform regulatory validation on the current security state block and link the current security state block to the security state blockchain upon successful validation.

7. Threat monitoring method for blockchain hosts under claim 1, where the logging of intrusion events, including security state information, is stored in the blockchain event log storage unit, including: - Logging the host's network ID, intrusion event logs, and security state information into the block body of the current event log block for regulatory validation; - Recognizing the block header information of the event log block that occurred in the event log blockchain and recognizing the main block's hash value by calculating it based on the block header information to meet the block creation conditions;- Calculating the hash value of the event log block content based on the information stored in the event log block content; - Recording the main block's hash value, the block content's hash value, and the current time's timestamp into the event log block header; and - Publishing the event log block to the event blockchain network for regulatory validation and linking the event log block to the event blockchain upon successful validation.

8. Threat monitoring tools for blockchain hosts include: - A traffic monitoring unit configured to monitor host traffic on the communication network and determine whether the traffic is malicious;- A security state log unit configured to sense the host's security state information and log the security state information to the blockchain security state if the traffic is found to be malicious; and - an event log unit configured to create an intrusion event log corresponding to malicious traffic and log the intrusion event log, including the security state information, to the blockchain event log storage.

9. Computer media for reading values ​​on which computer programs are installed, which are configured to be executed under any of rights 1 through 7 when ordered by the processor.

10. Electronic device consisting of: - a processor; - memory configured to store executable instructions which are executed by order of the processor, where the processor is configured to perform the operation under any of rights 1 through 7, executing the executable instructions;

Images