Security protection method and system based on MPLS-VPN routing network

Abstract

The invention discloses a security protection method and system based on an MPLS-VPN routing network, and relates to the field of network security protection, and the method comprises the steps: firstly, obtaining PE router configuration, carrying out the static compliance analysis, and recognizing a potential configuration risk point in advance; and then, aiming at the identified risk point, scheduling a probe to carry out connectivity test, and directly verifying whether the isolation between the VPNs is broken or not. Meanwhile, in combination with flow data analysis, whether abnormal cross-VPN flow exists or not is determined. And finally, performing multi-source intelligent association on a configuration risk report, a probe connectivity result and an abnormal flow alarm, and accurately confirming a VPN flow leakage event. Through the mode, false alarm and missing alarm are avoided, so that more comprehensive and more accurate security protection of the MPLS-VPN routing network is realized.

Description

Technical Field

[0001] This application relates to the field of network security protection, and more specifically, to a security protection method and system based on an MPLS-VPN routing network. Background Art

[0002] With the in-depth development of enterprise digital transformation, the routing network based on MPLS-VPN (Multi-Protocol Label Switching-Virtual Private Network) has become the mainstream choice for building enterprise internal networks and connecting branch offices due to its high security, high reliability, and flexible networking capabilities. MPLS-VPN creates a logically isolated virtual network on the public network, providing an independent communication environment for different users or departments, effectively ensuring the privacy and integrity of data transmission. However, although MPLS-VPN provides isolation in design, its complexity also brings potential security risks. For example, misconfigurations of PE routers, misconfigurations or leaks of RT policies may lead to unexpected traffic interconnection between different VPNs, thus triggering serious security incidents such as data leakage and unauthorized access, posing threats to the business continuity and data security of enterprises. Therefore, it is particularly important to build a comprehensive and efficient security protection scheme for the MPLS-VPN routing network to actively discover and solve potential security hazards.

[0003] However, in the prior art, the security protection schemes for MPLS-VPN routing networks often have limitations. Traditional network security protection means, such as firewalls and intrusion detection systems, mainly focus on network boundaries and traffic content, and it is difficult to penetrate into the routing layer of MPLS-VPN to conduct fine-grained detection and verification on the compliance of PE router configurations and the effectiveness of VPN isolation policies. In addition, existing schemes usually lack the intelligent association ability of multi-source information and cannot comprehensively analyze configuration risks, connectivity test results, and actual traffic data, thus making it difficult to accurately judge whether there is a VPN traffic leakage event. For example, even if there are risks in the PE router configuration, if there is no actual traffic leakage, false alarms should not be reported; on the contrary, if there are no configuration risks but actual traffic leakage occurs, existing schemes may not be able to detect it in time. This lack of information isolation and analysis ability makes existing schemes unable to cope with the complex security challenges of MPLS-VPN routing networks and difficult to provide comprehensive and accurate security protection.

[0004] To solve the above deficiencies in the prior art, a security protection scheme that can comprehensively and accurately identify potential configuration risks and actual traffic leakage events in the MPLS-VPN routing network is expected. Summary of the Invention

[0005] Based on the deficiencies existing in the foregoing prior art, according to one aspect of the present application, a security protection method based on an MPLS-VPN routing network is provided, which includes: S1: Obtain the router configuration of the PE router.

[0006] S2: Perform static configuration compliance analysis on the router configuration of the PE router to obtain a configuration risk report.

[0007] S3: In response to the existence of configuration risk points in the configuration risk report, based on the configuration risk points, schedule the source probe to send a test packet to the target probe to obtain the probe-to-probe connectivity test result.

[0008] S4: In response to the probe-to-probe connectivity test result being reachable, analyze the flow data obtained from the flow record database to determine whether there is flow data between the source VRF and the target VRF to generate an abnormal flow warning.

[0009] S5: Perform multi-source information intelligent association and leakage event confirmation based on the configuration risk report, the probe-to-probe connectivity test result, and the abnormal flow warning to obtain a VPN traffic confirmed leakage event.

[0010] S6: Generate a security warning prompt for the VPN traffic confirmed leakage event.

[0011] According to another aspect of the present application, a security protection system based on an MPLS-VPN routing network is provided, which includes: a router configuration acquisition module for obtaining the router configuration of the PE router; a configuration risk report generation module for performing static configuration compliance analysis on the router configuration of the PE router to obtain a configuration risk report; a probe test module for, in response to the existence of configuration risk points in the configuration risk report, based on the configuration risk points, scheduling the source probe to send a test packet to the target probe to obtain the probe-to-probe connectivity test result; an abnormal flow warning module for, in response to the probe-to-probe connectivity test result being reachable, analyzing the flow data obtained from the flow record database to determine whether there is flow data between the source VRF and the target VRF to generate an abnormal flow warning; a VPN traffic leakage event confirmation module for performing multi-source information intelligent association and leakage event confirmation based on the configuration risk report, the probe-to-probe connectivity test result, and the abnormal flow warning to obtain a VPN traffic confirmed leakage event; a security warning prompt generation module for generating a security warning prompt for the VPN traffic confirmed leakage event.

[0012] Compared with the prior art, a security protection method and system based on an MPLS-VPN routing network provided by the present application aims to solve the problems of insufficient identification of configuration risks for PE routers, incomplete verification of VPN isolation, and lack of multi-source information correlation analysis in the prior art. Specifically, first, by obtaining the PE router configuration and performing static compliance analysis, potential configuration risk points are pre-identified, making up for the deficiency of the traditional solution in detecting configuration risks at the routing level. Then, for the identified risk points, probes are scheduled for connectivity testing to directly verify whether the isolation between VPNs is broken, solving the problem that the existing solution cannot effectively verify the isolation. At the same time, combined with flow data analysis, it is confirmed whether there is abnormal cross-VPN traffic, making up for the limitations of relying only on configuration or connectivity testing. Finally, through multi-source intelligent correlation of configuration risk reports, probe connectivity results, and abnormal flow alarms, VPN traffic leakage events are accurately confirmed, avoiding false alarms and missed alarms, thereby achieving more comprehensive and accurate security protection for the MPLS-VPN routing network and effectively solving the technical problems raised in the background art. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] By describing the embodiments of the present application in more detail with reference to the accompanying drawings, the above and other objects, features, and advantages of the present application will become more apparent. The drawings are used to provide a further understanding of the embodiments of the present application and constitute a part of the specification, and are used to explain the present application together with the embodiments of the present application, and do not constitute a limitation to the present application. In the drawings, the same reference numerals generally represent the same components or steps.

[0014] Figure 1 It is a flowchart of a security protection method based on an MPLS-VPN routing network according to an embodiment of the present application.

[0015] Figure 2 It is a schematic diagram of data flow of a security protection method based on an MPLS-VPN routing network according to an embodiment of the present application.

[0016] Figure 3 It is a flowchart of step S2 in a security protection method based on an MPLS-VPN routing network according to an embodiment of the present application.

[0017] Figure 4 It is a flowchart of step S3 in a security protection method based on an MPLS-VPN routing network according to an embodiment of the present application.

[0018] Figure 5 It is a block diagram of a security protection system based on an MPLS-VPN routing network according to an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0019] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although some embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Instead, these embodiments are provided to more thoroughly and completely understand the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not used to limit the protection scope of the present disclosure.

[0020] In view of the technical defects exposed in the above background art, the present application proposes a security protection method based on an MPLS-VPN routing network. Figure 1 FIG. is a flowchart of a security protection method based on an MPLS-VPN routing network according to an embodiment of the present application. Figure 2 FIG. is a schematic diagram of data flow of a security protection method based on an MPLS-VPN routing network according to an embodiment of the present application. As Figure 1 and Figure 2 shown, a security protection method based on an MPLS-VPN routing network according to an embodiment of the present application includes: S1: obtaining the router configuration of a PE router; S2: performing static configuration compliance analysis on the router configuration of the PE router to obtain a configuration risk report; S3: in response to the existence of a configuration risk point in the configuration risk report, based on the configuration risk point, scheduling a source probe to send a test packet to a target probe to obtain a probe-to-probe connectivity test result; S4: in response to the probe-to-probe connectivity test result being reachable, analyzing the flow data obtained from the flow record database to determine whether there is flow data between a source VRF and a target VRF to generate an abnormal flow alarm; S5: performing multi-source information intelligent association and leakage event confirmation based on the configuration risk report, the probe-to-probe connectivity test result, and the abnormal flow alarm to obtain a VPN traffic confirmation leakage event; S6: generating a security alarm prompt for the VPN traffic confirmation leakage event.

[0021] In step S1, the router configuration of the PE router is obtained. It can be understood that the configuration of the PE router is the cornerstone of the security protection of the MPLS-VPN routing network. As the entry and exit of VPN traffic, the configuration of the PE router directly determines the isolation policy and routing behavior between different VPNs. Any configuration error, especially the misconfiguration or leakage of the RT policy, may cause traffic intercommunication between VPNs that should be isolated, thus triggering serious security incidents such as data leakage. Therefore, in the technical solution of the present application, obtaining the router configuration of the PE router is the premise for subsequent static configuration compliance analysis, and is also the primary step to discover potential configuration risks and evaluate the effectiveness of VPN isolation, providing key initial information for subsequent connectivity testing and traffic analysis, so as to discover and solve the security hidden dangers of the MPLS-VPN routing network from the source.

[0022] As an alternative implementation, step S1 is carried out as follows: First, a secure connection is established with the target PE router through a network management protocol, such as the Secure Shell Protocol (SSH) or the Simple Network Management Protocol (SNMP). After the connection is established, specific command-line interface commands or SNMP query requests are sent to obtain the complete configuration information of the PE router. The output of these commands contains all the current running configurations of the PE router, including interface configurations, routing protocol configurations, Virtual Private Network instance (VRF) configurations, and the crucial Route Target (RT) import / export policies, etc. The obtained configuration information is returned in text format. To ensure the integrity and accuracy of the data, mechanisms such as checksums or digital signatures are also used to verify the obtained configuration data. For example, after obtaining the configuration, the MD5 hash value of the configuration file can be calculated and compared with the hash value provided by the router side to confirm that the data has not been tampered with during transmission. In addition, to achieve automated and periodic acquisition, a configuration acquisition period can be preset, such as once every 24 hours, or an immediate acquisition can be triggered when a configuration change of the PE router is detected, ensuring that security analysis is always based on the latest configuration information. The obtained router configuration in the original text format is used for subsequent static configuration compliance analysis.

[0023] In step S2, a static configuration compliance analysis is performed on the router configuration of the PE router to obtain a configuration risk report. Correspondingly, although MPLS-VPN provides logical isolation, the configuration complexity of the PE router is extremely high, and it is difficult for manual review to discover all potential configuration errors or non-compliant items. Especially the configuration of the RT policy directly determines the routing import / export relationship between different VPNs. Once the configuration is improper, it is extremely easy to cause accidental intercommunication of traffic between VPNs, leading to data leakage. Therefore, through static configuration compliance analysis, this application can deeply check the configuration of the PE router without affecting network operation, identify configuration items that do not conform to the predefined security baseline, and thus warn and locate potential risk points before actual traffic leakage occurs. This can effectively make up for the deficiency in detecting configuration risks at the routing level in the prior art, provide a clear risk indication for subsequent connectivity testing and traffic analysis, and is an important part of building a comprehensive and accurate security protection scheme, which can effectively avoid security incidents caused by configuration errors.

[0024] In particular, as an alternative implementation Figure 3 is a flowchart of step S2 in the security protection method based on the MPLS-VPN routing network according to the embodiment of the present application. As Figure 3As shown, step S2 includes: S21, performing configuration parsing on the router configuration of the PE router to obtain a standardized PE configuration object; S22, extracting an RT policy from the standardized PE configuration object; S23, inputting the RT policy into a configuration audit engine to obtain the configuration risk report, where the configuration audit engine is used to compare the RT policy with a predefined VPN isolation policy baseline.

[0025] Specifically, step S2 is implemented as follows: First, step S21 is executed. The configuration parsing module reads the original text configuration of the PE router, which usually exists in the form of the output of the command-line interface and has a specific syntax structure. For subsequent unified processing, the parsing module uses predefined syntax parsing rules to structure it. These rules can be regular expression-based pattern matching for identifying specific keywords, parameters, and values in the configuration. For example, by matching vrf definition <VRF_NAME> to identify the start of the VRF definition, or matching route-target import <RT_VALUE> and route-target export <RT_VALUE> to extract the route target values. For more complex, hierarchical configurations, the parsing module uses context-free grammars or parser generator tools such as ANTLR to construct a parser that can understand the router configuration language. This parser can convert the original text stream into an abstract syntax tree, clearly representing the hierarchical relationship of the configuration and the semantics of each configuration item. After parsing, the original, unstructured text configuration is converted into a unified, program-friendly standardized PE configuration object. This standardization aims to eliminate the impact of differences in router configuration syntax, enabling subsequent RT policy extraction and auditing to be performed on a common data model. The standardized PE configuration object is represented in the form of a tree structure or a collection of key-value pairs. For example, a VRF instance can be abstracted as an independent configuration object that contains its unique name, such as VPN_A, a route distinguisher, RD, such as 100:1, and a list that details all configured import route target route-target import and export route target route-target export values. Each RT value itself can also be a sub-object, containing its type (export / import) and specific values such as 65000:100 and 65000:200.

[0026] Next, step S22 is executed. The extraction module traverses the standardized PE configuration object to identify and extract all configuration items related to the RT policy. Specifically, it looks for the route-target import and route-target export statements defined in each VRF instance, as well as route maps or prefix lists that may affect the RT policy. For example, if there is a VRF named VPN_A in the standardized object, which contains the attributes route-target import 65000:100 and route-target export 65000:200, then these RT values (65000:100 and 65000:200) and the VRF they belong to (VPN_A) will be extracted to form a structured set of RT policies. This set contains the import RT and export RT information for each VRF.

[0027] Finally, step S23 is executed. It should be understood that the configuration audit engine is a core component that contains a predefined VPN isolation policy baseline internally. This baseline is a set of rules that clearly define the allowed or prohibited RT import / export relationships between different VPNs. For example, the RT of VPN_A cannot be imported into VPN_B, and the RT of all customer VPNs cannot be imported into the management VPN, etc. These baseline rules can be preset by network security experts according to the enterprise security policy and stored in the database. After receiving the set of RT policies, the audit engine traverses each RT import / export relationship in it and compares it one by one with all the rules in the baseline. The comparison process may involve logical judgments such as pattern matching and set operations. For example, if the baseline stipulates that no RT import is allowed between VPN_X and VPN_Y, and the audit engine finds that there is a situation where the RT of VPN_X imports the RT of VPN_Y or the RT of VPN_Y imports the RT of VPN_X in the set of RT policies, then the audit engine will mark this configuration as a risk point and generate a detailed configuration risk report, including the risk type, such as RT import conflict, the VRFs involved, such as source VRF: VPN_X, target VRF: VPN_Y, the RT value, and the risk level, such as high risk.

[0028] In step S3, in response to the existence of configuration risk points in the configuration risk report, based on the configuration risk points, the source probe is scheduled to send a test packet to the target probe to obtain the test result of the connectivity between probes. It should be understood that although static configuration analysis can detect potential configuration errors, it cannot directly prove whether these errors have caused actual network connectivity problems. For example, even if there is an import risk in the RT policy, due to the limitations of other routing policies or network topologies, the actual traffic may not be able to communicate with each other. Therefore, in this application, through active probe connectivity testing, the configuration risk can be dynamically verified to confirm whether there is an accidental connection between the expected isolated VPNs in the case of configuration risks. This dynamic verification mechanism makes up for the deficiencies of static analysis, avoids false alarms, and provides a more direct and accurate isolation verification result. It converts potential configuration risks into observable connectivity states, provides key empirical data for subsequent traffic analysis and leakage event confirmation, and is an indispensable part of building a comprehensive and accurate MPLS-VPN security protection solution, ensuring the effective identification of actual security threats.

[0029] Specifically, as an alternative implementation form, Figure 4 is a flowchart of step S3 in the security protection method based on the MPLS-VPN routing network according to the embodiment of the present application. As Figure 4 shown, step S3 includes: S31, extracting the expected isolated source VRF and target VRF from the configuration risk points; S32, based on the source VRF and the target VRF, determining to schedule the source probe to send a test packet to the target probe; S33, in response to the target VRF receiving the test packet from the source VRF or the source VRF receiving the response from the target VRF, determining that the test result of the connectivity between the probes is reachable.

[0030] Specifically, step S3 is implemented as follows: First, step S31 is executed. The configuration risk report clearly indicates which VRFs have potential RT import / export risks. For example, source VRF: VPN_A, target VRF: VPN_B, risk type: RT import conflict. The extraction module will parse these risk records and identify the source VRF and target VRF pairs that are clearly indicated to be potentially interconnected but expected to be isolated. For example, if the report indicates that there is an RT import risk between VPN_A and VPN_B, the extracted source VRF is VPN_A and the target VRF is VPN_B. This process will traverse all the risk points in the report to extract the VRF pairs, that is, the source VRF and target VRF that are expected to be isolated but may have already been interconnected.

[0031] Then, step S32 is executed. To conduct an actual connectivity test, network probes need to be deployed. These probes are lightweight software agents or hardware devices that are pre-deployed at key locations in the MPLS-VPN routing network, such as on servers or virtual machines connected to different VRFs. Each probe is configured with a specific VRF context, enabling it to simulate traffic behavior within that VRF. A probe scheduling module will select appropriate source and target probes from a preset probe pool based on the source VRF and target VRF extracted in S31. It is worth mentioning that the source probe is a network device deployed inside the source VRF or having routing reachability with the source VRF. For example, a virtual machine or a physical server that can simulate the traffic initiator inside the source VRF. Similarly, the target probe is a network device deployed inside the target VRF or having routing reachability with the target VRF, which can simulate the traffic receiver inside the target VRF. After determining the probes, an instruction is sent to the source probe to request it to initiate a test packet towards the target probe. The test packet is a simple network protocol data packet, such as an Internet Control Message Protocol ICMP echo request ping packet or a User Datagram Protocol UDP data packet. To ensure the accuracy of the test, the source IP address of the test packet should belong to the address space of the source VRF, and the target IP address should belong to the address space of the target VRF. For example, if the source VRF is VPN_A, the target VRF is VPN_B, the IP address of the source probe is 10.1.1.10 belonging to VPN_A, and the IP address of the target probe is 10.2.2.20 belonging to VPN_B, then the source probe will send a ping packet to 10.2.2.20.

[0032] Finally, step S33 is executed. Continuously monitor whether the target probe receives the test packet sent by the source probe, or whether the source probe receives the response from the target probe, such as an ICMP echo reply. If the target probe successfully receives the test packet, or the source probe successfully receives the response, it indicates that there is network connectivity between the source VRF and the target VRF. In this case, even though there are isolation requirements in the configuration, the actual network path is reachable. Therefore, it is determined that the connectivity test result between the probes is reachable, which means that although the configuration audit report shows risks, there is indeed cross-VRF connectivity in the actual network, confirming the potential traffic leakage path. On the contrary, if no response or test packet is received within a preset timeout period, such as 5 seconds, the connectivity is considered unreachable. For example, if the source probe sends a ping packet to the target probe and receives a ping reply within the specified time, it is determined to be reachable.

[0033] In step S4, in response to the result of the inter-probe connectivity test being reachable, the flow data obtained from the flow record database is analyzed to determine whether there is flow data between the source VRF and the target VRF to generate an abnormal flow alarm. Accordingly, although the probe connectivity test confirms a potential intercommunication path, this is only a theoretical reachability and does not mean that actual service traffic has leaked. There may be various routing policies or security controls in the network, such that even if the path is reachable, the actual traffic does not pass through this path. Therefore, by analyzing the actual flow data, it can be verified whether there is real and unexpected cross-VRF traffic on the reachable path. This verification mechanism based on actual traffic can accurately determine whether there is a real traffic leakage behavior, avoiding false alarms based solely on configuration risks or connectivity test results. It combines potential risks with actual behaviors, provides the most direct evidence of leakage, and is a key link in constructing a comprehensive and accurate MPLS-VPN security protection scheme, ensuring the effective identification and alarm of actual security threats, thereby avoiding unnecessary resource waste and security panic.

[0034] Specifically, as an alternative implementation form, step S4 includes: S41, based on the ifIndex of the ingress interface and egress interface of each flow data, determining the candidate source VRF and candidate target VRF of each flow data; S42, combining the candidate source VRF and candidate target VRF of each flow data and inputting them into a hash encoder to obtain a set of flow data compressed hash indexes; S43, combining the source VRF and the target VRF and inputting them into the hash encoder to obtain a hash query; S44, inputting the hash query and the set of flow data compressed hash indexes into a hash search engine to determine whether there is flow data between the source VRF and the target VRF.

[0035] It should be understood that flow data itself usually only contains information such as IP addresses and ports, and lacks a direct VRF identifier. However, in the MPLS-VPN environment, the VRF affiliation of traffic is determined by the interfaces through which it enters and exits the PE router, because each interface is usually bound to a specific VRF. Thus, in the technical solution of this application, through the ifIndex (interface index) of the ingress interface and egress interface recorded in the flow data, the interface configuration information of the PE router can be queried in reverse, thereby inferring the source VRF and target VRF to which the traffic belongs. This is a key step in associating abstract flow data with specific VPN isolation policies, providing a basis for subsequent determination of whether there is abnormal cross-VRF traffic, ensuring the accuracy and effectiveness of traffic analysis, and is an indispensable link in realizing MPLS-VPN traffic leakage detection.

[0036] Specifically, step S41 is implemented as follows: First, obtain the original flow data from the flow record database. The flow record database is constructed by receiving flow protocol packets such as NetFlow, IPFIX, or sFlow from the PE router. The PE router is configured to export the traffic information passing through its interfaces to the flow collector in the form of flow records. After receiving these packets, the flow collector parses, aggregates, and stores them to form the flow record database. Each flow record contains the five-tuple information of the traffic (source IP, destination IP, source port, destination port, protocol), timestamp, number of bytes, number of packets, and the key ingress interface ifIndex and egress interface ifIndex.

[0037] Next, in order to determine the VRF affiliation of the flow data, a mapping table of interface index (ifIndex) and VRF name needs to be established. This mapping table is pre-constructed and updated regularly. In the MPLS-VPN network, each interface (physical interface or logical interface, such as sub-interface) on the PE router is bound to a specific VRF or belongs to the global routing table. Therefore, by parsing the router configuration of the PE router obtained in step S1, the corresponding relationship between the ifIndex of each interface and the VRF it belongs to can be extracted. For example, if the PE router configuration shows that interface GigabitEthernet0 / 1.100 is bound to VRF_A and its ifIndex is 1001, and interface GigabitEthernet0 / 1.200 is bound to VRF_B and its ifIndex is 1002, then the mapping table will contain entries: {1001:VRF_A, 1002:VRF_B}. This mapping table is stored in a memory database or lookup table for quick query.

[0038] Then, the flow data analysis module reads the flow data from the flow record database one by one. For each flow record, the module extracts the ifIndex of its ingress interface and the ifIndex of its egress interface. Then, using the pre-constructed ifIndex-VRF mapping table, these two ifIndices are queried.

[0039] Specifically, for the ifIndex of the ingress interface of a flow record, query the mapping table to determine the VRF associated when this traffic enters the PE router. This VRF is then determined as the candidate source VRF for this flow data. For example, if the ifIndex of the ingress interface of a flow record is 1001 and querying the mapping table yields its corresponding VRF_A, then the candidate source VRF for this flow is VRF_A. Similarly, for the ifIndex of the egress interface of a flow record, query the mapping table to determine the VRF associated when this traffic leaves the PE router. This VRF is then determined as the candidate destination VRF for this flow data. For example, if the ifIndex of the egress interface of the same flow record is 1002 and querying the mapping table yields its corresponding VRF_B, then the candidate destination VRF for this flow is VRF_B. It should be noted that if a certain ifIndex fails to find the corresponding VRF in the mapping table, it can be marked as the global VRF or an unknown VRF and special processing or filtering can be performed in subsequent analysis. In this way, each flow data record determines its corresponding candidate source VRF and candidate destination VRF attributes.

[0040] It can be understood that the flow record database may contain a vast amount of flow data. Directly comparing each original VRF pair one by one will incur huge computational and storage overheads, affecting the analysis efficiency. Therefore, by combining the candidate source VRF and candidate destination VRF and performing hash encoding, the complex VRF pair information can be compressed into a hash index of a fixed length. This hash index can not only efficiently represent the VRF pair, but also significantly reduce the storage space and support fast lookup and comparison operations. This is crucial for quickly locating the traffic between specific VRF pairs in the subsequent vast amount of flow data, greatly enhancing the efficiency and scalability of traffic analysis and being a key technical means for realizing real-time or near-real-time abnormal flow detection.

[0041] Specifically, step S42 is implemented as follows: The candidate source VRF and the candidate destination VRF of each piece of flow data are combined. The combination operation is to splice the two VRF name strings according to a preset rule to form a unique string representation. For example, the candidate source VRF and the candidate destination VRF can be connected with a specific delimiter, such as _. To ensure the consistency of the hash result, the splicing order must be fixed, for example, it is always candidate source VR_ candidate destination VRF. Then, the combined string is input into a hash encoder. The hash encoder is a deterministic function that receives input data of any length and outputs a hash value (or hash index) of a fixed length. Commonly used hash algorithms include MD5, SHA-256, or the FNV hash more suitable for strings, etc. The selected hash algorithm should have good hashability, that is, different input strings should produce different hash values as much as possible to reduce hash collisions. The hash encoder does not have weight or bias parameters that need to be preset, and its output is completely determined by the input data and the algorithm itself. For the combined string, the hash encoder will calculate a unique hash value. This hash value is the compressed hash index of the flow data. Repeating the above combination and hash encoding process for all flow data obtained from the flow record database, a set containing the compressed hash indexes of all flow data will be finally obtained. Each element in this set represents a unique identifier of the path from the source VRF to the destination VRF that a certain piece of flow data has passed through.

[0042] Particularly, in the scenario of combined hash encoding of the candidate source VRF and the candidate destination VRF, when the hash distributions of the candidate source VRF and the candidate destination VRF (i.e., the hash value statistical characteristics of the candidate source VRF and the candidate destination VRF) are mapped to the encoding space, since the hash encoding is binary encoding, the mapping to the binary space as the value range of the hash table will encounter the problem of expression degradation, that is, under the binary encoding representation, the distortion of the hash value or the loss of hash information will affect the entire sequence.

[0043] Based on this, preferably, as an alternative implementation form, step S42, combining the candidate source VRF and candidate target VRF of each flow data and inputting them into a hash encoder to obtain a set of flow data compression hash indexes, includes: First, combining the candidate source VRF and the candidate target VRF and inputting them into the hash encoder to obtain a hash sequence. It should be understood that in a traditional MPLS-VPN network, traffic isolation is achieved through VRF (VPN Routing and Forwarding Instance). To identify abnormal traffic across VRFs, it is necessary to associate the candidate source VRF and candidate target VRF information of the traffic. Combining these two VRF names to form a unique string is the basis for constructing a traffic path identifier. Subsequently, this variable-length string is mapped to a fixed-length binary hash sequence through an initial hash encoder, aiming to achieve data compression and standardization, facilitating subsequent bit operations and efficient storage. The combination operation concatenates the two VRF name strings according to a preset and fixed rule to form a unique string representation, which is the same as the above method. Then, this combined string is input into a hash encoder, for example, a standard string hash function such as FNV hash or MurmurHash. This hash encoder maps the string to a fixed-length binary hash value, that is, the hash sequence. This step transforms the complex VRF pair information into a unified and compact binary representation, laying the foundation for subsequent refined hash processing, and at the same time initially achieving data dimensionality reduction, providing an efficiency premise for the processing of massive flow data.

[0044] Next, perform bidirectional shifting on the hash sequence and then aggregate it to obtain a shifted aggregated hash sequence, that is: ; where is the hash sequence, is the shifted aggregated hash sequence, is bitwise exclusive OR, is the number of shift bits, is to find and the value with the smallest KL divergence between them, starting from the initial value of 1 and gradually increasing. For example, for an 8-bit hash sequence, can range from 1 to 4, is a right shift, that is the rightmost bit will be discarded and filled with zeros on the left, is a left shift, that is the leftmost bit will be discarded and filled with zeros on the right. For example , is 2, , in this example, .

[0045] Correspondingly, although the hash sequence is the unique identifier of the VRF pair, under binary coding representation, hash value distortion or hash information loss may lead to the problem of expression degradation, that is, the potential correlation information between VRF pairs cannot be fully captured. Bidirectional shift aggregation aims to simulate class coding aggregation within the local domain. By introducing bit information in different directions and performing exclusive OR operations, the local correlation and robustness of the hash sequence are enhanced. The optimal shift bit number is determined by the KL divergence between the shifted aggregated hash sequences. This is to ensure that while aggregating local information, the deviation between the newly generated hash sequence and the original information distribution is minimized, avoiding excessive distortion. In this way, the problem of potential expression degradation in hash coding is effectively solved. Through intelligent displacement and aggregation, the shifted aggregated hash sequence can more comprehensively and accurately reflect the inherent correlation characteristics between the source VRF and the target VRF, providing a richer and more reliable information dimension for subsequent abnormal traffic identification.

[0046] Then, a gating function threshold-based decision is made on the shifted aggregated hash sequence and the hash sequence to obtain a gated hash sequence, that is: ; where are each value in are each value in is the gating function, that is, for each bit of the shifted aggregated hash sequence and the hash sequence, if , that is and are the same, then the -th bit of the gated hash sequence is set to 1; otherwise, it is set to 0.

[0047] It should be understood that although the shifted aggregated hash sequence aggregates local information, there may still be some unstable or information-redundant bits. The gating function threshold-based decision aims to compare and bit by bit, and judge which bits are stable and representative through a preset logic. This decision mechanism can activate the compensation operation of the gated hash sequence, filter out those hash bits that are highly consistent with the original information after shift aggregation, thereby improving the quality and reliability of the hash sequence. In this way, the gated hash sequence can more accurately capture the key information of the VRF pair, providing a cleaner and more effective input for the final corrected hash distribution.

[0048] Finally, the gated hash sequence is XORed with the hash sequence to correct the combined hash distribution to obtain a corrected hash sequence as the compressed hash index of the flow data, i.e.: ; where is the corrected hash sequence. That is to say, the final XOR operation is a compensation link in the entire optimized hash encoding process. It combines the optimized information after gated screening with the hash sequence . This combination aims to compensate for the possible degradation of combined information in the initial hash expression to the greatest extent. By activating the compensation operation for hash bit selection and enhancing the relevant synchronization information, the final hash index can more comprehensively and accurately represent the traffic relationship between the source VRF and the target VRF. The generated compressed hash index of the flow data not only inherits the uniqueness of the original hash but also effectively overcomes the problems of information loss and expression degradation that may exist in traditional hash encoding through multi-stage optimization processing, significantly improving the quality and information-carrying capacity of the hash index. This enables more accurate and efficient identification of potential cross-VRF abnormal traffic when querying in the hash search engine later, thus enhancing the security protection ability of the MPLS-VPN routing network.

[0049] Correspondingly, in order to efficiently search for the existence of traffic between specific VRF pairs in the massive set of compressed hash indexes of flow data, the source VRF and target VRF to be queried also need to be converted into the same hash format. In particular, the processing process of step S43 is the same as that of the above step S42. By maintaining a consistent combination and hash encoding process with the way of generating the flow data hash index in S42, it can be ensured that the query hash value is comparable to the indexes in the set. This unified hash representation method enables the subsequent search operation to utilize the O(1) average time complexity advantage of the hash table, greatly improving the query efficiency, and thus can quickly determine whether there is abnormal cross-VRF traffic. It is a key step in realizing efficient traffic analysis and abnormal alarm.

[0050] It should be understood that the above steps have converted both the VRF pairs to be queried and the VRF pairs in the massive flow data into an efficient hash index form. Now a fast and accurate mechanism is needed to determine whether a specific VRF pair (i.e., hash query) exists in the actual traffic records (i.e., the set of compressed hash indexes of flow data). The hash search engine can utilize the uniqueness and search efficiency of the hash value to complete the matching operation extremely quickly in a large dataset. This avoids the inefficiency of comparing the original VRF name strings one by one and ensures real-time or near-real-time detection of abnormal traffic even in the face of high-concurrency and large-volume network flows. It is a key link in the entire traffic analysis process to achieve efficient matching and rapid response.

[0051] In particular, as an alternative implementation form, in step S44, inputting the hash query and the set of stream data compressed hash indexes into a hash search engine to determine whether there is stream data between the source VRF and the target VRF includes: in response to querying that there is a stream data compressed hash index consistent with the hash query in the set of stream data compressed hash indexes, determining that there is stream data between the source VRF and the target VRF.

[0052] Specifically, step S44 is implemented as follows: The hash search engine receives these two inputs and performs a core lookup operation. The hash search engine determines whether a given hash query value exists in a set of hash indexes. Its implementation method is based on the lookup mechanism of a hash table. A hash table is a data structure that maps keys to storage locations through a hash function, thereby achieving an average O(1) time complexity lookup. In this scenario, the set of stream data compressed hash indexes generated in S42 is organized into a hash table, where each hash index is stored as a key. The hash search engine uses the hash query as the key to be looked up. It first uses the hash function inside the hash table to calculate the storage location of this query value in the hash table. Then, the search engine directly accesses this storage location to check whether there is a stream data compressed hash index exactly consistent with the hash query value. If there is a hash collision, the hash table will adopt a collision resolution mechanism such as the chaining method or open addressing method to handle it, and the search engine will traverse the elements in the bucket for exact matching. Finally, in response to querying a stream data compressed hash index consistent with the hash query in the set of stream data compressed hash indexes, it is determined that there is actual stream data between the source VRF and the target VRF. If no index matching the hash query value is found in the hash table after the lookup, it is determined that there is no stream data. If the result is that there is stream data, it means that unexpected traffic intercommunication has indeed occurred between the expected isolated VRFs, which will trigger an abnormal flow alarm.

[0053] In step S5, based on the configuration risk report, the probe - to - probe connectivity test result, and the abnormal flow alarm, perform multi - source information intelligent association and leakage event confirmation to obtain a VPN traffic confirmation leakage event. It should be understood that single - dimension security detection often has the risk of false positives or false negatives. For example, relying solely on configuration risks may only be a potential threat, and actual traffic may not occur; relying solely on reachable connectivity may only be a control - plane problem, and the data plane is not affected; relying solely on abnormal flow alarms may lack context and it is difficult to determine whether it is a real VPN leakage. Therefore, this application can form a more comprehensive and accurate judgment logic by intelligently associating these three types of heterogeneous information. Only when there are configuration risks, the connectivity is actually reachable, and abnormal cross - VRF traffic is indeed detected can a VPN traffic leakage event be finally confirmed, thereby significantly improving the accuracy of alarms, avoiding unnecessary security responses, and ensuring the timely identification of real threats.

[0054] Specifically, as an optional implementation form, step S5 includes: if the configuration risk report shows that there is a risk in importing the RT of the source VRF into the RT of the target VRF, and the inter-probe connectivity test result between the source VRF and the target VRF is reachable, and there is flow data between the source VRF and the target VRF, then generate the VPN traffic confirmation leakage event.

[0055] Specifically, step S5 is implemented as follows: First, it will traverse each risk record in the configuration risk report. For each record, it will extract the involved source VRF and target VRF. Then, for this pair of VRFs, it will query the corresponding inter-probe connectivity test result. If the query result shows that the inter-probe connectivity test result between the source VRF and the target VRF is reachable, then the condition is met. Subsequently, on the basis of meeting the first two conditions, it will further query the generated abnormal flow alarm to determine whether there is actual flow data between the same source VRF and target VRF. If the query result shows that there is flow data, then the third condition is met. Only when all three conditions are simultaneously met, that is, the configuration risk report shows that there is a risk in importing the RT of the source VRF into the RT of the target VRF, and the inter-probe connectivity test result between the source VRF and the target VRF is reachable, and there is flow data between the source VRF and the target VRF, at this time, the system will finally generate a VPN traffic confirmation leakage event. This VPN traffic confirmation leakage event will contain detailed information, such as: the names of the involved source VRF and target VRF, the specific risk type such as RT import conflict, the timestamp of the confirmed leakage, and the configuration risk points, probe test results and flow data existence as evidence.

[0056] In step S6, generate a security alarm prompt for the VPN traffic confirmation leakage event. That is, simply confirming the event is not sufficient to complete the closed-loop of security protection. Generating a security alarm prompt is a key link to ensure that security events can be promptly perceived, responded to and processed. It converts complex detection results into intuitive and actionable information, notifies relevant security operation and maintenance personnel or automated response mechanisms, and prompts them to take immediate measures, such as isolating the affected VRF, correcting configuration errors or further investigation. This makes the entire security protection solution move from detection to actual intervention and protection, and is a necessary step to ensure network security and avoid potential losses.

[0057] As an optional implementation form, step S6 is implemented as follows: First, the alarm generation module receives the VPN traffic confirmation leakage event output by S5. For each confirmed leakage event, the module will extract the key information in the event according to a predefined alarm template. The alarm template is a pre-designed text or data structure used to standardize the format of the alarm content and the included fields.

[0058] Then, the module fills the specific data in the leakage event into the corresponding fields of the alarm template. For example, if the leakage event involves traffic leakage between VPN_A and VPN_B and the risk type is routing RT import conflict, this information will be clearly indicated in the alarm prompt. Meanwhile, the alarm level is set according to the severity of the leakage event. For example, if the leakage involves critical service VRF or high-risk RT, the alarm level can be set to severe or high-risk; general leakage can be set to medium or normal. These alarm levels are pre-set thresholds or rules, which are associated with factors such as the risk level in the configuration risk report and the importance of the involved VRF. The finally generated security alarm prompt is a structured text message, which contains the unique identifier of the event, the clear alarm level, the type description of the leakage event, the source VRF and target VRF names involved, the specific risk details leading to the leakage, the connectivity test results and actual traffic evidence supporting this judgment, and the timestamp when the event is confirmed. For example, a security alarm prompt can be expressed as: [Severe Alarm] VPN traffic leakage event: Event ID [unique identifier], confirmation time [timestamp]. There is unauthorized traffic intercommunication between source VRF [source VRF name] and target VRF [target VRF name]. Risk details: [specific risk description, such as RT import conflict]. The connectivity test results show reachability, and the actual flow data has been confirmed to exist. It is recommended to immediately check the PE router configuration and remove the improper routing target import policy.

[0059] Finally, the generated security alarm prompts are distributed through multiple pre-set notification channels. These channels can include but are not limited to: sending emails to the designated security operation and maintenance team, sending notifications via text messages or instant messaging tools, pushing the alarm information to the Security Information and Event Management (SIEM) platform, displaying an alarm banner on the network management interface, or triggering an automated response script. The notification channels and recipient lists are pre-configured according to the enterprise security policy and operation and maintenance process. For example, high-risk alarms may trigger alarms on the email, text message, and SIEM platform simultaneously, while general alarms may only be notified via email. In this way, it is ensured that the confirmed VPN traffic leakage event can be transmitted to relevant personnel or systems in a timely and accurate manner, so as to initiate subsequent investigation, repair, and protection measures, and complete the entire security protection loop.

[0060] In summary, the security protection method based on the MPLS-VPN routing network according to the embodiments of the present application is elucidated, aiming to solve the problems of insufficient identification of configuration risks in PE routers, incomplete verification of VPN isolation, and lack of multi-source information correlation analysis in the prior art. Specifically, first, by obtaining the PE router configuration and performing static compliance analysis, potential configuration risk points are pre-identified, making up for the deficiency of the traditional solution in detecting configuration risks at the routing level. Then, for the identified risk points, probes are scheduled to perform connectivity tests to directly verify whether the isolation between VPNs is broken, solving the problem that the existing solution cannot effectively verify isolation. At the same time, combined with flow data analysis, it is confirmed whether there is abnormal cross-VPN traffic, making up for the limitations of relying only on configuration or connectivity tests. Finally, through multi-source intelligent correlation of the configuration risk report, probe connectivity results, and abnormal flow alarms, VPN traffic leakage events are accurately confirmed, avoiding false alarms and missed alarms, thus realizing more comprehensive and accurate security protection for the MPLS-VPN routing network and effectively solving the technical problems proposed in the background art.

[0061] Figure 5 FIG. is a block diagram of a security protection system based on an MPLS-VPN routing network according to an embodiment of the present application. As Figure 5 shown, the security protection system 100 based on the MPLS-VPN routing network according to the embodiment of the present application includes: a router configuration acquisition module 110 for acquiring the router configuration of a PE router; a configuration risk report generation module 120 for performing static configuration compliance analysis on the router configuration of the PE router to obtain a configuration risk report; a probe test module 130 for, in response to the existence of a configuration risk point in the configuration risk report, scheduling a source probe to send a test packet to a target probe based on the configuration risk point to obtain a probe-to-probe connectivity test result; an abnormal flow alarm module 140 for, in response to the probe-to-probe connectivity test result being reachable, analyzing the flow data obtained from the flow record database to determine whether there is flow data between a source VRF and a target VRF to generate an abnormal flow alarm; a VPN traffic leakage event confirmation module 150 for performing multi-source information intelligent correlation and leakage event confirmation based on the configuration risk report, the probe-to-probe connectivity test result, and the abnormal flow alarm to obtain a VPN traffic confirmed leakage event; and a security alarm prompt generation module 160 for generating a security alarm prompt for the VPN traffic confirmed leakage event.

[0062] Here, those skilled in the art can understand that the specific operations of each step in the above security protection system based on the MPLS-VPN routing network have been introduced in detail in the description of the security protection method based on the MPLS-VPN routing network above with reference to Figures 1 to 4 and therefore, the repeated description thereof will be omitted.

[0063] The embodiments of the present disclosure have been described above. The above description is exemplary and not exhaustive, and is also not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments.

Claims

1. A security protection method based on an MPLS-VPN routing network, characterized in that, Including: S1: Obtain the router configuration of the PE router; S2 : Perform static configuration compliance analysis on the router configuration of the PE router to obtain a configuration risk report; S3 : In response to the existence of configuration risk points in the configuration risk report, based on the configuration risk points, schedule the source probe to send test packets to the target probe to obtain the probe - to - probe connectivity test result; S4: In response to the probe - to - probe connectivity test result being reachable, analyze the flow data obtained from the flow record database to determine whether there is flow data between the source VRF and the target VRF to generate an abnormal flow alarm; S5: Based on the configuration risk report, the probe - to - probe connectivity test result, and the abnormal flow alarm, perform multi - source information intelligent association and leakage event confirmation to obtain a VPN traffic confirmed leakage event; S6: Generate a security alarm prompt for the VPN traffic confirmed leakage event.

2. The security protection method based on the MPLS-VPN routing network according to claim 1, wherein Step S2 includes: performing configuration parsing on the router configuration of the PE router to obtain a standardized PE configuration object; extracting the RT policy from the standardized PE configuration object; inputting the RT policy into a configuration audit engine to obtain the configuration risk report, where the configuration audit engine is used to compare the RT policy with a predefined VPN isolation policy baseline.

3. The security protection method based on the MPLS-VPN routing network according to claim 2, wherein Step S3 includes: extracting the source VRF and the target VRF expected to be isolated from the configuration risk points; based on the source VRF and the target VRF, determine to schedule the source probe to send test packets to the target probe; in response to the target VRF receiving the test packet from the source VRF or the source VRF receiving the response from the target VRF, determine that the probe - to - probe connectivity test result is reachable.

4. The security protection method based on the MPLS-VPN routing network according to claim 3, wherein, Step S4 includes: based on the ifIndex of the incoming interface and the outgoing interface of each flow data, determine the candidate source VRF and the candidate target VRF of each flow data; jointly input the candidate source VRF and the candidate target VRF of each flow data into a hash encoder to obtain a set of flow data compressed hash indexes; jointly input the source VRF and the target VRF into the hash encoder to obtain a hash query; input the hash query and the set of flow data compressed hash indexes into a hash search engine to determine whether there is flow data between the source VRF and the target VRF.

5. The security protection method based on the MPLS-VPN routing network according to claim 4, wherein, Jointly inputting the candidate source VRF and the candidate target VRF of each flow data into a hash encoder to obtain a set of flow data compressed hash indexes includes: jointly inputting the candidate source VRF and the candidate target VRF into the hash encoder to obtain a hash sequence; performing bidirectional shifting on the hash sequence and then aggregating to obtain a shifted - aggregated hash sequence; performing a gated function threshold - type decision on the shifted - aggregated hash sequence and the hash sequence to obtain a gated hash sequence; performing an exclusive - OR operation on the gated hash sequence and the hash sequence to correct the joint hash distribution to obtain a corrected hash sequence as the flow data compressed hash index.

6. The security protection method based on the MPLS-VPN routing network according to claim 4, characterized in that, Input the set of the hash query and the stream data compressed hash index into a hash search engine to determine whether there is stream data between a source VRF and a target VRF, including: in response to querying that there is a stream data compressed hash index consistent with the hash query in the set of the stream data compressed hash index, determining that there is stream data between the source VRF and the target VRF.

7. The security protection method based on the MPLS-VPN routing network according to claim 1, wherein, Step S5 includes: if the configuration risk report shows that there is a risk in the RT of the source VRF importing the RT of the target VRF, and the probe - to - probe connectivity test result between the source VRF and the target VRF is reachable, and there is stream data between the source VRF and the target VRF, then generating the VPN traffic confirmation leakage event.

8. A security protection system based on an MPLS-VPN routing network, characterized in that, Including: A router configuration acquisition module, configured to acquire the router configuration of a PE router; A configuration risk report generation module, configured to perform static configuration compliance analysis on the router configuration of the PE router to obtain a configuration risk report; A probe test module, configured to, in response to there being a configuration risk point in the configuration risk report, based on the configuration risk point, schedule a source probe to send a test packet to a target probe to obtain a probe - to - probe connectivity test result; An abnormal flow warning module, configured to, in response to the probe - to - probe connectivity test result being reachable, analyze the stream data obtained from a stream record database to determine whether there is stream data between the source VRF and the target VRF to generate an abnormal flow warning; A VPN traffic leakage event confirmation module, configured to perform multi - source information intelligent association and leakage event confirmation based on the configuration risk report, the probe - to - probe connectivity test result, and the abnormal flow warning to obtain a VPN traffic confirmation leakage event; A security warning prompt generation module, configured to generate a security warning prompt for the VPN traffic confirmation leakage event.

Images