[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Tor as a network filter
On 11 Mar 2015 06:12, <spencerone@xxxxxxxxxxxxxxx> wrote:
>> For example, I have a VM running an MUA, it should only ever connect to
>> it's mailserver's over Tor. To enforce that, my router runs Tor and an
>> iptables rule ensures that all traffic from that VM leaves my network
>> Tor (there are some other concerns with doing it this way, but they
>> relevant for what I'm trying to say).
> Can you expand on this, the Tor on a router part? Others have said,
in response to an out of the box product you can by, that running Tor on
a physical router is not so safe, though this is maybe where your iptables
rule comes in.
The advice given in that thread is correct - but it relates primarily to
Web browsing, and makes a few assumptions about user behaviour (wise
assumptions IMO though).
For the setup I described above, the traffic being carried is SMTP/IMAP so
I don't need to worry about tokens being exposed in quite the same way. I
can also guarantee that traffic from that VM will never leave my network
over anything but Tor (the edge firewall will drop it's traffic).
In theory, you could use an edge firewall to afford similar protection for
web browsing, though it would still leave a few risks, even assuming the
access device you were using was something that was only ever on that
network (i.e. a desktop not a laptop).
Similarly, if you were doing it all in one box (i.e. browser and Tor client
are all on the same system) you could, potentially achieve a similar
fail-safe environment, but it's by no means guaranteed.
Pushing to Tor at the network level helps against things like badly behaved
plugins that ignore proxy settings (though you shouldn't really be using
them anyway), but does carry it's own set of risks, some of which are well
described in that thread.
Because no specific config is needed at the browser, it allows you to use
your 'everyday' browser, so the cookies you pick up whilst browsing will be
sometimes be sent in the clear, and sometimes over Tor - that's obviously
Also, depending on your config, anything running on your machine will also
be routed over Tor. If any of those send credentials that can be tied back
to you (e.g. credentials for a backup server in your name) then you've got
You _could_ try to work around it by selectively routing over Tor, but then
you've just opened a nice wide vector for information leakage.
With my mail VM, I have specific ports and destination IPs that it can talk
to. Everything else is denied, so it should be fairly safe, but it is
>> There's no technical reason I (or, you) couldn't add a rule to first push
>> that traffic through some sort of (semi)transparent proxy so that
>> can be performed at application level.
> How much control do you then have over the traffic? Can you shape how
you appear, ignoring the risk of standing out? How would you interface
with the traffic?
It'd obviously depend on exactly what you were wanting to do, but as a
basic example, you could for example push HTTP traffic through a Squid
install first so that you can perform specific actions based on the HOST
header, or perhaps the content-type in the response (perhaps to block ads?).
If you're talking about doing it for an entire network, it'd also allow you
to cache specific resources.
All of the above could make your traffic stand out, of course, but it's
technically feasible. In effect, what you'd be doing is creating a proxy on
the network (transparent or otherwise) and configuring it to use Tor for
its upstream connection (though if you're doing it at the firewall level,
Squid would never see such a config).
>> But I am more asking if Tor can be used as part of a filter, with some
>> sort of application allowing for more control, maybe even of what is sent
>> to the entry.
You could achieve that with what I described above, whether or not it's a
good idea would depend largely on why you're using Tor - what are the
consequences if you make a mistake in the setup? If you're simply trying to
prevent your ISP from seeing where you're connecting to, it's potentially
less risky than if your activities might cause LEA(s) to kick down your
Using TBB with it's default settings is a fairly simplistic configuration,
and thanks to the developers behind it, there's not too much that should go
wrong on the average deployment.
Every additional step you insert introduces an opportunity for you to make
mistakes (even if that's as simple a not thinking of a specific type of
traffic), so you need to carefully design your setup and do a cost/benefit
on the changes.
I experiment with Tor quite a lot, and, on the average day a good
proportion of the traffic leaving my network via Tor is probably me testing
something 'harmless' to see if I can catch myself out. Once I'm happy that
a technique works, it'll get used for something I'm more sensitive about.
One thing I would say - you have to consider failure scenarios very
carefully. If Tor silently fails on your router, what will happen with new
connections? Will they fail (you probably want this) or will they be routed
out in the clear (leaving you non-the-wiser).
All that said - If I was doing something really sensitive, or with serious
real world implications, I'd be using the simplest solution possible (i.e.
TBB) to minimise the potential for mistakes on my part.
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to