= An Exercise in Anonymity = == Background == This has been created to be a classroom exercise to explain and demonstrate a few different techniques in active anonymity, and intercepting and making sense of web traffic. == Onion Routing == Onion routing is an anonymity tool which uses multiple routers to hide web traffic from the sender to the server. The web data is encrypted using layers, with each layer being removed at the subsequent routers. This means that each router can only see two parts of the traffic, the preceding node and the next node. Therefore a compromised node would not lead to the identity of either person being revealed. This image was obtained from http://en.wikipedia.org/wiki/File:Onion diagram.svg = The Exercise = == Step 1 Setting Up the Network == Swap in the Experiment using [attachment:anonymous.ns this NS file] [[Image(wan.php3)]] [[Image(networksetup.png)]] Then log in to '''users.isi.deterlab.net''' through [http://www.chiark.greenend.org.uk/~sgtatham/putty/ Putty.] For help on logging onto Putty check out [https://trac.deterlab.net/wiki/DETERSSH this] tutorial. === Setting up apache === We need to generate traffic in our network and one of the easiest ways to do that is with HTTP traffic, so we need to set up a server and a web page. Connect to Server 1 and run [attachment:runme.apache this script] with the `sudo` command This will run a script with Apache 2 which sets up the server and web page and displays the users IP address on the Server 1 node. When prompted "Do you want to continue [Y/n]?" select `Y` Once the script is done running, the server is now set up and we can generate traffic! You can check this by typing `w3m http://localhost/cgi-bin/ip.cgi` which should display your IP address. [[Image(apache2setup.png)]] It should look like this. Repeat this process on Server 2 === Setting up the proxy node === Log onto the proxy node and use [attachment:runme.proxy this script] with the `sudo` command this will run a script which installs and sets up [https://banu.com/tinyproxy/ tinyproxy] on the node. The proxy is now set up! We'll get to using it in a little while. == Step 2 Generating and Listening to Network Traffic == We are now ready to begin learning! One person needs to connect to either Alice while another person logs into the server1 node (or server2 if you choose). From the server node type the command `ifconfig` This will show the ethernet links that the node is using. [[Image(ifconfig.3.png)]] Find the one that shows an inet address of 10.x.x.x In the example above it is eth0. Yours may be different, but that is still ok. === Direct Client-to-Server Traffic === Then type the command `sudo tcpdump -i eth0 -s 0 -x -w /tmp/direct.pcap` and then`cp /tmp/direct.pcap .` This will begin listening to the traffic that comes through this node and that specific ethernet link, eth0 in the example, write the data out to the file direct.pcap in the tmp diretory, and then copy it into the users directory. At this time, the person connected to Alice will enter the command `wget --no-proxy http://server1/cgi-bin/ip.cgi` This saves a local copy of the web page set up on the server, and by doing so generates HTTP traffic to examine. We were able to listen in on this traffic thanks to the `tcpdump` command. We'll analyze what this data looks like and can tell us at a later time. === Client-to-Server Traffic through a Proxy === Now we'll use a proxy to make this traffic a bit more anonymous. A proxy will mask the source and destination of the traffic from both the client and the server by working as a go between for the two nodes. Repeat the `tcpdump` command `sudo tcpdump -i eth0 -s 0 -x -w /tmp/throughproxy.pcap` and then `cp /tmp/throughproxy.pcap .` from the server node. However, now the user connected to Alice should enter the command `env http_proxy=http://proxy:8888 wget http://server1/cgi-bin/ip.cgi` This command changes an environmental setting and sends the `wget` command through the proxy on port 8888. Thanks to the `tcpdump` command, we have a copy of this traffic as well. === Client-to-Server Traffic through Tor === We will now use [https://www.torproject.org/ Tor] to onion route the data. As the name suggests onion routing alters the data flow through a minimum of 3 relays, each adding another layer of anonymity, because the packets of data only know the address of the next relay and the previous relay. Repeat the `tcpdump` command `sudo tcpdump -i eth0 -s 0 -x -w /tmp/throughtor.pcap` and `cp /tmp/throughtor.pcap .` from the server node. Now, the user on Alice should use the command `torify wget http://server/cgi-bin/ip.cgi` == Step 3 Analyzing the Traffic Data == So now we have collected HTTP network traffic data from 3 different connections: direct, through a proxy, and through the Tor network. Now, it's time to analyze that data. We will do this using [http://www.wireshark.org/ Wireshark]. To access this data we need to use the SSH Secure File Transfer Client [[Image(sshclientstart.png)]] Click on the Quick Connect Button [[Image(sshclientlogon.png)]] It should look like this. Click Connect, and enter your password when prompted. In the right column, you should see three files: direct.pcap, throughproxy.pcap, and throughtor.pcap. Copy these files and place them on your desktop. Then open up Wireshark. [[Image(wireshark.png)]] Click on the File tab, and click Open. Find the 3 data files on your desktop and open up direct.pcap. [[Image(wiresharkdirect.png)]] It should look similar to this. Let's check out the source and destination information from the HTTP data packets. We can see that the source is 10.1.4.2, which corresponds to the Alice node IP address, and the destination is 10.1.1.2, which corresponds to the Server1 node's IP address. This makes it clear that Alice was making an HTTP request to Server1. [[Image(Regular Dataflow.png)]] Now open up throughproxy.pcap in Wireshark. [[Image(wiresharkthroughproxy.png)]] What we see is much different, we see that the source is 10.1.3.4, which is the IP address of the proxy node. So, now the destination, Server1, doesn't know that the request came from Alice, but instead thinks that the request came from the proxy node. [[Image(Proxy Dataflow.png)]] Now, we try it with the throughtor.pcap file. [[Image(wiresharkthroughtor.png)]] Again we see that the source is not Alice, but instead matches the IP address from one of the Tor Relay nodes. It won't always be the same every time because the path that the data takes through the Tor network is random. This, like going through the proxy, provides anonymity for the client, in our case Alice, but this provides more anonymity because the data goes through 3 Tor relays instead of just one proxy. [[Image(Tor Dataflow.png)]] This may provide for anonymous communication, but it doesn't keep the data secure. We might not know who the data came from, but we can still tell what it was. Open up one of the .pcap files. [[Image(readwireshark.png)]] Highlight one of the HTTP packets, then expand the Hypertext Transfer Protocol section. Here we can read that the command `wget` and the user was trying to access `http://server1/cgi-bin/ip.cgi`. So, even though the server doesn't know where the request came from, we still know what the command is. == More on Your Own == If you want to explore this some more, you can use `tcpdump` and Wireshark on more than just the server node. When using the proxy to send data, you can use it on the Alice node and the proxy node to determine what each knows about the source and destination of the packets. If you're using Tor, then you can use it on the Alice node and the Tor Relays to determine what they all know about the packets. After you've done some of that, which anonymity tool do you think is the best at keeping users anonymous?