Achieving Anonymity with Tor Part 1

Wubi · August 16, 2012

We all know that Tor enables us to be anonymous on the Internet. In this article we’ll look at how to achieve this and truly know what we’re up against.

First, let’s install Tor and start using it to get a grasp on things. There are many tutorials on the Internet describing how to install and use Tor, but let’s mention all of the required steps again.

We’ll assume that we use Ubuntu Linux distribution, but the steps are relevant for other distributions as well. First check [1] on how to add the right repository to the sources list. In case you’re using Ubuntu 10.04 – the same versions as Backtrack 5 R2 uses – then issue the commands presented below:

# echo "deb [URL="http://deb.torproject.org/torproject.org"]Index of /torproject.org[/URL] lucid main" >> /etc/apt/sources.list
# echo "deb-src [URL="http://deb.torproject.org/torproject.org"]Index of /torproject.org[/URL] lucid main" >> /etc/apt/sources.list

Then install the tor and privoxy:

# apt-get update
# apt-get install tor privoxy

At this point we should note what both of them are:

tor: is used to connect us to anonymous network over TCP.
privoxy: is used to connect our browser to Tor over HTTP proxy.

Add the following line to the /etc/privoxy/config:

# echo "forward-socks4a / 127.0.0.1:9050 ." >> /etc/privoxy/config

Also edit the /etc/tor/torrc and add the following lines:

AvoidDiskWrites 1
ControlPort 9051
Log notice stdout
SafeSocks 1
WarnUnsafeSocks 1
SocksListenAddress 127.0.0.1
SocksPort 9050

We won’t go into too much detail what the options mean right now, but we’ll describe the interesting configuration variables later. First let’s start tor and privoxy:

# /etc/init.d/tor start
# /etc/init.d/privoxy start

This should open two ports, the 9050 one for tor and 8118 for privoxy. Let’s check if that’s true:

# netstat -lntup
tcp 0 0 127.0.0.1:8118 0.0.0.0:* LISTEN 8520/privoxy
tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN 8540/tor

Ok, the ports are in a listening state, which means all is well, because they can accept connections. The only missing step is to actually configure our browser to use the privoxy. An example of Firefox configuration is presented on the next picture:

We can see that we configured the browser to connect through the proxy running on IP 127.0.0.1 and port 8118, which is exactly our Privoxy proxy. Out web browser connects to Privoxy, which in turn connects to Tor, which enables us to browse the Internet anonymously.

Let’s check whether the browser is actually using the Tor network to browse the Internet anonymously. We can do that by visiting the URI Check Torproject. If we get something like below picture, then we’ve set up Tor successfully and we can browse the Internet anonymously.

Instead of setting it manually, we can also use Tor Browser Bundle, which integrates practically everything that we need to anonymous browsing. We do that by downloading the Tor Browser Bundle, extracting it, and running the start-for-browser script, as presented below:

# tar -xvzf tor-browser-gnu-linux-x86_64-2.2.37-1-dev-en-US.tar.gz
# cd tor-browser_en-US
# ./start-tor-browser

The start-for-browser script first starts Vidalia, which is a QT frontend for Tor and will look like this:

On this picture we can see that we’ve successfully connected to Tor network (the connection happens when the Vidalia is started). If we click on the “View the Network”, we’ll also get a listing of all the online relays the Tor network is using – this might be more up-to-date as Tor Nodes.

The start-for-browser script will also open the Tor web browser once we’ve successfully connected to Tor network. Tor web browser is based on Firefox and will look like the picture below:

We can see that our browser is successfully using the Tor network and we can browse the Internet anonymously.

2. How does Tor work

Before describing how Tor works, we must know how modern Internet works. When we’re visiting a website like Google we’re sending a request to one of the Google’s web servers. But this doesn’t happen directly from our computer at home to Google web server. What happens is that we send the request to our home router first, followed by the ISP (Internet Service Provider), which forwards it to one of the NIRs (National Internet Registries), which forwards it to one of the LIRs (Local Internet Registries), which forwards it to one of the RIRs (Regional Internet Registries), etc, until eventually the process is reversed when the request finally reaches the target – the Google web server. This can be observed by using the Traceroute program that sends packets with specifically set TTL (Time To Live) value, which expires on every hop (TTL is increased by 1 each time the packet is sent to make sure that it expires) between our client and server, thus revealing the identity of each node. To find all the nodes the packet has to visit when it travels through the Internet to the Google web server, we can execute the command presented below:

# traceroute [URL="http://www.google.com"]Google[/URL]

The basic problem with the above approach is that all intermediary nodes can monitor our packets being forwarded through the Internet. Even if we use an encrypted connection (HTTPS), various data can still be gathered just by looking at the TCP header, like source IP, destination IP, payload size, time of communication, etc.

But what happens if we’re using Tor on top of the usual Internet network? We can’t actually execute Traceroute when we’re using Tor, because of the way Tor was designed. Because Tor can’t handle ICMP (ping) packets, there is no way of actually knowing where the packets will be routed to. This is what makes Tor secure. When we’re using our browser to connect to Tor network, we’re actually sending a request through the Internet to the first Tor relay, which forwards it to the next relay and the next and the next, until finally reaching the target.

In Tor network, we still need to send our packets to our home network, then ISP, since this is our Internet service provider; without it, we can’t even use the Internet. But additionally, our packets are also routed though the Tor network, where they are randomly routed through secure relays. This enables our traffic to be unseen by the skillful attacker and government that are monitoring the traffic at any given location on the Internet.

The client connecting to the Tor network first needs a list of Tor nodes that can be obtained from the directory server. We can see the available Tor relays by visiting Tor Nodes, where we can find various data about the Tor relays, including hostname, router name, uptime, available bandwidth, etc.

After the client has obtained a list of available Tor relays, it needs to build a circuit of connections between the relays on the Tor network. Each connection between subsequent nodes in a circuit is encrypted with different encryption keys, so each node only knows the previous and the next node in a circuit.

We should also mention that Tor works over TCP protocol and it can be used by any application that can be configured to send its traffic through a SOCKS proxy. This isn’t entirely true, since we can torify the application with the use of tsocks, which we’ll describe in one of the subsequent articles.

So all in all, Tor network provides a means to hide the link between the source and destination address of any given connection. Therefore, an eavesdropper cannot determine where the data came from and where it is going, thus making us anonymous.

But the question remains: can that really make us anonymous? The answer is yes and no. We need to remember that all the data packets that are sent from our client to the server will be unencrypted on the server. This really makes sense, since how would the server use the data and do something with it if the data was encrypted. Therefore, Tor provides anonymity over the Internet, but it can’t provide the means to actually stay anonymous from the server that’s receiving data.

Let’s describe this a little further. If we’re sending data packets that contain our username, domain name, or any other information that indicate our presence, then the target machine will know who we are, although any eavesdropper listening in an intermediary relay may not. It boils down to this:

In each connection going though the Tor network, we need to be concerned about:

the client sending the data
the Internet routing the data
the server receiving the data

With Tor, we can ensure that the Internet routing the data doesn’t have any idea about the source and destination address we’re using, which is crucial for being anonymous over the Internet. But the data being sent from client to server are visible on both ends of the connection. Therefore, to truly stay anonymous, even to the target machine, we need not encapsulate any sensitive information within the data packet of the traffic flowing between client and server.

In order to hide the application-level information that could compromise our anonymity, we can use Torbutton; a Firefox extension that disables many possible information leakage that can compromise our anonymity. Even better, we can use Tor browser bundle, which uses Vidalia to configure and start Tor. It also opens Tor web browser with Torbutton integrated, which we can use to anonymously search the Internet.

3. Tor configuration variables

Let’s present what the manual says about the configuration variables that we used in this article:

AvoidDiskWrites: If non-zero, try to write to disk less frequently than we would otherwise. This is useful when running on flash memory or other media that support only a limited number of writes. (Default: 0)

ControlPort: If set, Tor will accept connections on this port and allow those connections to control the Tor process using the Tor Control Protocol (described in control-spec.txt). Note: unless you also specify one or more of HashedControlPassword or CookieAuthentication, setting this option will cause Tor to allow any process on the local host to control it. (Setting both authentication methods means either method is sufficient to authenticate to Tor.) This option is required for many Tor controllers; most use the value of 9051. Set it to “auto” to have Tor pick a port for you. (Default: 0).

Log: Send all messages to the standard output stream, the standard error stream, or to the system log. (The “syslog” value is only supported on Unix.) Recognized severity levels are debug, info, notice, warn, and err. We advise using “notice” in most cases, since anything more verbose may provide sensitive information to an attacker who obtains the logs. If only one severity level is given, all messages of that level or higher will be sent to the listed destination.

SocksListenAddress: Bind to this address to listen for connections from Socks-speaking applications. (Default: 127.0.0.1) You can also specify a port (e.g. 192.168.0.1:9100). This directive can be specified multiple times to bind to multiple addresses/ports.

SocksPort: Advertise this port to listen for connections from Socks-speaking applications. Set this to 0 if you don’t want to allow application connections via SOCKS. Set it to “auto” to have Tor pick a port for you. (Default: 9050)

3. Configuring DNS resolution securely

The one thing that we must really watch out when using Tor is the DNS resolution. Usually, our client machine is using our own DNS servers, which in turn use ISP’s DNS server, so an eavesdropper can still obtain the source and destination IP we’re communicating with. This is an unwanted behavior, because the DNS server sees what hostname we are trying to resolve and connect to, which can lead to user disclosure.

Our web browser uses SOCKS proxy to connect to Tor. We must know what kind of SOCKS proxies are out there. There are three kinds of SOCKS proxies, listed below:

SOCKS 4 : uses IP addresses.

SOCKS 4a : uses hostnames.
SOCKS 5 : uses IP addresses and hostnames.

To test whether we’re resolving hostnames locally or remotely, we can edit torrc configuration file and add the following line into the configuration file:

TestSocks 1

SafeSocks 1

WarnUnsafeSocks 1

TestSocks: When this option is enabled, Tor will make a notice-level log entry for each connection to the Socks port indicating whether the request used a safe socks protocol or an unsafe one (see above entry on SafeSocks). This helps to determine whether an application using Tor is possibly leaking DNS requests. (Default: 0)

SafeSocks: When this option is enabled, Tor will reject application connections that use unsafe variants of the socks protocol?—?ones that only provide an IP address, meaning the application is doing a DNS resolve first. Specifically, these are socks4 and socks5 when not doing remote DNS. (Defaults to 0.)

WarnUnsafeSocks: When this option is enabled, Tor will warn whenever a request is received that only contains an IP address instead of a hostname. Allowing applications to do DNS resolves themselves is usually a bad idea and can leak your location to attackers.

(Default: 1)

In the next article we’ll describe how to set-up DNS resolution mechanism to prevent any possible information leakage and client disclosures.

4. Conclusion

We can see that if we’re careful we can achieve total anonymity on the Internet. We must watch out not to resolve hostnames locally and we must not include sensitive information in an application data that can blow our cover. If we do that, we can really stay anonymous on the Internet.

References:

[1] Ubuntu tor installation guide, retrieved from https://help.ubuntu.com/community/Tor.

[2] Tor manual, retrieved from https://www.torproject.org/docs/tor-manual.html.en.

Sursa, InfoSec Institute (InfoSec Resources – Achieving Anonymity with Tor Part 1)