Anonymising your traffic with linux

Public networks like the internet are very vulnerable to traffic analysis. Packet headers identify the IP addresses of the recipient(s) and the packet routes can rather easily be tracked, see Networking concepts.

Transmissions can be encrypted so that an attacker cannot learn the content of these transmissions, but this still reveals the fact that two parties are communicating. If for example a government official is sending encrypted data to a website of the opposition, and later that site publishes a document that was supposed to be secret, it is pretty clear what happened.

To explain how enhanced communication anonymity can be reached on a linux platform, this page gives an overview of used approaches. The 3 major anonymity networks are Tor/Onionland, I2P/Garlicland and Freenet. If you feel confused on which one is the "best" one to use the answer is simple. Use all three. Each anonymity network is designed for a different purpose. One network alone cannot do what the three can do together. Tor and I2P cannot persist information like Freenet can, Tor and Freenet can't offer the generic transports that I2P provides and Freenet doesn't handle data streaming as well as Tor and I2P. There is also no better proxy system than the Tor network.

To get to the bones and see for yourself, check out the resulting traffic after making changes, for example with wireshark. And to not run into a wall during experimentation (aaaah, nothing works), punch the necessary holes in your firewall. If you adjusted your /etc/sysctl.conf you may want to learn how to use exception options (when available) for commands, or undo some of those changes.

Plausible deniability

Plausible deniability in networking is about relaying certain types of broadcasts automatically in such a way that the original transmitter of a file is indistinguishable from those who are merely relaying it allows for the person who first transmitted the file to claim that his computer had merely relayed it from elsewhere, and this claim cannot be disproven without a complete decrypted log of all network connections to and from that person's computer, or ...

Plausible deniability has its limits. Recent cryptographic primitives and protocols offer a wide range of features besides confidentiality and integrity. There are many protocols that have more advanced properties such as forward secrecy, deniability or anonymity. In a phrack article a deeper look at deniability in communication (e.g. messaging) protocols appeared. One protocol that claims to offer deniability is OTR. The construction in the article can probably be extended in a quite general way. It shows the limits of deniability, especially in protocols that offer message integrity features (as OTR does). A protocol is constructed that enables each partner in a conversation to cooperate with an observing party, such that he can prove the authenticity of any message that was part of the conversation to the observing party .

SSH tunneling

Tunneling with local port forwarding

Imagine wikileaks being blocked using a proxy filter in a university somewhere. A SSH tunnel can be used to bypass this restriction.

Let’s name the machine at the university socially-correct and the home machine as home. The home machine needs to have a public IP and be running a SSH server for this to work. You must have ssh user access on home and socially-incorrect must have access to host:hostport (is not blocked).

$ ssh -L localport:host:hostport user@home -N 

where:

• -L: port forwarding parameters
• localport: local port (choose a port that is not in use by other service)
• host: server that has the port (hostport) that you want to forward
• hostport: remote port
• -N: do not execute a remote command (you will not have the shell).
• user: user that has ssh access to the ssh server
• home: the machine/server running the ssh server that will be used for forwarding/tunneling

For example, to create the SSH tunnel execute following from the socially-correct machine:

$ ssh -L 9001:wikileaks.org:80 user@home

                    +--------------+<--  port 22  -->+--------------+<--  port 80  -->+-----------+ 
                    |  SSH client  |-----------------|  SSH server  |-----------------|   host    | 
                    +--------------+                 +--------------+                 +-----------+ 
                     localhost:9001                        home                      wikileaks.org:80

Open a browser and go to http://localhost:9001 to see if the tunnel is working.

Now the SSH client at socially-correct will connect to the SSH server running at home (usually running at port 22) binding port 9001 of socially-correct to listen for local requests thus creating a SSH tunnel between home and socially-correct. At the home end it will create a connection to wikileaks.org at port 80. So socially-correct doesn’t need to know how to connect to wikileaks.org. Only home needs to worry about that. The channel between socially-correct and home will be encrypted while the connection between home and wikileaks.org will be unencrypted.

The home to wikileaks.org connection is only made when the browser makes the request, not at the tunnel setup time.

The SSH man pages say:

• -L port:host:hostport specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. This works by allocating a socket to listen to port on the local side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the remote machine. Port forwardings can also be specified in the configuration file. Only root can forward privileged ports. IPv6 addresses can be specified with an alternative syntax: port/host/hostport
• -N Do not execute a remote command. This is useful for just forwarding ports (protocol version 2 only).

You can also use local port forwarding to set up a VNC session between socially-correct and your home server. From socially-correct:

$ ssh -L 5900:localhost:5900 user@home

The localhost is relative to the gateway (home in this case), not the machine from where the tunnel is initiated. So this will make a connection to port 5900 of the home computer where the VNC client would be listening in.

Reverse tunnelling with remote port forwarding

What if we wish to connect to an internal university website from home? The university firewall is blocking all incoming traffic. We can connect from home to the university internal network so that we can browse the internal site. We can initiate the tunnel from the socially-correct computer behind the firewall. This is possible since only incoming traffic is blocked and outgoing traffic is allowed. The client will now be at the home computer and instead of -L option we use -R which specifies a reverse tunnel is to be created. From socially-correct:

$ ssh -R 9001:internalsite.org:80 user@home

The SSH client at socially-correct will connect to the SSH server running at home creating a SSH channel. The server will bind port 9001 on the home machine to listen for incoming requests that are then routed through the created SSH channel between home and socially-correct. Now it’s possible to browse the internal site by visiting http://localhost:9001 in a web browser on the home machine. The socially-correct machine will then create a connection to internalsite.org and relay back the response to home via the created SSH channel.

Dynamic port forwarding

Dynamic port forwarding allows for configuring one local port for tunnelling data to all remote destinations. This requires the Socks protocol. At the client side of the tunnel a Socks proxy would be created and the application uses the Socks protocol to specify where the traffic should be sent when it leaves the other end of the ssh tunnel. From socially-correct:

$ ssh -D 9001 user@home

SSH will create a Socks proxy listening in for connections at local port 9001 and when receiving a request routes the traffic via the SSH channel created between socially-correct and home. Configure the browser to point to the Socks proxy at port 9001 at localhost.

Virtual private networks

DNS leaks

Error creating thumbnail: timeout: can't execute '180': No such file or directory

Error code: 127

Using wireshark to check for DNS leaks

This is an example in a virtualbox VM. Virtual machines receive its network address and configuration on the private network from a DHCP server integrated into VirtualBox. The IP address assigned to the virtual machine is on a completely different network than the host (but can be seen with wireshark from the host). As more than one card of a virtual machine can be set up to use NAT, the first card is connected to the private network 10.0.2.0, the second card to the network 10.0.3.0 and so on.

• Start capturing on eth0 and connect to the VPN.
• After capturing either a fixed number of packets, or an amount of data or for a specific time period, go to Statistics -> Endpoints

There should only be one public IP address, namely that of the VPN server that you’re connected to.

Setting DNS nameservers in debian

Fail:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

In case the network you hook into uses DHCP and you set your DNS nameservers (in debian) manually in /etc/resolv.conf, any change will be lost as it gets overwritten next time something triggers resolvconf. And adding nameservers after a loopback in interfaces doesn’t work either.

resolvconf is a set of script and hooks managing DNS resolution using DHCP client hooks, a network manager plugin and /etc/network/interfaces to generate a list of nameservers and domain to put in /etc/resolv.conf

The /etc/resolvconf/resolv.conf.d directory (probably) contains base, head, original and tail files in resolv.conf format:

• base: used when no other data can be found
• head: for the header of resolv.conf, can be used to ensure a DNS server is always the first one in the list
• original: backup of your resolv.conf at the time of resolvconf installation
• tail: appended at the end of the resulting resolv.conf

Open the head file with your favorite editor for it (geany, vi, vim, nano) as root (sudo, su or root terminal). The head file contains the same warning as above … but in this case it is there so that when the resolv files are constructed, the warning will ultimately work its way into the resulting resolv.conf file.

Add (or replace) the nameservers you picked from for example, the opennic project or the wikileaks alternative DNS list:

nameserver nnn.nnn.nn.nnn
nameserver nn.nn.nnn.nnn

Then update:

$ sudo resolvconf -u

And test by viewing the results in /etc/resolv.conf. You can also create /etc/resolv.conf.tail, but do check because only the first two are used.

Proxying with tor

Liberté linux

See making your own images.

Chaining

Related

• Networking concepts
• Encrypting everything