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

Abstract

The present application discloses a security protection method and system based on an MPLS-VPN routing network, which relates to the field of network security protection. It first identifies potential configuration risk points in advance by obtaining the PE router configuration and performing static compliance analysis. Then, for the identified risk points, the probe is scheduled to perform a connectivity test to directly verify whether the isolation between VPNs is broken. At the same time, combined with flow data analysis, it is confirmed whether there is abnormal cross-VPN traffic. Finally, by performing multi-source intelligent correlation of configuration risk reports, probe connectivity results, and abnormal flow alarms, VPN traffic leakage events are accurately confirmed. In this way, false alarms and missed alarms are avoided, thereby achieving more comprehensive and accurate security protection for the MPLS-VPN routing network.

Description

Technical Field

[0001] The present 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] As enterprises deepen their digital transformation, MPLS-VPN (Multi-Protocol Label Switching - Virtual Private Network)-based routing networks have become a mainstream choice for building internal enterprise networks and connecting branch offices due to their high security, high reliability, and flexible networking capabilities. MPLS-VPN creates logically isolated virtual networks within public networks, providing independent communication environments for different users or departments, effectively ensuring the privacy and integrity of data transmission. However, while MPLS-VPN provides isolation by design, its complexity also introduces potential security risks. For example, PE router configuration errors, misconfiguration of RT policies, or leaks can lead to unintended traffic flow between different VPNs, potentially causing serious security incidents such as data leakage and unauthorized access, threatening business continuity and data security. Therefore, it is crucial to establish a comprehensive and efficient security solution based on MPLS-VPN routing networks to proactively identify and address potential security risks.

[0003] However, existing security solutions for MPLS-VPN routing networks often have limitations. Traditional network protection measures, such as firewalls and intrusion detection systems, primarily focus on network boundaries and traffic content. They struggle to penetrate the MPLS-VPN routing layer and perform fine-grained detection and verification of PE router configuration compliance and the effectiveness of inter-VPN isolation policies. Furthermore, existing solutions often lack the ability to intelligently correlate information from multiple sources, failing to comprehensively analyze configuration risks, connectivity test results, and actual traffic data. This makes it difficult to accurately determine whether VPN traffic leakage has occurred. For example, even if a PE router configuration presents a risk, a false alarm should not be generated if actual traffic has not been leaked. Conversely, if the configuration is risk-free but actual traffic has been leaked, existing solutions may fail to detect it in a timely manner. This information isolation and lack of analytical capabilities make existing solutions inadequate for the complex security challenges of MPLS-VPN routing networks, hindering their ability to provide comprehensive and accurate security protection.

[0004] To address the deficiencies in the prior art described above, a security protection solution is desired that comprehensively and accurately identifies potential configuration risks and actual traffic leakage events in an MPLS-VPN routing network. Summary of the Invention

[0005] Based on the defects in the aforementioned 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: obtaining the router configuration of a PE router.

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

[0007] S3: In response to the presence of a configuration risk point in the configuration risk report, based on the configuration risk point, the source probe is scheduled to initiate a test package to the target probe to obtain a connectivity test result between the probes.

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

[0009] S5: Based on the configuration risk report, the inter-probe connectivity test result and the abnormal flow alarm, multi-source information intelligent correlation and leakage event confirmation are performed to obtain VPN traffic confirmed leakage events.

[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 acquiring the router configuration of a PE router; a configuration risk report generation module for performing a static configuration compliance analysis on the router configuration of the PE router to obtain a configuration risk report; a probe testing module for, in response to the existence of a configuration risk point in the configuration risk report, scheduling a source probe to initiate a test packet to a target probe based on the configuration risk point to obtain a connectivity test result between probes; an abnormal flow alarm module for, in response to the connectivity test result between probes being reachable, analyzing the flow data obtained from the flow record database to determine whether flow data exists between the source VRF and the target VRF to generate an abnormal flow alarm; a VPN traffic leakage event confirmation module for performing multi-source information intelligent correlation and leakage event confirmation based on the configuration risk report, the connectivity test result between probes and the abnormal flow alarm to obtain a VPN traffic confirmed leakage event; and a security alarm prompt generation module for generating a security alarm prompt for the VPN traffic confirmed leakage event.

[0012] Compared to existing technologies, the present application provides a security protection method and system for MPLS-VPN routing networks, aiming to address existing issues such as insufficient identification of PE router configuration risks, incomplete VPN isolation verification, and a lack of multi-source information correlation analysis. Specifically, by first obtaining PE router configurations and performing static compliance analysis, potential configuration risk points are pre-identified, addressing the shortcomings of traditional solutions in detecting configuration risks at the routing level. Next, probes are dispatched to perform connectivity tests on identified risk points to directly verify whether isolation between VPNs has been breached, addressing the inability of existing solutions to effectively verify isolation. Simultaneously, combined with flow data analysis, the system confirms the presence of abnormal cross-VPN traffic, addressing the limitations of relying solely on configuration or connectivity testing. Finally, by intelligently correlating configuration risk reports, probe connectivity results, and abnormal flow alarms, VPN traffic leakage events are accurately identified, avoiding false positives and missed negatives. This provides more comprehensive and accurate security protection for MPLS-VPN routing networks, effectively addressing the technical issues raised in the background art. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The above and other purposes, features, and advantages of the present application will become more apparent through a more detailed description of the embodiments of the present application in conjunction with the accompanying drawings. The accompanying drawings are intended to provide a further understanding of the embodiments of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application and do not constitute a limitation of the present application. In the drawings, the same reference numerals generally represent the same components or steps.

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

[0015] Figure 2 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 This is a flowchart of step S2 in the security protection method based on the MPLS-VPN routing network according to an embodiment of the present application.

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

[0018] Figure 5 This 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

[0019] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. While the drawings illustrate certain embodiments of the present disclosure, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0020] In response to the technical defects exposed by the above background technology, this application proposes a security protection method based on MPLS-VPN routing network. Figure 1 The flowchart of the security protection method based on the MPLS-VPN routing network according to the embodiment of the present application is shown. Figure 2 Schematic diagram of data flow based on the MPLS-VPN routing network security protection method according to the embodiment of the present application. Figure 1 and Figure 2 As shown, according to the embodiment of the present application, the security protection method based on the MPLS-VPN routing network includes: S1: obtaining the router configuration of the PE router; S2: performing a 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 the source probe to initiate a test package to the target probe to obtain a connectivity test result between probes; S4: in response to the connectivity test result between probes 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 alarm; S5: based on the configuration risk report, the connectivity test result between probes and the abnormal flow alarm, performing multi-source information intelligent correlation and leakage event confirmation 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 is understandable that the configuration of the PE router is the cornerstone of the security protection of the MPLS-VPN routing network. As the entrance and exit of VPN traffic, the configuration of the PE router directly determines the isolation strategy and routing behavior between different VPNs. Any configuration error, especially the mismatch or leakage of the RT policy, may cause traffic to flow between VPNs that should be isolated, thereby causing 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 a prerequisite for subsequent static configuration compliance analysis. It is also the first step to discover potential configuration risks and evaluate the effectiveness of VPN isolation. It provides key initial information for subsequent connectivity testing and traffic analysis, so that security risks of the MPLS-VPN routing network can be discovered and resolved from the source.

[0022] As an optional implementation, step S1 is performed as follows: First, a secure connection is established with the target PE router via a network management protocol, such as Secure Shell (SSH) or Simple Network Management Protocol (SNMP). After the connection is established, specific command-line interface commands or SNMP queries are sent to retrieve the PE router's complete configuration information. The output of these commands contains the PE router's entire current running configuration, including interface configuration, routing protocol configuration, VPN instance (VRF) configuration, and, crucially, routing target (RT) import / export policies. The retrieved configuration information is returned in text format. To ensure data integrity and accuracy, the retrieved configuration data is verified using mechanisms such as checksums or digital signatures. For example, after retrieving the configuration, an MD5 hash of the configuration file can be calculated and compared with the hash provided by the router to confirm that the data has not been tampered with during transmission. Furthermore, to enable automated and periodic retrieval, a configuration retrieval cycle can be preset, such as every 24 hours, or an immediate retrieval can be triggered upon detecting a change in the PE router configuration, ensuring that security analysis is always based on the latest configuration information. The router configuration obtained in raw 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. Accordingly, although MPLS-VPN provides logical isolation, the configuration of PE routers is extremely complex, making it difficult to detect all potential configuration errors or non-compliance items through manual review. In particular, the configuration of RT policies directly determines the routing import and export relationships between different VPNs. If improperly configured, it can easily lead to unexpected inter-VPN traffic flow and cause data leakage. To this end, the present application uses static configuration compliance analysis to conduct in-depth inspections of PE router configurations without affecting network operations, identifying configuration items that do not comply with predefined security baselines, thereby providing early warnings and locating potential risk points before actual traffic leakage occurs. This effectively compensates for the shortcomings of existing technologies in routing-level configuration risk detection, provides clear risk guidance for subsequent connectivity testing and traffic analysis, and is an important component of building a comprehensive and precise security protection solution, effectively preventing security incidents caused by configuration errors.

[0024] In particular, as an optional implementation, Figure 3 FIG. 1 is a flow chart of step S2 in the security protection method based on the MPLS-VPN routing network according to an embodiment of the present application. 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 the RT policy from the standardized PE configuration object; S23, inputting the RT policy into a configuration audit engine to obtain the configuration risk report, wherein 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, execute step S21. The configuration parsing module reads the original text configuration of the PE router. These configurations are usually in the form of command line interface output and have a specific grammatical structure. For subsequent unified processing, the parsing module uses predefined grammatical parsing rules to structure them. These rules can be pattern matching based on regular expressions to identify specific keywords, parameters, and values ​​in the configuration, for example, by matching vrf definition<VRF_NAME> To identify the definition start of VRF, or match route-target import<RT_VALUE> and route-target export<RT_VALUE> To extract route target values. For more complex, hierarchical configurations, the parsing module uses a context-free grammar or parser generation tool such as ANTLR to build a parser capable of understanding the router configuration language. This parser converts the raw text stream into an abstract syntax tree that clearly represents the configuration hierarchy and the semantics of each configuration item. After parsing, the raw, unstructured text configuration is converted into a unified, standardized PE configuration object that is easy for programs to process. This standardization aims to eliminate the impact of differences in configuration syntax across different routers, allowing subsequent RT policy extraction and auditing to be performed on a common data model. This standardized PE configuration object is represented in a tree structure or as a set of key-value pairs. For example, a VRF instance can be abstracted as a separate configuration object, consisting of its unique name, such as VPN_A, a route distinguisher (RD), such as 100:1, and a list detailing all configured import route targets (route-targetimport) and export route targets (route-targetexport). Each RT value itself can also be a sub-object, including 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, identifying and extracting all configuration items related to the RT policy. Specifically, it searches 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-targetimport 65000:100 and route-target export 65000:200, then these RT values ​​(65000:100 and 65000:200) and the VRF to which they belong (VPN_A) are extracted to form a structured RT policy set. This set contains the imported RT and exported 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. This baseline is a set of rules that clearly stipulates the RT import and export relationships that are allowed or prohibited 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. These baseline rules can be pre-set by network security experts based on enterprise security policies and stored in the database. After receiving the RT policy set, the audit engine will traverse each RT import / export relationship therein and compare 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 VPN_X imports VPN_Y's RT or VPN_Y imports VPN_X's RT in the RT policy set, the audit engine will mark the configuration as a risk point and generate a detailed configuration risk report, including the risk type, such as RT import conflict, involved VRFs, such as source VRF: VPN_X, target VRF: VPN_Y, RT value, and risk level, such as high risk.

[0028] In step S3, in response to the presence of a configuration risk point in the configuration risk report, the source probe is scheduled to initiate a test packet to the target probe based on the configuration risk point to obtain inter-probe connectivity test results. 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 issues. For example, even if there is an import risk in the RT policy, actual traffic may not be able to communicate due to other routing policies or network topology restrictions. Therefore, in this application, through active probe connectivity testing, configuration risks can be dynamically verified to confirm whether unexpected connectivity has actually occurred between the expected isolated VPNs in the presence of configuration risks. This dynamic verification mechanism compensates for the shortcomings of static analysis, avoids false positives, and provides more direct and accurate isolation verification results. It converts potential configuration risks into observable connectivity status, providing key empirical data for subsequent traffic analysis and leakage event confirmation. It is an indispensable part of building a comprehensive and accurate MPLS-VPN security protection solution and ensures the effective identification of actual security threats.

[0029] In particular, as an optional implementation, Figure 4 FIG3 is a flow chart of step S3 in the security protection method based on the MPLS-VPN routing network according to an embodiment of the present application. Figure 4 As shown, step S3 includes: S31, extracting the expected isolated source VRF and target VRF from the configured risk point; S32, based on the source VRF and the target VRF, determining to schedule the source probe to initiate a test package to the target probe; S33, in response to the target VRF receiving the test package of the source VRF or the source VRF receiving the response of the target VRF, determining that the connectivity test result between the probes is reachable.

[0030] Specifically, step S3 is implemented as follows: First, execute step S31. The configuration risk report clearly indicates which VRFs have potential RT import / export risks, such as source VRF: VPN_A, target VRF: VPN_B, risk type: RT import conflict. The extraction module parses these risk records and identifies the source VRF and target VRF pairs that are clearly stated therein and are expected to remain isolated but have potential intercommunication risks. 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 traverses all risk points in the report and extracts VRF pairs, that is, source VRFs and target VRFs that are expected to be isolated but may have intercommunication.

[0031] Then, step S32 is executed. To conduct actual connectivity testing, network probes need to be deployed. These probes are lightweight software agents or hardware devices, pre-deployed at key locations within the MPLS-VPN routing network, such as servers or virtual machines connected to different virtual resource routing (VRFs). Each probe is configured with a specific VRF context, enabling it to simulate traffic behavior within that VRF. A probe scheduling module selects appropriate source and target probes from a pre-set probe pool based on the source and target VRFs extracted in S31. It is worth noting that a source probe is a network device deployed within or with routable reachability to the source VRF, such as a virtual machine or a physical server. It can simulate the initiator of traffic within the source VRF. Similarly, a target probe is a network device deployed within or with routable reachability to the target VRF. It can simulate the receiver of traffic within the target VRF. After the probe is determined, an instruction is sent to the source probe, requesting it to initiate a test packet to 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 test accuracy, the source IP address of the test packet should belong to the address space of the source VRF, and the destination IP address should belong to the address space of the destination VRF. For example, if the source VRF is VPN_A and the destination VRF is VPN_B, the source probe's IP address is 10.1.1.10, which belongs to VPN_A, and the destination probe's IP address is 10.2.2.20, which belongs to VPN_B, the source probe will send a ping packet to 10.2.2.20.

[0032] Finally, execute step S33. Continue to monitor whether the target probe receives the test packet sent by the source probe, or whether the source probe receives a response from the target probe, for example, 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 if there is an isolation requirement in the configuration, the actual network path is reachable, so the inter-probe connectivity test result is determined to be reachable, which means that although the configuration audit report shows that there is a risk, there is indeed cross-VRF connectivity in the actual network, confirming the potential traffic leakage path. Conversely, if no response or test packet is received within the preset timeout period, for example, 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 inter-probe connectivity test result being reachable, the flow data obtained from the flow record database is analyzed to determine whether flow data exists between the source VRF and the target VRF, thereby generating an abnormal flow alarm. Accordingly, although the probe connectivity test confirms a potential intercommunication path, this is only theoretical reachability and does not mean that actual service traffic has been leaked. Various routing policies or security controls may exist in the network, so that even if a path is reachable, actual traffic does not pass through it. Therefore, by analyzing the actual flow data, it is possible to verify whether there is real, unexpected cross-VRF traffic on the reachable path. This actual traffic-based verification mechanism can accurately determine whether there is actual traffic leakage, avoiding false alarms based solely on configuration risks or connectivity test results. It combines potential risks with actual behavior, providing the most direct evidence of leakage. It is a key component in building a comprehensive and accurate MPLS-VPN security protection solution, ensuring the effective identification and warning of actual security threats, thereby avoiding unnecessary resource waste and security panic.

[0034] In particular, as an optional implementation form, step S4 includes: S41, determining the candidate source VRF and candidate target VRF of each flow data based on the ifIndex of the input interface and the output interface of each flow data; S42, combining the candidate source VRF and the candidate target VRF of each flow data and inputting them into the 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 the 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 typically only contains information such as IP addresses and ports, and lacks direct VRF identification. However, in an MPLS-VPN environment, the VRF affiliation of traffic is determined by the interfaces it enters and exits the PE router, as each interface is typically bound to a specific VRF. Therefore, in the technical solution of this application, the interface configuration information of the PE router can be reversely queried through the ifIndex (interface index) of the inbound and outbound interfaces recorded in the flow data, thereby inferring the source and destination VRFs 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 achieving MPLS-VPN traffic leakage detection.

[0036] Specifically, step S41 is implemented as follows: First, raw flow data is obtained from the flow record database. The flow record database is constructed by receiving flow protocol packets such as NetFlow, IPFIX, or sFlow from PE routers. PE routers are configured to export traffic information passing through their 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 flow's five-tuple information (source IP, destination IP, source port, destination port, protocol), timestamp, byte count, packet count, and the key inbound and outbound interface ifIndex values.

[0037] Next, to determine the VRF to which the flow data belongs, a mapping table is created between interface indexes (ifIndex) and VRF names. This mapping table is pre-built and regularly updated. In an MPLS-VPN network, each interface (physical or logical, such as a subinterface) on a PE router is bound to a specific VRF or belongs to the global routing table. Therefore, by parsing the PE router configuration obtained in step S1, the correspondence between each interface's ifIndex and its VRF can be extracted. For example, if the PE router configuration shows that interface GigabitEthernet0 / 1.100 is bound to VRF_A with an ifIndex of 1001, and interface GigabitEthernet0 / 1.200 is bound to VRF_B with an ifIndex of 1002, then the mapping table will contain the entry: {1001:VRF_A, 1002:VRF_B}. This mapping table is stored in an in-memory database or lookup table for fast querying.

[0038] The flow data analysis module then reads flow data from the flow record database one by one. For each flow record, the module extracts the ifIndex of the incoming interface and the ifIndex of the outgoing interface. It then uses the pre-built ifIndex-VRF mapping table to query these two ifIndex values.

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

[0040] It is understandable that the flow record database may contain a massive amount of flow data. Directly comparing the original VRF pairs one by one will incur huge computational and storage overhead, affecting analysis efficiency. To this end, by combining the candidate source VRF and the candidate target VRF and performing hash encoding, the complex VRF pair information can be compressed into a fixed-length hash index. This hash index not only efficiently represents VRF pairs, but also significantly reduces storage space and supports fast search and comparison operations. This is crucial for quickly locating traffic between specific VRF pairs in massive flow data. It greatly improves the efficiency and scalability of traffic analysis and is a key technical means to achieve real-time or near-real-time anomaly flow detection.

[0041] Specifically, step S42 is implemented as follows: the candidate source VRF and candidate target VRF for each flow data item are joined. The join operation concatenates the two VRF name strings according to preset rules to form a unique string representation. For example, the candidate source VRF and candidate target VRF can be concatenated with a specific delimiter, such as _. To ensure consistency in the hash result, the concatenation order must be fixed, for example, always candidate source VR_candidate target VRF. This joined string is then input into a hash encoder. A hash encoder is a deterministic function that accepts input data of arbitrary length and outputs a fixed-length hash value (or hash index). Common hash algorithms include MD5, SHA-256, or the more string-appropriate FNV hash. The selected hash algorithm should have good hashing properties, meaning that different input strings should produce different hash values ​​as much as possible to reduce hash conflicts. The hash encoder does not require preset weights or bias parameters; its output is entirely determined by the input data and the algorithm itself. For the joined string, the hash encoder calculates a unique hash value. This hash value serves as the compressed hash index for the flow data. Repeating the above union and hashing process for all flow data obtained from the flow record database will eventually produce a set containing the compressed hash indexes of all flow data. Each element in this set represents the unique identifier of the path from the source VRF to the destination VRF that a particular flow data passed through.

[0042] In particular, in the scenario of jointly hash coding the candidate source VRF and the candidate target VRF, when the hash distributions of the candidate source VRF and the candidate target VRF (i.e., the statistical characteristics of the hash values ​​of the candidate source VRF and the candidate target VRF) are mapped to the coding space, since the hash coding is binary coding, the mapping to the binary space as the value range of the hash table will encounter the expression degradation problem. That is, under the binary coding representation, hash value distortion or hash information loss will affect the entire sequence.

[0043] Based on this, preferably, as an optional implementation, step S42 combines the candidate source VRFs and candidate target VRFs of each flow data and then inputs them into a hash encoder to obtain a set of compressed hash indexes for the flow data. This includes: first, combining the candidate source VRFs and candidate target VRFs and then inputting them into the hash encoder to obtain a hash sequence. It should be understood that in traditional MPLS-VPN networks, traffic isolation is achieved through VRFs (VPN routing and forwarding instances). 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 forms a unique string, which serves as the basis for constructing a traffic path identifier. Subsequently, an initial hash encoder maps this variable-length string into a fixed-length binary hash sequence, aiming to achieve data compression and standardization, facilitating subsequent bit operations and efficient storage. The join operation involves concatenating the two VRF name strings according to preset, fixed rules to form a unique string representation, similar to the method described above. This combined string is then fed into a hash encoder, for example, a standard string hash function such as FNV Hash or MurmurHash. This hash encoder maps the string into a fixed-length binary hash value, or hash sequence. This step converts complex VRF pair information into a unified, compact binary representation, laying the foundation for subsequent refined hash processing. It also achieves preliminary data dimensionality reduction, providing an efficient foundation for processing massive stream data.

[0044] Next, the hash sequence is bidirectionally shifted and aggregated to obtain a shifted aggregated hash sequence, namely: ;in, is a hash sequence, is a shift aggregate hash sequence, is bitwise exclusive OR, is the number of shifts, Yes found and The KL divergence between the smallest value, Starting from the initial 1, it increases gradually. For example, for an 8-bit hash sequence, It can be from 1 to 4, is shifted to the right, that is The rightmost The bits will be discarded and filled on the left 0, is shifted to the left, that is The leftmost The bits will be discarded and the right side will be filled 0, for example , is 2, , in this example, .

[0045] Accordingly, although the hash sequence is the unique identifier of the VRF pair, hash value distortion or hash information loss under binary coding representation may lead to expression degradation problems, that is, the potential correlation information between the VRF pairs cannot be fully captured. Bidirectional shift aggregation aims to simulate class coding aggregation in the local domain. By introducing bit information in different directions and performing XOR operations, the local correlation and robustness of the hash sequence are enhanced. The optimal number of shift bits is determined by the KL divergence between the shifted aggregated hash sequence and the hash sequence. This is to ensure that the deviation between the newly generated hash sequence and the original information distribution is minimized while aggregating local information, avoiding excessive distortion. This effectively solves the expression degradation problem that may exist in hash coding. Through intelligent displacement and aggregation, the shifted aggregated hash sequence can more comprehensively and accurately reflect the intrinsic 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 gated function threshold decision is performed on the shifted aggregate hash sequence and the hash sequence to obtain a gated hash sequence, namely: ;in, yes Each value in yes Each value in It is a gating function, that is, for each bit of the shifted aggregate hash sequence and the hash sequence ,if ,Right now and If two bits are the same, the gated hash sequence No. The bit is set to 1; otherwise, it is set to 0.

[0047] It should be understood that although the shifted aggregate hash sequence aggregates local information, there may still be some unstable or redundant bits. The gate function threshold decision is designed to and A bit-by-bit comparison is performed, and preset logic is used to determine which bits are stable and representative. This decision-making mechanism activates the compensation operation of the gated hash sequence, screening out hash bits that maintain a high degree of consistency with the original information after shifting and aggregation, thereby improving the quality and reliability of the hash sequence. This allows the gated hash sequence to more accurately capture the key information of the VRF pair, providing a purer and more efficient input for the final modified hash distribution.

[0048] Finally, the gated hash sequence is XORed with the hash sequence to correct the joint hash distribution to obtain a corrected hash sequence as the stream data compression hash index, namely: ;in, It is to modify the hash sequence. In other words, the final XOR operation is the compensation link of the entire optimized hash coding process. It will be gated and filtered by the optimization information With hash sequence This fusion is designed to compensate for the possible degradation of joint information in the initial hash expression to the greatest extent possible, and to enhance the relevant synchronization information by activating the compensation operation for hash bit selection, so that the final hash index can more comprehensively and accurately represent the traffic relationship between the source VRF and the target VRF. The generated flow data compression hash index not only inherits the uniqueness of the original hash, but also effectively overcomes the information loss and expression degradation problems 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 subsequent queries in the hash search engine to identify potential cross-VRF abnormal traffic with higher accuracy and efficiency, thereby enhancing the security protection capabilities of the MPLS-VPN routing network.

[0049] Accordingly, in order to efficiently search for traffic between a specific VRF pair in a massive set of compressed hash indexes of stream data, the source VRF and target VRF to be queried need to be converted into the same hash format. In particular, the processing of step S43 is the same as the processing of step S42 above. By combining and hashing the values ​​in a manner consistent with the generation of the stream data hash index in S42, it is possible to ensure that the query hash value is comparable to the index in the set. This unified hash representation method enables subsequent search operations to take advantage of the O(1) average time complexity of the hash table, greatly improving query efficiency and enabling rapid determination of whether there is abnormal cross-VRF traffic. This is a key step in achieving efficient traffic analysis and abnormality alarms.

[0050] As you can understand, the preceding steps have already converted both the VRF pairs to be queried and the VRF pairs in the massive flow data into an efficient hash index format. Now, a fast and accurate mechanism is needed to determine whether a specific VRF pair (i.e., the hash query) exists in the actual flow records (i.e., the compressed hash index set of the flow data). A hash search engine leverages the uniqueness and search efficiency of hash values ​​to perform extremely fast matching operations within large data sets. This avoids the inefficiency of comparing the original VRF name strings one by one, ensuring real-time or near-real-time detection of anomaly traffic even in the face of high-concurrency and high-volume network flows. This is a key component in achieving efficient matching and rapid response in the entire traffic analysis process.

[0051] In particular, as an optional implementation form, step S44 inputs the hash query and the set of flow data compression hash indexes into a hash search engine to determine whether flow data exists between the source VRF and the target VRF, including: in response to querying that there is a flow data compression hash index consistent with the hash query in the set of flow data compression hash indexes, determining that flow data exists 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 the core search operation. The hash search engine determines whether a given hash query value exists in a hash index set. Its implementation method is based on a hash table search mechanism. 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 search. In this scenario, the stream data compressed hash index set generated by 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 searched. It first uses the hash function inside the hash table to calculate the storage location of the query value in the hash table. Then, the search engine directly accesses the storage location to check whether there is a stream data compressed hash index that is exactly the same as the hash query value. If there is a hash conflict, the hash table will use a conflict resolution mechanism such as a linked list method or an open addressing method to handle it, and the search engine will traverse the elements in the bucket for an exact match. Finally, if a flow data compression hash index matching the hash query is found in the set of flow data compression hash indexes, it is determined that flow data actually exists between the source and destination VRFs. If the hash table does not contain an index matching the hash query value, it is determined that flow data does not exist. If the result indicates that flow data exists, it means that unexpected traffic has indeed occurred between the intended isolated VRFs, triggering an abnormal flow alarm.

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

[0054] In particular, 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 probe-to-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 the VPN traffic confirmation leakage event is generated.

[0055] Specifically, step S5 is implemented as follows: first, each risk record in the configuration risk report is traversed. For each record, it extracts the source VRF and target VRF involved. Then, for this pair of VRFs, the corresponding inter-probe connectivity test results are queried. If the query result shows that the inter-probe connectivity test result between the source VRF and the target VRF is reachable, the condition is met. Subsequently, on the basis of meeting the first two conditions, the generated abnormal flow alarm will be further queried 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, the third condition is met. Only when these three conditions are met at the same time, that is, the configuration risk report shows that there is a risk of the RT of the source VRF being imported 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 leak confirmation event will include detailed information such as the source and destination VRF names involved, the specific risk type such as RT import conflict, the timestamp of the confirmed leak, as well as the configuration risk point as evidence, probe test results, and the existence of flow data.

[0056] In step S6, a security alert is generated for the confirmed VPN traffic leakage event. In other words, simply confirming the event is not enough to complete the closed-loop security protection. Generating a security alert is a key step in ensuring that security incidents are promptly detected, responded to, and handled. It transforms complex detection results into intuitive, actionable information, notifying relevant security operations personnel or automated response mechanisms, prompting them to take immediate action, such as isolating the affected VRF, correcting configuration errors, or conducting further investigation. This moves the entire security protection solution from detection to actual intervention and protection, a necessary step to ensure network security and avoid potential losses.

[0057] As an optional implementation, step S6 is performed as follows: First, the alarm generation module receives the VPN traffic leak event confirmed by S5. For each confirmed leak event, the module extracts key information from the event based on a predefined alarm template. An alarm template is a pre-designed text or data structure that specifies the format and fields of the alarm content.

[0058] The module then populates the corresponding fields of the alert template with specific data from the leak event. For example, if the leak event involves traffic leakage between VPN_A and VPN_B, and the risk type is a routing RT import conflict, the alert will clearly indicate this information. Furthermore, the alert level is set based on the severity of the leak event. For example, if the leak involves a critical VRF or a high-risk RT, the alert level can be set to severe or high; a general leak can be set to moderate or general. These alert levels are pre-defined thresholds or rules, linked to factors such as the risk level in the configured risk report and the importance of the affected VRF. The resulting security alert is a structured text message that includes a unique event identifier, a clear alert level, a description of the leak event type, the names of the source and target VRFs involved, details about the specific risk that caused the leak, connectivity test results and actual traffic evidence supporting the determination, and the timestamp of the event confirmation. For example, a security alert might read: [Severe Alert] VPN Traffic Leak Event: Event ID [Unique Identifier], Confirmed Time [Timestamp]. Unauthorized traffic is flowing between source VRF [source VRF name] and destination VRF [destination VRF name]. Risk Details: [Detailed risk description, such as RT import conflict]. Connectivity test results indicate reachability, and actual flow data has been confirmed. We recommend immediately reviewing PE router configurations and removing inappropriate route target import policies.

[0059] Finally, generated security alerts are distributed through a variety of pre-set notification channels. These channels may include, but are not limited to: sending emails to designated security operations teams, sending notifications via SMS or instant messaging tools, pushing alert information to the Security Information and Event Management (SIEM) platform, displaying alert banners on the network management interface, or triggering automated response scripts. Notification channels and recipient lists are pre-configured based on corporate security policies and operations processes. For example, high-risk alerts may trigger email, SMS, and SIEM platform alerts simultaneously, while general alerts may only be notified via email. This ensures that VPN traffic leak confirmation incidents can be promptly and accurately delivered to relevant personnel or systems, thereby initiating subsequent investigations, remediation, and protective measures, completing the entire security protection closed loop.

[0060] In summary, the security protection method for MPLS-VPN routing networks based on the embodiments of the present application is described, which aims to address the problems of insufficient identification of PE router configuration risks, incomplete VPN isolation verification, and lack of multi-source information correlation analysis in the prior art. Specifically, by first obtaining the PE router configuration and performing static compliance analysis, potential configuration risk points are pre-identified, which makes up for the shortcomings of traditional solutions 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 existing solutions cannot effectively verify isolation. At the same time, combined with flow data analysis, it is confirmed whether there is abnormal cross-VPN traffic, which makes up for the limitations of relying solely on configuration or connectivity tests. Finally, by performing multi-source intelligent correlation of configuration risk reports, probe connectivity results, and abnormal flow alarms, VPN traffic leakage events are accurately confirmed, avoiding false positives and missed negatives, thereby achieving more comprehensive and accurate security protection for MPLS-VPN routing networks and effectively solving the technical problems raised in the background technology.

[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. Figure 5 As shown, according to an embodiment of the present application, the security protection system 100 based on the MPLS-VPN routing network includes: a router configuration acquisition module 110, which is used to obtain the router configuration of the PE router; a configuration risk report generation module 120, which is used to perform static configuration compliance analysis on the router configuration of the PE router to obtain a configuration risk report; a probe testing module 130, which is used to, in response to the existence of a configuration risk point in the configuration risk report, schedule the source probe to initiate a test packet to the target probe based on the configuration risk point to obtain a connectivity test result between probes; an abnormal flow alarm module 140, which is used to, in response to the connectivity test result between probes 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; a VPN traffic leakage event confirmation module 150, which is used to perform multi-source information intelligent correlation and leakage event confirmation based on the configuration risk report, the connectivity test result between probes and the abnormal flow alarm to obtain a VPN traffic confirmation leakage event; a security alarm prompt generation module 160, which is used to generate a security alarm prompt for the VPN traffic confirmation leakage event.

[0062] Here, those skilled in the art will appreciate that the specific operations of each step in the above-mentioned security protection system based on the MPLS-VPN routing network have been described in detail above. Figures 1 to 4 The security protection method based on the MPLS-VPN routing network has been described in detail, and therefore, its repeated description will be omitted.

[0063] While various embodiments of the present disclosure have been described above, the above description is intended to be illustrative, not exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

Claims

1. A security protection method based on MPLS-VPN routing network, characterized in that: include: S1: Get the router configuration of the 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 presence of a configuration risk point in the configuration risk report, scheduling the source probe to initiate a test package to the target probe based on the configuration risk point to obtain a connectivity test result between the probes; S4: In response to the inter-probe connectivity test result being reachable, analyzing the flow data obtained from the flow record database to determine whether flow data exists between the source VRF and the target VRF to generate an abnormal flow alarm; S5: Based on the configuration risk report, the inter-probe connectivity test result and the abnormal flow alarm, multi-source information intelligent correlation and leakage event confirmation are performed to obtain a VPN traffic leakage event; S6: Generate a security alert for the VPN traffic confirmed leakage event; Among them, step S3 includes: extracting the expected isolated source VRF and target VRF from the configured risk point; based on the source VRF and the target VRF, determining to schedule the source probe to initiate a test package to the target probe; in response to the target VRF receiving the test package of the source VRF or the source VRF receiving the response of the target VRF, determining that the connectivity test result between the probes is reachable.

2. The MPLS-VPN routing network security protection method 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 an RT policy from the standardized PE configuration object; and inputting the RT policy into a configuration audit engine to obtain the configuration risk report, wherein the configuration audit engine is used to compare the RT policy with a predefined VPN isolation policy baseline.

3. The MPLS-VPN routing network-based security protection method according to claim 2, characterized in that: Step S4 includes: determining a candidate source VRF and a candidate target VRF for each flow data based on the ifIndex of the input interface and the output interface of each flow data; combining the candidate source VRF and the candidate target VRF for each flow data and inputting the resultant into a hash encoder to obtain a set of flow data compressed hash indexes; combining the source VRF and the target VRF and inputting the resultant into the hash encoder to obtain a hash query; and inputting the hash query and the set of flow data compressed hash indexes into a hash search engine to determine whether flow data exists between the source VRF and the target VRF.

4. The MPLS-VPN routing network-based security protection method according to claim 3, characterized in that: The candidate source VRFs and candidate target VRFs of each flow data are combined and input into a hash encoder to obtain a set of flow data compression hash indexes, including: combining the candidate source VRFs and the candidate target VRFs and inputting into the hash encoder to obtain a hash sequence; performing bidirectional shifting on the hash sequence and then aggregating it 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 XOR 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 compression hash index.

5. The MPLS-VPN routing network-based security protection method according to claim 3, characterized in that: The hash query and the set of flow data compression hash indexes are input into a hash search engine to determine whether flow data exists between the source VRF and the target VRF, including: in response to querying that there is a flow data compression hash index consistent with the hash query in the set of flow data compression hash indexes, determining that flow data exists between the source VRF and the target VRF.

6. The MPLS-VPN routing network-based security protection method according to claim 1, characterized in that: 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 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 the VPN traffic confirmation leakage event is generated.

7. A security protection system based on an MPLS-VPN routing network, executing the security protection method based on an MPLS-VPN routing network according to any one of claims 1 to 6, characterized in that: include: Router configuration acquisition module, used to obtain the router configuration of the PE router; a configuration risk report generating module, configured to perform static configuration compliance analysis on the router configuration of the PE router to obtain a configuration risk report; A probe testing module is configured to, in response to a configuration risk point in the configuration risk report, schedule a source probe to initiate a test packet to a target probe based on the configuration risk point to obtain a connectivity test result between the probes; an abnormal flow alarm module, configured to analyze flow data obtained from a flow record database to determine whether flow data exists between a source VRF and a target VRF in response to a connectivity test result between the probes being reachable, so as to generate an abnormal flow alarm; A VPN traffic leakage event confirmation module is configured to perform multi-source information intelligent correlation and leakage event confirmation based on the configuration risk report, the inter-probe connectivity test result, and the abnormal flow alarm to obtain a VPN traffic leakage event confirmation; The security warning prompt generating module is used to generate a security warning prompt for the VPN traffic confirmed leakage event.

Images