Posted by: Tamer Sameeh December 10, 2018 in Articles, Featured 1 Comment
There are currently many approaches to conducting Tor network security research. Direct experiments on the live Tor network, formal modeling, connection simulation, and emulation of the Tor network represent a few examples of these approaches. It should be emphasized that there are multiple ethical issues associated with conducting experiments on the live Tor network. The main challenges include undermining the security of real Tor users and negatively affecting the performance of the Tor network itself. As such, security researchers are always seeking safer alternatives for conducting Tor experiments.
A recently published paper proposed the use of the VMware virtualization platform to create discrete virtual machines that play the roles of directory server, relay nodes, clients, and web servers. The group of virtual machines are set up in the form of a small-scale, yet functioning Tor network. It can be used to conduct Tor experiments or to educate newbies about how Tor network functions in general.
ATTENTION: Click Here To Get Over $100,000 Money Transfer Through Bank Transfer Hackers!!!
ATTENTION: Get Your Hacked Western Union MTCN Transfer and Cash Out Over $2500 within minutes!!!
ATTENTION: Click Here For Your Blank/Cloned ATM Cards for ATM Cashout and Online Purchase!!!
Using VMWare Fusion for creating Tor network virtual environments:
When using VMware, the choice of operating systems is not limited to Linux or special Linux packages (e.g. Ubuntu). The experimenter is thus free to choose any of the Linux variants or Microsoft Windows platforms as an OS to install the Tor directory server, relay nodes, and client. VMware Fusion is particularly designed for the MacOS. It is mostly identical to the VMware virtualization technology for the Microsoft Windows and Linux operating systems known as VMware Workstation.
Installing a Tor node using VMware yields a virtual machine but the operating system acts and operates exactly as it would on a dedicated hardware. Features such as graphical user interface (GUI) are available for the user if desirable. All available tools on the operating system are accessible, including GUI-based ones. The differences include a bigger footprint, higher resource requirements, and heavier demand on the host machine’s CPU. Keeping the individual virtual machine operating system up to date is also easier using the VMware approach. All the package manager tools are easily accessible which renders it easier to update the Tor nodes on the network, opposite to using Docker containers, for instance. It is also possible to only update a single instance of a Tor node, because it is independent of all other node instances. This is not the case with other virtualization technologies like Docker or Netkit. The experiment conducted in this study used VMWare Fusion to create all Tor virtualization environments.
Using the experimental Tor network created via VMWare Fusion to connect to a web server:
For this experiment, the Tor client attempts to connect to a remote web server via the created virtual Tor network. A total of 3 relay nodes and 1 client will take part in the experiment. One exit relay node (exit1) and 2 non-exit relay nodes (relay1 and directoryserver) will form the Tor circuit. The web server and the DNS server are not part of the Tor circuit. The setup is illustrated in Figure (1).
Figure (1): Connecting to a web server via the virtual Tor network
The client uses the Linux “curl” command to obtain a web page that contains the remote address of the connecting machine. This is the first step towards showing that the VMWare Fusion setup actually operates in a similar fashion to the live Tor network. Traffic originating from the client must be routed to the entry relay node, passed on to the middle relay node, and then routed to the exit relay node, before finally being directed towards the destination web server.
It must also be shown that traffic sent into the virtual Tor network setup is properly encrypted at each Tor relay node to preserve Tor client’s anonymity. Figure (2) and Figure (3) prove that the Tor client connection via the virtual Tor network to reach the web server is successful. It is also shown that the remote IP address of the machine connecting to the remote web server is that of the exit relay node (relay1) rather than that of the Tor client.
Figure (2): Output of the curl command running on the client showing the IP address of the exit relay node (exit1)
Figure (3): Using the Tor browser to access the remote web server via the virtual Tor network
The 3-hop Tor circuit created for use by the Tor client is shown in Figure (4). The circuit includes directoryserver (192.168.1.4) which also functions as a Tor relay node, relay1 (192.168.1.1) and exit1 (192.168.1.5).
Figure (4): Tor circuits created on the client’s machine
In order to verify that the anonymity of the Tor client is preserved by this virtual Tor network, a series of packet captures is conducted on the following machines using the TCPDUMP utility:
• client
• directoryserver
• relay1
• exit1
• webserver
Wireshark protocol decoder was used to visualize the captured packets graphically. The order of decoded traffic viewed are as follows:
client → entry relay → middle relay → exit relay → web server
The first packet capture decoded is composed of the packets captured at the Tor client, which is the SOCKS proxy traffic over port 9050, shown in Figure (5). The SOCKS proxy connection is established via the loopback interface, 127.0.0.1.
Figure (5): Protocol decode of the SOCKS proxy connection over port 9050 at the client
The second packet capture decoded is composed of the client packets destined to port 5000, which is the Onion Router port setting in the Tor configuration files of all the Tor relay nodes in the setup. In this case, these represent the packets sent by the Tor client to the entry relay. Figure (6) displays the protocol decode which shows the client (192.168.1.100) making a connection to the entry relay (192.168.1.4).
Figure (6): Protocol decode of the client connection to the entry relay node of the virtual Tor network (client perspective)
The third protocol capture decoded represents the packets captured at the entry relay (192.168.1.4), as shown in Figure (7). It is possible to clearly see the client’s IP address (192.168.1.100). This is expected because the entry relay node must know about the client that is establishing the connection into the Tor network.
Figure (7): Protocol decode of the client connection to the entry relay of the Tor network (entry relay perspective)
The fourth protocol capture decoded represents the packets captured at the middle relay node (192.168.1.1). As shown by Figure (8), there is a connection established by the entry relay node (192.168.1.4) to the middle relay node (192.168.1.1), but the client’s IP address (192.168.1.100) is not shown.
Figure (8): Protocol decode of the entry relay making a connection to the middle relay
The fifth protocol capture decoded represents the packets captured at the exit relay node (192.168.1.5). As shown in Figure (9), the middle relay node (192.168.1.1) is establishing a connection to the exit relay node (192.168.1.5). Once more, the client’s IP address (192.168.1.100) is not visible in the protocol decode.
Figure (9): Protocol decode of the middle relay making a connection to the exit relay
The sixth packet capture decoded represents all packets destined for port 80 (HTTP) at the exit relay node. This is what is visible to the exit relay node as it establishes the final outgoing connection to the target remote web server. As Figure (10) shows, the exit relay node (192.168.1.5) is establishing the connection to the remote web server (192.168.1.200). The client identity remains hidden and invisible under protocol analysis.
Figure (10): Protocol decode of the exit relay node establishing a connection to the remote web server (exit relay perspective)
The final protocol capture decode represents the traffic captured at the remote web server (192.168.1.200). It is confirmed here, too, that the web server only sees the request coming from the exit relay (192.168.1.5) and not from the client (192.168.1.100). The protocol decode is shown in Figure (11).
Figure (11): Protocol decode of the exit relay node establishing a connection to the remote web server (web server perspective)
This experiment proves that the created virtual Tor network behaves as expected in the most fundamental sense. Client anonymity is preserved except to the entry relay node. Likewise, only the exit relay node knows the final destination of the client’s connection request.
Final thoughts:
Creating a virtual Tor network composed of discrete virtual machines for directory server, relay nodes, client, and target remote web server offers a myriad of realistic possibilities for the researcher. It is also ideal for investigating what is happening within each Tor node by means of the available graphical user interface and the ability to establish multiple terminal windows opened simultaneously.
VMware Fusion virtualization platform is an ideal tool for creating a virtual Tor network. The experiments we presented over the created virtual network were conducted to confirm the Tor network functionality. The results prove that the virtual Tor network created via VMWare Fusion behaves almost identically to the actual Tor network even though it is limited by the number of relay nodes and clients created.