How to build a Router that will only allow Tor users
Hi, I try to configure OpenWRT in a way that it will only allow outgoing connections if it is Tor. Basically it is the opposite of "blacklisting exit relays on servers": "whitelisting (guard) relays for clients". It should *not* run Tor itself. A first test setup (onionoo document, ipset and iptables) kind of worked. It's definitely doable, but not totally trivial in the end. What did *not* work, was starting Torbrowser. That's a hard requirement, and before bebugging it through I ask: Do I miss something when I just allow outgoing connections to * Guard, * Authority, * and HSDir flagged relays (do I *need* them? that's a different question probably) I don't restrict ports for now, even though I really should, and it's all only IPv4 addresses I care about for now, and I easily could just have OpenWRT configured wrongly, but: DNS is not an issue I think, what else could be? So far I only see Torbrowser talking to one Authority while starting. thanks martin
Am 2016-03-15 um 16:52 schrieb Martin Kepplinger:
Hi,
I try to configure OpenWRT in a way that it will only allow outgoing connections if it is Tor. Basically it is the opposite of "blacklisting exit relays on servers": "whitelisting (guard) relays for clients". It should *not* run Tor itself.
A first test setup (onionoo document, ipset and iptables) kind of worked. It's definitely doable, but not totally trivial in the end.
What did *not* work, was starting Torbrowser. That's a hard requirement, and before bebugging it through I ask: Do I miss something when I just allow outgoing connections to
* Guard, * Authority, * and HSDir flagged relays (do I *need* them? that's a different question probably)
I don't restrict ports for now, even though I really should, and it's all only IPv4 addresses I care about for now, and I easily could just have OpenWRT configured wrongly, but: DNS is not an issue I think, what else could be?
So far I only see Torbrowser talking to one Authority while starting.
thanks martin
When I start up Torbrowser on a full network, switch to my "onion router" while it's open, I *can* use it (and no other direct connection). There is something I miss about Torbrowsers startup. thanks martin
On 15 March 2016 at 10:52, Martin Kepplinger <martink@posteo.de> wrote:
Hi,
I try to configure OpenWRT in a way that it will only allow outgoing connections if it is Tor. Basically it is the opposite of "blacklisting exit relays on servers": "whitelisting (guard) relays for clients". It should *not* run Tor itself.
A first test setup (onionoo document, ipset and iptables) kind of worked. It's definitely doable, but not totally trivial in the end.
What did *not* work, was starting Torbrowser. That's a hard requirement, and before bebugging it through I ask: Do I miss something when I just allow outgoing connections to
* Guard, * Authority, * and HSDir flagged relays (do I *need* them? that's a different question probably)
Well it won't work with bridges obviously, including the hardcoded ones in TBB... -tom
Am 2016-03-15 um 18:10 schrieb Tom Ritter:
On 15 March 2016 at 10:52, Martin Kepplinger <martink@posteo.de> wrote:
Hi,
I try to configure OpenWRT in a way that it will only allow outgoing connections if it is Tor. Basically it is the opposite of "blacklisting exit relays on servers": "whitelisting (guard) relays for clients". It should *not* run Tor itself.
A first test setup (onionoo document, ipset and iptables) kind of worked. It's definitely doable, but not totally trivial in the end.
What did *not* work, was starting Torbrowser. That's a hard requirement, and before bebugging it through I ask: Do I miss something when I just allow outgoing connections to
* Guard, * Authority, * and HSDir flagged relays (do I *need* them? that's a different question probably)
Well it won't work with bridges obviously, including the hardcoded ones in TBB...
-tom
Yes, that's fine. Let's just ignore bridges too for a proof of concept ;)
Martin Kepplinger:
I try to configure OpenWRT in a way that it will only allow outgoing connections if it is Tor. Basically it is the opposite of "blacklisting exit relays on servers": "whitelisting (guard) relays for clients". It should *not* run Tor itself.
I actually implemented this while running Tor on the router. This provides easy retrieval and validation of the consensus. Before we go further, I think it's worthwhile to put a serious disclaimer: such a setup will only prevent accidental leaks and will not prevent targeted attacks. A determined attacker will be able to run a relay long enough and with sufficient bandwidth to become a Guard. It will then be trivial for them to recognize non-Tor packets coming at one of its port. I need to clean up my notes and turn them into a proper article for the upcoming Tor Labs. Meanwhile, here's what I have written down already: --- 8< --- ### First steps 1. Create a new Wi-Fi interface, mode Access Point. 2. Add Wi-Fi interface to new network named “filtered”. 3. Configure “filtered” to use a static address, and have a DHCP server. 4. Add “filtered” interface to new firewall zone named “filtered”. 5. Create a rule to allow input for DHCP (UDP port 67). ### Install tools Get Tor! # opkg install tor Is tor connected? # ls -l /var/lib/tor/cached-microdesc-consensus Get `ipset`: # opkg install ipset ### /usr/sbin/refresh-tor-guard-set Content: #!/bin/sh while true; do ipset -q create tor-guards hash:ip,port ipset -q create tor-guards-new hash:ip,port awk ' /^r / { cmd = "ipset -q add tor-guards-new " $6 "," $7 "\n"; cmd = cmd "ipset -q add tor-guards-new " $6 "," $8 } /^s / { if ($0 ~ /\<(Guard|Authority)\>/) { print cmd } } ' /var/lib/tor/cached-microdesc-consensus | sh ipset swap tor-guards-new tor-guards ipset destroy tor-guards-new sleep 3600 done Needs to be set executable: # chmod +x /usr/sbin/refresh-tor-guards-set ### /etc/init.d/refresh-tor-guards-set Content: #!/bin/sh /etc/rc.common START=50 STOP=50 USE_PROCD=1 start_service() { procd_open_instance procd_set_param respawn ${respawn_threshold:-3600} ${respawn_timeout:-5} ${respawn_retry:-5} procd_set_param stderr 1 # same for stderr procd_set_param command /usr/sbin/refresh-tor-guard-set procd_close_instance } Needs to be set executable: # chmod +x /etc/init.d/refresh-tor-guard-set Enable: # /etc/init.d/refresh-tor-guard-set enable # /etc/init.d/refresh-tor-guard-set start ### Extra firewall rule ``` config ipset option name tor-guards option external tor-guards option family ipv4 option storage hash list match 'dest_ip' list match 'dest_port' config rule option name Allow-Tor-Traffic-on-filtered option src filtered option dest wan option family ipv4 option proto tcp option ipset tor-guards option target ACCEPT ``` --- >8 --- I think I made a few adjustments to the above scripts after more tests since I took the above notes. Hope that helps, -- Lunar <lunar@torproject.org>
Hi Martin,
I try to configure OpenWRT in a way that it will only allow outgoing connections if it is Tor. Basically it is the opposite of "blacklisting exit relays on servers": "whitelisting (guard) relays for clients". It should *not* run Tor itself.
Maybe corridor would work for you: https://github.com/rustybird/corridor You could point it at a Tor control port somewhere in your network if running tor on OpenWRT (just to fetch the networkstatus consensus documents every 1-2 hours) is impossible.
What did *not* work, was starting Torbrowser. That's a hard requirement, and before bebugging it through I ask: Do I miss something when I just allow outgoing connections to
* Guard, * Authority,
But the authority IP addresses hardcoded in the Tor client source code differ from the authority IP addresses published in the networkstatus consensus... https://github.com/rustybird/corridor/commit/a56d751df399ab1c54f64b0d4dc59f7...
* and HSDir flagged relays (do I *need* them? that's a different question probably)
AFAICT, regular clients only make connections to authorities and guards. Rusty
Am 2016-03-15 um 19:07 schrieb Rusty Bird:
Hi Martin,
I try to configure OpenWRT in a way that it will only allow outgoing connections if it is Tor. Basically it is the opposite of "blacklisting exit relays on servers": "whitelisting (guard) relays for clients". It should *not* run Tor itself.
Maybe corridor would work for you: https://github.com/rustybird/corridor
You could point it at a Tor control port somewhere in your network if running tor on OpenWRT (just to fetch the networkstatus consensus documents every 1-2 hours) is impossible.
Thanks, I'll have a look at it!
What did *not* work, was starting Torbrowser. That's a hard requirement, and before bebugging it through I ask: Do I miss something when I just allow outgoing connections to
* Guard, * Authority,
But the authority IP addresses hardcoded in the Tor client source code differ from the authority IP addresses published in the networkstatus consensus...
https://github.com/rustybird/corridor/commit/a56d751df399ab1c54f64b0d4dc59f7...
* and HSDir flagged relays (do I *need* them? that's a different question probably)
AFAICT, regular clients only make connections to authorities and guards.
Rusty
On 16 Mar 2016, at 18:05, Martin Kepplinger <martink@posteo.de> wrote:
Am 2016-03-15 um 19:07 schrieb Rusty Bird:
What did *not* work, was starting Torbrowser. That's a hard requirement, and before bebugging it through I ask: Do I miss something when I just allow outgoing connections to
* Guard, * Authority,
But the authority IP addresses hardcoded in the Tor client source code differ from the authority IP addresses published in the networkstatus consensus...
https://github.com/rustybird/corridor/commit/a56d751df399ab1c54f64b0d4dc59f7... <https://github.com/rustybird/corridor/commit/a56d751df399ab1c54f64b0d4dc59f732dc0adc3>
Is this still an issue? Can you provide an example? The authority addresses are kept up to date in both the tor source code and the network consensus. If you're using an old version of tor, some of the addresses may be outdated. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Hi Tim,
But the authority IP addresses hardcoded in the Tor client source code differ from the authority IP addresses published in the networkstatus consensus...
https://github.com/rustybird/corridor/commit/a56d751df399ab1c54f64b0d4dc59f7...
Is this still an issue? Can you provide an example?
Sure: - moria1 (source 128.31.0.39 vs. consensus 128.31.0.34) - longclaw (source 199.254.238.52 vs. consensus 199.254.238.53) Rusty
On Sun, Mar 20, 2016 at 05:18:16PM +0000, Rusty Bird wrote:
- moria1 (source 128.31.0.39 vs. consensus 128.31.0.34) - longclaw (source 199.254.238.52 vs. consensus 199.254.238.53)
Yes, this is intentional. In the past, this approach has caused governments who tried to censor connections to the Tor network to miss these bootstrapping avenues. It's certainly not a robust trick, but it has few downsides, so I think it's reasonable to keep it in place. (It does, every so often, result in a confused researcher who thinks she has "blocked all the Tor relays", yet is surprised when Tor Browser bootstraps anyway. To me this presents a good opportunity to increase understanding of how censorship works and doesn't work.) --Roger
participants (6)
-
Lunar -
Martin Kepplinger -
Roger Dingledine -
Rusty Bird -
Tim Wilson-Brown - teor -
Tom Ritter