A distributed multi-modal safety monitoring method, device and medium

Abstract

The application discloses a distributed multi-mode security monitoring method and device and a medium, and relates to the technical field of operation and maintenance, which comprises the following steps: reading operation mode parameters when a node device starts and determining a current mode; if the current mode is a single-machine mode, initializing a local database, a traffic collection interface and an analysis engine, realizing a closed loop of traffic collection, analysis and storage; if the current mode is a probe mode, initializing the traffic collection interface and a lightweight analysis engine as a probe node, connecting a management center, collecting traffic, detecting abnormal behavior data records and sending the abnormal behavior data records to the management center; and if the current mode is a management center mode, initializing a receiving service and a deep analysis engine as a management center node, receiving abnormal behavior data records from other probes and performing deep correlation analysis to generate global alarms. The application can flexibly adapt to security monitoring deployment of different network scales.

Description

Technical Field

[0001] This invention relates to the field of operation and maintenance technology, and in particular to a distributed multi-mode security monitoring method, device and medium. Background Technology

[0002] In the field of network security monitoring, selecting a suitable deployment architecture based on network scale and business needs is a core challenge. Small network environments typically tend to centralize data collection, analysis, and storage functions on a single server. This standalone model effectively reduces hardware costs, but its limited single-node processing capacity makes it prone to becoming a performance bottleneck when facing large-scale traffic. Large enterprise networks, on the other hand, more widely adopt a distributed deployment model, with multiple data collection nodes responsible for traffic collection and data aggregation to a central server for unified analysis. While this architecture improves horizontal scalability, it also introduces communication complexity, often requiring reliance on external message queues or remote procedure call frameworks for data transmission between nodes. Furthermore, in a distributed environment, it is difficult to maintain consistent configuration information across nodes. When policies change at the central end, remote data collection nodes cannot update in a timely manner, potentially leading to rule execution deviations. Moreover, because these two mainstream deployment models are disconnected, security managers must predetermine the network scale during the actual selection process. Once deployed, flexible adjustments are difficult, resulting in significant reconstruction costs when expanding or reducing nodes, and an inability to dynamically adapt to business changes. Summary of the Invention

[0003] This invention provides a distributed multi-mode security monitoring method, device, and medium, aiming to solve the technical problem of how to provide a security monitoring deployment solution that can flexibly adapt to different network sizes.

[0004] In a first aspect, the present invention provides a distributed multi-mode security monitoring method, executed by node devices in a security monitoring system, comprising: At startup, the running mode parameter in the configuration file is read to determine the current running mode; If the current operating mode is standalone mode, the node device initializes the local database connection, traffic acquisition interface and analysis engine to perform local traffic acquisition, local anomaly analysis and independent security monitoring of local storage; If the current operating mode is probe mode, the node device operates as a probe node, initializes the traffic acquisition interface and lightweight analysis engine, establishes a communication connection with the management center, collects network traffic data, detects the network traffic data through the lightweight analysis engine to generate abnormal behavior data records, and sends the abnormal behavior data records to the management center through the communication connection. If the current operating mode is the management center mode, the node device runs as a management center node, initializes the receiving service and the deep analysis engine, receives abnormal behavior data records from one or more other probe nodes through the receiving service, and performs deep correlation analysis on the abnormal behavior data records through the deep analysis engine to generate a global alarm.

[0005] Secondly, the present invention also provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0006] Thirdly, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0007] This invention provides a distributed multi-mode security monitoring method, device, and medium. By introducing a multi-mode architecture driven by operating mode parameters, it effectively solves the challenge of flexible deployment of security monitoring systems across different network scales. Specifically, this method enables a single node device to adaptively select and execute three preset modes based on a single parameter in a configuration file. For small networks, the node device operates in standalone mode, independently completing traffic collection, local anomaly analysis, and local storage, forming a closed-loop security monitoring unit. For large-scale networks, the node device can switch to probe mode, responsible for lightweight data collection and analysis, and reporting abnormal data to the management center; or switch to management center mode, aggregating data from multiple probes for in-depth correlation analysis and generating global alarms. This configuration-based dynamic mode switching mechanism allows the same software system to seamlessly adapt to the needs of all scenarios, from small single-site networks to large enterprise networks, significantly improving the flexibility and adaptability of security monitoring deployment and reducing the cost of maintaining multiple system architectures for networks of different sizes. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 A flowchart illustrating a distributed multi-mode security monitoring method provided in an embodiment of the present invention; Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0010] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0011] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0012] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0013] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0014] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0015] Please see Figure 1 This invention provides a distributed multi-mode security monitoring method, which is executed by node devices in a security monitoring system. By reading the operating mode parameters in the configuration file, it flexibly switches between stand-alone mode, probe mode, and management center mode to adapt to the needs of network deployments of different scales. Specifically, the method includes the following steps: S1, upon startup, reads the running mode parameters from the configuration file to determine the current running mode.

[0016] In practice, when a node device starts up, it reads the operating mode parameter from the configuration file to determine the current operating mode. The configuration file is stored in the node device's non-volatile storage medium, typically in a standard format (such as JSON or XML). Further, the operating mode parameter is a predefined enumeration value used to identify the node device's role. For example, a parameter value of "0" represents standalone mode, "1" represents probe mode, and "2" represents management center mode. The node device determines its current operating mode based on this parameter value.

[0017] Furthermore, based on the current operating mode, the node device selects and executes the corresponding processing branch.

[0018] S2, If the current operating mode is stand-alone mode, the node device initializes the local database connection, traffic acquisition interface and analysis engine to perform local traffic acquisition, local anomaly analysis and independent security monitoring of local storage.

[0019] In specific implementation, when the current operating mode is standalone mode, the node device initializes the local database connection, traffic acquisition interface, and analysis engine. Further, the node device captures network packets from the local network interface through the traffic acquisition interface, which is typically implemented based on library functions provided by the operating system, such as the libpcap library in Linux systems. Further, the node device inputs the network packets into the analysis engine for local anomaly analysis. The analysis engine detects abnormal behavior in network traffic based on preset intrusion detection rules or behavioral models. The intrusion detection rules can be a rule set based on signature matching or a behavioral model based on machine learning; this invention does not specifically limit this. Further, after the analysis is completed, the node device writes the analysis results and raw traffic data into a local database for persistent storage. The local database can be SQLite or an embedded database.

[0020] In one optional implementation, when employing a machine learning-based behavioral model, the analysis engine can be configured to be implemented based on an unsupervised anomaly detection model such as an autoencoder or an isolated forest. Taking an autoencoder model as an example, the model input is a preprocessed traffic feature vector, including statistical features such as packet rate, byte rate, protocol type distribution, and connection duration within a unit time window. The model architecture includes an encoder and a decoder. The encoder compresses the input features into a low-dimensional latent representation, and the decoder reconstructs the latent representation back to the original input. Anomalies are determined by calculating the reconstruction error. Furthermore, the model is trained unsupervised, using only normal traffic data, with mean squared error as the loss function. The optimizer can be an adaptive moment estimation optimizer. Further, after training, the analysis engine extracts the aforementioned traffic feature vector from real-time traffic during the inference phase, inputs it into the model to calculate the reconstruction error, and determines abnormal behavior when the reconstruction error exceeds a preset threshold.

[0021] Furthermore, in standalone mode, the node device does not establish distributed communication connections with any other nodes, forming a completely independent closed-loop security monitoring system, which is suitable for security protection scenarios of small networks or independent devices.

[0022] S3, if the current operating mode is probe mode, the node device operates as a probe node, initializes the traffic acquisition interface and lightweight analysis engine, establishes a communication connection with the management center, collects network traffic data, detects the network traffic data through the lightweight analysis engine to generate abnormal behavior data records, and sends the abnormal behavior data records to the management center through the communication connection.

[0023] In specific implementation, when the current operating mode is probe mode, the node device operates as a probe node. The core idea of ​​probe mode is to deploy data acquisition and lightweight analysis close to the data source, while centralizing complex analysis and global decision-making at the management center, thereby achieving distributed deployment and centralized management. Specifically, the node device initializes the traffic acquisition interface and lightweight analysis engine, and executes the step of establishing a communication connection with the management center. The lightweight analysis engine is a trimmed and optimized detection engine with low computational resource consumption, suitable for resource-constrained deployment environments, such as embedded devices or low-power gateways. Further, the node device collects network traffic data through the traffic acquisition interface, inputs the network traffic data into the lightweight analysis engine for detection, and generates abnormal behavior data records when abnormal behavior is detected. Further, the node device sends the abnormal behavior data records to the management center through the established communication connection, where the management center performs further in-depth analysis and global judgment.

[0024] In some preferred embodiments, establishing a communication connection with the management center includes: reading the management center address in the configuration file; creating a communication client instance based on the management center address and starting an independent connection maintenance thread; and establishing a communication connection with the management center through the communication client instance to obtain a communication connection object.

[0025] In this implementation, a customized distributed communication client was used to establish an efficient and reliable communication link between the probe nodes and the management center. The specific implementation method is as follows: First, the management center address is read from the configuration file. This address, stored in the configuration file, consists of an Internet Protocol (IP) address and a port number, for example, "192.168.1.100:8080". This address uniquely identifies the network location of the management center, where the IP address is used to locate the host at the network layer, and the port number is used to locate the service process at the transport layer.

[0026] Furthermore, a communication client instance is created based on the management center address. This communication client instance is an object that encapsulates all the resources required for communication with the management center, including socket handles, input / output buffers, connection status flags, and callback function pointers. Furthermore, the communication client instance is managed using a singleton pattern, meaning that only one communication client instance exists throughout the entire lifecycle of the node device.

[0027] The Singleton pattern is a software design pattern whose core idea is to ensure that a class has only one instance and provides a single global access point. In distributed communication scenarios, the Singleton pattern ensures that there is only one communication connection object globally, avoiding resource contention and data inconsistency issues caused by multiple connection instances. When creating a communication client instance, the node device is configured with necessary information such as the application identifier, the server's Internet Protocol address, and port parameters.

[0028] Furthermore, a separate connection maintenance thread is launched. This connection maintenance thread is a background daemon thread, bound to the communication client instance, and responsible for subsequent connection status monitoring and maintenance. This thread runs independently of the main business logic thread and will not block traffic collection and data analysis processes. In the software architecture, separating network connection maintenance functionality into a separate thread is a typical separation of concerns design pattern, which can prevent the main business thread from being affected by network jitter.

[0029] Furthermore, a communication connection is established between the communication client instance and the management center to obtain a communication connection object. The specific process of establishing the connection includes: the communication client instance initiating a three-way handshake request to the management center's address using the Transmission Control Protocol (TCP). TCP is a connection-oriented, reliable transport layer protocol; establishing a connection through a three-way handshake ensures that both parties are ready for data transmission. After a successful handshake, the management center's receiving service accepts the connection and allocates a socket handle. The communication client instance encapsulates this socket handle into a communication connection object, which includes connection status flags, input / output stream buffers, and callback function pointers. Further, the connection status flags indicate whether the current connection is available; for example, a status value of "1" indicates a connected connection, and "0" indicates an unconnected connection. The callback function pointer is used to notify the upper-layer application when the connection status changes; for example, when the connection is broken, the callback function can trigger data caching or reconnection logic.

[0030] This embodiment manages communication client instances using a singleton pattern, ensuring the uniqueness and consistency of global communication resources and avoiding connection chaos caused by multiple concurrent instances. Furthermore, a separate connection maintenance thread decouples connection status monitoring from business logic, allowing node devices to smoothly switch data reporting paths when connections are established or terminated without affecting normal traffic collection and analysis. This decoupling design significantly improves system stability in complex network environments.

[0031] In some preferred embodiments, the connection maintenance thread performs the following operations: determines the connection status of the communication connection object; if the connection status is connected, the communication connection is maintained; if the connection status is disconnected, a periodic reconnection operation is performed until the connection is successful or a stop command is received.

[0032] In practice, this embodiment solves the problem of automatic recovery after connection interruption between probe nodes and the management center due to network jitter or node restart by introducing periodic detection and automatic reconnection mechanisms in the connection maintenance thread. The specific implementation method is as follows: First, the connection maintenance thread performs monitoring operations periodically according to a preset cycle. This cycle can be configured based on the stability of the network environment, for example, set to 30 seconds. During each monitoring cycle, the connection maintenance thread reads the current connection status flag from the communication connection object.

[0033] Furthermore, the connection status of the communication connection object is determined. This determination is based on the value of the connection status flag. When the flag value is "connected," it indicates that the socket is normal and the data transmission and reception channel is available; when the flag value is "not connected," it indicates that the socket is closed or the communication link is broken. This determination operation can verify the authenticity and validity of the connection by checking the readability of the socket or sending a heartbeat packet.

[0034] Furthermore, if the connection status is "connected," the communication connection is maintained. The connection maintenance thread performs no operation and directly enters an idle waiting state until the next monitoring cycle arrives. Further, to ensure the connection does not break due to idle timeouts of intermediate devices (such as firewalls or routers), the connection maintenance thread can perform keep-alive operations, such as periodically sending heartbeat messages to verify the connection's validity. The heartbeat message is a short data packet that does not carry business data and is only used to verify link connectivity. If the heartbeat response times out, the status is forcibly marked as "connected."

[0035] Furthermore, if the connection status is disconnected, a periodic reconnection operation is performed. The specific steps of the reconnection operation are as follows: First, the connection maintenance thread calls the close interface of the communication client instance to release currently invalid socket resources and clear the input / output buffers to avoid resource leaks; second, the thread reads the management center address stored in the configuration file and re-initiates the three-way handshake request of the transmission control protocol; third, the thread determines whether the connection is successful. If the handshake is successful, the connection status flag of the communication connection object is updated to "connected," and the data reporting channel is restored; if the handshake fails, the thread waits for a preset backoff interval, such as 5 seconds, and then repeats the above reconnection attempt. The backoff interval can adopt a fixed time or an exponential backoff strategy. The exponential backoff strategy means that the waiting time is doubled after each reconnection failure, for example, from 5 seconds to 10 seconds, 20 seconds, and so on, to avoid the additional load caused by frequent reconnections during network failures.

[0036] Furthermore, the reconnection operation will continue until the connection is successful or the node device receives an explicit stop command, which can be manually triggered by the user or a system shutdown signal.

[0037] This embodiment uses an independent connection maintenance thread to periodically monitor connection status and automatically perform reconnection operations. This allows probe nodes to automatically resume data reporting after the management center service restarts, network equipment fails, or intermediate link experiences intermittent interruptions, without manual intervention. Furthermore, periodic keep-alive message verification further improves the accuracy of connection status detection, avoiding false positives or false negatives. Moreover, when the network is unstable, an exponential backoff strategy reconnection mechanism avoids the waste of network resources caused by frequent reconnections. This automatic reconnection mechanism significantly improves the fault tolerance and operational automation level of the distributed monitoring system, ensuring the continuity and integrity of monitoring data.

[0038] In some preferred embodiments, sending the abnormal behavior data record to the management center via the communication connection includes: serializing the abnormal behavior data record to obtain abnormal behavior serialized data; and sending the abnormal behavior serialized data to the management center via the established communication connection.

[0039] In practice, this embodiment achieves reliable transmission of structured data over the network through serialization processing and transport layer encapsulation. The specific implementation method is as follows: First, the probe node serializes the generated abnormal behavior data records to obtain serialized abnormal behavior data. Serialization is the process of converting data structures or object states in memory into a storable or transmittable byte sequence. In distributed systems, serialization is a fundamental technology for enabling cross-process and cross-network data exchange. In this embodiment, the serialization process uses a predefined serialization format, such as Protocol Buffers or a lightweight binary serialization format, to encode each structured field in the abnormal behavior data record into a compact byte array.

[0040] Furthermore, the abnormal behavior data record, as a structured data object, typically includes the following core fields: an anomaly type identifier, indicating the specific category of the anomaly, such as port scanning, malware communication, or distributed denial-of-service attacks; an occurrence timestamp, usually accurate to milliseconds or microseconds, used to record the time of occurrence of the abnormal event; the Internet Protocol address and Media Access Control address of the associated device, used to locate the affected network device; and a traffic feature vector, such as statistical features like packet size distribution, packet rate, and protocol type proportion, used to describe the behavioral patterns of the abnormal traffic. Further, serialization converts the complex data structure with the above multiple fields into a continuous byte array, i.e., the abnormal behavior serialized data. After serialization, the size of the abnormal behavior serialized data is typically significantly smaller than the original structured object, compressible to 30% to 50% of its original size. This compression effect benefits from the compact encoding of the data types; for example, integer data uses variable-length encoding, and strings are stored using length prefix encoding.

[0041] Furthermore, after serialization, the probe node sends the abnormal behavior serialized data to the management center through the established communication connection. The specific sending process is as follows: the probe node obtains the output stream buffer of the communication connection object, writes the abnormal behavior serialized data into the buffer, and then calls the underlying socket's send function to encapsulate and send the abnormal behavior serialized data as the payload of a Transmission Control Protocol (TCP) data packet. Further, after sending, the probe node waits for an acknowledgment message from the management center. If no acknowledgment is received within a preset timeout period, such as 10 seconds, the application layer retransmission mechanism is triggered to resend the data packet. Furthermore, the TCP itself provides a reliable byte stream transmission service, ensuring on-order arrival and lossless delivery of data. The application layer acknowledgment mechanism in this embodiment further enhances the reliability of data transmission, especially in scenarios with large data volumes or unstable network environments.

[0042] This embodiment transforms complex internal data structures into compact anomaly behavior serialization data through serialization, significantly reducing network transmission overhead, making it particularly suitable for probe deployment environments with limited bandwidth. As independent data objects, the anomaly behavior serialization data is clearly named to distinguish its state differences from the original anomaly behavior data records, making the transformation relationships in the data stream readily apparent. Furthermore, the serialized data supports cross-platform parsing; regardless of the hardware architecture or operating system running on the probe nodes and management center nodes (e.g., Linux, Windows, or embedded systems), the original data can be correctly restored, achieving platform-independent interoperability. The data packet encapsulation and acknowledgment retransmission mechanisms at the transport layer ensure reliable data delivery in unreliable network environments, avoiding data loss or out-of-order issues, and ensuring that the management center receives complete anomaly event information.

[0043] In some preferred embodiments, generating abnormal behavior data records includes: classifying and encapsulating detected abnormal behaviors to obtain initial abnormal records; associating the initial abnormal records with corresponding network devices through device information queries to obtain device association records; and performing duplicate alarm filtering on the device association records to obtain the abnormal behavior data records.

[0044] In practice, this embodiment achieves lightweight preprocessing of abnormal behavior data by performing classification and encapsulation, device association, and duplicate alarm filtering at the probe end, thereby reducing the processing pressure on the management center. The specific implementation method is as follows: The probe nodes classify and encapsulate detected abnormal behaviors to obtain initial anomaly records. The classification operation is performed based on a predefined anomaly type mapping table, which defines the correspondence between anomaly features and anomaly types. For example, the behavior of a source Internet Protocol address sending synchronization packets to multiple target ports within a short period (e.g., within 1 second) is classified as port scanning; Domain Name System (DNS) queries initiated to known malicious domains are classified as malware communication; and the behavior of a large number of data packets flooding a specific target in a short period is classified as a distributed denial-of-service (DDoS) attack. The encapsulation operation packages the classification results, the original 5-tuple information (source IP, destination IP, source port, destination port, protocol type), timestamps, and feature vectors into a structured data object, called the initial anomaly record.

[0045] Furthermore, by querying device information, the initial anomaly record is associated with the corresponding network device to obtain a device association record. The specific method for device information querying is as follows: The probe node maintains a local device fingerprint database, which stores metadata such as the Internet Protocol address, Media Access Control address, device type (e.g., router, switch, server, terminal device), operating system version, and physical location of all known devices in the network. The probe node extracts the source or target Internet Protocol address from the initial anomaly record, performs a matching search in the device fingerprint database, and after finding the corresponding device information, appends the device information to the initial anomaly record to form a device association record. This device information provides valuable context for the management center, enabling subsequent analysis to accurately locate affected assets and providing crucial clues for attack tracing.

[0046] Further, duplicate alarm filtering is performed on the device-associated records to obtain the abnormal behavior data records. Duplicate alarm filtering is a common noise reduction technique in network security monitoring systems. Its core idea is to avoid reporting the same alarm information multiple times for the same abnormal event within a short time window. Specifically, the probe node maintains a recently processed anomaly feature fingerprint hash table. The key of the hash table is the anomaly feature fingerprint, and the value is the most recent processing timestamp. The anomaly feature fingerprint is a digest value obtained by hashing key fields in the device-associated record. Key fields typically include anomaly type, source Internet Protocol address, destination Internet Protocol address, and destination port. For a new device-associated record, the probe node calculates its feature fingerprint. If the feature fingerprint exists in the hash table, and the difference between the current time and the timestamp stored in the hash table is less than a preset filtering window period (e.g., 30 seconds), it is determined to be a duplicate alarm, and the record is discarded. If the feature fingerprint does not exist or the time difference exceeds the filtering window period, the record is output as an abnormal behavior data record, and the feature fingerprint and timestamp are updated in the hash table. This time-window-based filtering mechanism can effectively suppress sudden, recurring alarm storms while ensuring that no real anomalies that cross the window period are missed.

[0047] This embodiment performs lightweight data preprocessing before data reporting by performing classification and encapsulation, device association, and duplicate alarm filtering at the probe end. Device association provides rich contextual information for subsequent in-depth analysis by the management center, enabling it to quickly locate affected devices and improving attack tracing efficiency. Furthermore, the duplicate alarm filtering mechanism significantly reduces the amount of data reported to the management center. Taking a 30-second window as an example, duplicate alarm filtering can reduce redundant data by more than 80%, effectively reducing network bandwidth consumption and computational processing pressure on the management center. This allows the probe end to adapt to resource-constrained deployment environments, such as embedded devices or low-power gateways.

[0048] S4. If the current operating mode is the management center mode, the node device runs as a management center node, initializes the receiving service and the deep analysis engine, receives the abnormal behavior data records from one or more other probe nodes through the receiving service, and performs deep correlation analysis on the abnormal behavior data records through the deep analysis engine to generate a global alarm.

[0049] In specific implementation, when the current operating mode is management center mode, the node device operates as a management center node. Management center mode aggregates and deeply analyzes scattered abnormal events from multiple probe nodes to obtain a global security posture. The node device initializes a receiving service and a deep analysis engine. The receiving service is a network service process that listens on a specific port to accept connection requests and data transmissions from probe nodes, typically implemented based on a transmission control protocol. Further, through the receiving service, the node device receives abnormal behavior data records from one or more other probe nodes. Further, the node device inputs the abnormal behavior data records into the deep analysis engine, which performs deep correlation analysis on the abnormal behavior data records. The deep analysis engine can perform attack behavior identification across time, devices, and protocols, and generate global alarms and statistical reports.

[0050] This embodiment achieves flexible switching between standalone, probe, and management center modes for the same software architecture by dynamically reading operating mode parameters. Standalone mode provides complete closed-loop monitoring capabilities for small-scale scenarios, probe mode offers lightweight data acquisition and preprocessing capabilities for distributed deployments, and management center mode provides centralized in-depth analysis and situational awareness capabilities for large-scale networks. Furthermore, the three modes cover the full range of needs from small single-site networks to large enterprise networks. Users only need to modify one parameter in the configuration file to complete the deployment mode conversion, without replacing hardware or reinstalling software, significantly reducing deployment and maintenance costs.

[0051] In some preferred embodiments, the step of performing deep correlation analysis on the abnormal behavior data records through the deep analysis engine to generate a global alert includes: receiving abnormal behavior serialized data from one or more other probe nodes through the receiving service; deserializing the received abnormal behavior serialized data to obtain the abnormal behavior data records; verifying the abnormal behavior data records; writing the verified abnormal behavior data records into persistent storage; performing cross-device correlation analysis on the verified abnormal behavior data records to identify attack behaviors; and generating a global alert and statistical report based on the identified attack behaviors.

[0052] In practice, this embodiment achieves the goal of extracting the global attack situation from massive probe reporting data through a full-process processing of receiving, deserializing, verifying, storing, and correlating the data. The specific implementation method is as follows: First, the management center node receives serialized abnormal behavior data from one or more other probe nodes via a receiving service. This receiving service, a long-running network service process, maintains a listening socket and continuously accepts connection requests from probe nodes. When a new connection is established, the receiving service allocates an independent session thread for each probe node to handle its data transmission and reception. This multi-threaded design allows for concurrent processing of data reports from multiple probes, improving system throughput and response speed. The receiving service then reads byte stream data from the network socket; this data represents the serialized abnormal behavior data sent by the probe nodes.

[0053] Furthermore, upon receiving the serialized data of abnormal behavior, the management center node deserializes the serialized data to obtain the abnormal behavior data record. Deserialization is the reverse process of serialization, and its function is to restore the byte array into an internal data structure operable by the application. Specifically, the deserialization process parses the original values ​​of each field from the byte array according to the same predefined serialization format as the probe node, and reconstructs it into a structured data object. Further, after deserialization, the management center node obtains a complete abnormal behavior data record, which contains all fields such as abnormality type, timestamp, device information, and traffic characteristics, and can be directly used for subsequent analysis and processing.

[0054] Furthermore, after obtaining the abnormal behavior data record, the management center node verifies the data record. Verification is a crucial step in ensuring data reliability in this embodiment, specifically including three aspects: First, checking data integrity by verifying whether the digital signature or checksum of the data packet matches the pre-calculated value to confirm that the data has not been tampered with during transmission; second, checking data format compliance to confirm that all required fields exist and their values ​​are within legal ranges, such as timestamps must be within a reasonable time range and Internet Protocol addresses must be in a valid address format; third, checking the credibility of the data source to confirm that the data comes from a trusted probe node, for example, by verifying the probe node's digital certificate or pre-shared key. These three dimensions of verification together constitute the data credibility assessment system, ensuring that the data entering the analysis engine is complete, standardized, and trustworthy.

[0055] Furthermore, after successful verification, the management center node writes the verified abnormal behavior data records to persistent storage. Persistent storage can be a relational database or a time-series database. The write operation stores each abnormal behavior data record as a row in the database table, containing a complete copy of all fields. Upon completion of the write, the database returns a success flag, indicating that the data has been securely persisted to disk. Persistent storage not only provides a data source for subsequent correlation analysis but also provides a reliable data foundation for post-event evidence collection and compliance audits, ensuring that complete information on historical abnormal events can be traced when needed.

[0056] Furthermore, after data storage is completed, the management center node performs cross-device correlation analysis on the verified abnormal behavior data records to identify attack behaviors. Cross-device correlation analysis is the core function of the deep analysis engine. Its basic idea is to aggregate isolated abnormal events from multiple probe nodes in both time and space dimensions, thereby discovering complex attack patterns that cannot be detected from a single probe perspective. The specific execution process is as follows: First, all abnormal behavior data records within a certain time window are read from the database. The time window can be configured according to actual needs, such as the past 1 hour or 24 hours. Further, in the time dimension, abnormal events with the same source Internet Protocol address or the same attack type are arranged chronologically to form an attack timeline, thereby identifying the stages and evolution trends of the attack. Further, in the spatial dimension, abnormal events from different probe nodes are aggregated according to the target device's Internet Protocol address or geographical location to identify whether there are lateral movement or coordinated attack patterns. For example, when multiple probe nodes report similar abnormal characteristics at similar times, the management center can infer that the attacker is performing a distributed denial-of-service attack or worm scanning. Furthermore, when an abnormal event reported by one probe node is causally related to an abnormal event reported by another probe node in terms of time, the management center can infer that the attacker is carrying out a multi-stage attack, such as scanning first and then exploiting.

[0057] Furthermore, based on the identified attack behaviors, the management center node generates global alerts and statistical reports. Global alerts typically include key information such as attack type, attack source Internet Protocol address, list of affected devices, and attack time range, and are pushed to security operations personnel via email, SMS, or API for timely response and handling. The statistical reports summarize attack trends, device risk levels, and anomaly event distribution statistics, presented in charts or tables for security decision-making and compliance auditing.

[0058] This embodiment enables the management center to correctly process compressed data from probe nodes by receiving and deserializing serialized abnormal behavior data. Furthermore, the deserialized abnormal behavior data records can be directly used for verification and in-depth analysis, ensuring the consistency and accuracy of data processing. Furthermore, cross-device correlation analysis technology can discover complex attack patterns that are imperceptible from a single probe perspective, such as multi-stage attacks, lateral movement, and coordinated attacks, improving the overall situational awareness capability of security monitoring. Furthermore, persistent storage provides a reliable data foundation for post-event forensics and compliance audits, while global alarms and statistical reports provide intuitive data support for security decisions and responses. Furthermore, through this embodiment, the management center can extract valuable data from massive amounts of serialized abnormal behavior data reported by probes, achieving a complete closed loop from data acquisition to situational awareness.

[0059] In some preferred embodiments, the method further includes a configuration synchronization process, which includes: periodically checking the set of database table changes to be processed in an independent monitoring thread; when the set to be processed is detected to be non-empty, extracting all table names to be processed; performing a corresponding refresh operation based on the table name, the refresh operation including: if the table name corresponds to a topology range table, reloading the topology discovery range configuration; if the table name corresponds to an alarm configuration table, reloading the alarm configuration from the distributed cache; if the table name corresponds to an access whitelist table, reloading the threat device whitelist; if the table name corresponds to an application service table, reloading the custom protocol identification rules; and after performing the refresh operation, clearing the processed table names.

[0060] In practice, this embodiment solves the problem of inconsistent configuration information among nodes in a distributed deployment environment by automatically triggering configuration refresh operations through background monitoring of database table changes. The specific implementation method is as follows: The node device starts an independent monitoring thread in the background, which executes according to a preset cycle, such as 60 seconds. This monitoring thread is separate from core business threads such as traffic collection and data analysis, and will not affect the performance of the main process. The monitoring thread executes independently of the current operating mode; that is, whether in standalone mode, probe mode, or management center mode, this thread will continue to run in the background to ensure real-time synchronization of configurations.

[0061] Furthermore, the monitoring thread periodically checks the set of database table changes to be processed. This set is a first-in, first-out queue, its data structure being a list containing table names, protected against concurrent access by a mutex lock. The mutex lock is a synchronization mechanism used to ensure that only one thread can access the protected data at any given time, thus preventing data contention under concurrent conditions. Whenever an insert, update, or delete operation occurs in a database table in the system, the database change notification module adds the corresponding table name to the set to be processed. The database tables include, but are not limited to, a topology range table, an alarm configuration table, an access whitelist table, and a custom protocol identification rule table. These tables store different categories of configuration information; for example, the topology range table stores the network segment or subnet range that the probe node should monitor, the alarm configuration table stores alarm rule thresholds, alarm levels, and notification methods, the access whitelist table stores a list of known legitimate device addresses, and the custom protocol identification rule table stores pattern rules used to identify non-standard or private protocols.

[0062] Furthermore, when the monitoring thread detects that the set to be processed is not empty, it extracts all the table names to be processed. The extraction operation uses atomic operations, retrieving the entire list at once and clearing the original queue to avoid duplicate processing. Atomic operations are indivisible operations that either complete entirely or are not executed at all, ensuring operational consistency.

[0063] In one specific embodiment, when the system is deployed in a management center mode, the management center node also maintains a distributed cache component. This distributed cache centrally stores and manages configuration information shared by all nodes, including alarm configurations, threat device whitelists, and custom protocol identification rules. Further, the distributed cache can be implemented using a memory-based key-value storage system, with the management center node responsible for writing and updating it. Each probe node reads the latest configuration from the cache through a communication connection with the management center node. Through this distributed cache, when an administrator modifies the configuration in the management center, the updated content can be pushed in real time or periodically retrieved by each node, ensuring the consistency of configuration information in a distributed environment.

[0064] Further, a corresponding refresh operation is performed based on the table name. The specific mapping relationship is as follows: If the table name corresponds to the topology range table, the topology discovery range configuration is reloaded. This configuration defines the network segment or subnet range that the probe node should monitor. After the refresh, the probe will start monitoring newly added or removed subnets. If the table name corresponds to the alarm configuration table, the alarm configuration is reloaded from the distributed cache. The alarm configuration includes alarm rule thresholds, alarm levels, and notification methods. After the refresh, the alarm logic will be executed based on the latest rules. If the table name corresponds to the access whitelist table, the threat device whitelist is reloaded. This whitelist is used to filter known legitimate devices and reduce false alarms. After the refresh, the whitelist takes effect. If the table name corresponds to the application service table, the custom protocol identification rule is reloaded. This rule is used to identify non-standard or private protocol traffic. After the refresh, the new protocol identification rule will take effect.

[0065] Furthermore, after performing the refresh operation, the monitoring thread clears the names of the processed tables. The clear operation removes the processed table names from the pending set to avoid duplicate refreshes. The clear operation also needs to be performed under the protection of a mutex lock.

[0066] This embodiment achieves real-time awareness and automatic synchronization of configuration changes by periodically checking the database table change set through an independent monitoring thread and automatically triggering the reloading of the corresponding configuration. Taking a 60-second check cycle as an example, configuration changes take effect on all nodes within 1 minute, without the need for manual restarts or manual push of configuration files. Furthermore, this mechanism effectively solves the inconsistency problem caused by manual node-by-node configuration in distributed deployment scenarios, ensuring that all nodes execute unified policy rules, improving the system's automated operation and maintenance level and overall security. Furthermore, when a new probe node is added, it automatically pulls the latest configuration from the database after startup, without additional manual intervention, further reducing deployment complexity.

[0067] In some preferred embodiments, the method further includes a mode switching process, which includes: in response to receiving a mode switching instruction, stopping all services and threads in the current operating mode; updating the operating mode parameters in the configuration file; re-executing the system startup steps and returning to the startup process to read the operating mode parameters in the configuration file and determine the current operating mode.

[0068] In practice, this embodiment achieves a smooth transition of node devices between different deployment modes through a complete process of stopping services, updating configurations, and re-initializing. The specific implementation method is as follows: First, upon receiving a mode switching command, the node device stops all services and threads in the current operating mode. This mode switching command can originate from local console input, remote application programming interface (API) calls, or be triggered by a scheduled task. The specific steps for stopping the service are as follows: First, stop the traffic acquisition interface, close the network socket, and release the packet capture buffer; further, shut down the analysis engine, stop all analysis tasks, and release the feature library and status table in memory to prevent memory leaks; further, disconnect established network connections; for probe mode, close the communication connection object with the management center and release socket resources; further, stop the receiving service, close the listening socket, and disconnect all probe node connections.

[0069] Furthermore, the node device updates the operating mode parameter in the configuration file. The update operation modifies the value of the operating mode parameter to the value corresponding to the target mode, for example, changing "1" for the probe mode to "2" for the management center mode. After the update is complete, the node device writes the parameter back to the configuration file to ensure that the parameter is persisted after a restart. Furthermore, the write operation can use atomic write or transactional write to prevent configuration corruption due to unexpected events during the write process.

[0070] Furthermore, the node device re-executes the system startup steps, i.e., re-runs the startup process. Specifically, the node device rereads the operating mode parameters in the updated configuration file, determines the new current operating mode, and then initializes the corresponding services and connections according to the new operating mode. For example, if the new mode is probe mode, the traffic acquisition interface and lightweight analysis engine are re-initialized, and the communication connection with the management center is re-established; if the new mode is management center mode, the receiving service and deep analysis engine are re-initialized.

[0071] Furthermore, the node devices resume data acquisition and processing. Once restored, the node devices operate normally in the new mode, continuing to perform security monitoring tasks. The entire switchover process is transparent to the user, requiring no operating system restart and seamlessly completing the mode transition.

[0072] This embodiment achieves dynamic switching between standalone, probe, and management center modes by receiving mode switching commands at runtime and executing a complete stop, update, and restart process, without requiring redeployment or operating system restart. Taking network expansion scenarios as an example, users can switch multiple standalone nodes to probe mode and deploy a management center node without interrupting existing monitoring tasks, quickly upgrading from a standalone to a distributed architecture. Taking network shrinkage scenarios as an example, users can switch the management center node to standalone mode, reducing resource overhead. Furthermore, this dynamic switching capability significantly improves the system's resource utilization and deployment flexibility, enabling the security monitoring system to flexibly adjust its deployment architecture according to business needs and adapt to constantly changing network environments.

[0073] Please see Figure 2 , Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0074] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0075] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to execute a distributed multi-mode security monitoring method.

[0076] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0077] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a distributed multi-mode security monitoring method.

[0078] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0079] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of a distributed multi-mode security monitoring method provided in any of the above embodiments.

[0080] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0081] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0082] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of the distributed multi-mode security monitoring method provided in any of the above embodiments.

[0083] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0084] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0085] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0086] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0087] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0088] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0089] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, this invention is also intended to include these modifications and variations as long as they fall within the scope of the claims of this invention and their equivalents.

[0090] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A distributed multi-mode security monitoring method, characterized in that, Performed by node devices in the security monitoring system, including: At startup, the running mode parameter in the configuration file is read to determine the current running mode; If the current operating mode is standalone mode, the node device initializes the local database connection, traffic acquisition interface and analysis engine to perform local traffic acquisition, local anomaly analysis and independent security monitoring of local storage; If the current operating mode is probe mode, the node device operates as a probe node, initializes the traffic acquisition interface and lightweight analysis engine, establishes a communication connection with the management center, collects network traffic data, detects the network traffic data through the lightweight analysis engine to generate abnormal behavior data records, and sends the abnormal behavior data records to the management center through the communication connection. If the current operating mode is the management center mode, the node device runs as a management center node, initializes the receiving service and the deep analysis engine, receives abnormal behavior data records from one or more other probe nodes through the receiving service, and performs deep correlation analysis on the abnormal behavior data records through the deep analysis engine to generate a global alarm.

2. The method according to claim 1, characterized in that, The establishment of a communication connection with the management center includes: Read the management center address from the configuration file; Based on the management center address, create a communication client instance and start an independent connection maintenance thread; A communication connection is established between the communication client instance and the management center to obtain a communication connection object.

3. The method according to claim 2, characterized in that, The connection maintenance thread performs the following operations: The connection status of the communication connection object is determined; If the connection status is "connected", then maintain the communication connection; If the connection status is not connected, a periodic reconnection operation is performed until the connection is successful or a stop command is received.

4. The method according to claim 1, characterized in that, The step of sending the abnormal behavior data record to the management center through the communication connection includes: The abnormal behavior data records are serialized to obtain abnormal behavior serialized data. The serialized data of the abnormal behavior is sent to the management center through the established communication connection.

5. The method according to claim 1, characterized in that, The generated abnormal behavior data records include: The detected abnormal behaviors are classified and encapsulated to obtain initial abnormal records; By querying device information, the initial abnormal record is associated with the corresponding network device to obtain the device association record; Duplicate alarm filtering is performed on the device-related records to obtain the abnormal behavior data records.

6. The method according to claim 1, characterized in that, The step of performing deep correlation analysis on the abnormal behavior data records using the deep analysis engine to generate a global alert includes: The receiving service receives serialized data of abnormal behavior from one or more other probe nodes. The received serialized abnormal behavior data is deserialized to obtain the abnormal behavior data record; The abnormal behavior data records are verified; Write the verified abnormal behavior data records to persistent storage; Perform cross-device correlation analysis on the verified abnormal behavior data records to identify attack behaviors; Based on the identified attack behaviors, global alerts and statistical reports are generated.

7. The method according to claim 1, characterized in that, The method further includes configuring a synchronization process, which includes: In a separate monitoring thread, the set of database table changes to be processed is periodically checked; When the set to be processed is detected to be non-empty, extract all table names to be processed; Perform a refresh operation based on the table name. The refresh operation includes: if the table name corresponds to a topology range table, reload the topology discovery range configuration; if the table name corresponds to an alarm configuration table, reload the alarm configuration from the distributed cache; if the table name corresponds to an access whitelist table, reload the threat device whitelist; if the table name corresponds to an application service table, reload the custom protocol identification rules. After performing the refresh operation, the processed table names are cleared.

8. The method according to claim 1, characterized in that, The method further includes a mode switching process, which includes: In response to receiving a mode switching command, all services and threads in the current operating mode are stopped; Update the run mode parameters in the configuration file; Re-execute the system startup steps and return to the startup process, where the running mode parameters in the configuration file are read to determine the current running mode.

9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images