MVPN: A Defense Architecture against VPN Traffic Hijacking Based on MTD

Abstract

With the increasing awareness of privacy protection, Virtual Private Networks (VPNs) are widely used to build a more secure communication tunnel. However, a traffic hijacking attack called blind in/on-path has seriously threatened the security of VPNs. Inspired by Moving Target Defense (MTD), Moving VPN architecture (MVPN) is designed to defend against such attacks. MVPN includes multiple nodes to encrypt and decrypt traffic to enhance reliability. Thus, the consistency judgment algorithm is proposed to make MVPN obtain the ability to perceive attacks. Moreover, according to the judgment result and the state update strategy, the MVPN state is dynamically changed so as to achieve the purpose of active defense. In addition, this paper also designs the multichannel packet classification mechanism and availability assurance strategy, which not only ensures the security and availability of the system but also reduces the performance loss caused by the defense strategy. The simulation verifies that MVPN architecture can reduce the success rate of blind in/on-path attacks by five orders of magnitude. In addition, we implemented and deployed MVPN based on the fast-forwarding framework of the Data Plane Development Kit (DPDK). Experiments in the real environment also show that the MVPN system can effectively prevent attackers from carrying out blind in/on-path attacks.

1. Introduction

Since 2020, against the background of the global spread of COVID-19, the frequent application of scenarios such as telecommuting and teleconferencing has led to an increase in the security requirements of communications. Due to the advantages of high security, high flexibility, and low communication cost, Virtual Private Networks (VPNs) have become one of the first choices to ensure the secure transmission of network traffic. VPNs use tunnel encryption and key management technologies to provide secure communication over links.

However, because of the vulnerability of the VPN technology implementation or the malicious behavior of VPN service providers [1], VPN is still plagued by security issues such as DNS leakage, insufficient encryption, and Javascript injection. On the other hand, the 30th USENIX Security Symposium published in 2021 introduces a new protocol-level attack on the VPN called blind in/on-path [2], which is divided into the client-side attack and server-side attack. The server-side attack is much more threatening because it successfully implements DNS hijacking on the VPN server. Combined with the traffic analysis of an encrypted tunnel, the server-side attack injects forged packets into the VPN server and cleverly bypasses the attack barrier caused by the VPN encryption tunnel, which causes the security of the VPN protocol to be questioned.

What is more, some vendors have taken defense measures against the client-side attack recently, such as reverse path filtering or iptables firewall filtering, but no vendors or researchers have yet developed effective defenses against the server-side attack of blind in/on-path attacks. Defending against server-side attacks presents the following challenges. (1) There is no way for the VPN server to distinguish between forged packets and legitimate packets from the actual connection because they will be identical and come in from the same interface. (2) Attackers cannot be prevented from obtaining coarse-grained information through traffic analysis. Although VPN technology makes it hard for attackers to get specific information in encrypted packets, the attacker can obtain coarse-grained information such as packet size and time.

Aiming at solving the defense difficulties of server-side attack of blind in/on-path attacks (the latter term “blind in/on-path attacks” refers to server-side attacks), inspired by the idea of shuffling [3,4,5] and redundancy [6,7] of Moving Target Defense (MTD) [8], in this paper, we propose a Moving VPN architecture (MVPN) that can dynamically change the MVPN state in real-time based on the current attack situation. MTD technology has been proposed by the Federal Department of Network and Information Technology Research and Development (NITRD) over the past several years. The main concept of the system is to improve the complexity and cost for attackers to cope with a large number of uncertainties by making the system dynamic and unpredictable.

The main contributions of this paper are as follows:

We propose an MVPN, a transformational redundancy architecture for protecting VPN servers from blind in/on-path attacks without any modification of existing VPN protocols. The consistency decision algorithm allows the MVPN to detect and filter forged packets injected by attackers in real-time and change the state of the NAT through the NAT state update strategy to increase the attack cost.

The MVPN is implemented and deployed based on the Data Plane Development Kit (DPDK) that consists of libraries to accelerate packet processing workloads running on a wide variety of CPU architectures. Furthermore, the performance loss caused by the defense strategy is reduced by the multichannel packet classification mechanism. Meanwhile, the availability assurance strategy is proposed to ensure the security and availability of the MVPN.

Theoretically, we build the attack and defense model to verify the effectiveness of the MVPN defense. Simulation shows that the MVPN can reduce the success rate of blind in/on-path attacks by five orders of magnitude. The experiments in the real environment show that the MVPN reduces the average number of effectively injected forged packets from 27,049 to 0.515 within the attack time, which effectively prevents attackers from executing blind in/on-path attacks.

The remainder of the paper is organized as follows. Section 2 presents relevant work. Section 3 presents the design of the MPVN architecture and workflow. In Section 4, we introduce the implementation of an MVPN based on DPDK and key technologies. Section 5 is devoted to theoretical analysis and simulation. Section 6 is devoted to testing the defense effect and MVPN performance. Section 7 concludes the paper.

2. Related Work

Previous research has mainly focused on the security of VPN protocols, such as increasing the security of the transmission of keys [9,10] and the rationality of the policy configuration [11,12]. With the continuous development and improvement of VPN technology, VPN has matured and become widely used [13]. However, VPNs also face serious security problems, such as traffic redirection [2], DNS leaks [14], lack of encryption, Javascript injection [15], and TLS interception. In particular, the academic community has given extensive attention to the recently proposed VPN traffic hijacking [2], which guesses the randomly-generated secret values of communication traffic by using the technology of traffic analysis of an encrypted tunnel with spoofed packets. This attack shows that even a properly configured and secured VPN system that has applied all known security patches is still vulnerable.

There are currently three main methods of defending against traffic hijacking. (1) The security design of the protocol. In some transmission protocols, randomly generated secret values are adopted, which not only plays the role of confirming the matching of request responses but also increases the attack difficulty of traffic hijacking. For example, the transaction ID in DNS protocol [16] and the sequence number and acknowledge number in TCP protocol [17] have similar effects. However, the security based on randomly generated secret values is limited, and the attacker can infer the value of the safe field by enumeration or according to the protocol rules. (2) Session-layer encryption between the client and server, such as TLS [18] or DNS over HTTPS/TLS [19,20,21]. Although session-layer encryption can greatly increase the attack costs of traffic hijacking, there are still some problems. The session layer cannot hide the metadata of the connection, and the attacker can use the metadata, such as the time [22] and the load size [23], to obtain the required attack information. Thus, technologies such as VPNs are often used to add another layer of security and privacy to protect against traffic hijacking. (3) Safety policy based on MTD. The goal of the MTD is to use dynamic and uncertainty strategies to confuse the attackers, which will make it hard for attackers to identify the target, such as IP Shuffling [5,24,25], Port Hopping [26], Packet Header Randomization [4], etc. These measures increase the cost of attack or scanning and prevent the attacker from obtaining useful intelligence [27,28].

However, blind in/on-path attackers use the NAT rules of the VPN server to guess the randomly generated secret values in the packet by injecting forged packets into the encrypted tunnel to achieve the purpose of hijacking traffic. In this way, the blind in/on-path attackers can not only get the value of the secret security field but also bypass the protection of the VPN encryption tunnels. Unfortunately, the current MTD-based defense strategies, such as IP Shuffling, Port Hopping, and Packet Header Randomization, have little effect against blind in/on-path attacks because the MTD defense policy can only dynamically change the characteristics of the VPN server egress traffic. Once the traffic is forwarded by NAT, the IP address and port information are recorded in the kernel using Connection Track (conntrack, CT). Therefore, whether normal response packets or packets forged by attackers, those that meet conntrack entries will be placed onto the virtual interface by NAT and forwarded to the client through the encrypted tunnel. As a result, the above three types of defense methods cannot effectively defend against blind in/on-path attacks. Moreover, there are no vendors or researchers defending against the new VPN traffic hijacking.

3. Materials and Methods

3.1. MVPN Architecture

In this paper, we design a dynamically transformed VPN service architecture based on the fast-forwarding DPDK framework. The following design requirements need to be met.

(1)

The architecture can defend against blind in/on-path attacks effectively and, depending on the attacker’s action, dynamically changes the state over time, thereby increasing the attacker’s attack difficulty.

(2)

The existing VPN protocol should not be changed. MVPN can offer the same service as traditional VPNs, and it is easy to deploy.

(3)

Transparent to clients. MVPN’s dynamic architecture is transparent to VPN clients, and clients do not need to install redundant plugins or change communication protocols.

(4)

Minimizing the network delay. Due to its dynamic and redundant properties, the MVPN architecture will inevitably cause disruption in the transmission of the network and affect the transmission speed of the network.

(5)

Keep the stability of network transmission. When the state changes dynamically, normal network communication cannot be affected.

Based on the above design requirements, this paper designs the DPDK dynamic VPN architecture, as shown in Figure 1. Unlike the traditional VPN architecture, the MVPN decouples the key negotiation function from the encryption-decryption function and makes the encryption-decryption function redundant. Traffic is forwarded to different nodes for encryption and decryption. Because nodes do not interfere with each other, attackers need to control more than half of the nodes at the same time in order to succeed if they want to send forged packets back to the client through the encryption tunnel. The MVPN does not change the VPN protocol and maintains the original communication protocol and process, so it is transparent to the VPN client. Aiming at the performance problems caused by MVPN, the DPDK multicore forwarding framework is used to realize the separation of forwarding and control to optimize the forwarding mechanism and reduce the performance loss.

The specific functional framework of the MVPN framework is shown in Figure 2. The system is divided into the management layer, control layer, and data layer. It realizes the separation of the data plane and control layer; that is, control packets and data packets are sent to different threads for processing, which effectively improves forwarding efficiency. The specific description of each functional unit is as follows.

(1)

Packet receiving and sending unit. This unit is responsible for receiving and sending packets from the internal and external networks.

(2)

Packets classification unit. This unit is responsible for classifying and forwarding all traffic received by the interfaces bound to the DPDK. According to the transmission direction (inbound or outbound) and the protocol type of the packets, the packet is sent to the matching functional unit.

(3)

Key agreement unit. This unit is responsible for key agreements with VPN clients and transferring the negotiated key to the key synchronization unit without changing the original VPN negotiation protocol and process.

(4)

Key synchronization unit. This unit is responsible for transferring the current key to the encryption-decryption node in the active set. The key can be transmitted based on TLS, SSL, or other encryption protocols to avoid key disclosure.

(5)

Packets distribution unit. This unit is responsible for copying and forwarding encrypted data packets and TCP packets. Taking IPsec protocol as an example, ESP is a major protocol in IPsec, which provides confidentiality and integrity through encryption and verification. The unit distributes the ESP packets to the encryption-decryption nodes in the active for synchronization. Since TCP needs to maintain the connection state, it also needs to distribute it to the nodes for synchronization.

(6)

Packet forwarding unit. This unit is responsible for forwarding UDP packets directly to the encryption-decryption node or the public network according to the transmission direction of the packets.

(7)

Judgment unit. This unit is responsible for judging whether the MVPN system is suffering from blind in/on-path attacks by comparing the encrypted packets sent to the client from the active set. The decision is based on the following assumption: it is difficult for attackers to guess the temporary ports used by different nodes at the same time. Therefore, the same reply from nodes can be considered the correct and safe reply. If an inconsistent reply is found, the judgment unit will send the inconsistent packet information (source IP, source port, etc.) to the NAT status update unit.

(8)

NAT status update unit. This unit judges which encryption-decryption node is being attacked according to the inconsistent information determined by the judgment unit and sends the command to update the NAT status to the suspicious node.

(9)

Encryption-decryption node pool. This unit consists of multiple encryption-decryption nodes. Each node maintains the same VPN protocol. This unit is mainly responsible for decrypting the packets forwarded by the VPN proxy and returning the encrypted packets to the VPN proxy.

(10)

Management layer. The system administrator can change the configuration file of the MVPN to register new VPN users, change the number of DPDK binding cores and the database access password, or perform other management operations.

Eight functional units, such as the packets forwarding unit and management layer, are implemented based on DPDK (Figure 2 in blue). NAT status update unit and Key synchronization unit can be implemented based on various databases. This paper realizes the access of the negotiation key and the update of executor NAT status based on Redis [29]. (Figure 2 in red).

3.2. Workflow

To make the MVPN workflow easy to understand, the message transmission direction (inbound or outbound) is introduced. Take the client processing DNS message through MVPN as an example, and the processing flow is shown in Figure 3 and Figure 4.

The key agreement unit first negotiates the key with the client and synchronizes the negotiated key with the active set of keys. The packet distribution unit then distributes the encrypted message sent by the client back to the active set. In the active set, each node decrypts based on the key and sends the DNS query to the public network via VPN proxy, as shown in Figure 3. When a node receives the DNS reply message from the packet forwarding unit, it encrypts the message and forwards the encrypted packets back to the VPN proxy. At the same time, DNS response packets forged by the blind in/on-path attackers can also reach external interfaces and be sent to nodes. Header information in forged packets cannot be distinguished from normal DNS response packets. Therefore, defense methods such as source address validation cannot be effective.

Finally, the judgment unit compares and judges the encrypted packets generated from the active set and returns the most secure and efficient encrypted packet to the client, as shown in Figure 4. The standard for determining the security of the judgment unit is whether each node generates encrypted packets with the same content. The attacker cannot use forged packets to infer the port value of all nodes in a short time. Therefore, even if forged packets are encrypted by a node and returned to the VPN proxy, the judgment unit will filter encrypted forged packets and generate inconsistent information because packets returned by nodes are inconsistent. According to the inconsistent information generated by the judgment unit, the state update unit will send state update instructions according to that information in order to keep the MVPN in a safe and flexible state.

4. MVPN Key Technology Design

4.1. Multichannel Packet Classification Mechanism

Since the functional requirements of the MVPN will result in some loss in network performance, in this paper, we adopt a multichannel packet mechanism [30] based on multicore to improve data forwarding performance.

DPDK supports thread binding on multicore devices with different cores, which reduces thread scheduling to improve performance. In this paper, based on this function, the control plane data and management plane data are separated, i.e., control packets and data packets are put on different cores to be processed. Figure 5 shows a flowchart of the MVPN optimization design for multicore and multipath. The control information that needs to be stored and maintained, such as the key and node status, is processed on Core1, and the data packets that need to be quickly forwarded are processed on Core2. The system design dynamically adjusts the number of data plane binding cores according to the number of sessions. The system designs a traffic statistics interface in fp_ether_input_one. If the traffic load exceeds the threshold, the number of data plane binding cores can be dynamically adjusted to enhance the data plane processing ability. The threshold is dynamically allocated according to the ratio of the number of sessions in different rings.

4.2. Consistency Judgment Algorithm

The judgment unit is the vital unit of the MVPN for realizing awareness attacks. Through the key synchronization unit, each node obtains the same key for encryption. The judgment unit judges the response encrypted packets sent from each encryption-decryption node in the active set, and its logic flow is shown in Algorithm 1.

Algorithm 1: Consistency judgment algorithm.

Input: encryption packets from different encryption-decryption nodes. Output: consistently encrypt packets or adjudicate inconsistent messages. (1)   function judgment (2)   flag_lookup = lookup_table(packet_label) (3)   if flag_lookup == NOT_EXIST (4)               creat_table(packet_label) (5)               timer_init(packet, timeout_handle) (6)   else (7)               flag_comp = compare(current_packet, old_packet) (8)               if flag_comp == CONSISTENT (9)                       consis_num ++ (10)               else (11)                      unconsis_num ++ (12)               end if (13)   end if (14)   if consis_num > ACTIVE_SET_NUM/2 (15)               send(packet) (16)   else (17)               alarm(packet) (18)   end if (19)   end function

In the normal case, when reply packets from the same DNS request arrive at different nodes for encryption, the content of the response encrypted payload should be the same, and the consistent response will be returned to the client through the judgment unit. On the other hand, when an attacker tries to perform blind in/on-path attacks on DNS reply packets, since the forged packets cannot reach all of the encryption-decryption nodes across NAT at the same time, they will be discarded by the judgment. The attacker cannot sniff the encrypted packets corresponding to the injection response in the tunnel. Thus, in the MVPN system, it is not feasible for attackers to guess the value by injecting packets with different payload sizes during the sniff phase of the temporary port.

4.3. NAT Status Update Strategy

Blind in/on-path attacks rely primarily on most VPN servers to perform the network address translation (NAT) operation. VPN specifications are clearly defined in RFC 2663, in which NATs are specified based on five tuples (protocol, source address, destination address, source port, and destination port). Most VPNs run NATs at tunnel endpoints to provide secure transportation over external network domains. Once the decrypted request message has been passed to the public network through NAT, the corresponding conntrack entries are left in the kernel. Therefore, if the response message field matches them, the reply packets will be NATed to the encrypted VPN tunnel. If the packets do not match, the architecture will throw them away even if there is a VPN implementation that does not use NATs, such as Outline13 using the SOCKS proxy. In essence, it also follows the same principle as NAT: packets with correct fields will be forwarded through the tunnel, whereas packets with incorrect fields will not be forwarded. Attackers in encrypted tunnels use this principle to inject forged packets into VPN servers to infer correct packet security fields.

For this reason, to prevent attackers from using the principles above to implement blind in/on-path attacks, NAT states must be changed dynamically, such as removing conntrack entries that can be used by attackers or modifying NAT rules. The traditional VPN architecture, however, cannot provide an efficient standard for when NATs are dynamic. Since forged messages and legal messages arrive at the same port and are indistinguishable in the header information of the message. The architecture of the MVPN obtains the ability to identify forged packets via the consistency judgment algorithm.

In the case of blind in/on-path attacks, two methods can be used to update the state to increase the confusion for the attacker.

(1)

Temporal triggering. Under the no abnormal judgment condition, the NAT state is changed regularly to increase the dynamics of the MVPN system. For example, the MVPN can periodically modify the target DNS server through DNAT to confuse attackers.

(2)

Event triggering. In the event of an anomalous judgment, the NAT state update unit confirms the anomalous node according to the anomalous information. Meanwhile, this unit sends the command to the node to update the NAT state. Depending on the command, the node removes the conntrack entries that may be exploited by attackers and set a new DNS request address by default.

4.4. Availability Assurance Strategy

However, some abnormalities are not brought about by the attacker, and changes in the state of the system can also lead to abnormalities. For instance, when the encryption-decryption function of a node in the active set is anomalous and encrypted packets cannot be sent to the VPN proxy, it is possible that the judgment unit erroneously thinks that the exception is caused by other normal nodes. This can cause the system to fail to send encrypted messages to the client in the normal way or cause additional delays. In order to avoid the additional delay and misjudgment caused by the change in the state of encryption-decryption nodes, we have designed the following mechanism.

(1)

Only when the encryption-decryption functions are normal can the node return the encrypted packets to the judgment unit. Therefore, the judgment unit maintains the status information of the nodes by counting the encrypted packets sent by the node. When the cumulative encrypted packet responses returned by a node exceed the threshold value, the node is considered normal.

(2)

The node in a normal state participates in the judgment. The nodes identified as normal by the judgment unit participate in the decision, while the nodes identified as abnormal do not participate in the decision, but they are still counted. For example, for the two new nodes added at the time, since the accumulated encrypted messages of the two new nodes have not exceeded the threshold, the status is not normal, and the returned responses do not participate in the judgment. That is, the judgment unit still uses the responses returned by the three nodes in normal status to determine the request in time. When the encrypted packet count of the newly added node exceeds the threshold value, it is set as the normal state at the time, and then all five normal nodes participate in the judgment, as shown in Figure 6.

(3)

Nodes judged as abnormal are removed from the active set. At the time, the judgment unit determines the abnormal node, sets the node status information as abnormal, and resets the counter. At the same time, the response returned by this node will not participate in the next decision until the node count reaches the threshold again.

With this mechanism, the decision is made when each node’s encryption-decryption functions are normal and when changing the state of nodes would not cause additional delays and errors in judgment.

5. Theoretical Analysis and Simulation

This section conducts a theoretical analysis of the success rate of blind in/on-path attacks under the traditional VPN architecture and MVPN architecture and verifies the effectiveness of MVPN architecture defense through simulation. The required variables are shown in

Table 1. Variable name and its meaning.

Variable Name	Variable Meaning
$P$	The probability that an attacker can “guess” a single forged message
$TO$	DNS timeout
$NoA$	The number of forged packets sent by attackers within the timeout period
$NoS$	Number of forged packets sent by attackers per second
$NoTX$	Value range of TXID
$NoP$	Value range of port
$nos$	Number of nodes in the active set

.

5.1. Theoretical Analysis

The attack premise of blind in/on-path attacks on the server side is that the attacker has analyzed whether the encrypted VPN packet is a DNS query for a domain name that the attacker is searching for by traffic analysis and other means. Moreover, to avoid competing with the correct answer, the attacker performs a denial-of-service attack on the DNS server using the IP address, causing it to cease responding to the VPN server. As a result, the attacker only needs to deliver the valid forged packets to the client before the DNS response timeout in order to attack successfully. The number of packets an attacker can forge in the timeout period is as follows:

$$NoA=NoS\times TO$$

(1)

Attackers implement blind in/on-path attacks mainly in two phases:

Phase 1: The attacker sends forged packets of different port numbers for DNS query requests of the same domain name. The forged packets with the correct temporary port will be sent to the encrypted tunnel by NAT. The attacker in the encrypted tunnel can determine the port value according to the size of the forged message.

Phase 2: After confirming the port, the attacker sends forged DNS response packets with error response information and different TXIDs. If the forged packet with the correct TXID arrives at the client within the DNS timeout, the attack is successful.

Attackers send forged packets of different port numbers or TXIDs for collision with DNS query requests of the same domain name, which meets the conditions of the birthday attack [31]. According to the birthday attack formula, the relationship between the probability $P$ of “guessing” a single message and the probability of attack success $P_{birth\_att}$ is as follows.

$$P_{birth\_att}(k)=1-{\displaystyle {\prod }_{k=1}^{NoA}(1-\frac{P}{1-P\cdot (k-1)})}$$

(2)

In the traditional VPN architecture model, the source port and TXID are random. In this model, the attacker needs to guess the temporary port in phase 1 and the TXID in phase 2. Suppose that the number of packets attempted by the attacker in phase 1 is $H_1$, and the number of packets attempted in phase 2 is $H_2$ then:

$$\begin{array}{l}{P}_{basic}=P(H_1+H_2\le NoA) =P_{birth\_att}(H_1=h_1,P_1)\cdot P_{birth\_att}(H_2=h_2,P_2)\\ =\left[1-{\displaystyle {\prod }_{k=1}^{NoA}(1-\frac{P_1}{1-P_1\cdot (h_1-1)})}\right]\cdot \left[1-{\displaystyle {\prod }_{k=1}^{NoA}(1-\frac{P_2}{1-P_2\cdot (h_2-1)})}\right]\end{array}$$

(3)

wherein $P_1$ and $P_2$ represent the probability that the attacker sends a single message at different phases.

$$P_1=\frac{1}{NoP};P_2=\frac{1}{TXID}$$

(4)

In the MVPN model, to successfully attack, an attacker needs to successfully attack at least $l=(nos+1)/2$ nodes at the same time. Suppose the number of packets attempted by the attacker in phase 1 is $H_1$, and the number of packets attempted in phase 2 is $H_2$, then:

$$\begin{array}{l}{P}_{basic}=P(H_1+H_2\le NoA) =P_{birth\_att}(H_1=h_1,P_3)\cdot P_{birth\_att}(H_2=h_2,P_4)\\ =\left[1-{\displaystyle {\prod }_{k=1}^{NoA}(1-\frac{P_3}{1-P_3\cdot (h_1-1)})}\right]\cdot \left[1-{\displaystyle {\prod }_{k=1}^{NoA}(1-\frac{P_4}{1-P_4\cdot (h_2-1)})}\right]\end{array}$$

(5)

where $P_3$ and $P_4$ are:

$$P_3=\frac{1}{No{P}^l};P_4=\frac{1}{TXID}$$

(6)

5.2. Simulation

5.2.1. Verification of Model Authenticity

First, we verified the authenticity of the theoretical model according to the known attack parameters in the blind in/on-path attack in the literature [2]. Parameter values are shown in

Table 2. Variable values in the simulation experiment.

Variable Name	Variable Value
$NoP$	64,000
$NoTX$	65,535
$nos$	3
$TO1$	5
$TO2$	10
$TO3$	15

.

Based on the traditional VPN architecture model, we calculated the change of attack success rate with the number of forged packets per unit time of attackers under different timeout periods, as shown in Figure 7. The attack success rate $P_{success}$ is obtained through $testnum$ repeated experiments:

$$P_{success}=\frac{succnum}{testnum}$$

(7)

$succnum$ represents the number of successful attacks in $testnum$ repeated experiments. Just as in the original experiment, the number of repeated experiments $testnum$ is 1000.

When the number of forged packets per unit time is 5900, the error reaches the minimum. The comparison between the simulation results and the original experimental results is shown in

Table 3. Comparison between simulation results and experimental results.

Timeout	Experimental Result [2]	Simulation Result
5	75.3%	79.6%
10	48.1%	43.7%
15	11.6%	10.8%

. The results show that the simulation can calculate the attack success rate of attackers in the real experimental environment.

5.2.2. Attack Success Rate under MVPN Model

On the premise of the same experimental setup, we conducted simulation experiments on the MVPN model. The number of repeated experiments $testnum$ is 10⁷.

The number of encryption-decryption nodes is three, which is the simplest case of MVPN and the lower security limit provided by the model. The relationship between attack success rate and the number of messages sent by attackers per second is shown in Figure 8. The simulation results show that compared with the traditional VPN model, the attack success rate of MVPN decreases by five orders of magnitude. This greatly increases the attack difficulty of the blind in/on-path attackers.

5.2.3. Attack Success Rate under White Box Condition

To further explore the impact of the MVPN model on the success rate of the blind in/on-path attacks, we give attackers higher permission. Assumptions are as follows:

(1)

The attacker knows which nodes selected by the VPN proxy are active sets and hijacks the nodes in the active set.

(2)

When the attack on a node succeeds, the attacker can instantly perceive and immediately turn to the next node.

The above assumption is based on the fact that the attacker knows the internal structure of the MVPN and can sniff inside the MVPN. In reality, attackers do not know the internal structure of the MVPN and the selection of the active set, so the above assumption is the upper limit of attack success probability. Under the condition that the number of forged messages per unit time is 5900, we calculated the attack success rate when taken as 3, 5, and 7, respectively. The results are shown in Figure 9.

The experimental data show that under the white box condition, even if the attacker has the simplest MVPN structure and the timeout is 15 s, the attack success rate is only 15.2%, far lower than the original 75.3%. They further show that MVPN can effectively defend against blind in/on-path attacks. Furthermore, as the value increases, the attack difficulty also increases.

6. Experiments and Evaluation in the Real Environment

6.1. Experimental Environment Settings

We set up an experimental environment on the virtual machine and used Ubuntu 18.04 on all of the machines in our experiments. The network topology is shown in Figure 10. The attacker is located in route 1 of the encrypted tunnel and uses the sniffer library libtins to create and spoof packets. MVPN includes a VPN proxy and three encryption-decryption nodes. We conducted experiments based on IPsec VPN, one of the most popular VPN technologies. To form a control experiment, we built an original IPsec VPN in the same network segment of the VPN proxy.

Our experiments include:

• Whether the MVPN defense against the blind in/on-path attacks is effective;
• Whether the MVPN system can reduce the success rate of blind in/on-path DNS hijacking attacks to a certain extent in the real environment;
• Evaluate the active defense capability of the MVPN system;
• Test delay and performance of the MVPN system.

Experiment I is part of other experiments, so no separate experiment was conducted. The effectiveness of MVPN defense can be seen in other experiments.

6.2. Attack and Defense Test (Experiment II)

We have created a virtual experimental environment composed of virtual machines that simulate VPN servers, DNS servers, and VPN clients. Three routes form the “Internet,” and a VPN server, a DNS server, and a VPN client connect to each of them, respectively.

In the original attack experiment [2], three standards were set based on the DNS response time of different systems: 5 s, 10 s, and 15 s. A total of 1000 attack experiments were performed for all three standards. On each trial, the VPN client used nslookup to issue a single, specified request. Half a second later, the attacker started the injection script in an attempt to infer and inject a malicious DNS response.

In the second phase of the blind in/on-path attacks, the correct temporary port detected in the first phase was used as the basis for the attack. To determine the temporary DNS query port as quickly as possible, in this case, the attacker mapped the forged DNS reply payload with the port and split the port space into 1000 unit blocks (such as 30,000–31,000 31,000–32,000, …). When scanning each port block, the load increased with the number of ports and was reset to 0 when the next port block was made. In this way, different loads corresponded to different ports within the same block of ports. Because VPN cannot hide features of granularity as coarse as the size of the payload, attackers located in encrypted tunnels could confirm the range of temporary ports by sniffing the payload of encrypted messages. For instance, if an attacker observed an encrypted packet of size 600, the last three digits of the port could be determined by the attacker to be 600 digits and then confirm which block was triggered by the same principle to finally confirm the accurate temporary port.

To illustrate the effectiveness of the MVPN defense, we tested the attacks against IPsec VPN and MPVN under the same attack conditions. We also conducted 1000 attack experiments under three standards, and the experimental results are shown in

Table 4. Comparison of the success rate of IPsec VPN and MVPN attacks.

Timeout	IPsec VPN	MVPN
5	77.6%	0
10	50.2%	0
15	9.5%	0

.

6.3. Active Defense Capability Assessment (Experiment III)

From the user’s point of view, we evaluated the active defense capability of MVPN. The blind in/on-path attacks used NAT rules to forward forged packets to encrypted tunnels, and the forged packet was transmitted to the client through encrypted tunnels. As a result, the number of passing forged packets through encrypted tunnels was an important standard of ability for blind in/on-path attackers, which is also a standard for evaluating a defender’s defensive capabilities. The more forged packets the client received, the stronger the attacker’s ability to attack and, on the contrary, the weaker the defender’s ability to defend.

We conducted tests on OpenVPN, IPsec VPN, and MVPN and counted the number of forged packets received by the client at different timeout times over 1000 experiments. The results are shown in Figure 11.

Experimental data show that the average number of forged packets received by the OpenVPN client and IPsec VPN client per attack, respectively, was 27,029 and 27,049 when the timeout duration was 15 s. However, the MVPN client received only 0.515 on average. The MVPN reduced the number of forged packets passing through the tunnel to less than one in each attack. This is why MVPN could reduce the attack success rate to zero under the same experimental conditions.

6.4. Performance Testing (Experiment IV)

Performance testing was conducted to evaluate the performance of the system in the real network environment. In this paper, the experimental environment was set up as shown in Figure 12. The experimental environment included seven physical hosts and servers, four switches, and a router. The VPN proxy consisted of a Centos 7 system server and a heterogeneous board. The heterogeneous board integrated multiple houseware architectures (X86 and arm) and installed different operating systems (ubuntu 18.04 and centos 7). The two clients were composed of Ubuntu 18.04 and Win7.

6.4.1. Delay and Throughput

We compared the DNS query latency and throughput of the following three modes: (1) The query latency of MVPNs in the active set is 3, which represents the simplest MVPN architecture. Previous experiments showed that when the number of active sets was only 3, it could effectively defend against the blind in/on-path attacks; (2) Query delay and throughput when connecting to a normal IPsec VPN; (3) Not connected to any VPN. We counted the query delay and throughput of the above three cases on the clients of two different operating systems. In this paper, we used the Jmeter network performance testing tool to conduct experiments. The results are shown in Figure 13 and Figure 14.

The client queried the real DNS server 223.6.6.6 for the domain name www.baidu.com, statistics of 1000 query delays, and the experimental results are shown in Figure 13. It can be seen that there was a spike in the first MVPN query. This is because when the first packet passed through the system, it needed to establish a flow table. Therefore, when the first packet passed through the system, there would be a high delay, and then the system delay would tend to be stable. The average delay in the three cases was: (1) no VPN: 22.09 ms; (2) IPSec: 22.51 ms; (3) MVPN: 22.65 ms. Compared with the first two cases, the query latency of the MVPN increased by 2.5% and 0.6%, respectively.

Next, the client tested the throughput of the three cases under the same conditions by accessing the Internet. The results are shown in Figure 14. The experimental results show that the throughput of MVPN decreased by 31.2% and 34.7%, respectively, compared with the first two cases.

6.4.2. System Stability Assessment

This paper evaluated the stability of the system by verifying the time and integrity of file transmission between the client and the VPN server using the FTP file transfer tool FileZilla on the client to access the FTP server through the MVPN. The client transmitted files of different sizes to the FTP server (that is, the file sizes were 10 Mb, 30 Mb, 100 Mb, 300 Mb, 400 Mb, 500 Mb, 600 Mb, and 1024 Mb). The results are shown in Figure 15. It can be seen that the MVPN was similar to the other two cases when transmitting small files, but the transmission time of the MVPN became longer when transmitting large files.

Finally, the file transmitted by the client was compared with the file received by the FTP server. The consistency of the file effectively illustrated the stability of the MVPN system.

7. Conclusions

For defending a new protocol-level attack on the VPN called blind in/on-path, we propose and implement an MVPN architecture based on DPDK, which contains multiple encryption and decryption nodes to process traffic in parallel. The MVPN obtains the ability to perceive the attack status through the consistency judgment algorithm and dynamically changes the NAT status of the node through the judgment result and NAT status update strategy, thus increasing the difficulty of the attack. In addition, to reduce the performance loss caused by the defense strategy, we designed the multichannel packet classification mechanism and the availability assurance strategy. The experimental results show that MVPN can greatly reduce the effectively forged packets injected into the encrypted tunnel by the attacker within the attack time and reduce the attack success rate to zero under the same experimental conditions as the original attack experiment.

However, the MVPN system still has the following problems: (1) Traffic distribution will cause great forwarding pressure to the network adapter, resulting in throughput decline; (2) If the same DNS request is sent to the DNS server multiple times, the performance of the DNS server may be compromised. For future work, we plan to: (1) Optimize the distribution logic and relieve the forwarding pressure of the network adapter through traffic splitting [32]; (2) Set different DNS configurations so that different nodes send the same request to different DNS servers for a query, to relieve the pressure of querying to the same DNS server.