One serious security issue is that we don't know what software will attempt to contact the network and whether their proxy settings are set up to use the Tor SOCKS proxy correctly. This is solved by blocking all outbound Internet traffic except Tor, and explicitly configuring all applications to use one of these.

The default case is to block all outbound network traffic; let us now document all exceptions and some clarifications to this rule.

Tor user

Tor itself obviously has to connect to the Internet without going through the Tor network. This is achieved by special-casing connections originating from the debian-tor Unix user.

clearnet user

The clearnet user is used to run tails-get-network-time.

It is granted full network access (but no loopback access). It most specifically needs to resolve hosts and to make an HTTP connection.

Unsafe Browser

The Unsafe Browser is run by the amnesia user, in the clearnet network namespace. This is not to be confused with the clearnet user.

The clearnet network namespace has full network access (UDP and TCP) but no loopback access.

Local Area Network (LAN)

Tails short description talks of sending through Tor outgoing connections to the Internet. Indeed: traffic to the local LAN (RFC1918 addresses) is wide open as well as the loopback traffic obviously.

LAN DNS queries are forbidden to protect against some attacks.

Local services whitelist

The Tails firewall uses a whitelist which only grants access to each local service to the users that actually need it. This blocks potential leaks due to misconfigurations or bugs, and deanonymization attacks by compromised processes. For specifics, see the firewall configuration where this is well commented: config/chroot local-includes/etc/ferm/ferm.conf

Automapped addresses

AutomapHostsOnResolve is enabled in Tor configuration, and a firewall rule transparently redirects to the Tor transparent proxy port the connections targeted at the 127.192.0.0/10 virtual mapped address space.

Only the amnesia user is granted access to the Tor transparent proxy port, so in practice only this user can use this hostname-to-address mapping facility.

IPv6

Tor does not support IPv6 yet so IPv6 communication is blocked.

UDP, ICMP and other non-TCP protocols

Tor only supports TCP. Non-TCP traffic to the Internet, such as UDP datagrams and ICMP packets, is dropped.

An unfortunate consequence of fully blocking ICMP is that Path MTU Discovery is broken. We workaround this problem by enabling Packetization Layer Path MTU Discovery. For details, see:

RELATED packets

As a general rule, the Tails' firewall does not accept RELATED packets: accepting them enables quite a lot of code in the kernel that we don't need, so we prefer reducing the attack surface a bit by blocking them. See the "[Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls" thread for details.

However, RELATED ICMP packets to the loopback interface are let through, in order to smooth user experience whenever a program's local network connection is blocked, and the TCP stack generates ICMP packets (e.g. with TYPE=3 CODE=3, i.e. the destination port is unreachable) to let the program know what is going on early, instead of letting it wait for a timeout.