Revision as of 20:10, 10 August 2015 (view source) Lilith2 (Talk | contribs) m (→‎Publishing with freenet) ← Older edit		Revision as of 20:15, 10 August 2015 (view source) Lilith2 (Talk | contribs) m (→‎Browser bundle) Newer edit →
Line 224:		Line 224:
	=== Browser bundle ===		=== Browser bundle ===
		+
		+	The Firefox-based Tor Browser Bundle integrates the Tor network's enhanced privacy and security. It includes the Vidalia network connection utility. It's installation is easy and it works out of the box. https://www.torproject.org/projects/torbrowser.html.en
	=== Tor ===		=== Tor ===

---

Revision as of 20:15, 10 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 tunneling 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

OpenVPN is free and open source software originally released in 2002. Since then it has become quite popular in the ease it can traverse wireless access points, firewalls, NAT-based routers, and HTTP proxy servers. By using OpenVPN it is possible to use different ports in order to bypass both firewalls and throttling. For more on OpenVPN and other options see networking concepts: VPN.

Working with OpenVPN you will have the ability to work with OpenWRT or DD-WRT and run your local network on a single VPN account. In order to do this you will need to have an OpenVPN account, as well as a router that can be flashed, preferably OpenWRT.

Routed vs bridged VPN

Choose bridging only when:

• the VPN needs to be able to handle non-IP protocols such as IPX
• you are running applications over the VPN which rely on network broadcasts (such as LAN games)
• avoiding setting up a Samba or WINS server for m$ file sharing across the VPN. Better yet, just get rid of the m$ files and machines.

Installing OpenVPN client

If you are using a debian-based distro, you can use a package manager such as apt-get:

$ sudo apt-get install openvpn

It is also possible to install openvpn using the universal ./configure method. First expand the .tar.gz file:

$ tar xfz openvpn-[version].tar.gz

Then cd to the top-level directory, configure and install:

$ sudo ./configure
$ sudo make
$ make install

You can either use the VPN server you set up yourself, or an existing service. Several autonomous collectives offer services for activists. For bitmask see below. Set it up as described.

Connection failures and DNS leaks

If you simply add a VPN using common instructions, it generally fails open. That means, if the VPN breaks down, because the connection is interrupted, traffic will be sent without the VPN. It's much safer when it fails closed, i.e. when the VPN connection breaks down, the whole internet connection must be down as long as the VPN connection isn't restored.

In addition to VPN connection failures, the other big threat to your anonymity when using a trusted VPN service is that of DNS leaks, which can result in your ISP being able to ‘see’ and monitor your online activity even though you think you are safely protected by an encrypted VPN tunnel.

Using wireshark to check for leaks

This is an example in a debian virtualbox VM, but is also valid in general for other setups.

Virtual machines receive their 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.

If you haven't installed wireshark yet, see linux security: wireshark for installing and basic usage.

To check if you have DNS leaks, fire up wireshark:

• 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

Resolver libraries look to /etc/resolv.conf for a list of nameservers. In the simplest case, that is the file to edit to set the list of name servers. And various other programs for dynamic configuration will be happy to overwrite your settings:

• The resolvconf program
• The network-manager daemon
• DHCP clients

In most situations, the file to edit is the configuration file for such a program.

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.nnn.nnn
nameserver nnn.nnn.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.

Punching holes in ufw for a VPN

To forcibly prevent DNS leaks use a firewall. ufw can be set up as a fail safe mechanism (aka kill switch).

Install ufw if not already installed.

Set all traffic to deny:

$ sudo ufw default deny outgoing
$ sudo ufw default deny incoming

Permit OpenVPN traffic (if using OpenVPN adapter is probably tun0 but check)

$ sudo ufw allow out on tun0 from any to any 

For added security you may want to keep incoming traffic disabled but if desired or required then allow it:

$ sudo ufw allow in on tun0 from any to any

With this rule all non VPN traffic (and subsequently DNS requests not routed though VPN) will be blocked.

But, this set up currently requires that you disable the firewall to connect to the VPN and then enable it once connection is made. To allow establishment of a connection to the VPN server even when firewall is enabled:

$ sudo ufw allow out from any to [VPN server IP address]

Add multiple rules for all VPN servers you will be using. If you want more strict rules and better security then only allow desired ports on tun0.

Using the VPNfirewall script

The VPNfirewall script by Adrelanos:

• Forbids outgoing traffic after the VPN software broke down for some reason.
• Has tight firewall rules, using iptables policy drop.
• Only tested with OpenVPN. Should work with other VPN clients such as PPTP in theory, you should test if it does what it claims anyway.
• Only tested on Debian Wheezy and Whonix. Should work on any other Linux distribution in theory, you should test if it does what it claims.
• Open Source / Free Software

More here, including how to install it: https://github.com/adrelanos/VPN-Firewall

Bitmask

Bitmask is an open source application to provide easy and secure encrypted communication. You can choose among several different service providers or start your own. Currently, Bitmask supports encrypted internet (VPN) with encrypted email coming soon. https://bitmask.net/

Publishing with freenet

Freenet uses UDP and is the "oldest" of the 3 networks. Freenet is an anonymous data publishing network and very different from Tor and I2P. Freenet is much higher latency and focuses more on friend to friend interactions with often military grade security. It is slow and very resource intensive.

Freenet is a tool for bypassing totalitarian censorship where people would be killed for publishing certain content. It is not for casual browsing. https://freenetproject.org/

Proxying with tor

Tor is an anonymous internet proxy using onion routing. In an onion network, messages are encapsulated in layers of encryption, analogous to layers of the vegetable onion. The encrypted data is transmitted through a series of network nodes called onion routers, each of which "peels" away a single layer, uncovering the data's next destination. When the final layer is decrypted, the message arrives at its destination. The sender is thought to remain anonymous because each intermediary knows only the location of the immediately preceding and following nodes. Connections with Tor aren't dynamic like I2P tunnels are, Tor circuits persist until closed. This can reduce anonymity. There is no support for UDP.

The best use for Tor is anonymous proxying to the regular internet. It is the most sophisticated and robust system for proxying currently devised. And despite Tor being a powerful tool, it is possible to distinguish Tor traffic from normal traffic, and it is possible to perform correlation-based attacks to de-anonymise our use of it.

Browser bundle

The Firefox-based Tor Browser Bundle integrates the Tor network's enhanced privacy and security. It includes the Vidalia network connection utility. It's installation is easy and it works out of the box. https://www.torproject.org/projects/torbrowser.html.en

Tor

Liberté linux, tails, whonix, freepto

Note for Liberté linux: See making your own LiveCD/DVD images.

Chaining

Going underground with i2p

I2P is a Distributed Peer to Peer Anonymous Network Layer that is strictly message-based (like IP), but there is a library available to allow reliable streaming communication on top of it (similar to TCP, although from version 0.6 there is a new UDP-based SSU transport). It allows you to send data between computers running I2P anonymously with multilayer end to end encryption. The name I2P derived from Invisible IRC Project (IIP) which was one of FreeNet's sister projects. I2P focuses on exclusively internal communication and not proxying to the regular internet. I2P uses garlic routing which involves clumping packets together into bigger packets. The combination of garlic routing, multilayer encryption -even the end points ("destinations") are cryptographic identifiers- and random padding on packets makes analysis of the content and detection of the origin of I2P traffic by third-party observers highly impractical if not nearly impossible.

The best use for I2P is for peer to peer file sharing and a replacement for the regular internet in the event that it gets bad enough to warrant such action.

Related

• Networking concepts
• Encrypting everything

References

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