A Tor network attack and defense experimental platform based on multi-granularity simulation

Abstract

The present invention provides a Tor network attack and defense experimental platform based on multi-granularity simulation, which is to mirror the Tor node to a Docker container, and according to the network topology information uploaded by the user, use the container node of the Docker container mirror and the Tor node to form a simulated private Tor network, the simulated private Tor network can effectively generate background nodes that conform to the real network distribution, and then use the Master node to realize the construction of the simulated private Tor network cluster, and realize the maximum resource utilization of the simulated private Tor network cluster through the cluster scheduling strategy algorithm. The Tor network environment built by the present invention has the participation of real Tor applications, the traffic generated in the Tor link is the traffic of the real Tor protocol, and the traffic in the network can be captured, which is convenient to support the tracing attack and defense experiments.

Description

Technical Field

[0001] The invention relates to a Tor network platform in the technical field of cyberspace security, and in particular to a Tor network attack and defense experimental platform based on multi-granularity simulation. Background Art

[0002] In recent years, as people's demand for personal privacy protection increases, anonymous technology has gradually entered people's production and life, and played an increasingly important role. People are increasingly using anonymous networks to protect the privacy of personal communications. At the same time, the improvement of Internet connectivity has also led to the emergence of a large number of dangers such as online fraud, information leakage, and penetration attacks. While criminals are increasing their own aggressiveness, in order to evade scrutiny and pursuit, they often rely on online anonymous technology to enhance the anonymity of their identities. Malicious behavior relying on anonymous technology will pose a great threat to network security.

[0003] Tor is currently the world's largest anonymous network, consisting of thousands of volunteer nodes from all over the world and with a huge user base. Researchers have conducted many studies on anonymous network technology in the past. In order to test attacks against the Tor network, evaluate the impact of Tor software changes on the entire anonymous network, or analyze statistics on the Tor network, researchers inevitably need to conduct a large number of experiments on the Tor network. Although it is not difficult to join an anonymous network in the real world, there are still many problems in conducting experimental research in a real anonymous network (such as the Tor network).

[0004] (1) The real Tor network cannot be used to study modified versions of Tor software, because such experiments must ensure that most nodes in the Tor network have undergone version modification in order to examine the impact of such changes on the entire network. Deploying a large number of nodes on Tor is not only costly, but will also be subject to official Tor scrutiny, because a single organization or institution controlling a large number of Tor network nodes will cause great damage to the anonymity of the entire system.

[0005] (2) Conducting experiments on a real Tor network may affect Tor's performance and functionality. A node joining the Tor network has corresponding responsibilities (such as routing traffic, etc.), but some human intervention seems to be necessary for researchers (because the purpose of most experimental research is to crack the Tor anonymous network), which will undoubtedly have a negative impact on Tor's performance. At the same time, measuring sensitive data in the Tor network may also damage the anonymity of Tor users, especially when researchers publish the collected data.

[0006] (3) When conducting experiments such as tracking and tracing, the nodes in the real Tor network are widely distributed, which leads to low efficiency in traffic data collection by experimenters. It is difficult to observe the communication traffic of the entry and exit nodes of Tor users at the same time, and it is not easy to participate in the complete anonymous communication process of others.

[0007] In order to conduct experimental research on anonymity technology more conveniently, researchers often choose to deploy experiments in a simulated private anonymous network environment. This experimental method in a simulated environment rather than a real environment will not affect other users of the anonymous network in the real world. At the same time, the autonomous and controllable simulation environment also greatly improves the flexibility of the experiment.

[0008] Compared with experiments in the real Tor network environment, experiments in a simulated environment will not only not affect the real Tor network, but also improve the efficiency of the experiment. Domestic and foreign researchers have already achieved a lot of research results in this field. Their methods of simulating the Tor network environment are generally divided into the following three categories: one is to simulate the anonymous communication process based on a general discrete event simulator; the second is the Tor anonymous network simulation based on software; the third is the Tor anonymous network simulation based on hardware.

[0009] 1. Simulating the communication process of anonymous communication This type of method can simulate discrete anonymous communication events, but there is no participation of the Tor application in the simulation process, and the Tor anonymous communication protocol is not used to generate traffic. Therefore, the Tor anonymous communication scenarios that can be simulated by this type of method are very limited, and it is impossible to fully study the vulnerabilities of the Tor anonymous communication protocol through this type of tool. Moreover, the tools used by this type of method are mostly general network simulators, which are not specially designed for Tor and are often only used in the preliminary research stage.

[0010] Second, in the Tor anonymous network simulation method based on dedicated simulation software, researchers have designed a series of experimental tools dedicated to the Tor network, such as Shadow, ExperimentTor, SNEAC, etc. In addition, they have also proposed the Tor Path Simulator (TorPS) for path security analysis, etc. These simulation tools can restore the topology of the Tor anonymous network and simulate a large number of Tor nodes for experiments. However, they all use memory reading and writing to replace actual traffic transmission. At the same time, this type of discrete event network simulator does not have the ability to adapt to highly dynamic environments. Its experimental purpose is often to test the performance of the Tor network, and it does not provide enough support for Tor network security experiments such as tracking and tracing the control nodes.

[0011] 3. Hardware-based private Tor network simulation methods generally use high-performance network server clusters (such as PlanetLab, DeterLab, Emulab, etc.) to run virtual machine clusters. In addition, in 2020, Wang et al. proposed a new method to build a real Tor private network by controlling Raspberry Pi. This work used Raspberry Pi to build a private Tor network with a scale of 20 nodes and conducted related experiments. Compared with other similar platforms, this platform has the advantages of low cost, easy expansion, high quality of real-time data transmission, high degree of network protocol recovery, and convenient configuration. Using high-performance servers to build virtual machine clusters to simulate the Tor network, the manual investment in maintaining server memory allocation and server management is huge, and most of these platforms are not open and require researchers to apply; while using small hardware devices such as Raspberry Pi to simulate private Tor networks, although the cost is lower than previous methods, it is still a considerable expense when the number of simulation nodes is large.

[0012] In summary, the existing Tor network simulation methods are mainly divided into the following three categories: the first category uses a general network simulator to simulate the anonymous communication process. This type of method does not run the real Tor program during the experiment and is generally only used in the early stages of research; the second category is a software-based Tor network simulation method, which generally relies on software tools designed by researchers specifically for Tor experiments, such as Shadow. Its main advantage is that it can simulate a fairly large-scale Tor network. The disadvantage is that this type of tool often uses memory reading and writing to replace actual traffic transmission and cannot operate nodes during the experiment; the third category is a hardware-based Tor network simulation method. This type of method generally uses a hardware device cluster (such as a virtual machine cluster) to build a private Tor network. The experimental environment is relatively real, but at the same time, its simulation cost is also very high. See Table 1-1 below for a specific comparison:

[0013]

[0014] The above methods still face various problems when supporting Tor network attack and defense experiments. The following uses Tor's backtracking attack experiment as an example to analyze the pros and cons of various methods (including methods tested on a real Tor network):

[0015] (1) In the real Tor network, nodes are widely distributed, and it is difficult for experimenters to simultaneously observe the communication traffic of Tor users' entry nodes and exit nodes. The experimenters' Tor node traffic data collection efficiency is low, and the overall experimental efficiency is low.

[0016] (2) Since the Tor application is not involved in the discrete event simulation method, it is impossible to conduct backtracking attack experiments.

[0017] (3) For the software-based Tor network simulation method, since it uses memory reading and writing instead of traffic transmission and cannot operate the nodes in real time, it cannot capture the real Tor network protocol traffic, so this experiment cannot be carried out.

[0018] (4) The hardware-based Tor network simulation method will build a private Tor network environment, which is a "mini version" of the real Tor network. Since all nodes are controllable by the experimenter and are real hardware devices, the experimenter can capture the desired communication traffic data on all nodes and conduct source tracing attack experiments against the Tor network.

[0019] It can be seen that the method of simulating the communication process of anonymous communication based on a general network simulator has very limited scenarios that can be simulated because there is no actual Tor application involved, and is generally only used in the preliminary research stage. The software-based Tor network simulation method proposes a series of experimental tools dedicated to Tor research. These tools can restore the topology of the real network and simulate large-scale network nodes, but they all use memory reading and writing to replace actual traffic transmission and cannot operate specific Tor network nodes in real time during the simulation. The authenticity of the simulation is significantly different from that of experiments conducted in the real Tor network. The hardware-based Tor network simulation method is the closest to the real experimental environment in terms of simulation authenticity, but whether it is using a virtual machine cluster or a small hardware device such as Raspberry Pi to simulate a private Tor network, there is a problem of excessive experimental cost during large-scale simulation. Therefore, the existing methods have problems such as excessive cost when simulating the Tor network, insufficient simulation authenticity, and insufficient support for Tor network attack experiments (such as tracing experiments). Summary of the invention

[0020] The invention provides a Tor network attack and defense experimental platform based on multi-granularity simulation, which is used to solve the problems of excessive cost and insufficient simulation authenticity when simulating the Tor network in existing research, and solves the problem of effectively balancing the authenticity and simulation cost of the Tor network attack and defense experimental environment.

[0021] A Tor network attack and defense experimental platform based on multi-granularity simulation is proposed. The Tor nodes are mirrored to Docker containers, and the nodes are divided into three categories: controlled nodes, background nodes, and auxiliary nodes. According to the network topology information uploaded by the user, the container nodes of the Docker container mirror and the Tor nodes are used to form a simulated private Tor network. The three types of nodes are used to form a simulated private Tor network, including the following steps:

[0022] S1: Calculate the number of auxiliary nodes for each role to be deployed based on the configuration requirements of the network topology configuration of the background nodes;

[0023] S2: Start the Docker container images of the controlled node and the auxiliary node, and let the container nodes in the Docker container image first build a simulated private Tor network;

[0024] S3: According to the configuration requirements of the network topology configuration of the background node, add the information of the background node to the consensus file generated after networking.

[0025] The controlled node is a container node running a Docker container image, and is the node with the strongest simulation authenticity; the background node has no real running entity, and only exists in the consensus file of the simulated private Tor network; the auxiliary node is formed when the Tor client selects the route based on the information of the routing node in the consensus file of the private Tor network. When the background node is selected to participate in building a link, the background node is replaced, and multiple background nodes correspond to one auxiliary node.

[0026] Furthermore, in step S1, the information of the network topology configuration includes the scale of background nodes of each role in the private Tor network to be simulated and the value of the proportional parameter p. The scale of background nodes of each role includes the number of authoritative directory server nodes, the number of exit nodes, and the number of ordinary routing nodes.

[0027] Furthermore, in step S2, the roles of Tor nodes in the network are divided into authoritative directory server nodes DA, ordinary routing nodes Relay, exit nodes Exit, and ordinary bridge nodes Bridge. They all run Tor applications, but the torrc configuration at startup is different. Both controlled nodes and auxiliary nodes need to build Tor node container images of multiple roles.

[0028] In step S2, when deploying the simulated private Tor network experimental environment, it is necessary to run the authoritative directory server DA node first. After the successful operation of this type of node, the generated IP and fingerprint information will be written into a public file that can be read by other types of nodes. When other types of nodes are started, they will first read the information in the public file and add it to their own torrc file, and then start running the Tor program normally. After running, they will upload the descriptor of this node to the authoritative directory server DA node in the configuration, thereby joining the simulated private Tor network.

[0029] Furthermore, in step S3, the background node information is added according to the background nodes of the real network distribution. To effectively generate the background nodes that conform to the real network distribution, the following steps are included:

[0030] S31: First, collect Tor user data, pre-process the data based on the official Tor data, and obtain the Tor user ratio in different regions;

[0031] S32: Generate background nodes through topology configuration, where the information in the topology configuration includes the scale of the background nodes of each role in the simulated network and the value of the proportional parameter p;

[0032] S33: Generate a hybrid consensus file. The hybrid consensus file is a newly generated file after adding the background node information to the real consensus file. The subsequent route selection will be based on this file.

[0033] Furthermore, in step S33, if none of the selected three-hop nodes are background nodes, a link is directly constructed and a log is recorded; if the selected three-hop nodes are all background nodes, since there is no traffic communication relationship with the controlled node, no specific link is constructed, but only recorded in the log file; if the selected three-hop nodes include both background nodes and controlled nodes, the background node is replaced with an auxiliary node, the link is constructed through the auxiliary node, and a log is recorded.

[0034] For the background nodes generated by the simulated private Tor network, their IPs should not conflict with the node IPs in the original real consensus file. The first eight digits of the background node's IP address are designed to be x, and the network segment address is expressed as x.0.0.1 / 16 to distinguish it from the node IP in the original file. The bandwidth mean M of the routing node in the original file is calculated. Since it is necessary to simulate the randomly fluctuating bandwidth values ​​of different nodes, the random values ​​in the interval (0,2*M) can be generated through Python's Random library as the bandwidth of each background node.

[0035] Furthermore, in step S2, the image creation of the Docker container is performed by writing a Dockerfile file, including the following steps:

[0036] S41: The selected base image is debian:buster;

[0037] S42: Set some environment variables in the Docker container through the ENV command, including the port where Tor is running;

[0038] S43: Use the RUN command to install the software tools required for the environment, including Python, Curl, and Wget;

[0039] S44: Use the COPY command to copy the Tor application source code on the host machine to the Docker container, and install the Tor program in the Docker container by compiling the source code;

[0040] S45: Expose the possible ports through the EXPOSE instruction and specify the container entry command ENTERPOINT;

[0041] Based on the above image building process, Docker container images of authoritative directory servers, ordinary routing nodes, exit nodes, clients, and ordinary bridge nodes related to multiple Tor nodes are produced respectively.

[0042] The simulated private Tor network cluster established by the Tor network attack and defense experimental platform based on multi-granularity simulation adopts a multi-granularity node deployment scheduling algorithm. Considering the different resource requirements of controlled nodes and auxiliary nodes, the scheduling algorithm is divided into the following two stages:

[0043] In the first stage, nodes with insufficient resources are filtered out, including cluster nodes whose CPU or memory resources no longer meet the requirements for deploying a Tor node. The node set generated in this stage is called the candidate set. If all nodes cannot meet the resource requirements, they will directly exit this round of scheduling.

[0044] In the second stage, based on the candidate node set screened in the first stage, the one with the highest score is selected. The scoring is based on the remaining resources of the cluster node and the balance between the CPU utilization and memory utilization of the cluster node. After selection, the scheduling results of this round are saved in the scheduling result set, and the cluster node resource set K and the cluster node score set are updated in turn.

[0045] The Tor network attack and defense experimental platform based on multi-granularity simulation uses containers as the basic units of Tor network node simulation for controlled nodes in the network to ensure the authenticity required by the experiment; while for other background nodes, it sacrifices some of their authenticity (such as the inability to perform real-time operations during the experiment) to increase the scale of the overall simulated network, designs the orchestration and scheduling mechanism of multi-granularity nodes, and builds the Tor network attack and defense experimental platform based on Docker containers and Kubernetes cluster technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is a schematic diagram of the node architecture of the Tor network attack and defense experimental platform based on multi-granularity simulation;

[0047] Figure 2 It is a deployment diagram of the Tor network attack and defense experimental platform based on multi-granularity simulation;

[0048] Figure 3 It is a schematic diagram of the deployment process of the Tor network attack and defense experimental platform based on multi-granularity simulation;

[0049] Figure 4 It is a flow chart of simulation route selection;

[0050] Figure 5 is a schematic diagram of the Dockerfile file. DETAILED DESCRIPTION

[0051] The Tor network attack and defense experimental platform based on multi-granularity simulation provided by the present invention is to mirror the Tor node to the Docker container, and according to the network topology information uploaded by the user, use the container node of the Docker container image and the Tor node to build a simulated private Tor network. The simulated private Tor network can effectively generate background nodes that conform to the real network distribution, and then use the Master node to realize the construction of the simulated private Tor network cluster, and realize the maximum resource utilization of the simulated private Tor network cluster through the cluster scheduling strategy algorithm.

[0052] like Figure 1 As shown, the Tor network attack and defense experimental platform based on multi-granularity simulation is to mirror the Tor node to the Docker container. The container node of the Docker container image involves three types of nodes, including controlled nodes, background nodes and auxiliary nodes. The controlled node is the container node running the Docker container image. The background node has no real running entity. When it is selected to participate in building a link, it is replaced by an auxiliary node. The auxiliary node is an uncontrollable controlled node.

[0053] Considering that in the actual Tor network experiment, researchers are really concerned about the network nodes they control. For such nodes, they can be regarded as controlled nodes. It is necessary to ensure that the real network traffic packets can be captured and the nodes can be logged in to operate like real hosts. For other nodes, if there is data communication with the nodes controlled by researchers, it is necessary to ensure that the traffic generated by the communication is generated by the real Tor protocol. Based on the above content, the Tor network attack and defense experimental platform based on multi-granularity simulation divides multi-granularity nodes into different types to form three types of nodes. The following is a specific description of the three types of nodes:

[0054] (1) Controlled node: A container node that runs a Docker container image. It is the node with the strongest simulation authenticity. The experimenter can log in to the container node to perform operations in real time and can capture real communication traffic packets on the container node.

[0055] (2) Background node: The background node does not have a real running entity. It only exists in the consensus file of the simulated private Tor network. As mentioned earlier, the content in the consensus file is the information of all Tor network routing nodes. It is only necessary to add the background node information to the consensus file in the format of a normal routing node. The background node needs to rely on auxiliary nodes to work together.

[0056] (3) Auxiliary nodes: Since the Tor client (the client where the Tor node is located) will select the route based on the information of the routing node in the above consensus file, when the background node is selected to participate in the link construction, it is replaced by the auxiliary node to ensure that a real link can be created to generate Tor protocol traffic. The construction method of the auxiliary node is the same as that of the controlled node, except that the auxiliary node is not controlled by the experimenter in design.

[0057] In this design method, multiple background nodes correspond to one auxiliary node, and the parameter p can be set to represent the corresponding ratio. For example, if the p value is 0.1, it means that 10 (1 / p) background nodes correspond to one auxiliary node.

[0058] The following is a description of the three types of nodes through a multi-granularity node comparison table, see Table 1-2 below:

[0059]

[0060] like Figure 2 As shown in the figure, using three types of nodes to build a simulated private Tor network includes the following steps:

[0061] S1: Calculate the number of auxiliary nodes for each role to be deployed based on the configuration requirements of the background nodes;

[0062] S2: Start the Docker container images of the controlled node and the auxiliary node, and let the container nodes in the Docker container image first build a simulated private Tor network;

[0063] S3: According to the configuration requirements of the background nodes, add the background node information to the consensus file generated after networking in the previous step.

[0064] The following is a detailed description of each step:

[0065] In step S1, background nodes are generated by configuring the network topology. The information of the network topology configuration includes the scale of background nodes of each role in the private Tor network to be simulated (such as the number of authoritative directory server nodes, the number of exit nodes, the number of ordinary routing nodes, etc.), and the value of the proportional parameter p. The background nodes do not have actual running entities, so there is no need to design container images for such nodes. For controlled nodes and auxiliary nodes, it is necessary to build images of Tor network nodes.

[0066] In step S2, the Docker container images of the controlled node and the auxiliary node are started, and the container nodes in the Docker container images are allowed to first build a simulated private Tor network;

[0067] There are thousands of nodes on the real Tor network. According to the role of Tor nodes in the network, Tor nodes can be divided into DA (authoritative directory server node), Relay (ordinary routing node), Exit (exit node), Bridge (ordinary bridge node), etc. They all run Tor applications, but the torrc configuration at startup is different.

[0068] The Tor network attack and defense experiment platform based on multi-granularity simulation adopts the design concept of separating node identity from function. Both the controlled node and the auxiliary node need to build Tor node container images of multiple roles. Since the controlled node is designed to be a node that researchers can actually operate, the Tor network attack and defense experiment platform based on multi-granularity simulation adds many tools that may be used in the experiment process, including curl, wget, stem, etc., to the basic Tor node images of various roles. In addition, various customized Docker images related to Tor experiments can be made, which can be deployed in the form of containers when conducting Tor network experiments.

[0069] When deploying a simulated private Tor network experimental environment, you need to run the authoritative directory server (DA) node first. After the successful operation of this type of node, the generated IP, fingerprint and other information will be written into a public file that can be read by other types of nodes; when other types of nodes are started, they will first read the information in the file and add it to their own torrc (configuration file when running the Tor program) file, and then start running the Tor program normally. After running, the descriptor of this node will be uploaded to the authoritative directory server node in the configuration, thereby joining the simulated private Tor network.

[0070] In the entire process of simulating the private Tor network, researchers only need to upload the topology information of the Tor network they want to simulate, which mainly includes the number of DA nodes, the number of ordinary routing nodes, the number of exit nodes, etc. This method can generate a custom simulated private Tor network based on the topology information. The overall deployment process is as follows: Figure 3 shown.

[0071] Figure 3 The overall deployment process includes the following steps:

[0072] S11: Upload the configuration information of the network topology configuration at the ingress;

[0073] S12: After that, the Master node is created and a node join token is generated. Subsequent worker nodes are verified and deployed based on this token information.

[0074] The Master node is the core node in the distributed system responsible for managing and controlling other nodes. In the Kubernetes cluster, the Master node is the control center, responsible for managing all Worker nodes, including processing client requests, maintaining cluster status, scheduling resources, etc. Node join refers to the node that needs to be joined.

[0075] S13: Worker node joins;

[0076] S14: Next, cluster network deployment and container persistent storage deployment are performed;

[0077] S15: Upload network topology information at the ingress;

[0078] S16: After the network topology information is read, a yml file is generated. The yml file is a configuration list for the cluster network to execute the deployment task.

[0079] S17: The authoritative directory server is created;

[0080] S18: Share DA information to a persistent storage server;

[0081] S19: Finally, the routing node creation is completed.

[0082] It can be seen that in the entire Tor network simulation networking process, for users, they only need to upload the topological structure information of the network they want to simulate, which mainly includes the number of DA nodes, the number of ordinary routing nodes, the number of exit nodes, etc.

[0083] In step S3, according to the configuration requirements of the background nodes, the background node information is added to the consensus file generated after the previous step of networking. The addition of the background node information is implemented based on the background nodes of the real network distribution. In order to effectively generate background nodes that conform to the real network distribution, the following steps are included:

[0084] S31: First, count Tor user data. Tor users come from all over the world, and Tor officially records the statistics of users in each region every day. Preprocess the data provided by Tor officially to obtain the Tor user ratio in different regions.

[0085] S32: The next step is how to generate background nodes through topology configuration. The information in the topology configuration mainly includes the scale of background nodes of each role in the simulated network (such as the number of Guard nodes, the number of exit nodes, the number of ordinary routing nodes, etc.) and the value of the proportional parameter p. Take the following topology as an example: 600 ordinary routing nodes, 400 exit nodes, and the parameter p is 0.1. Create 60 ordinary routing node containers and 40 exit nodes through the produced Docker container image and add them to the Tor network simulated in the previous step as auxiliary nodes.

[0086] S33: Then start to generate a hybrid consensus file. The hybrid consensus file is a newly generated file after adding the background node information to the real consensus file. The subsequent route selection will be based on this file.

[0087] For the generated background nodes, it is necessary to ensure that their IPs do not conflict with the node IPs in the original real consensus file. To this end, the first eight digits of the background node IP address are designed to be x, and the network segment address is represented as x.0.0.1 / 16 to distinguish it from the node IP in the original file. Subsequently, the bandwidth mean M of the routing node in the original file is calculated. Since it is necessary to simulate the random fluctuation bandwidth value of different nodes, it is necessary to use Python's Random library to generate random values ​​in the interval (0,2*M) as the bandwidth of each background node.

[0088] Furthermore, when simulating routing, the routing is simulated based on the information in the hybrid consensus file. Since there are background nodes in the file, such as Figure 4 As shown in the figure, the following design is required for the case of path selection (taking the default three-hop link as an example):

[0089] Figure 4 In the simulation, the rules for route selection are as follows: if none of the selected three-hop nodes are background nodes, a link is directly built and a log is recorded; if all the selected three-hop nodes are background nodes, since there is no traffic communication relationship with the controlled node, no specific link is built, and only the link is recorded in the log file; if the selected three-hop nodes include both background nodes and controlled nodes, the background node is replaced with an auxiliary node, the link is built through the auxiliary node, and the log is recorded.

[0090] Furthermore, in step S2, when starting the Docker container images of the controlled node and the auxiliary node, it is necessary to make the image of the Docker container for the Tor node, wherein the image of the Docker container is made by writing a Dockerfile file.

[0091] There are thousands of nodes in the real Tor network. According to the role of the node in the network, the nodes can be divided into DA (authoritative directory server node), Relay (ordinary routing node), Exit (exit node), Bridge (ordinary bridge node), etc. They all run Tor applications, but the torrc configuration at startup is different. There are generally two ways to make a Docker container image for a Tor node. The first is to build a new image based on an existing container through the docker commit command; the second is to write a fixed-format Dockerfile file and generate a custom container image through the docker build command. This article adopts the method of writing a Dockerfile file, which has many advantages.

[0092] A typical Dockerfile for Tor network simulation is as follows: Figure 5 As shown:

[0093] S41: The selected base image is debian:buster, which is a stable debian 10 version container image.

[0094] S42: Then use the ENV command to set some environment variables in the container, mainly some ports when Tor is running.

[0095] S43: Then use the RUN command to install some software required for the environment. Considering that the environment where the container runs may not be able to connect to the external network, some software tools commonly used in many experiments are installed in this step, including Python, Curl, Wget, etc.

[0096] S44: Afterwards, the Tor application source code on the host is copied to the container through the COPY command, and the Tor program is installed in the container by compiling the source code.

[0097] S45: Finally, the possible ports are exposed through the EXPOSE instruction and the entry command ENTERPOINT of the container is specified.

[0098] In the startup script specified by ENTRYPOINT, the difference between different role node images mainly lies in the different torrc files for running Tor. For example, the exit node needs to add the ExitRelay 1 configuration item to the basic torrc file. Another difference is that after startup, the DA node needs to write its own information to a file that can be accessed by other types of nodes, while other nodes need to read the file at startup and add the file content to their own torrc files.

[0099] Based on the above image building process, the Tor network attack and defense experimental platform based on multi-granularity simulation has produced multiple Tor node-related Docker container images such as tor_da (authoritative directory server), tor_relay (ordinary routing node), tor_exit (exit node), tor_client (client), and tor_bridge (ordinary bridge node).

[0100] Considering that storing all images locally on the machines will cause a waste of disk resources, the Tor network attack and defense experimental platform based on multi-granularity simulation has built a private image warehouse torhub, and uploaded all images needed for the experiment to the warehouse. Each worker node in the k8s cluster can pull the image to the local after the container is assigned to the node, which can save some disk resources.

[0101] Furthermore, in step S14, a simulated private Tor network cluster is built:

[0102] When the simulation scale is large (thousands of machines), a single machine often cannot meet the demand and does not have the flexibility for subsequent expansion. The Master node is mainly responsible for managing and scheduling cluster resources. All Tor node container deployments in the private Tor network environment simulated by this method are performed through the interface provided by the Master node. All instructions are also run on the Master node, including deployment instructions, viewing specific Tor node information, etc. The Worker node is the actual resource provider. All Tor node containers scheduled by the Master node eventually run on a Worker node. The experimenter can log in to a specific Tor node in the private Tor network through the interactive interface provided by the Worker node to perform actual operations.

[0103] When deploying the network plug-in, the Tor network attack and defense experimental platform based on multi-granularity simulation specifies the address of the private Tor network segment through the configuration item. For example, if it is specified as 9.0.0.0 / 16, the network of each worker node is divided into subnets such as 9.0.0.0 / 24, 9.1.0.0 / 24, and 9.2.0.0 / 24 in turn. Based on which subnet a node IP in the private Tor network belongs to, it can be determined which worker node the Tor container node is running on.

[0104] For the simulated private Tor network cluster, a scheduling algorithm can be used for utilization. The Tor network attack and defense experimental platform based on multi-granularity simulation adopts a multi-granularity node deployment scheduling algorithm to maximize the utilization of all cluster resources: in nodes of different granularities, the resources are consumed by controlled nodes and auxiliary nodes, both of which are containers running Tor processes. Since the Tor network attack and defense experimental platform based on multi-granularity simulation adopts the design concept of separating node identity and function, the two types of nodes have different requirements for resources. In order to maximize the utilization of all cluster resources, a cluster scheduling strategy algorithm is designed. The scheduling strategy algorithm is shown in Table 1-3 below:

[0105] Table 1-3 Scheduling strategy algorithm

[0106]

[0107] The scheduling strategy algorithm is mainly divided into the following two stages:

[0108] The purpose of the first stage is to filter out nodes with insufficient resources, mainly cluster nodes whose CPU or memory resources no longer meet the requirements for deploying a Tor node. This is reflected in steps 1-6, where a candidate set N is established, and then a node score set is obtained based on the cluster node resource set K. The nodes are then scored based on the node's memory, CPU and other resource parameters, and the nodes are then screened and transferred to the candidate set N. The node set generated in the first stage is called the candidate set. If all nodes cannot meet the resource requirements, they will directly exit this round of scheduling.

[0109] The second stage is the optimization stage. Based on the candidate node set selected in the first stage, the one with the highest score is selected. The scoring is based on the remaining resources of the cluster node and the balance of the CPU utilization and memory utilization of the cluster node, so as to ensure the maximum utilization of resources and the balance of resource consumption of all cluster nodes as much as possible, which is reflected in steps 7-13. After selection, the scheduling results of this round are saved in the scheduling result set, and the cluster node resource set K and the cluster node score set are updated in turn.

[0110] Existing hardware-based Tor network simulation methods use hardware devices as the basic unit of simulated nodes. For example, in virtual machines, only one Tor application process is run on each virtual machine. This is to ensure the independence of different Tor nodes, such as avoiding IP conflicts and other issues. Virtual machines need to consume resources used to simulate hardware, resulting in excessive costs. If multiple Tor processes are run on a virtual machine, the resource cost of the virtual machine for simulating hardware can be shared, greatly reducing the resources required to simulate each Tor node. However, multiple Tor nodes on the same virtual machine will conflict.

[0111] The Tor network attack and defense experimental platform based on multi-granularity simulation uses Docker containers as the basic unit to simulate Tor network nodes, proposes a simulation method for multi-granularity nodes, and sacrifices the authenticity of some uncontrolled nodes to improve the scale of the overall simulation nodes. This method proposes a mechanism for container nodes to automatically form a private Tor network. With the help of the NameSpace mechanism under Linux, the containers on the same virtual machine are "isolated" from each other, ensuring that each process has its own independent virtual network card device, IP protocol stack, IP routing table and other network status information, and can also log in to a specific container for operation. This method creates a Tor network. At the same time, this method also introduces k8s technology to ensure that containers on different virtual machines can communicate with each other, enhancing the scalability of the system. Researchers can create various custom Docker images related to Tor experiments, and when conducting Tor network experiments, they can be deployed in the form of containers to access the private Tor network simulated by this method, such as FTP server nodes, Web server nodes, etc. This design method can simplify the process of researchers building a Tor experimental environment. At the same time, a private Docker image repository is built in the cluster to store the images of the Tor network basic nodes. Researchers' self-made container images can also be uploaded and stored in the image repository for subsequent experimental use.

[0112] In view of the scalability and authenticity balance problem faced by existing technologies in supporting Tor network attack and defense research experiments, this method designs a Tor network attack and defense experiment platform based on multi-granularity simulation, and the beneficial effects achieved are as follows:

[0113] (1) The Tor network environment built by the experimental platform has real Tor applications involved. The traffic generated in the Tor link is the traffic of the real Tor protocol, and the traffic in the network can be captured. This is convenient for supporting tracing attack and defense experiments, because such experiments require research and analysis of real Tor protocol data packets.

[0114] (2) The private Tor network environment built by the experimental platform can simulate large-scale network nodes and meet the operation of thousands of nodes. Small-scale networks built by traditional methods cannot experience the network effects of large-scale networks. For some network security experiments such as DoS attack experiments, small-scale networks are difficult to meet the needs of the experiments.

[0115] (3) In the private Tor network environment built by the experimental platform, the experimenter can easily control certain Tor network nodes, that is, he can perform real-time operations on Tor network nodes during the experiment, such as capturing node traffic, adjusting node routing strategies, and executing scripts. This is crucial for the Tor network attack and defense experimental platform, because most attack and defense research requires dynamic adjustments during the experiment. If some Tor network nodes cannot be controlled in real time, these studies cannot be conducted.

[0116] (4) The private environment built by the experimental platform is autonomous and controllable. Autonomy means that experimenters can build and destroy the experimental environment at any time, while controllability mainly means that all traffic in and out of the private Tor network environment can be controlled by the experimenter. Otherwise, experiments such as watermark attacks and censorship attacks cannot be carried out.

[0117] (5) The private Tor network built on the experimental platform is fully functional. By simulating various network nodes, it has complete network proxy and hidden service deployment functions.

[0118] (6) The experimental platform can build multiple private Tor network environments at the same time, and each Tor network environment does not affect each other. This ensures that multiple Tor network security experiments can be carried out simultaneously without interfering with each other, which can effectively improve the efficiency of the experiment.

[0119] (7) The experimental platform is simple and easy to use. Experimenters only need to provide a simple network topology configuration to build a customized private Tor network environment, which can greatly reduce the learning cost of researchers.

[0120] The following are descriptions of the professional terms:

[0121] (1) Tor

[0122] Tor is a distributed overlay network designed to anonymize TCP-based application services such as web browsing, secure shells, and instant messaging. Users obtain Tor network consensus through Tor clients, select a path based on the network node information in the consensus file, and build a three-hop (default) link. Each node on this link only knows its previous and next nodes, but other nodes in the link do not know.

[0123] (2) Authoritative Directory Server

[0124] There are 9 special nodes in the Tor network, called Authoritative Directory (DA) nodes, which are the central servers of the entire network. For a node that wants to join the Tor network, it must first upload its own descriptor information to the authoritative directory server node (the IP of the authoritative directory server node has been hard-coded into the Tor application code). Only after the authoritative directory server votes and writes the consensus file can it be considered to have truly joined the Tor network. In the real Tor network, the authoritative directory server generally initiates a vote every hour and generates a new consensus file.

[0125] (3) Tor consensus files

[0126] The Tor consensus file is a file generated by the voting of the authoritative directory server nodes, which contains the information of all routing nodes in the Tor network, including the IP address, fingerprint information, bandwidth, OR port, Dir port, Tor running version, and network strategy of the routing node. At the same time, the consensus file also records some labels of the node, such as Exit, Guard, etc., which play an important role in Tor route selection.

[0127] (4) Ordinary routing nodes

[0128] Nodes that do not have the Exit or Guard label in the Tor consensus file are ordinary routing nodes. They mainly act as Middle nodes when Tor selects a path and will not be selected as entry nodes or exit nodes.

[0129] (5) Exit Node

[0130] Nodes with the Exit label in the Tor consensus file are exit nodes. Such nodes can be selected as the last hop of the link when selecting a route. Of course, they can also become intermediate nodes in the link like ordinary routing nodes. To become an exit node, you need to add the configuration item ExitRelay 1 in the torrc file that starts the Tor application.

[0131] (6) Guard Node

[0132] Guard nodes refer to nodes with Guard labels in the Tor consensus file. Such nodes can be selected as the first hop or intermediate node of the link when selecting a route. Since the first hop in the link is in direct contact with the user, it plays a very important role in the anonymous system. Therefore, it cannot be actively configured like the Exit node, but needs to meet a series of strict requirements to be given the Guard label, such as node stability and long-term operation.

[0133] (7) Bridge node

[0134] Bridge nodes are a special type of node in the Tor network. They do not exist in the Tor consensus file. This is because the consensus file officially released by Tor is public, and it is not difficult for censors to ban Tor. Therefore, private bridge nodes are a good solution. They often assume the function of entry nodes, ensuring that Tor users can smoothly access the Tor network without censorship.

[0135] (8) Hidden Services

[0136] Tor hidden services are services that can only be accessed through the Tor network. When a user deploys a hidden service, a unique onion address will be generated. When a visitor accesses the Tor network, Tor will resolve this onion address and direct the visitor to a specific anonymous service. Hidden services provide two-way anonymity, which ensures that the server does not know the specific IP address of the client, and the client also does not know the IP address of the server (it only knows the onion address of the hidden service), which has strong privacy protection capabilities.

[0137] The Tor network attack and defense experimental platform based on multi-granularity simulation images the Tor node into a Docker container, and uses the container node of the Docker container image and the Tor node to build a simulated private Tor network according to the network topology information uploaded by the user. The simulated private Tor network can effectively generate background nodes that conform to the real network distribution, and then use the Master node to build a simulated private Tor network cluster, and maximize the resource utilization of the simulated private Tor network cluster through the cluster scheduling strategy algorithm; it also includes the close integration of k8s cluster deployment technology and Tor deployment, making full use of the distributed characteristics of the cluster to deploy Tor private networks on a large scale, and at the same time has good scalability; it also includes the organic combination of various experimental tools such as Tor node traffic collection, Tor node resource monitoring, Tor node log monitoring, Tor node console interaction, etc., to facilitate the experimenter's experimental research on Tor private networks.

Claims

1. A Tor network attack and defense experimental platform based on multi-granularity simulation, characterized by: The Tor node is mirrored to a Docker container, and the nodes are divided into three categories: controlled nodes, background nodes, and auxiliary nodes. According to the network topology information uploaded by the user, the container nodes of the Docker container image and the Tor nodes are used to build a simulated private Tor network; the three types of nodes are used to build a simulated private Tor network, including the following steps: S1: Calculate the number of auxiliary nodes for each role to be deployed based on the configuration requirements of the network topology configuration of the background nodes; The network topology configuration information includes the scale of background nodes of each role in the private Tor network to be simulated and the value of the proportional parameter p. The scale of background nodes of each role includes the number of authoritative directory server nodes, the number of exit nodes, and the number of ordinary routing nodes. S2: Start the Docker container images of the controlled node and the auxiliary node, and let the container nodes in the Docker container images first build a simulated private Tor network; The method of writing a Dockerfile file to create a Docker container image includes the following steps: S41: The selected base image is debian:buster; S42: Set some environment variables in the Docker container through the ENV command, including the port where Tor is running; S43: Use the RUN command to install the software tools required for the environment, including Python, Curl, and Wget; S44: Use the COPY command to copy the Tor application source code on the host machine to the Docker container, and install the Tor program in the Docker container by compiling the source code; S45: Expose the possible ports through the EXPOSE instruction and specify the container entry command ENTERPOINT; Based on the above image building process, Docker container images of authoritative directory servers, common routing nodes, exit nodes, clients, and common bridge nodes related to multiple Tor nodes are produced respectively; S3: According to the configuration requirements of the network topology configuration of the background node, add the information of the background node to the consensus file generated after networking; The information of adding background nodes is realized according to the background nodes of the real network distribution. To effectively generate background nodes that conform to the real network distribution, the following steps are included: S31: First, collect Tor user data, pre-process the data based on the official Tor data, and obtain the Tor user ratio in different regions; S32: Generate background nodes through topology configuration, where the information in the topology configuration includes the scale of the background nodes of each role in the simulated network and the value of the proportional parameter p; S33: Generate a hybrid consensus file. The hybrid consensus file is a newly generated file after adding the background node information to the real consensus file. The subsequent route selection will be based on this file.

2. The Tor network attack and defense experimental platform based on multi-granularity simulation according to claim 1, characterized in that: The controlled node is a container node running a Docker container image, and is the node with the strongest simulation authenticity; the background node has no real running entity, and only exists in the consensus file of the simulated private Tor network; The auxiliary node is formed by replacing the background node when the Tor client selects the path based on the information of the routing node in the consensus file of the private Tor network. When the background node is selected to participate in building the link, multiple background nodes correspond to one auxiliary node.

3. The Tor network attack and defense experimental platform based on multi-granularity simulation according to claim 1, characterized in that: In step S2, the roles of Tor nodes in the network are divided into authoritative directory server nodes DA, ordinary routing nodes Relay, exit nodes Exit, and ordinary bridge nodes Bridge. They all run Tor applications, but the torrc configuration at startup is different. Both controlled nodes and auxiliary nodes need to build Tor node container images of multiple roles.

4. The Tor network attack and defense experimental platform based on multi-granularity simulation according to claim 3 is characterized in that: In step S2, when deploying the simulated private Tor network experimental environment, it is necessary to run the authoritative directory server DA node first. After the successful operation of this type of node, the generated IP and fingerprint information will be written into a public file that can be read by other types of nodes. When other types of nodes are started, they will first read the information in the public file and add it to their own torrc file, and then start running the Tor program normally. After running, they will upload the descriptor of this node to the authoritative directory server DA node in the configuration, thereby joining the simulated private Tor network.

5. The Tor network attack and defense experimental platform based on multi-granularity simulation according to claim 1, characterized in that: In step S33, if none of the selected three-hop nodes is a background node, a link is directly constructed and a log is recorded; if all of the selected three-hop nodes are background nodes, no specific link is constructed because there is no traffic communication relationship with the controlled node, and only a record is made in the log file; If the selected three-hop node includes both background nodes and controlled nodes, the background node is replaced with an auxiliary node, the link is built through the auxiliary node, and the log is recorded.

6. The Tor network attack and defense experimental platform based on multi-granularity simulation according to claim 1, characterized in that: For the background nodes generated by the simulated private Tor network, their IPs should not conflict with the node IPs in the original real consensus file. The first eight digits of the background node's IP address are designed to be x, and the network segment address is expressed as x.0.0.1 / 16 to distinguish it from the node IP in the original file. The bandwidth mean M of the routing node in the original file is calculated. Since it is necessary to simulate the randomly fluctuating bandwidth values ​​of different nodes, the random values ​​in the interval (0,2*M) can be generated through Python's Random library as the bandwidth of each background node.

7. The Tor network attack and defense experimental platform based on multi-granularity simulation according to claim 1, characterized in that: The Tor network attack and defense experimental platform based on multi-granularity simulation builds a simulated private Tor network cluster, which adopts a multi-granularity node deployment scheduling algorithm. Considering the different resource requirements of controlled nodes and auxiliary nodes, the scheduling algorithm is divided into the following two stages: In the first stage, nodes with insufficient resources are filtered out, including cluster nodes whose CPU or memory resources no longer meet the requirements for deploying a Tor node. The node set generated in this stage is called the candidate set. If all nodes cannot meet the resource requirements, they will directly exit this round of scheduling. In the second stage, based on the candidate node set screened in the first stage, the one with the highest score is selected. The scoring is based on the remaining resources of the cluster node and the balance between the CPU utilization and memory utilization of the cluster node. After selection, the scheduling results of this round are saved in the scheduling result set, and the cluster node resource set K and the cluster node score set are updated in turn.

Images