Difference between revisions of "Anonymising your traffic with linux"

Revision as of 18:46, 5 August 2015

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 ^[1].

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

OpenVPN

DNS leaks

Firewall

Bitmask

Proxying with tor

Browser bundle

Installing and configuring tor

Liberté linux, tails, whonix, freepto

Liberté linux

See making your own images.

Tails

Whonix

Freepto

Chaining

Going underground with i2p

References

↑ Secure Function Evaluation vs. Deniability in OTR and similar protocols http://phrack.org/issues/68/14.html#article

[1] Secure Function Evaluation vs. Deniability in OTR and similar protocols http://phrack.org/issues/68/14.html#article

[1]

@@ Line 66: / Line 66: @@
 === Dynamic port forwarding ===
+Dynamic port forwarding allows for configuring one local port for tunnelling data to all remote destinations. This requires the [[Networking_concepts#Socks_protocol|Socks protocol]]. At the client side of the tunnel a [[Networking_concepts#Socks_proxy|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 ==