- tor-relays - lists.torproject.org

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

Keeping an exit node off of blacklists due to botnet activity.
by Julian Plamann 04 Jun '15

04 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 -----BEGIN PGP SIGNATURE----- Version: Mailvelope v0.13.1 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJVcKatCRB9wOTqlogdgwAAgdYP/268o2gs1nSKVcNKQfJR gnKQyBsduy2DZCGlSCnEmj4JJ0E9jiOsh+aBrZBknnbbwYPtwMBuctHTblXD czQAy5DxMNUE+E9wofLQJHLUe3W43hueKGuKzVjBnnSgxKhsUS+7dH1q4dLt KHzYdxUqQQYmmX4P9uY43/6tWeratdUF7w93cevatRpDbULMTb0j09+aeUyE MfU2i3KK6CZXIij6oo2pndwrglHywcasFwXpmEN058SYrHlB/4QDQBl7xgyU eELb71jxmz+vwZOyfEyj10ffwVtT/TcYKi5wOT1viDqQV9orNmlu8UOvu3xE 47zsb8M1Bt8JU19AsKmJNVS3YLH+2J5ertyi2mFM2PpSRIAQ6NzGA/zd/+Qr MJ7pilIBpozauf/iqiZH3UFDU5UUSezqR62fSkUDuTNaSIV5Inz0gWJnqK8w ZUMLM5xovCvWg/SqrZo0Qbry2AxOZ/l5zyhW4Jn2uioOoP+Z763FP04LcRm9 gVqfvVDNHyaAvdgKR8PSPXi2PrnNb0uEKDZLea76deWN8f2DBgfqp5hRAUOf Mk2BD9Fk30F1RC0QH0DLm/hsgTnxDEyq+XDtD6LJiGkfiHtwPkye6pH+Qf3K ZuonkypZqdfccY68lb2hMkLW7N/hsOf4hjUVQri/TL8V6eUMoEw0OAZLzhtZ gv2S =HitE -----END PGP SIGNATURE-----

1 0

amount of unmeasured relays continuously rising since 2 weeks
by nusenu 03 Jun '15

03 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor BW Authories, we'd like to bring the following issue to your attention. Since the last two weeks the amount of unmeasured relays is steadily rising [1]. unmeasured relays on 2015-05-01: 387 unmeasured relays today: 1087 (and growing) Graph showing the last 5 months: https://trac.torproject.org/projects/tor/attachment/ticket/13450/unmeasured… Data: https://trac.torproject.org/projects/tor/attachment/ticket/13450/2015-01-01… Would be great if you had some time to look into this: https://trac.torproject.org/projects/tor/ticket/13450 (follow ups should probably go to trac) ..so bw doesn't go wasted. A contributed but unused relay doesn't make relay ops happy. thanks! [1] https://lists.torproject.org/pipermail/tor-relays/2015-May/006946.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVVP8PAAoJEFv7XvVCELh03bwP/1NQi99IweePw+o/Mj4nWieE yRLDmTt2J8IeJXp8tMQPcqJIZSEzSOW7u7J9o7McNR+n2lm2Mx9x9IMKQPCX6CFh /v5JJ2/aZyfu7JnkTLr7sNKw6DqkAODnKHbyALuc20zsc1oQmu56VZpY6orwC3RG n4qhbXxyD7+TXCv5iZF5CZsnlrVojHevK6tKkivOem/qMVSwshFHCUSnYVi/YK+R CcLIGllT5fx8msYEWDnnTdIBi9PoIl2gO7SE4Y3TKEpkFhGeU8FEsGmIV9LQi8O1 XcaIeU2BVup4PJMDBSgtB9BlSuKGQAq1ICiVx3OnVUVPleTYsFATFUQxW83irfu9 o8Q3ns3srj3tmtLHE0LA9c2gCuE4NiWA++t72sCc+tiqCy9+X4f5BKsqsem7bT5o 89PfZijjuR4ZI3531e+PCjZDokNY9Gx7lCjIlnrGDeGKSIPqPz9N53bYYIXB+d4r uKDeRaRjv3iz/yKjXFYSra3p70HcQmx+CM4aws035LSCTLg/zFyARXb+hf8/NeKn JzXaVoURRiRX3gzeyiznQ7EVNXTyQmr1ppGJVZAXhtfAuiCrqS5JsPJ8BTzxcylI hZBkcwyQzkV3cCeBFMABQFy3AtQ2SZSOuLzS1vyH1oAHPPWd5K1bgHcSMvOqIEPh LspnH0QSv8ICnU1uhbTZ =rNB9 -----END PGP SIGNATURE-----

14 33

Updated: Running Tor When OS X Boots
by teor 02 Jun '15

02 Jun '15

I've recently updated the OS X launchd instructions for OS X Yosemite: https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot <https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot> They were starting to show their age - they were originally written in 2011, and were based on Vidalia, tor 0.2.2, and OS X 10.6 or 10.7. If you're running Tor on OS X, please try these instructions, fix any mistakes, and add missing steps. In particular, we've moved away from Vidalia to nyx (arm), so the nyx sections could do with some more detail. 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

1 0

Re: [tor-relays] Improving Node Connection Testing
by teor 02 Jun '15

02 Jun '15

> > Date: Tue, 02 Jun 2015 11:58:25 -0400 > From: 12xBTM <12xbtm(a)gmail.com> > > This is a little write-up on the quality of data connections involving > nodes, and some thoughts on that. So, as of today, the quality of nodes > is determined by their bandwidth, uptime, and not being malicious. There > are two major missing factors from this, and I wanted to bounce some > ideas around: Latency and Packet Loss. These are fairly simple tests > that can be performed on nodes, albeit, it would increase the resource > load on the bwauths. However, nodes with high latency or packet loss > should be identified, and nodes should be measured with these two > important factors. > > High latency will increase the delay of the circuit, but will not appear > in the consesus at all. A node can have enormous latency and hamper that > circuit without anyone knowing. The same could be said for a node that > drops a lot of packets, or drops a lot of packets at a certain time of > day (peak usage). Do the bwauths only measure the time to transmit the data, or do they include the time to connect as well? Including the time to connect would be a measure of latency, particularly for smaller file transfers. Are the bwauths only using one size of file transfer to measure bandwidth? Using a small and large size would allow measurement of mostly-latency and mostly-throughput with the current infrastructure. Since, as far as I know, Tor connections are in-order delivery, dropping packets will cause retransmits, and back up (parts of) the transmission. This will reduce the bandwidth as a side-effect. This reduction in bandwidth is currently measured by the bwauths - but, as you say, it isn't a direct measurement. In future, it would be great to have separate statistics for latency and packet loss - but this is perhaps a job for something more like Ooniprobe? 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

3 2

IPv6 slows BW?
by torelay 02 Jun '15

02 Jun '15

I have two relays that I set up last night to test. They're at the same datacenter, same spec server, and configured identically. The only difference is one is set up for IPv6 and the other isn't. With IPv6 BW is at: 75kB/s Without IPv6 BW is: 110kB/s Is this normal behavior or has anyone else experienced this loss of bandwidth? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

2 1

Fwd: Re: Multi-core Support
by 12xBTM 02 Jun '15

02 Jun '15

-------- Forwarded Message -------- Subject: Re: [tor-relays] Multi-core Support Date: Tue, 02 Jun 2015 11:55:31 -0400 From: 12xBTM <12xBTM(a)gmail.com> To: Roman Mamedov <rm(a)romanrm.net> Some multicore support (at least 4 cores) should be a priority. Going beyond doesn't cater to many node operators at this time. Don't quote me on the numbers, but having decent 4-core support would let someone run a node with the same bandwidth on an Atom/i5 that currently runs on one thread of a Xeon. Or, if someone has a Xeon, such as a collocation center, would let them fully utilize the processor they are paying for, which would be a good morale boost for node operators. But, honestly, the very minimum that can be done to improve the situation (which I know is being worked on as of 0.2.7) is improving a 2-thread program, to further utilize 2 threads of a cpu. That way, we can get by with 2 processes on one 4-thread CPU, instead of being tempted to jumped to 4 processes. On 2.6.15 11:31, Roman Mamedov wrote: > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12xbtm(a)gmail.com> wrote: > >> Improving multi-core support can allow users to saturate high bandwidth >> connections with cheaper processors, less setup, and just more efficient >> deployment of high-capacity nodes in general. Improving multi-core >> support should be a major priority. > Sure but I doubt anyone contests that it's better to have multicore support, > than to not have it. However that work doesn't get automatically done. > > One quick and simple stop-gap alternative that I suggested some time ago would > be to stop ignoring more than two relays per IP address. > > With the IPv4 shortage and abundance of multi-core CPUs, raising that limit to > let's say 4, would at least allow many people to run a Tor process per core on > the same single IPv4 that they have (utilizing up to four cores, not just two). > > Considering that Tor is already somewhat multi-threaded (each process can use > up to "120-130%" CPU), that might be just enough in most circumstances, since > true 6-8-core CPUs are rare, and what's seen more often beyond 4 cores is > either Intel HT or AMD's "light" core technologies. > > Of course the management (and memory) overhead of multiple processes is still > there, so proper multi-core scaling is the ideal final goal. >

1 0

Re: [tor-relays] Multi-core Support
by teor 02 Jun '15

02 Jun '15

> Thomas White: > Have there been any updated ETAs concerning the development/support > of multi-core for the core tor workloads? If not, is there anything > in particular that I could do to speed the process up? Scaling the > capabilities of the Tor process would be a huge relief and help for > my upcoming project so I am keen to push it through should it be > possible to bring up the priority list. t T > > On 1.6.15 9:11, Tor-Admin wrote: > I have to agree with that, multicore support is really important and > should be on the top of the priority list. > > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12xbtm(a)gmail.com> wrote: > Improving multi-core support can allow users to saturate high bandwidth > connections with cheaper processors, less setup, and just more efficient > deployment of high-capacity nodes in general. Improving multi-core > support should be a major priority. > > Date: Tue, 2 Jun 2015 20:31:56 +0500 > From: Roman Mamedov <rm(a)romanrm.net> > Sure but I doubt anyone contests that it's better to have multicore support, > than to not have it. However that work doesn't get automatically done. The work is currently listed in Trac in: https://trac.torproject.org/projects/tor/ticket/1749 https://trac.torproject.org/projects/tor/ticket/7572 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

1 0

Re: [tor-relays] Multi-core Support
by teor 02 Jun '15

02 Jun '15

> Date: Tue, 2 Jun 2015 20:31:56 +0500 > From: Roman Mamedov <rm(a)romanrm.net> > > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12xbtm(a)gmail.com> wrote: > >> Improving multi-core support can allow users to saturate high bandwidth >> connections with cheaper processors, less setup, and just more efficient >> deployment of high-capacity nodes in general. Improving multi-core >> support should be a major priority. > > Sure but I doubt anyone contests that it's better to have multicore support, > than to not have it. However that work doesn't get automatically done. > > One quick and simple stop-gap alternative that I suggested some time ago would > be to stop ignoring more than two relays per IP address. > > With the IPv4 shortage and abundance of multi-core CPUs, raising that limit to > let's say 4, would at least allow many people to run a Tor process per core on > the same single IPv4 that they have (utilizing up to four cores, not just two). This was suggested in https://trac.torproject.org/projects/tor/ticket/13414 But the concern was that any increase to 2 relays per IP would make it much easier for sybil attacks. Perhaps we could try an increase to 3 or 4 per IP? 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

1 0