[Tails-dev] Network policy exceptions

Üzenet törlése

Válasz az üzenetre
Szerző: William Waites
Dátum:  
Címzett: tails-dev
Tárgy: [Tails-dev] Network policy exceptions
Hello! I've starting using Tails since the 1.0 release and have a
little bit of feedback.

In network operations we have information that should be kept private,
things like keys and credentials but also some kinds of documentation.
The most commonly used tools on a workstation are basically ssh and a
web browser. So Tails looks like it is good for this use case, and
indeed so far it seems to be.

The main hiccough has to do with addressing, and I'd like to know if
there's a better way, or else just document what I'm doing on the list
archives.

There are some address ranges hard-coded in tails. The RFC1918 ranges
appear in the ssh config and the iptables rules at the very least. In
environments like mine, however, different ranges are used.
100.64.0.0/10 for example, the "carrier-grade" NAT prefix is used for
some parts of my infrastructure. Other parts are numbered out of our
CIDR blocks. If I am on my own network I do not want to wash local
traffic through tor, I want to treat it more or less the same way the
RFC1918 addresses are treated.

My first attempt at a workaround is a shell script called poke that
monkey-patches the firewall rules:

#!/bin/bash

  dst="$1"
  if test -z "$dst"; then
    echo "Usage: $0 <network>"
    exit 255
  fi


rfc1918=`iptables -n -L --line-numbers | awk '/192\.168\.0\.0\/16/ { print $1; }'`
iptables -I OUTPUT $(($rfc1918 + 1)) -d ${dst} -j lan

In other words makes an exception (-j lan) immediately after the entry
for 192.168.0.0/16. This doesn't seem to be exceptionally robust, but it
works. I just run it as

sudo poke 100.64.0.0/10

Is there a better way to do this?

Clearly I do not run this if I am away somewhere else. Incidentally if I
am away somewhere else, this is a good use for VPN software, since it is
not about trying to use a VPN for anonymity but rather for its proper
purpose. In any event it is easy enough to install, e.g. openvpn using
the live-additional-software.conf.

The monkey-patch is enough to have network level visibility but some
programs such as ssh and scp are being told at the application level to
use proxies when they shouldn't. This is done by hard coding the RFC1918
addresses in /etc/ssh/config. For what needs a web interface, the
unsafe web browser will work, but for ssh I have the following one-liner
scripts:

#!/bin/bash
exec ssh -o ProxyCommand=none $@

#!/bin/bash
exec scp -o ProxyCommand=none $@

which are called ussh and uscp respectively.

The usual purpose of the unsafe web browser is for captive portals on
wifi hotspots as I understand it, and I think it will fail without a
mechanism like the poke script if the operator of the access point uses
a different address range.

Perhaps it would be useful to automate this? When an interface receives
an IP address, to construct the firewall rules and ssh config from that
rather than having the hard-coded list? It still makes sense to have
the mechanism as a callable script for when the local domain extends
more than one hop out.

Would it make sense to have a knob in the advanced panel of the greeter
to enter networks that are to be exceptions? Maybe not since anyone who
wanted such a thing should be able to do it from the command line.

I have a few other thoughts about backing up the persistent volume and
mail reading but will save them for later to keep the Subject header
relevant.

All in all, quite impressed with Tails! Wonderful work!

-w