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 I2P when enabled), and explicitly configuring all applications to use one of
these.

- [[!tails_gitweb config/chroot_local-includes/etc/ferm/ferm.conf]]
  (uses [ferm](http://ferm.foo-projects.org/) to build an `iptables`
  ruleset)

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.

#### I2P

[I2P](https://geti2p.net/) (*Invisible Internet Project*) is
yet another anonymizing network
(load-balanced unspoofable packet switching network) that provides
access to eepsites (.i2p tld); eepsites are a bit like Tor hidden
services. Some users would like to be able to access eepsites from
Tails.

Like the `debian-tor` user, the `i2psvc` user is allowed to connect
*directly* to the Internet. Any rules granting the `i2psvc` user access are only
applied if the user explicitly enables I2P at the boot prompt.  See
[[the design document dedicated to Tails use of I2P|I2P]] for details.

#### Unsafe Browser and the `clearnet` user

The `clearnet` user used to run the
[[contribute/design/Unsafe_Browser]] is granted full network access
(but no loopback access) in order to deal with captive portals.

#### I2P Browser and the `i2pbrowser` user

The [[contribute/design/I2P_Browser]] is run by the `i2pbrowser` user. This
account is granted access to ports 4444, 7657, and 7658 on the loopback device *if*
I2P is enabled at the boot prompt. Sites outside of I2P cannot be reached by
the `i2pbrowser` user.

#### 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:
[[!tails_gitweb 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.

- [[!tails_gitweb config/chroot_local-includes/etc/tor/torrc]]
- [[!tails_gitweb config/chroot_local-includes/etc/ferm/ferm.conf]]

#### 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 unless it's going through I2P,
which supports UDP.

An unfortunate consequence of fully blocking ICMP is that [[!wikipedia
Path MTU Discovery]] is broken. We workaround this problem by enabling
[[!rfc 4821 desc="Packetization Layer Path MTU Discovery"]].
For details, see:

* [[!tails_gitweb_commit 1d1c83d]]
* [[!tails_gitweb config/chroot_local-includes/etc/sysctl.d/pmtud.conf]]

#### `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.

#### netfilter's connection tracking helpers

We disable netfilter's automatic conntrack helper assignment
(`nf_conntrack_helper`), that would otherwise enable a lot of code in
the Linux kernel that
[parses incoming network packets, which seems potentially unsafe](https://home.regit.org/netfilter-en/secure-use-of-helpers/)
compared to the little gain it brings in the use case of Tails:

[[!tails_gitweb config/chroot_local-includes/etc/modprobe.d/no-conntrack-helper.conf]]
