- tor-relays - lists.torproject.org

Relay behind VPN router
by Jochen 20 Oct '13

20 Oct '13

I have a TOR relay behind a Tomato router on an ADSL line. I activated the vpn client to route all traffic through privateinternetaccess.com. Because a TOR relay does not work behind NAT without port forwarding, I'm looking for a way how to route tor traffic directly to my internet provider. I can add static routes, but I don't now the IPs in advance. Maybe there is no problem to route outgoing traffic through the vpn tunnel, but how can I make my relay publish my WAN IP instead of the tunnel IP? My WAN IP is changing every day, so I cannot configure it as static. -- Mit besten Grüßen Jochen Fahrner

3 6

port 9001 udp
by zwiebel＠quantentunnel.de 19 Oct '13

19 Oct '13

Hi relay-tives! It's my first post here, so please can someone help me with my question Why do I have to open 9001 UDP at the DSL router firewall and not necessarily in iptables? Is it something specific on my side or does someone has an explanation? The OR service seems to work. Ok - I see nearly no traffic may-be because of my small bandwidth. See some information about my system Setup PC (P4 2GB noHDD) with USB-LAN adapter (eth2) connected to DSL router (NAT & firewall) Tails 0.20.1 on SD card with USB adapter write protected Server IP x.x.x.33 received from the DHCP DSL router Goal Run PC as OR relay non exit Run OR service Dont run DIR service DSL router setting Open DSL router firewall IP x.x.x.33 TCP 9001 for OR Open DSL router firewall IP x.x.x.33 UDP 9001 for OR <= IS THE POINT Done to tails manually each time the PC turns on (amnesia!): Root terminal (password) and "/sbin/iptables -A INPUT -i eth2 -p tcp --dport 9001 -j ACCEPT" The the only change to original tails iptables list is the added rule Done to Vidalia: relay-non-exit, nickname, email, port=9001, bandwidth limits typ 20kByte/s and max 25kByte/s The log messages tell me success and all runs for a week. Thanks front-up Zwiebel _||_ / \ / O O \ \ ____ / \\__//

2 1

Re: [tor-relays] minimum ram
by Eduard 19 Oct '13

19 Oct '13

I could say that this is true. I run a relay on my desktop, and I see that after 5-7h the ram ussage increase. Even on a 16GB system, the increase is detectable. Sent from my Orange Smartphone Moritz Bartl <moritz(a)torservers.net> wrote: >On 2013-10-19 03:50, I wrote: >> Is there any utility in the very cheap VPSs with 128mb of ram? > >I did some testing quite a while ago and found that 256MB was the >minimum amount of RAM for a relay. It works for some time with >128MB, but it then runs out of memory, and it is not very good >to have it restart all the time. > >I say "was" because currently, with more than 3 million clients >in the network, a relay might even run out of memory with 256MB >RAM. I don't have any current data on that though. > >-- >Moritz Bartl >https://www.torservers.net/ >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

serious gap in 'chroot' documentation
by starlight.2013q4＠binnacle.cx 19 Oct '13

19 Oct '13

Newer versions of 'openssl' require access to /proc/sys/kernel/random and so the line /proc/sys/kernel/random /chroot_tor/proc/sys/kernel/random auto bind 0 0 must be added to the /etc/fstab file or the command mount -o bind /proc/sys/kernel/random /chroot_tor/proc/sys/kernel/random must be run from somewhere. Keep in mind that issuing the 'mount' more than once causes nested overly mounts rather than doing nothing, so the 'fstab' approach is best. Obviously the directories proc/sys/kernel/random must be created in the 'chroot' jail tree. ---------------- This problem will appear when 'tor' attempts to roll-over it's key after several days. Took significant effort of figure out what happened as 'tor' dies without comment. It appears that if 'tor' fails in the middle of a re-key operation, the node name and state is lost entirely and the relay must rebuild it's reputation from scratch with a new name. Quite vexing.

4 5

My Relay speed has dropped nearly to zero - Why?
by David Carlson 19 Oct '13

19 Oct '13

On October 8 something caused my non-exit relay speed to drop from around 50 KB to less than 10 KB according to Atlas graphs. I have checked with my ISP and run speed tests that verify my upload speed to be .96 Mb and download to be over 3 Mb, as they have been for years. I am running Tor 0.2.4.17-rc on Windows 7 and my consensus weight has dropped to 26. What could have caused this?

2 1

Re: [tor-relays] OT: Re: risk of relay exploit
by starlight＠binnacle.cx 16 Oct '13

16 Oct '13

Very sorry! I forgot to use the throwaway version of my address that bypasses the curmudgeonly filter. Please try me at starlight.2013z3(a)binnacle.cx At 02:16 10/16/2013 +0100, Geoff Down wrote: >Hello starlight, > >Your outgoing self-generated Spam Score also gets >your emails treated as spam by my email provider >(I tried to email you privately but your >mailserver doesn't accept mail from my provider at >all...). > >GD >

1 0

risk of relay exploit
by starlight＠binnacle.cx 16 Oct '13

16 Oct '13

Hello, Can anyone comment on the pros and cons of running a separate client-only 'tor' instance for local browsing while maintaining an independent instance configure as a relay? My thought is that if high-resource adversary exploits/subverts the relay code and inserts a trojan/parasite, they would be in a position to monitor unencrypted traffic on the SOCKS port. Is the probability of exploit significantly reduced for instances that do not accept relay connections? If so then keeping local browsing in a non-relay client would seem to be more secure since I understand that remote relays see only encrypted traffic. Thanks

3 3

significance of different bandwidth values
by starlight＠binnacle.cx 15 Oct '13

15 Oct '13

Question: What the difference between the bandwidth value given by getinfo ns/name/xxxxx >>> w Bandwidth=297 and getinfo dir/server/authority >>> bandwidth 300000 375000 335872 Here they are close, but sometimes they are far apart. The first above is what shows up in the Vidalia Network Map and the latter is less visible, but shows up in various web tools for monitoring the Tor Network. In particular, how are these values used in choosing route paths? Thanks

1 0

dynamically adjusting bandwidth
by starlight＠binnacle.cx 15 Oct '13

15 Oct '13

Hello, I've recently established a full-time relay running on a fast Linux router. Working nice with version 0.2.4.17-rc. Have a daily offsite backup that was butting heads with TOR traffic, so I wrote a 'tor_bwreduce' and 'tor_bwrestore' script like these: nc 10.92.88.1 9151 <<EOF AUTHENTICATE "xxx" SETCONF RelayBandwidthRate=60000 SETCONF RelayBandwidthBurst=60000 QUIT EOF : nc 10.92.88.1 9151 <<EOF AUTHENTICATE "xxx" SETCONF RelayBandwidthBurst=375000 SETCONF RelayBandwidthRate=250000 QUIT EOF : and run them at the appropriate points in the offsite backup script. The backup is rate-limited as well so the link now avoids going into significant oversubscription or contention. This works much better than I expected. The Tor network consensus bandwidth for the node was taking a bad hit due to congestion delays when the backup ran. Now it seems unaffected and the consensus for my node has shot up above the 'RelayBandwidthRate' value. So that's all super. The question is, should I put in an adjustment for 'MaxAdvertisedBandwidth' during the backup window or make any other change to advise remote relays to de-prioritize the node for the duration? Ideally I'd like to put the node into temporary hibernation, but it seems the only way to do that is indirectly by fiddling with several Accounting* parameters. Thanks! P.S. BTW Vidalia could use some improvement in the area of dealing with a Tor relay living on a different box in the same network. Nothing major, but it should 1) not override the config and/or warn first 2) import the config when a virgin TBB install connects to a non-local address 3) not shut down the relay casually without an "are you sure?" pop-up

1 0

Re: [tor-relays] NSA's "Tor Stinks"
by Eugen Leitl 14 Oct '13

14 Oct '13

----- Forwarded message from Adam Back <adam(a)cypherspace.org> ----- Date: Mon, 14 Oct 2013 12:02:04 +0200 From: Adam Back <adam(a)cypherspace.org> To: Eugen Leitl <eugen(a)leitl.org> Cc: Cpunks List <cypherpunks(a)cpunks.org>, info(a)postbiota.org, zs-p2p(a)zerostate.is Subject: Re: [tor-relays] NSA's "Tor Stinks" Message-ID: <20131014100204.GA28712(a)netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) Btw speaking of GCHQ or NSA operating Tor nodes, of course that is inevitable; and to the extent that they are not perfectly policy aligned a good thing, and they'll try to do a professional job of securing their own tor nodes :) eg if you are a chinese dissident maybe you want to use them as one hop. You just dont want them controlling to many nodes. And probably the Russians, French, Israelis, Chinese etc are all running Tor nodes and even less mutually cooperative. What we could really do with is North Korea, and Iran intelligence services running some also. I suspect to the extent that they are experiencing limited success you could imagine its because not ony are some nodes controlled by users, but more that some are operated by mutually distrustful competing intelligence agencies. The intelligence agency nodes are probably better secured than user nodes, though some user nodes maybe run by security capable and conscious users. The intelligence agencies however have a budget for and hoard of unpublished 0-days on PC & router operating systems so they have a slight edge. Also the intelligence agency is not going to cave under legal pressure when someone from law enforcement comes with threats and demands relating to exit traffic so they have that advantage too. It would be better to my mind if they just came out and said yes this is our node and ran it from their own domain tor.gchq.gov.uk or tor.nsa.gov; then users could opt to use it. However I suspect they think no one would use it, or the people they actively want to use it (who they are trying to trace) would avoid it. Could be useful if they used an identified one and a plausibly hidden one. Speaking of plausibly hidden I notice there is mention of code word 'NEWTONS CRADLE' in one of the docs for a GCHQ tor node operation, speculating could that be some MoD funded student at cambridge in their dorm? (Quite commnon in the UK for students to be sponsored by a company they will work for afterwards or a government career they took a break from. A couple of my classmates at BSc, University of Exeter (UK) comp sci BSc were openly MoD sponsored.) No matter, its trivial for establishment to provide perfect cover for node operation, just run from home address, or persuade ISP/telco to route traffic via DSL lines identifying IP address range as a IP forwarding proxy. They can do whatever they want, you'd think that more likely, however a university dorm IP address range would look nice and plausible/credible also, maybe more so than a DSL address. Probably a university upstream or the university IT itself (universities often take defense contracts) could fake it or operate it under contract with intelligence cleared dual-hat admin if they cared enough. I do think it would be very useful if the intelligence agencies running tor nodes also ran one on their own domain. Then you could route via one who's government is overtly supportive of your political cause. (Doesnt protect you from backroom information exchange deals and horse trading, which I'm sure happens even with sworn enemies, but its a start if you are unintersting enough!) However I expect another reason they dont want to do that is they dont want to enable people to get stronger privacy period. They have a dual hat, they want internet privacy for their own open source research, but they selfishly dont want other users to have privacy or gain any privacy as a side-effect from their own. Adam On Mon, Oct 14, 2013 at 11:18:33AM +0200, Eugen Leitl wrote: > ----- Forwarded message from Jesse Victors <jvictors(a)jessevictors.com> ----- > > Date: Tue, 08 Oct 2013 13:23:48 -0600 > From: Jesse Victors <jvictors(a)jessevictors.com> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] NSA's "Tor Stinks" > Message-ID: <52545BC4.3020106(a)jessevictors.com> > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 > Reply-To: tor-relays(a)lists.torproject.org > > > I recently ran across several articles related to the NSA's attempts at > cracking Tor and de-anonymizing its users. They are after terrorists and > other individuals who seek to do harm of course, but their work > obviously has implications into other Tor users, the vast majority of > whom use Tor for legal and proper activities. So far, it appears that > the cryptographic standards and protocols implemented by the Tor devs > appear to be holding, which I find interesting. The NSA has been trying > other methods to figure out Tor, including identifying and then > infecting user machines, trying to control/hijack the Tor network, or by > influencing the network as a whole, and they've had a very small amount > of success, but not much. One thing that was especially interesting to > me (and I expect to everyone on this mailing list) is that they are > trying to control more relays via cooperation or direct access, which > can then be used for timing attacks or disruptions to the users. They > are also trying to shape traffic to friendly exits. For anyone > interested, I would highly recommend these links: > http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-pre… > http://www.bbc.co.uk/news/technology-24429332 > http://www.theguardian.com/world/2013/oct/04/nsa-gchq-attack-tor-network-en… > > Also, from > http://www.theguardian.com/world/interactive/2013/oct/04/tor-high-secure-in… > it appears that their opinion of Tails is that it "adds severe CNE > misery to [the] equation". These are all highly informative articles, > and it appears that Tor is remaining resilient to their efforts, as long > as people (including relay/exit operators) use the latest software, > remain aware that Tor doesn't protect them in all aspects, and as long > as there are enough non-NSA relays and exits (we need more!) such that > everything they see still remains encrypted and anonymous. Interesting I > say. > > Jesse V. > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ----- End forwarded message ----- > -- > Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org > AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0