Re: tor bandwith ratio
gabrix [EMAIL PROTECTED] wrote: I'm sorry if recently my tor node argo666tor wasn't always up ... but i'm sort of experimenting how much bandwith i have to allocate to the tor network.My will is to give as much band as possible without slowing down my connection.I'm trying with this 4 rules: AccountingStart day 12:00 AccountingMax 600MB #BandwidthRate 100 KB #BandwidthBurst 200 KB But i seriously don't know witch one is best considering i have a TIM adsl flat! Maybe using queues for prioritising empty ACKs would already be good enough: http://www.benzedrine.cx/ackpri.html It's PF and ALTQ specific, but the same can be done with other packet filters. Additionally you could give all Tor traffic a lower priority, I think it would be a better solution than to set a hard bandwidth limit in Tor, which most of the time would limit your server more than necessary. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: tor bandwith ratio
Fabian Keil wrote: gabrix [EMAIL PROTECTED] wrote: I'm sorry if recently my tor node argo666tor wasn't always up ... but i'm sort of experimenting how much bandwith i have to allocate to the tor network.My will is to give as much band as possible without slowing down my connection.I'm trying with this 4 rules: AccountingStart day 12:00 AccountingMax 600MB #BandwidthRate 100 KB #BandwidthBurst 200 KB But i seriously don't know witch one is best considering i have a TIM adsl flat! Maybe using queues for prioritising empty ACKs would already be good enough: http://www.benzedrine.cx/ackpri.html It's PF and ALTQ specific, but the same can be done with other packet filters. Additionally you could give all Tor traffic a lower priority, I think it would be a better solution than to set a hard bandwidth limit in Tor, which most of the time would limit your server more than necessary. Fabian I have this in my iptables script: # TOR iptables -t mangle -A PREROUTING -p tcp -m tcp --dport 9090 -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -p tcp -m tcp --dport 9090 -j RETURN iptables -t mangle -A PREROUTING -p tcp -m tcp --dport 9091 -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -p tcp -m tcp --dport 9091 -j RETURN as 2 tor has a high priority,now is on 5 . An another question is :if i announce port 110 and redirect traffic to 9090 which port shall i consider as priority in the above iptables ? Silly question isn't ?
Re: tor bandwith ratio
On Fri, Oct 13, 2006 at 02:45:39PM +0200, gabrix wrote: I have this in my iptables script: # TOR iptables -t mangle -A PREROUTING -p tcp -m tcp --dport 9090 -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -p tcp -m tcp --dport 9090 -j RETURN iptables -t mangle -A PREROUTING -p tcp -m tcp --dport 9091 -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -p tcp -m tcp --dport 9091 -j RETURN as 2 tor has a high priority,now is on 5 . Uhhh... What is that supposed to do? I only see that you mark the traffic, then immediately leaving the chain. Only marking them doesn't do anything. You usually mark the traffic if you want to handle it differently later, either with the mark-match inside iptables again, via the fwmark-option in iproute2 or tc. An another question is :if i announce port 110 and redirect traffic to 9090 which port shall i consider as priority in the above iptables ? Silly question isn't ? If you're going to redirect the traffic you won't acchieve anything - you need to consider the way the packets traverse through the indiviudal chains inside the Netfilter framework. 1) Packet enters machine 2) Packet enters mangle-table, PREROUTING chain (you may MARK here) 3) Packet enters nat-table, PREROUTING chain (DNAT/redirection happens here) 4) Packet enters Linux routing-code (tc and iproute2 use fwmark here) (*) 5) Packet enters filter-table, FORWARD chain (usual filtering-rules) 6) Packet enters mangle-table, POSTROUING chain (do some stuff) 7) Packet enters nat-table, POSTROUTING chain (SNAT and MASQUERADE) Coming back to your question: Since redirecting happens in step 3 you already missed the point where the packet got marked. Therefore: No, that won't happen. You'd need to mark the packet in the PREROUTING chain of the mangle-table onto port 110, and THEN redirecting it. That's the way it work with the Netfilter stuff. Where and how are you actually accessing the packets you've marked with MARK previously? I repeat: Only MARKing does nothing. It just puts a label on the packet to identify the packets in other parts of the kernel. Alex. (*) I'm not sure where tc integrates itself; but i think that happens in the routing-code. Please correct me if I'm wrong. However, that doesn't help you with your MARK and DNAT problem. -- I am tired of all this sort of thing called science here... We have spent millions in that sort of thing for the last few years, and it is time it should be stopped. -- Simon Cameron, U.S. Senator, on the Smithsonian Institute, 1901. signature.asc Description: Digital signature
Re: tor bandwith ratio
Kelly Byrd wrote:
I have had this exact same question for my server. It's running on an
ADSL line, 443 on the OR port, 80 for the Dir port (iptables redirects to
9001 and 9030) and I notice MUCH more bandwidth usage when I turn on the
dir port. Without the dir port, I barely notice tor slowing down my
regular usage. With it, I often want to turn off tor to do anything
interesting on the net.
I've been using the burst and mac bandwidth settings, but I think
prioritizing might be the better way to go. Any good simple references
for ip tables?
Another thought I had: Does opening up port 80 create problems all by
itself? I'm imagining non-tor users simply going to 80 and doing GET /
and slurping the results from my tor server, but not really wanting it.
As also the /etc/tor/torrc file says you can advertise a privileged port
, clients see you listening on that port but in facts binding to an
unprivileged one and the syn packet get redirected by iptables to
it.What confused me was an iptables i gave at the end of all rules ,a
catch all ulog jump and i saw 'some' syn packets hitting the advertising
port passing through all chains and not being redirected to the port
where tor was really binding and than get dropped by my iptables,so in
some way , some times,also the advertised port get involved ?Anyway this
is a script i googled around that i modified it and using it.It's just
from a little i'm into the 'mangle' ,looks like it works i will update
you soon and wait eventual corrections some parts are a bit obscures to
me
#
UPLINK_SPEED=688
#UPLINK_SPEED=688
INET_DEV=eth0
DOWNLINK_THROTTLE=Y# Set to 'Y' if you want to anable downlink
throttle
DOWNLINK_SPEED=3000
if [ $1 = status ]
then
tc -s qdisc ls dev $INET_DEV
tc -s class ls dev $INET_DEV
exit
fi
# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $INET_DEV root2 /dev/null /dev/null
tc qdisc del dev $INET_DEV ingress 2 /dev/null /dev/null
iptables -F -t mangle
if [ $1 = stop ]
then
exit
fi
#
# qdiscs, classes and filters
# add HTB root qdisc
tc qdisc add dev $INET_DEV root handle 1: htb default 14
tc class add dev $INET_DEV parent 1: classid 1:1 htb rate
${UPLINK_SPEED}kbit ceil ${UPLINK_SPEED}kbit
tc class add dev $INET_DEV parent 1:1 classid 1:10 htb rate
$[$UPLINK_SPEED/100*20]kbit ceil $[$UPLINK_SPEED]kbit prio 0
tc class add dev $INET_DEV parent 1:1 classid 1:11 htb rate
$[$UPLINK_SPEED/100*15]kbit ceil $[$UPLINK_SPEED]kbit prio 1
tc class add dev $INET_DEV parent 1:1 classid 1:12 htb rate
$[$UPLINK_SPEED/100*15]kbit ceil $[$UPLINK_SPEED]kbit prio 2
tc class add dev $INET_DEV parent 1:1 classid 1:13 htb rate
$[$UPLINK_SPEED/100*30]kbit ceil $[$UPLINK_SPEED]kbit prio 4
tc class add dev $INET_DEV parent 1:1 classid 1:14 htb rate
$[$UPLINK_SPEED/100*20]kbit ceil $[$UPLINK_SPEED]kbit prio 5
tc qdisc add dev $INET_DEV parent 1:10 handle 100: sfq perturb 10
tc qdisc add dev $INET_DEV parent 1:11 handle 110: sfq perturb 10
tc qdisc add dev $INET_DEV parent 1:12 handle 120: sfq perturb 10
tc qdisc add dev $INET_DEV parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev $INET_DEV parent 1:14 handle 140: sfq perturb 10
# filters
tc filter add dev $INET_DEV parent 1:0 protocol ip prio 1 handle 1 fw
classid 1:10
tc filter add dev $INET_DEV parent 1:0 protocol ip prio 2 handle 2 fw
classid 1:11
tc filter add dev $INET_DEV parent 1:0 protocol ip prio 3 handle 3 fw
classid 1:12
tc filter add dev $INET_DEV parent 1:0 protocol ip prio 4 handle 4 fw
classid 1:13
tc filter add dev $INET_DEV parent 1:0 protocol ip prio 5 handle 5 fw
classid 1:14
#
#
#classid 1:10 htb rate $[$UPLINK_SPEED/5]kbit ceil
$[$UPLINK_SPEED]kbit prio 0 [mark 1]
#This is the higher priority class. The packets in this class will
have the lowest delay
#and would get the excess of bandwith first so it's a good idea to
limit the ceil rate to
#this class. We will send through this class the following packets
that benefit from low
#delay, such as interactive traffic: ssh, telnet, dns, quake3,
irc, and packets with the
#SYN flag.
#
# classid 1:11 htb rate $[$UPLINK_SPEED/5]kbit ceil
$[$UPLINK_SPEED]kbit prio 1 [mark 2]
#Here we have the first class in which we can start to put bulk
traffic. In my example I have
#traffic from the local web server and requests for web pages:
source port 80, and destination
#port 80 respectively.
#
# classid 1:12 htb rate $[$UPLINK_SPEED/5]kbit ceil
$[9*$UPLINK_SPEED/10]kbit prio 2 [mark 3]
#In this class I will put traffic with Maximize-Throughput TOS bit
set and the rest of the
#traffic that goes from local processes on the router to the
Internet. So the following
#classes will only have traffic that is routed
Snakes On A Tor Scanner - 0.0.3
Over the past month or so I've been testing and improving my Tor network scanner, and it seems to be shaping up pretty nicely. http://fscked.org/proj/minihax/SnakesOnATor/SnakesOnATor-0.0.3.zip As a quick refresher, the scanner consists of two parts: The Metatroller: A Tor Controller that allows you to customize properties of your Tor routes. You can control path length, exit country, fast node cutoff, and lots of other neat things. Snakes On A Tor: A Scanner that uses the Metatroller to scan the network for nodes that are unstable and/or modifying exit traffic. Docs are now obtained randomly from google queries. Metatroller will work in ActivePerl on Windows without any other dependencies, however SOAT will require curl, md5sum, and openssl. I think SOAT and Metatroller are in good enough shape that they should make for good QA tools for Tor to help reduce circuit failure, and also useful tools for people who would like to monitor the Tor network. I'm also suspicious of the 7/8 node cutoff for fast nodes. I think that perhaps it should be raised to 65% or so, but I have no hard data as of yet to illustrate this cutoff point. Since adoption is critical to anonymity, and regular people won't use Tor if they think it is slow, I believe it is far more imporant that we have known reliable, fast nodes than lots of slow ones that are prone to dropping circuits. Hopefully we can discover these cutoffs using this tool. Here's the CHANGELOG for 0.0.3: Metatroller: - Now gets its node list directly from Tor using the control port - Implemented guard nodes - Added circuit/stream failure statistics - Improved reliability/recovery from circuit and stream failures - All commands can now take no arguments to print current value Soat: - obtains its doc list via google filetype queries - verifies this list contains no dynamic content - Saves long-term aggregate failure stats from metatroller I've given Roger and Nick some patches to expose circuit failure reason codes to the controller. I think part of these made it into 0.1.2.2-alpha, and hopefully the rest will be in 0.1.2.3. Metatroller does not need these reason codes to record failures, but it is more accurate if they are present. Here's the current list of Metatroller commands: 214 COUNTRY CC|ALL 214 - Pick a two letter country code to select exits from, or ALL 214 COUNTRIES 214 - List countries that have tor exits 214 PERCENTFAST # 214 - What % of the network is considered 'fast' for node selection 214 BWCUTOFF # 214 - Minimum observed bandwidth (KB) that a node must have to be selected 214 UNIFORM 1|0 214 - Should selection among fast nodes be uniform (or bandwidth-biased)? 214 ORDEREXITS 1|0 214 - Should exits be chosen one after another instead of randomly? 214 FASTEXITS 1|0 214 - Should exits be chosen from 'fast' nodes or all nodes? 214 GUARDNODES 1|0 214 - Use guard nodes? 214 PATHLEN # 214 - What should the path length of circuits be? 214 NEWEXIT 214 - Throw away all circuits and choose a new exit 214 SETEXIT NAME 214 - Hardcode an exit for all future circuits 214 GETLASTEXIT 214 - Lists the last used exit 214 FAILRATES 214 - Print out the failure rates of nodes While it is still not advisable for you to use SOAT on a machine you wish to preserve your anonymity with, Metatroller is perhaps not as dangerous as I thought. I've looked into the Tor source, and it turns out that in some cases Tor does make circuits out of low-uptime nodes. With that, and the addition of Guard Nodes to Metatroller, it is perhaps not nearly as dangerous as I had originally thought. The main dangers revolve around PATHLEN and PERCENTFAST, and are explained in the README. I believe normal usage should be comparable to Tor in safety at this point, though there are a couple of attractive fixes in 0.1.2.x I would like to adopt. Plans for the future include more finer-grained failure statistics, node max/min/avg bandwidth stats, and possible integration with the directory servers to help avoid unstable/malicious nodes (or at the very least, an internally saved blacklist for high failure-rate nodes). Also, the metatroller currently does not subscribe to router info or (non-existent) network status events, so it should be restarted periodically. When network-status events are available in 0.1.2.x I'll support them. -- Mike Perry Mad Computer Scientist fscked.org evil labs
