LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 01-13-2018, 03:27 PM   #1
Nonetas
LQ Newbie
 
Registered: Jan 2018
Posts: 8

Rep: Reputation: Disabled
Tor Browser Bundle/Tor and IPTables: Solution Needed


I am trying to set a policy for iptables for Tor and particularly Tor Browser Bundle, something apparently rare, judging from searches online which have never found me an iptable setup for TBB and whose complete default ports (socks, control, trans and DNS) are unmentioned. Many iptables configurations associated with Tor are complicated, mostly in the name of transproxying, here a secondary concern. Typical desktop Tor policies are unsuitable for adaptation.

My concern is to run TBB with a tighter environment with minimal rule set by specifying it exclusively in iptables, something I have only found possible by specifying tor ports (and which should be possible anyway), to isolate DNS to TBB, and to make sure the connection is maintained without compromising isolation (ie. avoiding DNS leaks) and minimal additional packet transit. This is more of a challenge given mobile usage.


So far I have been able to specify TBB's ports and DNS in its torrc file, after a few attempts at watching respecified defaults apparently break TBB's operation altogether (reassigned port numbers did not, a quirk): TBB will now start with my specified ports without complaint.

A basic iptables policy, shown here, consists of minimal NAT rules for mapping DNS to the tor DNS port and dumping UDP to port 9, (discard according to /etc/services) a filter RELATED ESTABLISHED rule and the three outgoing ports for Tor itself (the loopback allow and icmp/igmp blocks are disposable details, as far as I know, but shown). I am unclear as to whether Tor's assigned DNS port must be specified (other than the NAT redirect) - I have seen this done, but given the inability to otherwise isolate TBB (such as by UID), would have thought it a leak risk. According to what little info I have been able to find, Tor routes DNS through the onion routing and performs DNS at the end of its exit node: but does it's own DNS port need to be open in filter rules?

As can be seen in the -nvL readout, the Tor ports themselves show no packets outgoing, and after loopback all packets are dumped in a final DROP policy added at the end of filter rules.

My initial assumption was that, in the absence of seperate DNS and DHCP allows, the connection is merely dying. If I switch back to a clearnet policy with DNS and DHCP allowed in filter, the connection must be restarted to regain access to the net at all, suggesting this. In addition, if I -nvL the clearnet policy, DNS and DHCP ports can be seen to transit no data, all of which must be going through the general all-protocol allow, rendering DNS and DHCP meaningless for most public connections. This is problematic in general in mobile contexts where it is valuable to be able to control (or repossess) DNS lookups from ISPs, captive portals, etc.
Tor's own logs typically show it successfully listening on allocated ports, and a 'general socks server failure' (though it is also unclear to me how Tor can get this far at all if no packets are being shifted by socks, control and transports).

I have tried including UDP in the NAT table DNS redirect (no change), allowing DHCP in INPUT and OUTPUT filter rules (no change), and including the assigned Tor DNS port (here 5353) in OUTPUT filter rules (no change). If a standard clearnet policy is restored, TBB will run successfully and quickly resolve the net, indicating that the problem is definitely being caused by iptables.



TBB IPTables Policy
----------------------------------------------------------------------

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [4:240]
-A OUTPUT -p udp -m udp --dport 53 -j REDIRECT --to-ports 9
-A OUTPUT -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 5353
COMMIT

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p igmp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -i wlan0 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -i wlan0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o wlan0 -p tcp -m tcp --sport 9251 -j ACCEPT
-A OUTPUT -o wlan0 -p tcp -m tcp --sport 9250 -j ACCEPT
-A OUTPUT -o wlan0 -p tcp -m tcp --sport 9240 -j ACCEPT
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT


IPTables Output (-nvL)
----------------------------------------------------------------------

Chain INPUT (policy DROP 8 packets, 798 bytes)
pkts bytes target prot opt in out source destination
9514 534K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT icmp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT 2 -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
2 181 ACCEPT all -- wlan0 * 0.0.0.0/0 0.0.0.0/0 ctstate NEW
0 0 ACCEPT all -- wlan0 * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
9514 534K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * wlan0 0.0.0.0/0 0.0.0.0/0 tcp spt:9251
0 0 ACCEPT tcp -- * wlan0 0.0.0.0/0 0.0.0.0/0 tcp spt:9250
0 0 ACCEPT tcp -- * wlan0 0.0.0.0/0 0.0.0.0/0 tcp spt:9240
35 2300 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
 
Old 01-27-2018, 06:11 PM   #2
LQSlacker
Member
 
Registered: Jul 2016
Posts: 94

Rep: Reputation: Disabled
In Plain English what's the point to all this, what are you trying to accomplish by having rules specfic to Tor?

Hmm
 
Old 02-03-2018, 08:19 AM   #3
Nonetas
LQ Newbie
 
Registered: Jan 2018
Posts: 8

Original Poster
Rep: Reputation: Disabled
To harden Tor, obviously, with an exclusive policy (while retaining router connection) able to isolate TBB. It seems the best policy might be to get the tor service (package) configured in init.d/tor and tor-defaults to point at the TBB binary and transports. This would gain the benefit of the tor daemon and native UID, but the advantages of the TBB and its extensive transports provision.
I have never seen TBB itself isolated in any way, being just a 'portable' Firefox running a proxy. But TBB is actually way better than distro package tor.
 
Old 03-01-2018, 11:27 PM   #4
LQSlacker
Member
 
Registered: Jul 2016
Posts: 94

Rep: Reputation: Disabled
I think you're going to a lot of trouble for nothing...

Look at Hardening the OS instead, and running Tor through a VPN and you'll be secure enough...

And if you're really paranoid, hop through a few VPN servers and Tor...
 
  


Reply

Tags
iptables, tbb, tor


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Tor Browser Bundle/Tor and IPTables: Working Solution Sought Nonetas Linux - Security 1 01-14-2018 06:23 PM
Tor Browser Bundle and Thunderbird Mail biff Linux - Newbie 2 10-20-2013 02:45 PM
Tor Bundle Browser stubborn Linux - Software 2 08-20-2013 05:33 PM
LXer: Tor Browser Bundle-Tor Goes Portable LXer Syndicated Linux News 1 09-02-2011 02:29 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 09:49 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration