Distributed virtual machine network traffic auditing method and system

Abstract

The invention particularly relates to a distributed virtual machine network traffic auditing method and system. According to the distributed virtual machine network flow auditing method, an administrator submits a mirroring strategy configuration request, a Neutron server analyzes a mirroring strategy, generates an RPC task, and issues generated mirroring strategy data to a DVR-net-mirror-agent of a corresponding computing node; the DVR-net-mirror-agent analyzes the mirror image strategy data, verifies the port information, generates an OVS mirror image rule according to the mirror image strategy data, and calls an OVS interface to configure a flow mirror image rule; the OVS performs mirroring operation on the specified source port traffic; and after receiving the mirror image traffic, the auditing virtual machine performs real-time traffic monitoring and analysis, generates an auditing report according to an analysis result, and provides the auditing report to an administrator for subsequent processing. According to the distributed virtual machine network traffic auditing method and system, efficient and real-time virtual machine network traffic mirroring and monitoring are achieved, strategies can be dynamically adjusted, diversified application requirements are met, and the safety and management efficiency of a data center are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular to a distributed virtual machine network traffic auditing method and system. Background Art

[0002] In recent years, with the widespread application of cloud computing and virtualization technology, distributed network environments have become mainstream. With the large-scale migration of user services to the cloud, various non-business type devices in traditional data centers have also been gradually virtualized and migrated to the cloud. Such as Web Application Firewall (WAF), border firewall, DPI (Deep Packet Inspection) equipment, log audit equipment, etc. After these devices are virtualized, users can dynamically create and deploy them online in the cloud computing management console according to their own needs within the user's VPC, and then pull specific business traffic to one or more non-business type devices to achieve purposes such as security protection, Internet behavior auditing, and daily monitoring.

[0003] However, the simple routing or policy-based service diversion method of traditional data centers does not work properly under large-scale cloud computing platforms based on a fully distributed routing architecture. This is because under a fully distributed routing architecture, the SNAT / DNAT operations of the north-south traffic of the elastic cloud server when entering and exiting the VPC must be performed symmetrically, that is, performed on the VPC virtual router on the physical node where the elastic cloud server is located. The problem this brings is that when the source elastic cloud server of the diversion chain and the non-business type virtual device are located in different physical nodes, the traffic path in and out of the VPC and the source and destination IP addresses in the message are inconsistent, which will cause security devices to be unable to establish sessions normally and communications cannot be established normally.

[0004] The transparent traffic diversion solution based on the full flow table proposed by the OpenStack community for the DVR (Distributed Virtual Router) architecture is extremely invasive to the Layer 2 forwarding logic of the data plane, and requires the issuance of relevant flow tables to all source elastic cloud servers. When users' elastic cloud servers are added or deleted, a large number of interactions between the control plane and the data plane will occur. The scalability is poor and cannot support large-scale scenarios.

[0005] In this environment, traditional traffic mirroring technology is difficult to adapt to the complexity and dynamics of the distributed network environment. Based on the above situation, the present invention proposes a distributed virtual machine network traffic audit method and system. Summary of the invention

[0006] In order to make up for the defects of the prior art, the present invention provides a simple and efficient distributed virtual machine network traffic audit method and system.

[0007] The present invention is achieved through the following technical solutions:

[0008] A distributed virtual machine network traffic audit method comprises the following steps:

[0009] Step S1: The administrator logs in to the Neutron server through the web interface or command line tool, submits a mirror policy configuration request through the Neutron API interface, specifies the source port (mirrored virtual machine port) and the target port (audit virtual machine port), and the Neutron server verifies the submitted policy request to ensure that the port ID in the request is legal and exists;

[0010] Step S2: After receiving the mirroring policy request, the Neutron server parses the mirroring policy, extracts the source port ID and the target port ID, and stores the mirroring policy in the database to ensure the persistence of the mirroring policy.

[0011] Step S3, the Neutron server establishes an RPC connection with the DVR-net-mirror-agent of each computing node, generates an RPC task according to the mirroring strategy, and sends the generated mirroring strategy data, including the source port ID and the target port ID, to the DVR-net-mirror-agent of the corresponding computing node through the RPC interface;

[0012] Step S4: After receiving the mirroring policy, DVR-net-mirror-agent sends a confirmation message to the Neutron server, parses the mirroring policy data, verifies the port information, generates OVS mirroring rules according to the mirroring policy data, calls the OVS interface to configure the traffic mirroring rules, and feeds back information on whether the configuration is successful to the Neutron server.

[0013] Step S5: After the mirroring strategy configuration is completed, OVS performs mirroring operations on the specified source port traffic according to the mirroring rules issued by DVR-net-mirror-agent;

[0014] Step S6: After the audit virtual machine receives the mirrored traffic, it performs real-time traffic monitoring and analysis, generates an audit report based on the analysis results, and provides it to the administrator for subsequent processing.

[0015] The administrator updates the existing image strategy through the API interface. The update process is as follows:

[0016] Step S1.1.1: Submit update request

[0017] The administrator submits a mirror policy update request to modify the source port or target port;

[0018] Step S1.1.2: Policy parsing and storage

[0019] The Neutron server parses the image policy update request and updates the image policy record in the database;

[0020] Step S1.1.3: Issue update strategy

[0021] Send the updated policy to the DVR-net-mirror-agent of each computing node through the RPC interface;

[0022] The administrator deletes the image policy through the API interface. The deletion process is as follows:

[0023] Step S1.2.1: Submit a deletion request

[0024] The administrator submits an image policy deletion request and specifies the policy ID to be deleted;

[0025] Step S1.2.2: Policy analysis and deletion

[0026] The Neutron server parses the image policy deletion request and deletes the corresponding image policy record from the database;

[0027] Step S1.2.3: Issue a deletion instruction

[0028] Send the deletion command to the DVR-net-mirror-agent of each computing node through the RPC interface;

[0029] Step S1.2.4: Clear OVS rules

[0030] After receiving the deletion command, DVR-net-mirror-agent calls the OVS interface to clear the corresponding mirroring rules.

[0031] In step S3, the Neutron server continuously monitors the status of the DVR-net-mirror-agent on each computing node to ensure the effectiveness of the policy execution. The monitoring process is as follows:

[0032] Step S3.1: Status monitoring

[0033] Customize scheduled tasks and obtain status information of each DVR-net-mirror-agent regularly through the RPC interface;

[0034] Step S3.2: Fault detection

[0035] When a DVR-net-mirror-agent exception is detected on a certain node through the heartbeat mechanism, or when an exception message is received from a DVR-net-mirror-agent on a certain node reported to the Neutron server, the fault handling process is triggered;

[0036] Step S3.3: Fault recovery

[0037] Customize the fault handling mechanism to re-issue policies or notify administrators for manual intervention based on the fault situation.

[0038] In step S3.3, when a DVR-net-mirror-agent failure is detected, the Neutron server triggers a fault handling mechanism as follows:

[0039] Step S3.3.1. Restart the agent

[0040] Try to automatically restart the DVR-net-mirror-agent on the failed node;

[0041] Step S3.3.2: Re-issue the strategy

[0042] Re-issue the image policy to ensure that the agent can continue to perform the established image tasks after recovery;

[0043] Step S3.3.3: Notify the administrator

[0044] If automatic recovery fails, a failure notification is sent to the administrator, requiring manual intervention;

[0045] Step S3.3.4: Data backup and recovery

[0046] To ensure that the system can recover quickly when a failure occurs, a custom scheduled task is set up, and the Neutron server regularly backs up the mirror policy data;

[0047] During the failure recovery process, restore policy data from the backup to ensure that the system can be quickly restored to the state before the failure.

[0048] In step S4, after receiving the mirroring strategy, the DVR-net-mirror-agent performs the following steps:

[0049] Step S4.1: Analyze strategy data

[0050] DVR-net-mirror-agent parses the received policy data and extracts the source port ID and the destination port ID;.

[0051] Step S4.2: Verify port information

[0052] Verify the validity of the port ID and ensure that the source port and the destination port exist in the OVS of the local compute node;

[0053] Step S4.3: Generate OVS image rules

[0054] Generate corresponding OVS image rules based on policy data;

[0055] Step S4.4: Call the OVS interface

[0056] Configure traffic mirroring rules through the OVS command line interface or API;

[0057] Step S4.5: Feedback execution results

[0058] DVR-net-mirror-agent feeds back the execution results to the Neutron server, including information on whether the configuration is successful or not.

[0059] In step S5, OVS performs a mirroring operation on the specified source port traffic according to the mirroring rules issued by DVR-net-mirror-agent, specifically including the following steps:

[0060] Step S5.1: Traffic capture

[0061] Capture network traffic sent from source ports;

[0062] Step S5.2: Traffic replication

[0063] Copy and send the captured traffic to the target port, which is the port of the audit virtual machine;

[0064] Step S5.3: Traffic forwarding

[0065] Ensure that the mirrored traffic is forwarded to the audit VM without affecting the normal communication of the source VM.

[0066] In step S6, after the audit virtual machine receives the mirrored traffic, it performs real-time traffic monitoring and analysis, which specifically includes the following steps:

[0067] Step S6.1: Traffic capture

[0068] Use a traffic capture tool to capture the mirrored traffic received from the target port in real time;

[0069] Step S6.2: Traffic analysis

[0070] Analyze the captured traffic and detect potential network security threats and abnormal behaviors based on custom rules;

[0071] Step S6.3: Generate audit report

[0072] An audit report is generated based on the analysis results and provided to the administrator for subsequent processing.

[0073] A distributed virtual machine network traffic audit system, comprising:

[0074] DVR-net-mirror-agent: Distributed and deployed on each computing node, responsible for receiving and implementing the mirroring policy issued by the Neutron server; DVR-net-mirror-agent interacts with OVS to implement traffic mirroring function;

[0075] Neutron server: communicates with DVR-net-mirror-agent through the API interface, accepts the administrator's mirror policy configuration request, and sends the mirror policy to the DVR-net-mirror-agent of each computing node through the RPC interface;

[0076] OVS (Open vSwitch): A virtual switch running on each computing node, responsible for network traffic forwarding between virtual machines and implementing traffic mirroring according to the configuration of DVR-net-mirror-agent;

[0077] Audit VM: A VM used to receive and analyze mirrored traffic. It is responsible for monitoring and auditing network activities by receiving mirrored traffic.

[0078] Northbound interface: responsible for providing a RESTful interface for creating, modifying, deleting and viewing user-defined traffic images for the cloud computing management platform or third-party platform;

[0079] Configuration database: used to record relevant information of the service diversion chain created by the user;

[0080] Traffic mirror configuration management module: responsible for creating, modifying and deleting traffic mirror rules, calling the relevant functions of the interconnection subnet management module to create an interconnection subnet for each non-functional virtual device, and calling the virtual network traffic mirror management module;

[0081] Virtual network traffic mirroring management module: responsible for creating policy routing items by calling relevant interfaces and sending them to OVS to achieve traffic traction on the data plane;

[0082] OVS traffic management module: is a multi-layer virtual switch that supports standard management interfaces and protocols, allowing the network control plane to programmatically define traffic forwarding behavior; responsible for traffic forwarding, mirroring the traffic on the port to the IP of the audit virtual machine through commands; traffic mirroring allows users to capture copies of traffic on the switch and send them to specified ports or interfaces for further analysis or processing.

[0083] A distributed virtual machine network traffic auditing device is characterized by comprising a memory and a processor; the memory is used to store a computer program, and the processor is used to implement the above method steps when executing the computer program.

[0084] A readable storage medium, characterized in that: a computer program is stored on the readable storage medium, and the computer program implements the above method steps when executed by a processor.

[0085] The beneficial effects of the present invention are as follows: the distributed virtual machine network traffic auditing method and system realizes efficient and real-time virtual machine network traffic mirroring and monitoring through distributed deployment of DVR-net-mirror-agent and flexible configuration of mirroring strategies, overcomes the performance bottleneck and delay problems of existing centralized monitoring systems, can dynamically adjust strategies to meet diverse application requirements, and realizes real-time analysis and auditing of network traffic through auditing virtual machines, significantly improving the security and management efficiency of data centers. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0087] Attached Figure 1 It is a schematic diagram of the distributed virtual machine network traffic auditing method of the present invention. DETAILED DESCRIPTION

[0088] In order to enable those skilled in the art to better understand the technical solutions in the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0089] The distributed virtual machine network traffic audit method comprises the following steps:

[0090] Step S1: The administrator logs in to the Neutron server through the web interface or command line tool, submits a mirror policy configuration request through the Neutron API interface, specifies the source port (mirrored virtual machine port) and the target port (audit virtual machine port), and the Neutron server verifies the submitted policy request to ensure that the port ID in the request is legal and exists;

[0091] Step S2: After receiving the mirroring policy request, the Neutron server parses the mirroring policy, extracts the source port ID and the target port ID, and stores the mirroring policy in the database to ensure the persistence of the mirroring policy.

[0092] Step S3, the Neutron server establishes an RPC connection with the DVR-net-mirror-agent of each computing node, generates an RPC task according to the mirroring strategy, and sends the generated mirroring strategy data, including the source port ID and the target port ID, to the DVR-net-mirror-agent of the corresponding computing node through the RPC interface;

[0093] Step S4: After receiving the mirroring policy, DVR-net-mirror-agent sends a confirmation message to the Neutron server to ensure the reliability of policy transmission, parses the mirroring policy data, verifies the port information, generates OVS mirroring rules according to the mirroring policy data, calls the OVS interface to configure the traffic mirroring rules, and feeds back information on whether the configuration is successful to the Neutron server;

[0094] Step S5: After the mirroring strategy configuration is completed, OVS performs mirroring operations on the specified source port traffic according to the mirroring rules issued by DVR-net-mirror-agent;

[0095] Step S6: After the audit virtual machine receives the mirrored traffic, it performs real-time traffic monitoring and analysis, generates an audit report based on the analysis results, and provides it to the administrator for subsequent processing.

[0096] The control plane is also responsible for the management and maintenance of image strategies to ensure the stable operation of the system and the dynamic adjustment of strategies.

[0097] The administrator updates the existing image strategy through the API interface. The update process is as follows:

[0098] Step S1.1.1: Submit update request

[0099] The administrator submits a mirror policy update request to modify the source port or target port;

[0100] Step S1.1.2: Policy parsing and storage

[0101] The Neutron server parses the image policy update request and updates the image policy record in the database;

[0102] Step S1.1.3: Issue update strategy

[0103] Send the updated policy to the DVR-net-mirror-agent of each computing node through the RPC interface;

[0104] The administrator deletes the image policy through the API interface. The deletion process is as follows:

[0105] Step S1.2.1: Submit a deletion request

[0106] The administrator submits an image policy deletion request and specifies the policy ID to be deleted;

[0107] Step S1.2.2: Policy analysis and deletion

[0108] The Neutron server parses the image policy deletion request and deletes the corresponding image policy record from the database;

[0109] Step S1.2.3: Issue a deletion instruction

[0110] Send the deletion command to the DVR-net-mirror-agent of each computing node through the RPC interface;

[0111] Step S1.2.4: Clear OVS rules

[0112] After receiving the deletion command, DVR-net-mirror-agent calls the OVS interface to clear the corresponding mirroring rules.

[0113] In step S3, the Neutron server continuously monitors the status of the DVR-net-mirror-agent on each computing node to ensure the effectiveness of the policy execution. The monitoring process is as follows:

[0114] Step S3.1: Status monitoring

[0115] Customize scheduled tasks and obtain status information of each DVR-net-mirror-agent regularly through the RPC interface;

[0116] Step S3.2: Fault detection

[0117] When a DVR-net-mirror-agent exception is detected on a certain node through the heartbeat mechanism, or when an exception message is received from a DVR-net-mirror-agent on a certain node reported to the Neutron server, the fault handling process is triggered;

[0118] Step S3.3: Fault recovery

[0119] Customize the fault handling mechanism to re-issue policies or notify administrators for manual intervention based on the fault situation.

[0120] A complete fault handling mechanism is customized and designed on the control plane to ensure high availability and stability of the system.

[0121] Through the status monitoring mechanism, the Neutron server can detect the running status of the DVR-net-mirror-agent on each computing node in real time.

[0122] Heartbeat mechanism: DVR-net-mirror-agent periodically sends heartbeat messages to the Neutron server to report its own status.

[0123] Abnormal reporting: When DVR-net-mirror-agent detects abnormal operation or fails to configure OVS rules, it reports abnormal information to the Neutron server.

[0124] In step S3.3, when a DVR-net-mirror-agent failure is detected, the Neutron server triggers a fault handling mechanism as follows:

[0125] Step S3.3.1. Restart the agent

[0126] Try to automatically restart the DVR-net-mirror-agent on the failed node;

[0127] Step S3.3.2: Re-issue the strategy

[0128] Re-issue the image policy to ensure that the agent can continue to perform the established image tasks after recovery;

[0129] Step S3.3.3: Notify the administrator

[0130] If automatic recovery fails, a failure notification is sent to the administrator, requiring manual intervention;

[0131] Step S3.3.4: Data backup and recovery

[0132] To ensure that the system can recover quickly when a failure occurs, a custom scheduled task is set up, and the Neutron server regularly backs up the mirror policy data;

[0133] During the failure recovery process, restore policy data from backup if necessary to ensure that the system can be quickly restored to the state before the failure.

[0134] In step S4, after receiving the mirroring strategy, the DVR-net-mirror-agent performs the following steps:

[0135] Step S4.1: Analyze strategy data

[0136] DVR-net-mirror-agent parses the received policy data and extracts the source port ID and the destination port ID;.

[0137] Step S4.2: Verify port information

[0138] Verify the validity of the port ID and ensure that the source port and the destination port exist in the OVS of the local compute node;

[0139] Step S4.3: Generate OVS image rules

[0140] Generate corresponding OVS image rules based on policy data;

[0141] Step S4.4: Call the OVS interface

[0142] Configure traffic mirroring rules through the OVS command line interface or API;

[0143] Step S4.5: Feedback execution results

[0144] DVR-net-mirror-agent feeds back the execution results to the Neutron server, including information on whether the configuration is successful or not.

[0145] In step S5, OVS performs a mirroring operation on the specified source port traffic according to the mirroring rules issued by DVR-net-mirror-agent, specifically including the following steps:

[0146] Step S5.1: Traffic capture

[0147] Capture network traffic sent from source ports;

[0148] Step S5.2: Traffic replication

[0149] Copy and send the captured traffic to the target port, which is the port of the audit virtual machine;

[0150] Step S5.3: Traffic forwarding

[0151] Ensure that the mirrored traffic is smoothly forwarded to the audit virtual machine without affecting the normal communication of the source virtual machine.

[0152] In step S6, after the audit virtual machine receives the mirrored traffic, it performs real-time traffic monitoring and analysis, which specifically includes the following steps:

[0153] Step S6.1: Traffic capture

[0154] Use traffic capture tools (such as tcpdump, Wireshark, etc.) to capture the mirrored traffic received from the target port in real time;

[0155] Step S6.2: Traffic analysis

[0156] Analyze the captured traffic and detect potential network security threats and abnormal behaviors based on custom rules;

[0157] Step S6.3: Generate audit report

[0158] Generate a detailed audit report based on the analysis results and provide it to the administrator for subsequent processing.

[0159] The distributed virtual machine network traffic audit system includes:

[0160] DVR-net-mirror-agent (network video surveillance client): distributed and deployed on each computing node, responsible for receiving and implementing the mirroring policy issued by the Neutron server; DVR-net-mirror-agent interacts with OVS to implement traffic mirroring function;

[0161] Neutron server: communicates with DVR-net-mirror-agent through the API interface, accepts the administrator's mirror policy configuration request, and sends the mirror policy to the DVR-net-mirror-agent of each computing node through the RPC interface;

[0162] OVS (Open vSwitch, open virtual switching standard): a virtual switch running on each computing node, responsible for network traffic forwarding between virtual machines and implementing traffic mirroring according to the configuration of DVR-net-mirror-agent;

[0163] Audit VM: A VM used to receive and analyze mirrored traffic. It is responsible for monitoring and auditing network activities by receiving mirrored traffic.

[0164] Northbound interface: responsible for providing a series of RESTful interfaces for creating, modifying, deleting and viewing user-defined traffic images for the cloud computing management platform or third-party platform;

[0165] Configuration database: used to record relevant information of the service diversion chain created by the user;

[0166] Traffic mirror configuration management module: responsible for creating, modifying and deleting traffic mirror rules, calling the relevant functions of the interconnection subnet management module to create an interconnection subnet for each non-functional virtual device, and calling the virtual network traffic mirror management module;

[0167] Virtual network traffic mirroring management module: responsible for creating policy routing items by calling relevant interfaces and sending them to OVS to achieve traffic traction on the data plane;

[0168] OVS traffic management module: is a multi-layer virtual switch that supports standard management interfaces and protocols, allowing the network control plane to programmatically define traffic forwarding behavior; responsible for traffic forwarding, mirroring the traffic on the port to the IP of the audit virtual machine through commands; traffic mirroring is an important feature that allows users to capture a copy of the traffic on the switch and send it to a specified port or interface for further analysis or processing.

[0169] The distributed virtual machine network traffic auditing device comprises a memory and a processor; the memory is used to store a computer program, and the processor is used to implement the above method steps when executing the computer program.

[0170] The readable storage medium stores a computer program, and when the computer program is executed by a processor, the above method steps are implemented.

[0171] Compared with the prior art, the distributed virtual machine network traffic audit method and system has the following characteristics:

[0172] 1). Distributed deployment and scalability

[0173] By deploying DVR-net-mirror-agent on each computing node, distributed deployment and efficient traffic mirroring processing are achieved. This architecture can:

[0174] Improve system scalability: As the number of computing nodes increases, the system can expand linearly without being restricted by single-point performance bottlenecks.

[0175] Reduce centralized processing load: Each computing node independently processes local traffic mirroring, avoiding performance bottlenecks and network delays caused by centralized processing.

[0176] Enhanced system stability: Distributed architecture reduces the risk of single point failure and improves the overall reliability and stability of the system.

[0177] 2). Flexible mirroring strategy configuration

[0178] Administrators can flexibly configure and modify mirroring policies through the API interface to meet the needs of different application scenarios. This flexibility brings many advantages:

[0179] Dynamic adjustment capability: Based on changes in business needs and security policies, administrators can adjust mirroring policies at any time without shutting down or restarting the system.

[0180] Precise control: Traffic can be mirrored for specific virtual machines or ports, enabling precise traffic monitoring and auditing.

[0181] Diversified application scenarios: Supports a variety of network environments and usage scenarios, such as security auditing, troubleshooting, performance monitoring, etc.

[0182] 3). Real-time monitoring and rapid response

[0183] The audit virtual machine can receive and analyze mirrored traffic in real time, and promptly detect and handle potential network security threats and performance issues. This real-time performance brings the following benefits:

[0184] Real-time threat detection: Real-time analysis of mirrored traffic, rapid detection of network attacks and abnormal behavior, and improved system security.

[0185] Rapid fault location: Through real-time monitoring of mirrored traffic, network faults and performance bottlenecks can be quickly located, shortening the troubleshooting time.

[0186] Optimize network performance: Monitor traffic in real time, identify and resolve network congestion and performance bottlenecks, and optimize network performance in data centers.

[0187] 4). Efficient strategy management and maintenance

[0188] It provides a complete policy management and maintenance mechanism to ensure the effective implementation of mirroring policies and the stable operation of the system. The specific advantages include:

[0189] Automated management: Automatically distribute and update mirroring strategies through the RPC interface, reducing manual intervention and improving management efficiency.

[0190] Continuous monitoring and fault recovery: The Neutron server continuously monitors the DVR-net-mirror-agent status on each computing node, and can detect and handle faults in a timely manner, ensuring high availability of the system.

[0191] Data backup and recovery: Regularly back up mirroring policy data and quickly restore policy configuration during fault recovery to ensure system reliability.

[0192] 5). Optimize resource utilization

[0193] By processing traffic mirroring independently on each compute node, resources can be used more efficiently:

[0194] Reduce network bandwidth usage: Traffic mirroring is completed in the local computing node, reducing the bandwidth usage of cross-node traffic forwarding.

[0195] Reduce computing resource consumption: DVR-net-mirror-agent and OVS run on local nodes, reducing the computing resource load of centralized processing nodes.

[0196] 6) Enhanced data security and compliance

[0197] Real-time traffic mirroring and analysis can significantly improve data security and compliance:

[0198] Compliance Audit: Supports real-time monitoring and recording of key business traffic to meet data security and compliance requirements.

[0199] Sensitive data protection: Through traffic mirroring and analysis, sensitive data leakage and illegal access can be discovered and prevented in a timely manner.

[0200] 7). Easy to integrate and deploy

[0201] Based on mature open source components (such as OVS and Neutron), it is easy to integrate into existing cloud computing and virtualization environments:

[0202] Open source ecosystem: Leverage the open source community resources of OVS and Neutron to reduce development and maintenance costs.

[0203] Rapid deployment: Standardized API interfaces and deployment tools enable the system to be quickly deployed and launched, shortening the project cycle.

[0204] The embodiment described above is only one specific implementation of the present invention. Common changes and substitutions made by those skilled in the art within the scope of the technical solution of the present invention should be included in the protection scope of the present invention.

Claims

1. A distributed virtual machine network traffic audit method, characterized by: The following steps are involved: Step S1: The administrator logs in to the Neutron server through the web interface or command line tool, submits a mirror policy configuration request through the Neutron API interface, specifies the source port and the target port, and the Neutron server verifies the submitted policy request to ensure that the port ID in the request is legal and exists; Step S2: After receiving the mirroring policy request, the Neutron server parses the mirroring policy, extracts the source port ID and the target port ID, and stores the mirroring policy in the database to ensure the persistence of the mirroring policy. Step S3, the Neutron server establishes an RPC connection with the DVR-net-mirror-agent of each computing node, generates an RPC task according to the mirroring strategy, and sends the generated mirroring strategy data, including the source port ID and the target port ID, to the DVR-net-mirror-agent of the corresponding computing node through the RPC interface; Step S4: After receiving the mirroring policy, DVR-net-mirror-agent sends a confirmation message to the Neutron server, parses the mirroring policy data, verifies the port information, generates OVS mirroring rules according to the mirroring policy data, calls the OVS interface to configure the traffic mirroring rules, and feeds back information on whether the configuration is successful to the Neutron server. Step S5: After the mirroring strategy configuration is completed, OVS performs mirroring operations on the specified source port traffic according to the mirroring rules issued by DVR-net-mirror-agent; Step S6: After the audit virtual machine receives the mirrored traffic, it performs real-time traffic monitoring and analysis, generates an audit report based on the analysis results, and provides it to the administrator for subsequent processing.

2. The distributed virtual machine network traffic auditing method according to claim 1 is characterized in that: The administrator updates the existing image strategy through the API interface. The update process is as follows: Step S1.1.1: Submit update request The administrator submits a mirror policy update request to modify the source port or target port; Step S1.1.2: Policy parsing and storage The Neutron server parses the image policy update request and updates the image policy record in the database; Step S1.1.3: Issue update strategy Send the updated policy to the DVR-net-mirror-agent of each computing node through the RPC interface; The administrator deletes the image policy through the API interface. The deletion process is as follows: Step S1.2.1: Submit a deletion request The administrator submits an image policy deletion request and specifies the policy ID to be deleted; Step S1.2.2: Policy analysis and deletion The Neutron server parses the image policy deletion request and deletes the corresponding image policy record from the database; Step S1.2.3: Issue a deletion instruction Send the deletion command to the DVR-net-mirror-agent of each computing node through the RPC interface; Step S1.2.4: Clear OVS rules After receiving the deletion command, DVR-net-mirror-agent calls the OVS interface to clear the corresponding mirroring rules.

3. The distributed virtual machine network traffic auditing method according to claim 1 is characterized in that: In step S3, the Neutron server continuously monitors the status of the DVR-net-mirror-agent on each computing node to ensure the effectiveness of the policy execution. The monitoring process is as follows: Step S3.1: Status monitoring Customize scheduled tasks and obtain status information of each DVR-net-mirror-agent regularly through the RPC interface; Step S3.2: Fault detection When a DVR-net-mirror-agent exception is detected on a certain node through the heartbeat mechanism, or when an exception message is received from a DVR-net-mirror-agent on a certain node reported to the Neutron server, the fault handling process is triggered; Step S3.3: Fault recovery Customize the fault handling mechanism to re-issue policies or notify administrators for manual intervention based on the fault situation.

4. The distributed virtual machine network traffic auditing method according to claim 3 is characterized in that: In step S3.3, when a DVR-net-mirror-agent failure is detected, the Neutron server triggers a fault handling mechanism as follows: Step S3.3.1, restart the agent Try to automatically restart the DVR-net-mirror-agent on the failed node; Step S3.3.2: Re-issue the strategy Re-issue the image policy to ensure that the agent can continue to perform the established image tasks after recovery; Step S3.3.3: Notify the administrator If automatic recovery fails, a failure notification is sent to the administrator, requiring manual intervention; Step S3.3.4: Data backup and recovery To ensure that the system can recover quickly when a failure occurs, a custom scheduled task is set up, and the Neutron server regularly backs up the mirror policy data; During the failure recovery process, restore policy data from the backup to ensure that the system can be quickly restored to the state before the failure.

5. The distributed virtual machine network traffic auditing method according to claim 1 is characterized in that: In step S4, after receiving the mirroring strategy, the DVR-net-mirror-agent performs the following steps: Step S4.1: Analyze strategy data DVR-net-mirror-agent parses the received policy data and extracts the source port ID and the destination port ID; 。 Step S4.2: Verify port information Verify the validity of the port ID and ensure that the source port and the destination port exist in the OVS of the local compute node; Step S4.3: Generate OVS image rules Generate corresponding OVS image rules based on policy data; Step S4.4: Call the OVS interface Configure traffic mirroring rules through the OVS command line interface or API; Step S4.5: Feedback execution results DVR-net-mirror-agent feeds back the execution results to the Neutron server, including information on whether the configuration is successful or not.

6. The distributed virtual machine network traffic auditing method according to claim 1 is characterized in that: In step S5, OVS performs a mirroring operation on the specified source port traffic according to the mirroring rules issued by DVR-net-mirror-agent, specifically including the following steps: Step S5.1: Traffic capture Capture network traffic sent from source ports; Step S5.2: Traffic replication Copy and send the captured traffic to the target port, which is the port of the audit virtual machine; Step S5.3: Traffic forwarding Ensure that the mirrored traffic is forwarded to the audit VM without affecting the normal communication of the source VM.

7. The distributed virtual machine network traffic auditing method according to claim 1 is characterized in that: In step S6, after the audit virtual machine receives the mirrored traffic, it performs real-time traffic monitoring and analysis, which specifically includes the following steps: Step S6.1: Traffic capture Use a traffic capture tool to capture the mirrored traffic received from the target port in real time; Step S6.2: Traffic analysis Analyze the captured traffic and detect potential network security threats and abnormal behaviors based on custom rules; Step S6.3: Generate audit report An audit report is generated based on the analysis results and provided to the administrator for subsequent processing.

8. A system based on the distributed virtual machine network traffic audit method according to any one of claims 1 to 7, characterized in that: include: DVR-net-mirror-agent: Distributed and deployed on each computing node, responsible for receiving and implementing the mirroring policy issued by the Neutron server; DVR-net-mirror-agent interacts with OVS to implement traffic mirroring function; Neutron server: communicates with DVR-net-mirror-agent through the API interface, accepts the administrator's mirror policy configuration request, and sends the mirror policy to the DVR-net-mirror-agent of each computing node through the RPC interface; OVS: A virtual switch running on each computing node, responsible for network traffic forwarding between virtual machines and implementing traffic mirroring according to the configuration of DVR-net-mirror-agent; Audit VM: A VM used to receive and analyze mirrored traffic. It is responsible for monitoring and auditing network activities by receiving mirrored traffic. Northbound interface: responsible for providing a RESTful interface for creating, modifying, deleting and viewing user-defined traffic images for the cloud computing management platform or third-party platform; Configuration database: used to record relevant information of the service diversion chain created by the user; Traffic mirror configuration management module: responsible for creating, modifying and deleting traffic mirror rules, calling the relevant functions of the interconnection subnet management module to create an interconnection subnet for each non-functional virtual device, and calling the virtual network traffic mirror management module; Virtual network traffic mirroring management module: responsible for creating policy routing items by calling relevant interfaces and sending them to OVS to achieve traffic traction on the data plane; OVS traffic management module: is a multi-layer virtual switch that supports standard management interfaces and protocols, allowing the network control plane to programmatically define traffic forwarding behavior; Responsible for traffic forwarding, mirroring the traffic on the port to the IP of the audit virtual machine through commands; traffic mirroring allows users to capture a copy of the traffic on the switch and send it to a specified port or interface for further analysis or processing.

9. A distributed virtual machine network traffic audit device, characterized in that: The method comprises a memory and a processor; the memory is used to store a computer program, and the processor is used to implement the method according to any one of claims 1 to 7 when executing the computer program.

10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images