A distributed virtual machine network traffic auditing method and system

Abstract

The present invention particularly relates to a distributed virtual machine network traffic auditing method and system. In the distributed virtual machine network traffic auditing method, an administrator submits a mirroring policy configuration request, a Neutron server parses the mirroring policy, generates an RPC task, and sends the generated mirroring policy data to the DVR‑net‑mirror‑agent of the corresponding computing node; the DVR‑net‑mirror‑agent parses the mirroring policy data, verifies the port information, generates an OVS mirroring rule based on the mirroring policy data, and calls the OVS interface to configure the traffic mirroring rule; the OVS performs a mirroring operation on the specified source port traffic; 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. The distributed virtual machine network traffic auditing method and system realizes efficient and real-time virtual machine network traffic mirroring and monitoring, can dynamically adjust policies, meet diverse application requirements, and significantly improve the security and management efficiency of the data center.

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, the widespread adoption of cloud computing and virtualization technologies has made distributed network environments mainstream. With the large-scale migration of user services to the cloud, various non-business-related devices within traditional data centers have also been virtualized and migrated to the cloud. These include Web Application Firewalls (WAFs), perimeter firewalls, Deep Packet Inspection (DPI) devices, and log auditing devices. After virtualization, users can dynamically create and deploy these devices online within their VPCs based on their needs in the cloud computing management console. Specific business traffic can then be directed to one or more of these non-business-related devices for purposes such as security protection, online behavior auditing, and daily monitoring.

[0003] However, the simple routing or policy-based routing methods used in traditional data centers for service traffic diversion don't work well on large-scale cloud computing platforms based on a fully distributed routing architecture. This is because, in a fully distributed routing architecture, SNAT / DNAT operations for north-south traffic entering and exiting the VPC for an ECS must be performed symmetrically, namely, on the VPC virtual router on the physical node where the ECS resides. This creates a problem: when the source ECS and non-service virtual devices in the diversion chain are located on different physical nodes, the traffic paths entering and exiting the VPC, as well as the source and destination IP addresses in the packets, become misaligned. This prevents security devices from establishing sessions and communication properly.

[0004] The transparent traffic diversion solution based on a 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. The addition or deletion of user elastic cloud servers will lead to a large amount of interaction between the control plane and the data plane, resulting in poor scalability and inability to support large-scale scenarios.

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

[0006] In order to overcome the deficiencies of the prior art, the present invention provides a simple and efficient distributed virtual machine network traffic auditing method and system.

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

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

[0009] Step S1: The administrator logs in to the Neutron server through the web interface or command line tool, submits a mirroring policy configuration request through the Neutron API interface, and specifies the source port (the port of the virtual machine being mirrored) and the target port (the port of the audit virtual machine). The Neutron server verifies the submitted policy request to ensure that the port ID in the request is valid 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 based on the mirroring strategy, and sends the generated mirroring strategy data, including the source port ID and the destination 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, the 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 based on the mirroring policy data, calls the OVS interface to configure traffic mirroring rules, and feeds back information on whether the configuration is successful to the Neutron server.

[0013] Step S5: After the mirroring policy configuration is completed, OVS mirrors 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] Administrators update existing mirror policies through the API interface. The update process is as follows:

[0016] Step S1.1.1: Submit an 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 policy

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

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

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

[0024] The administrator submits a request to delete an image policy, specifying the policy ID to be deleted.

[0025] Step S1.2.2: Policy parsing 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 delete command

[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 policy execution. The monitoring process is as follows:

[0032] Step S3.1: Status monitoring

[0033] Customize scheduled tasks and obtain the 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 on a node is detected through the heartbeat mechanism, or when an exception is reported by the DVR-net-mirror-agent on a node 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 policy

[0042] Re-issue the mirroring policy to ensure that the agent can continue to perform the established mirroring 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 policy, 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 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 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 the captured traffic and send it 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 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 auditing system, comprising:

[0074] DVR-net-mirror-agent: Deployed on each compute node, it receives and implements mirroring policies issued by the Neutron server. It interacts with OVS to implement traffic mirroring.

[0075] Neutron server: Communicates with the 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 on each computing node through the RPC interface;

[0076] OVS (Open vSwitch): A virtual switch running on each compute node, responsible for forwarding network traffic between virtual machines and mirroring traffic based on the configuration of the 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 mirrors for the cloud computing management platform or third-party platforms;

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

[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 mirror management module: responsible for creating policy routing items by calling relevant interfaces and sending them to OVS to achieve data plane traffic traction;

[0082] OVS traffic management module: It is a multi-layer virtual switch that supports standard management interfaces and protocols, allowing the network control plane to programmatically define traffic forwarding behavior; it is responsible for traffic forwarding and mirrors the traffic on the port to the IP address 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.

[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-mentioned 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 strategy, overcomes the performance bottleneck and delay problems of existing centralized monitoring systems, can dynamically adjust strategies to meet diverse application needs, 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 following briefly introduces the drawings required for use in the embodiments or the description of the prior art. 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 any creative work.

[0087] Attachment Figure 1 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 of 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 embodiments described are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work should fall within the scope of protection of the present invention.

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

[0090] Step S1: The administrator logs in to the Neutron server through the web interface or command line tool, submits a mirroring policy configuration request through the Neutron API interface, and specifies the source port (the port of the virtual machine being mirrored) and the target port (the port of the audit virtual machine). The Neutron server verifies the submitted policy request to ensure that the port ID in the request is valid 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 based on the mirroring strategy, and sends the generated mirroring strategy data, including the source port ID and the destination 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, the DVR-net-mirror-agent sends a confirmation message to the Neutron server to ensure the reliability of the policy transmission. It then parses the mirroring policy data, verifies the port information, generates OVS mirroring rules based on the mirroring policy data, calls the OVS interface to configure the traffic mirroring rules, and reports whether the configuration is successful to the Neutron server.

[0094] Step S5: After the mirroring policy configuration is completed, OVS mirrors 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] Administrators update existing mirror policies through the API interface. The update process is as follows:

[0098] Step S1.1.1: Submit an 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 policy

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

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

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

[0106] The administrator submits a request to delete an image policy, specifying the policy ID to be deleted.

[0107] Step S1.2.2: Policy parsing 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 delete command

[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 policy execution. The monitoring process is as follows:

[0114] Step S3.1: Status monitoring

[0115] Customize scheduled tasks and obtain the 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 on a node is detected through the heartbeat mechanism, or when an exception is reported by the DVR-net-mirror-agent on a node 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 comprehensive fault handling mechanism is custom 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: The DVR-net-mirror-agent periodically sends heartbeat messages to the Neutron server to report its own status.

[0123] Abnormal reporting: When the DVR-net-mirror-agent detects abnormal operation or fails to configure OVS rules, it reports the 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 policy

[0128] Re-issue the mirroring policy to ensure that the agent can continue to perform the established mirroring 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 fault recovery process, restore policy data from backup if necessary to ensure that the system can be quickly restored to its pre-fault state.

[0134] In step S4, after receiving the mirroring policy, 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 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 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 the captured traffic and send it 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 VM without affecting the normal communication of the source VM.

[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 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 auditing system includes:

[0160] DVR-net-mirror-agent (network video surveillance client): Distributed and deployed on each computing node, it is responsible for receiving and implementing mirroring policies issued by the Neutron server. The DVR-net-mirror-agent interacts with OVS to implement traffic mirroring.

[0161] Neutron server: Communicates with the 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 on each computing node through the RPC interface;

[0162] OVS (Open vSwitch): A virtual switch running on each compute node, responsible for forwarding network traffic between virtual machines and mirroring traffic based on the configuration of the 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 mirrors for cloud computing management platforms or third-party platforms;

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

[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 mirror management module: responsible for creating policy routing items by calling relevant interfaces and sending them to OVS to achieve data plane traffic traction;

[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; it is responsible for traffic forwarding and mirrors the traffic on the port to the IP address 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 includes 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, which implements the above method steps when executed by a processor.

[0171] Compared with existing technologies, this distributed virtual machine network traffic auditing 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 are achieved. This architecture can:

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

[0175] Reduced 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: The 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 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] Diverse 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] Audit VMs can receive and analyze mirrored traffic in real time, enabling timely detection and resolution of potential network security threats and performance issues. This real-time nature provides the following benefits:

[0184] Instant threat detection: Analyzes mirrored traffic in real time to quickly detect network attacks and abnormal behavior, improving system security.

[0185] Rapid fault location: Real-time monitoring of mirrored traffic enables rapid location of network faults and performance bottlenecks, shortening troubleshooting time.

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

[0187] 4). Efficient strategy management and maintenance

[0188] It provides a comprehensive policy management and maintenance mechanism to ensure the effective implementation of mirroring strategies and the stable operation of the system. Specific advantages include:

[0189] Automated management: Automatically distribute and update mirroring policies 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, enabling timely detection and resolution of faults, ensuring high system availability.

[0191] Data backup and recovery: Regularly back up mirror policy data and quickly restore policy configuration during fault recovery, ensuring system reliability.

[0192] 5) Optimize resource utilization

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

[0194] Reduced network bandwidth usage: Traffic mirroring is performed within 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 on 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 detected 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: Leveraging the open source community resources of OVS and Neutron reduces 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 and submits a mirror policy configuration request through the Neutron API interface, specifying the source port and target port. The Neutron server verifies the submitted policy request to ensure that the port ID in the request is valid 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 based on the mirroring strategy, and sends the generated mirroring strategy data, including the source port ID and the destination port ID, to the DVR-net-mirror-agent of the corresponding computing node through the RPC interface. Step S4: After receiving the mirroring policy, the 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 based on the mirroring policy data, calls the OVS interface to configure traffic mirroring rules, and feeds back information on whether the configuration is successful to the Neutron server. Step S5: After the mirroring policy configuration is completed, OVS mirrors 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, characterized in that: Administrators update existing mirror policies through the API interface. The update process is as follows: Step S1.1.1: Submit an 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 policy Send the updated policy to the DVR-net-mirror-agent of each computing node through the RPC interface; The administrator deletes the mirror policy through the API interface. The deletion process is as follows: Step S1.2.1: Submit a deletion request The administrator submits a request to delete an image policy, specifying the policy ID to be deleted. Step S1.2.2: Policy parsing 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 delete command 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, 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 policy execution. The monitoring process is as follows: Step S3.1: Status monitoring Customize scheduled tasks and obtain the 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 on a node is detected through the heartbeat mechanism, or when an exception is reported by the DVR-net-mirror-agent on a node 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, characterized in that: In step S3.3, when a DVR-net-mirror-agent failure is detected, the Neutron server triggers the 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 policy Re-issue the mirroring policy to ensure that the agent can continue to perform the established mirroring 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, characterized in that: In step S4, after receiving the mirroring policy, 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 destination port ID; Step S4.2: Verify port information Verify the validity of the port ID and ensure that the source port and 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, 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 the captured traffic and send it 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, 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 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: Deployed on each compute node, it receives and implements mirroring policies issued by the Neutron server. It interacts with OVS to implement traffic mirroring. Neutron server: Communicates with the 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 on each computing node through the RPC interface; OVS: A virtual switch running on each compute node, responsible for forwarding network traffic between virtual machines and mirroring traffic based on the configuration of the 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 mirrors for the cloud computing management platform or third-party platforms; Configuration database: used to record relevant information about the service diversion chain created by users; 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 mirror management module: responsible for creating policy routing items by calling relevant interfaces and sending them to OVS to achieve data plane traffic traction; 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 the specified port or interface for further analysis or processing.

9. A distributed virtual machine network traffic auditing device, characterized by: 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