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

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

Hmm

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.

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...