June 2015 - tor-relays - lists.torproject.org

Help with my first relay.
by janarkopunk＠riseup.net 07 Jun '15

07 Jun '15

Hi, i want to check if the relay has a good configuration. Also i have another question, why the speed of the relay is so slow, i have a VPS with a connection of 100mb/s, the relay is new. This is torrc: ORPort 443 Exitpolicy reject *:* Nickname Freedom4Anarchists ContactInfo nomail@... RelayBandwidthRate 85 MB RelayBandwidthBurst 90 MB DisableDebuggerAttachment 0 Thanks to all :)

2 1

False exit abuse from server4you
by Dr. Who 07 Jun '15

07 Jun '15

Fun fact of the week, I got this abuse email on friday: "Dear Customer, we've detected that you're running a TOR Exit Node on your machine. Please understand, that we cannot tolerate such a service on our infrastructure. Please ensure, that this service is disabled as soon as possible. Best Regards Your Intergenia Abuse Team" followed by over 6000 IPv4 numbers including one of my relay server. First I find it a privacy violation for those other users who might run any form of tor beeing found on an abuse email to me. It should have listed only my own IP number. Secondly I think they should be able to differate between exit and relay servers. I'm eager to hear their response on Monday. Either they keep relays running or I quit, monthly payment is a good idea in that case. Just letting you know...

4 4

Bridge Usage and Setup
by Tom Ritter 07 Jun '15

07 Jun '15

Earlier this month I set up an obfs3/obfs4 bridge that (as far as I can tell) has never been used. Is this normal? My bridge is at https://atlas.torproject.org/#details/C184F644B9D39B26647779282003ACAF59E80… During this exercise I ran across a few pain points for setting up a bridge. Maybe I completely ignored some existing resource for this, but the bottom of https://www.torproject.org/docs/bridges is out of date, BridgeDB doesn't have a link anywhere, and trac's search isn't that good but I couldn't find anything on that either. 1) Setup I followed https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md to set up the obfs3/obfs4 As good as this is, it would be great if it included a minimal and complete torrc for an obfs4 bridge, and perhaps also for an obfs3/obfs4 bridge and an IPv6 setup. My torrc is SocksPort 0 ControlPort 9051 HashedControlPassword ... CookieAuthentication 1 ORPort 9001 ORPort [<public ipv6 addr>]:9001 BridgeRelay 1 ExtORPort auto ServerTransportPlugin obfs3,obfs4 exec /usr/local/bin/obfs4proxy ServerTransportListenAddr obfs3 [::]:80 ServerTransportListenAddr obfs4 [::]:443 2) Testing How do I (easily) confirm my bridge is correctly configured? Especially if I don't have an IPv6 connection for TBB? netstat seems to say that things are good. The tcp6 connections on 80 and 443 also apply to ipv4 though; right? $ netstat -lpn tcp 0 0 127.0.0.1:9051 0.0.0.0:* LISTEN 479/tor tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 479/tor tcp 0 0 127.0.0.1:55346 0.0.0.0:* LISTEN 479/tor tcp6 0 0 :::443 :::* LISTEN 480/obfs4proxy tcp6 0 0 <public ipv6 addr> :::* LISTEN 479/tor tcp6 0 0 :::80 :::* LISTEN 480/obfs4proxy I can put my bridge line into TBB and try and use it for obfs4; seems to work. But actually finding that bridge line wasn't straightforward (cat /var/lib/tor/pt_state/obfs4_bridgeline.txt and then edit the fields, right?) And it doesn't help for obfs3. Some external validation would be nice. 3) Usage Can do I figure out if my bridge is being used? I've identified the following: $ cat /var/lib/tor/stats/bridge-stats bridge-stats-end 2015-05-31 18:58:43 (86400 s) bridge-ips bridge-ip-versions v4=0,v6=0 bridge-ip-transports $ zgrep unique /var/log/tor/* (a bunch of lines of "0 unique clients") Atlas graphs, showing virtually no traffic I feel like #2 might be addressed by Weather (if it was working), but all of these might be a good subject for a wiki page on how to run a bridge, if my understanding of everything is correct. -tom

8 9

Re: [tor-relays] BWAUTH weightings too volatile. . ."twitchy"
by teor 06 Jun '15

06 Jun '15

> Date: Sat, 06 Jun 2015 02:43:09 -0400 > From: starlight.2015q2(a)binnacle.cx > > … > One reason this vexes is that I > would like to see how well the relay > runs with Address Sanitizer active. > ASAN provides obvious benefits > w/r/t security, but entails a > performance trade-off. With the > BWauths throwing darts, eyes closed, > when choosing weighting, it's > impossible to gauge the performance > impact of various adjustments. > … Good timing! Tor 0.2.7.1-alpha on x86_64 is currently Address Sanitizer and Undefined Behavior Sanitizer clean. I've just submitted a branch with instructions for building, running, and testing Tor with ASAN and UBSAN. https://trac.torproject.org/projects/tor/ticket/15817#comment:8 The following known issues exist: Two of the tests deliberately invoke undefined / illegal behavior, the instructions provide a blacklist file and an environmental variable to exempt them from ASAN/UBSAN. Architectures without (x86?) 64-bit assembler use donna C code that left-shifts 1 bits into and past the sign bit of signed integers. Until https://trac.torproject.org/projects/tor/ticket/13538 is resolved, this particular file can be exempted from UBSAN. Please let me know how you go - the 0.2.6.x series should also be relatively ASAN and UBSAN clean, as Tor has been tested with them since late 2014. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

Updating tor to get fix for #15083?
by Elliott Jin 06 Jun '15

06 Jun '15

Hello, Over the last few days, my relay (D28D32015D9723E6C50827BFD9D19200901E19D1) has been going down quite often. When I checked the logs, I saw this message: tor_assertion_failed_(): Bug: ../src/or/buffers.c:2627: assert_buf_ok: > Assertion ch->data < &ch->mem[0]+ch->memlen failed; aborting. It looks like this issue has already been observed and addressed: https://trac.torproject.org/projects/tor/ticket/15083 However, when I tried to update tor, I got the message "tor is already the newest version". I have two questions for this list: - Is Tor 0.2.5.10 (git-43a5f3d91e726291) actually the newest stable version, or did I mess something up when trying to update tor? - Would it be a good idea to upgrade to an experimental version? Thanks! -Elliott -- Anonymous Feedback <http://www.admonymous.com/eyjin>

2 2

Re: [tor-relays] Keeping an exit node off of blacklists due to botnet activity.
by tor＠t-3.net 05 Jun '15

05 Jun '15

> I have a fairly high bandwidth exit node running for about a month now > that I'm having difficulty keeping off of the http://cbl.abuseat.org/ > blacklist and have been informed of this listing by the VPS provider. > The relay is running with a reduced exit policy -- and additionally I've > blocked common mail ports, etc via IPFW so I know that no spam is > actually being sent out of the relay. Still, various botnets connections > are connecting to abuseat.org botnet sinkholes via port 80 > Command&Control connection attempts. I'm at a loss at how to stop this > or somehow detect and filter botnet traffic. > > I've informed the VPS provider that I'm on top of it and have the > machine configured to not actually allow this sort of malicious traffic > out and they seem to be generally happy with that explanation, but a > better solution if one exists would be appreciated. > > Thanks, > > Julian Plamann > > julian (at) amity.be > GPG: 0x96881D83 Don't know if this will help, but maybe: ExitPolicy reject 85.159.211.119 # Cryptolocker ExitPolicy reject 212.71.250.4 # Cryptolocker ExitPolicy reject 54.83.43.69 # Cryptolocker ExitPolicy reject 192.42.116.41 # Cryptolocker ExitPolicy reject 192.42.119.41 # Cryptolocker ExitPolicy reject 198.98.103.253 # Cryptolocker ExitPolicy reject 208.64.121.161 # Cryptolocker ExitPolicy reject 142.0.36.234 # Cryptolocker ExitPolicy reject 173.193.197.194 # Cryptolocker In general, I see complaints about abuse from the exit relays we run due to someone using Tor to try to exploit remote web server scripts and databases and the like. I don't think there's anything that can be done about it? I would say that it's just part of what you get coming out out of Tor exit nodes. If anyone else has any better advice feel free to correct me but, I think it might be accurate to explain to the upstream that Tor exits will generate certain kinds of abuse complaints as part of normal operation. They open proxy web-related ports out, and some people abuse Tor for web hacking types of activity. I would say that it is normal for Tor exits to live permanently on certain kinds of blacklists. They do not need to be on the spam email related ones (reject *:25 and other email ports), but they will land on other types of blacklists, and I don't think it can be helped.

1 0

Re: [tor-relays] Updating tor to get fix for #15083? (Elliott Jin)
by AlexK (Tor lists) 05 Jun '15

05 Jun '15

tor-relays-request(a)lists.torproject.org schreef op 05/06/15 om 14:00: > Updating tor to get fix for #15083? (Elliott Jin) > > - Is Tor 0.2.5.10 (git-43a5f3d91e726291) actually the newest stable > version, or did I mess something up when trying to update tor? > - Would it be a good idea to upgrade to an experimental version? Assuming you're running 'standalone' on *Nix, this is a good place to check: https://www.torproject.org/download/download-unix.html.en Here you'll find the latest source (stable/unstable) and the latest packages for several *Nixes, including simple install instructions. Latest and greatest is 0.2.6.8, even if you rely on your package manager's updates this is what you should have, e.g. on my relay: $rpm -qa tor tor-0.2.6.8-tor.1.rh6_6.x86_64 Good luck! Alex

1 0

How to use our own TOR relay as entry node for local network hosts
by Tor User 05 Jun '15

05 Jun '15

Hello, We have been operating a moderately successful public tor relay for a while now. Having read about how TOR works back a couple of years ago, I was more or less sold on the idea that if traffic originating on your local network uses your own TOR relay as the first hop (entry node), then by the time your traffic has left your tor relay, people in the middle can't tell the difference between traffic originating from your network and other (relayed) traffic passing through your TOR relay. I also understand that this still doesn't protect you from an exit node being able to see your traffic (and why you should use HTTPS with a high-quality cipher if it's really important), and that there are other ways your traffic can be analyzed -- but all in all, I would rather our TOR traffic enter the TOR network through a relay I *KNOW* I can trust (mine!) than leave it to chance. We have polipo running on our public TOR relay, configured to accept traffic from our local subnets. We've basically followed the info in this TOR doco: https://trac.torproject.org/projects/tor/wiki/doc/CentralizedTorServer The TOR browser bundle appears to function correctly, ie, it is able to start up, open circuits, etc. and we get the expected Congratulations! page opening a new browser window. But when clicking the green onion to show the circuit of relays handling the browser's connection, our relay is never the first hop. I'm using TBB 5.01a on one particular system, and for an example, it shows this for the circuit: - This browser - Austria (aa.bb.cc.dd) - Germany (ee.ff.gg.hh) - Guatemala (ii.jj.kk.ll) - Internet I have tried defining an EntryNodes statement with the $fingerprint of our TOR relay and setting StrictNodes 1 in the TBB's torrc file, but it can't ever establish a circuit when I try this. We get messages like this logged on the browser's tor: 05/20/2015 04:21:20.700 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit. 05/20/2015 04:21:20.700 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit. 05/20/2015 04:21:20.900 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150 05/20/2015 04:21:20.900 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 05/20/2015 04:21:20.900 [NOTICE] Closing old Socks listener on 127.0.0.1:9150 05/20/2015 04:21:21.700 [NOTICE] Delaying directory fetches: DisableNetwork is set. Is it possible to define your desired entry node via IP address and port, or some other way that does not require a successful directory connection/circuit first? (so it can find the relay by its fingerprint)? It seems like a chicken vs. egg problem... Or what about defining a directory for the client to use by its IP/port? We are operating a public directory as well. I can't find any info about this or other approaches anywhere. So I always end up removing the EntryNodes and StrictNodes statement from TBB's torrc file, leaving only the HTTPSProxy aa.bb.cc.dd:<polipo-listen-port> statement in there with the DataDirectory, GeoIPFile, and GeoIPv6File statements. It gets the TBB's on our network to the local polipo proxy, which in turn forwards the traffic to our public TOR relay. TBB works fine, but I don't think our TOR relay is the one getting to see our traffic with the original source address with this setup. It is definitely possible, likely even, that I am misunderstanding parts of how this is supposed to work or how a central TOR relay/proxy is supposed to be configured. But it doesn't seem to me that proxying our local network's TBB clients' traffic through the polipo instance on our public TOR relay means that our TOR traffic is being "anonymized" as to where it originated from before it gets to the first node in the circuit - or we would be seeing our TOR relay as the first hop when we look at the circuit in "the green onion button". If I'm wrong about this, that's great - I'd love to see some documentation to explain it better if you have any links handy. But if I'm right, how can I configure our TBB clients to actually MAKE them use our TOR proxy as their entry node? Thanks, Tor User

3 5

Relay traffic triggering snort ftp rules
by Paul Pearce 05 Jun '15

05 Jun '15

Hey everyone, I've encountered tor relay traffic over port 21 is triggering some (overly aggressive?) snort rules. Our ISP recently sent us a slew of snort warnings that were triggered by our obfsproxies creating circuits with tor relays that run on port 21 (I've confirmed this). The warnings are of the form: ftp_pp: Telnet command on FTP command channel [**] [Classification: Generic Protocol Command Decode] [Priority: 3] ftp_pp: FTP response length overflow [**] [Classification: Attempted User Privilege Gain] [Priority: 1] {TCP} ftp_pp: Evasive Telnet command on FTP command channel [**] [Classification: Potentially Bad Traffic] [Priority: 2] (Lawl.) They described the quantity as "overwhelming." I have no idea if this rule is enabled by default or configurable in some way. I am not familiar with snort. Has anyone ever encountered this before? If encrypted relay traffic to port 21 does indeed trigger these widely distributed warnings, it might be a good idea for "best practices" to suggest avoiding relays on this port. Thanks.

1 0

non exit relay shows up as exit in arm connections
by Maximilian Kaul 04 Jun '15

04 Jun '15

Hi, I just set up my first relay and as I'm living in Germany it needs to be a non exit relay :-( However in arm -> connections it shows up as "exit" in the last column. >From my configuration /etc/tor/torrc ExitPolicy reject *:* This is also confirmed by the head row of arm which contains the entry exit policy: reject *:* So the only thing that confuses me is the arm connections view. Is this a bug or do I simply misunderstand the tool? I googled for this but I only found another unanswered question. The relays fingerprint is 1FF50B543DC87A6F0D1F3B44BDCCAF39B07C91AC And globe.torproject.org says that it is not a exit relay but the information there is old (I changed the ORPort and DirPort listing several hours ago). Sorry for the noise but I really want to be sure. Thanks

3 4