You are not logged in.
I've had this issue for a while now. I have a work-around, but it's not very secure. When I try to run tor with iptables up, it gets stuck at 85% boot, at the point where it negotiates the connection with the first hop. Currently I just set up a script so that there is a ten-second delay after tor starts and before iptables kicks in, so tor has time to work uninhibited. However, that's a ten-second lapse in security, and I'd like to fix it so that iptables can start and tor can start from behind it. Any idea what's wrong?
Offline
What are your iptables rules?
Post the output of `iptables -nvL`
OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec
Offline
Here is the output of the command you gave me:
Chain INPUT (policy DROP 3 packets, 385 bytes)
pkts bytes target prot opt in out source destination
764 419K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 127.0.0.1 127.0.0.1
457 441K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 32 packets, 3524 bytes)
pkts bytes target prot opt in out source destination
398 367K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123
424 117K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 43
295 35272 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9040
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8Here is my iptables.rules file:
# Generated by iptables-save v1.4.15 on Fri Oct 12 16:33:33 2012
*nat
:PREROUTING ACCEPT [12:3420]
:INPUT ACCEPT [1:261]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
#-A OUTPUT -p tcp -m tcp -m owner ! --uid-owner polipo -j ACCEPT
-A OUTPUT -p tcp -m tcp -j REDIRECT --to-ports 9040
#-A OUTPUT -p tcp -m tcp -m owner ! --uid-owner polipo -j REDIRECT --to-ports 9040
#-A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 9053
COMMIT
# Completed on Fri Oct 12 16:33:33 2012
# Generated by iptables-save v1.4.15 on Fri Oct 12 16:33:33 2012
*filter
:INPUT DROP [9:1175]
:FORWARD ACCEPT [0:0]
:OUTPUT DROP [8:488]
# allow loopback
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -p all -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
# allow NTPD time syncs
-A OUTPUT -p udp --dport 123 -j ACCEPT
# allow tor
-A OUTPUT -p tcp -m owner --uid-owner tor -j ACCEPT
-A OUTPUT -p tcp --dport 9040 -j ACCEPT
-A OUTPUT -p udp --dport 53 -j ACCEPT
#-A OUTPUT -p tcp --dport 9001 -j ACCEPT
#-A OUTPUT -p tcp --dport 9030 -j ACCEPT
# allow pings
-A OUTPUT -p icmp --icmp-type 8 -j ACCEPT
# allow traffic on established connections
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
COMMIT
# Completed on Fri Oct 12 16:33:33 2012The commented-out lines under #allow tor were my attempt to get this issue solved... I opened those ports on TCP and then told tor to use only those ports for connection. With the firewall down, tor opened circuits just fine. But with the firewall up and those ports open, it still failed.
[EDIT]
I tried adding -m owner --uid-owner tor as a criteria for port 9040, and the command you gave me shows no data output. It seems to me that the first rule, allowing all tor connections originated by the tor user, should work behind a firewall without the need to open specific ports. However, this doesn't appear to be the case. Perhaps something is wrong with the way the system deals with that line?
Last edited by ParanoidAndroid (2013-03-06 18:42:16)
Offline
I see, you have a default drop policy for outbound traffic.
Do you not need to end the Output policy with accepting ctstate RELATED,ESTABLISHED if the default is to drop?
or end it with ACCEPT all
In any case, now open up wireshark and then start tor to see where it gets hung up. Then compare that with your iptables rules. You can also stop tor, bring up the firewall, start tor, and then view `iptables -nvL` to see which rule is dropping or not catching the packet.
Last edited by hunterthomson (2013-03-07 04:50:45)
OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec
Offline
It appears that tor is sending out traffic, but traffic is not getting back to it through the RELATED,ESTABLISHED rule if tor is started behind the firewall. If tor is brought online before the firewall, the rule handles the traffic perfectly.
Offline