[tor-talk] Linux kernel transproxy packet leak (w/ repro case + workaround)

[Rusty Bird]

coderman:
> On Wed, Apr 2, 2014 at 10:59 AM, Rusty Bird <rustybird at openmailbox.org> wrote:
>> Maybe it can be boiled down to this: When redirecting *and* filtering,
>> the filtering should be done in OUTPUT (instead of INPUT), ...
> 
> this is where defense in depth at the multiple-virtual machine /
> routing layer fails safe in ways that a single / monolithic Tor setup
> cannot, when applied with care.
> 
> what i mean by "applied with care" is that forwarding through Tor only
> is the default.  Anything unexpected / unsupported gets the bit
> bucket.

Yeah, the machine doing the redirection better not have a default
gateway configured!

How about a 3 machine setup (Client -> Redirector -> Proxy):

- Client has Redirector configured as default gateway

- Redirector has no default gateway configured, it redirects suitable
traffic to Proxy. What remains (whether due to unsupported protocols,
policy decisions, or kernel bugs) has nowhere to go. This implicit
filtering also reduces the number of iptables rules.

- Proxy runs the tor daemon, has ip_forward=0 and an upstream gateway
configured as default.

So e.g. splitting Qubes' TorVM into a TorRedirectorVM and a TorProxyVM.
If I understand Qubes right, it is able to ensure that Client cannot
reach Proxy, and Client and Redirector cannot reach an upstream gateway.

Anyway, for legacy setups it's still an improvement to filter not in the
INPUT chain ("this traffic is (not) allowed because I am (not) going to
torify it") but in the OUTPUT chain ("this traffic is (not) allowed
because I have (not) torified it").

> the best target is actually TARPIT, not DROP, but that's
> another discussion...

TARPIT for outgoing connections, wha?

Rusty



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20140407/7253479d/attachment.sig>