tor-relays August 2019

tor-relays@lists.torproject.org

40 participants
29 discussions

Questions to ask exit node providers
by F67 Group 08 Oct '19

08 Oct '19

We are thinking of running a Tor Exit Node. Does anybody have a list of questions to ask before purchasing a VPS or colocation? I came up with some basic questions: - Do you allow a Tor exit node? [with explanation] - What are the policies for handling abuse complaints? - How much uplink bandwidth do you provide? Any other questions one should ask? Thanks.

17 49

Measuring the Accuracy of Tor Relays' Advertised Bandwidths
by Rob Jansen 23 Sep '19

23 Sep '19

Hello relay operators! I am planning on performing an experiment on the Tor network to try to gauge the accuracy of the advertised bandwidths that relays report in their server descriptors. Briefly, the experiment involves running a speed test on every relay for a short time (about 20 seconds). Details follow. I plan to run the experiment in about 1 week. Relay operators can opt-out of the speed test by replying on this thread, and we will remove you from the list of relays to scan. Peace, love, and positivity, Rob --- Measuring the Accuracy of Tor Relays' Advertised Bandwidths Motivation ---------- The capacity of Tor relays (maximum available goodput) is an important metric. Combined with mean goodput, it allows us to compute the bandwidth utilization of individual relays as well as the entire network in aggregate. Generally, capacity is used to help balance client load across relays, and relay utilization rates help Tor make informed decisions about how to allocate resources and prioritize performance and scalability improvements. Problem ------- Currently, Tor uses a heuristic measure of unknown accuracy to estimate Tor relay capacity. Each relay keeps track of the maximum goodput it has achieved over any 10 second window in a 24 hour period. This is called the "observed bandwidth". Relays take the minimum of their "observed bandwidth" and their bandwidth rate-limiting configuration and reports the result as the "advertised bandwidth" in their server descriptors. We do not know how well the advertised bandwidth estimates the true relay capacity, but we do know that it represents a lower bound on capacity. Hypothesis ---------- The advertised bandwidth significantly underestimates the true capacity of Tor relays. On average, relays with higher true capacities will be more strongly correlated with capacity underestimation (because it will be less likely that fast relays will have sustained their full capacity over a 10 second period). Experiment ---------- A relay reports its advertised bandwidth in its server descriptor. To test how well these reported numbers represent the true capacity of a relay, we can manually perform a speed test on the relay by initiating the simultaneous download of several large data streams for a period that exceeds 10 seconds. In the report following our test, the relay will report its advertised bandwidth in its server descriptor and the results will be collected and reported by metrics.torproject.org. The experiment involves two steps: running the speed test on a relay under our control, and running the speed test on all relays in Tor network. We will first run the speed test on at least one relay that we control, in order to test that the method is effective and that we can in fact observe a change in the advertised bandwidth reported on metrics.torproject.org. Once we have confidence that our speed test is functioning correctly, and that the metrics pipeline will allow us to gather the results, we will repeat it on all relays in the network. We will conduct the speed tests while minimizing network overhead. We will use a custom client that builds 2-relay circuits. The first relay will be the target relay we are speed testing, and the second relay will be a fast exit relay that we control. We will initiate data streams between a speedtest client and server running on the same machine as our exit relay. The setup will look like: speedtest-client <--> tor-client <--> target-relay <--> exit-relay <--> speedtest-server All components will run on the same machine that we control except for the target-relay, which will rotate as we test different relays in the network. For each target relay, we plan to run the speedtest for 20 seconds in order to increase the probability that the 10 second mean goodput will reach the true capacity. We will measure each relay over a few days to ensure that our speedtest effects are reported by every relay. Although we believe that the overhead of this speed test is in line with regular usage, relay operators can opt-out of the speed test by replying on this thread. Those that opt out will be removed from our list of relays to scan. Analysis -------- Following our speedtest, we will analyze the data collected and reported by Tor metrics. We will compared the advertised bandwidth that each relay reports before our experiment to those reported during our experiment. This will help us test our hypothesis that relays' advertised bandwidth underestimates the true capacity of relays. We will run a statistical correlation analysis on the data to test the strength of the correlation between the previously reported (estimated) relay capacity and relay capacity underestimation. We will report our results to the Tor community. We expect that the results of our experiment will help Tor decide how to allocate resources and will help them plan and prioritize performance improvements. It will also provide insight into the operation of the current load balancing system, which uses advertised bandwidth to produce consensus weights.

12 37

SSH scanning on TOR Exit - Nerfing Rules
by AMuse 16 Sep '19

16 Sep '19

Hi all! I'm curious what y'all think of this situation. I have SSH open as an exit port on a TOR exit that my friends and I are maintaining - and of course it's the #1 offender by far in automated abuse notifications we get from our ISP, from peoples' fail2ban servers sending abuse emails. This all seems like a huge waste of time, but that's a separate issue. I'm wondering if nerfing outbound SSH to rate limit will be effective at getting the SSH scanning bots to stop using my exit in their circuit, while leaving SSH open for actual humans who need to SSH while using TOR. I've implemented, as a test, rate limiting outbound on the SSH port. What do you think the impact of this will be? No impact? Losing exit status because connections on SSH die? Something else entirely? Here's the pf rules in question: pass in on $ext_if proto {tcp udp} from any to any port 9000:9150 keep state pass in on $ext_if proto tcp from any to any port 22 keep state pass in on $ext_if proto tcp from any to any port 80 keep state pass out on $ext_if from any to any keep state pass out on $ext_if proto tcp from any to any port 22 keep state (max-src-conn 25, max-src-conn-rate 1/5 )

3 2

Fast flag - wrong speed in dir-spec.txt?
by Michael Gerstacker 30 Aug '19

30 Aug '19

Hi Torproject, as far as i can see my relay currently can advertise 560 KiB/s. That are 573,44 KB/s. 43C7BC2E17FB26B204EC0BD9AA784E4736979087 Following your dir-specs it should get the "Fast" flag if it can provide more than 100KB/s. https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2595 At my other relay i already saw it providing 562 KiB/s and it got the "Fast" flag. A9DB853547A6459AB5190E62BF2F7B8F068FEB0A It seems the limit is above 560 KiB/s? If i remember it right then i already read somewhere that the requirements are now higher than 100 KB/s so i guess your documentation is wrong? Am i missing something why my relay with 560 KiB/s dont get the "Fast" flag?

3 3

Please test bandwidth and resiliency of greyponyitnyc002
by Conrad Rockenhaus 29 Aug '19

29 Aug '19

Hello, I was wondering if Rob would be willing to perform speed measurements on this node, it’s. 20 vcpu running CentOS 7 with manually compiled Tor against OpenSSL 1.1.1 on a 30Gbit link. I know it’s not going to see all of that bandwidth, it’s meant as a high powered VM platform because my intention is to start giving VMs back to the guys on my old infrastructure, and hopefully setup a “Torservers” type arrangement down the road, since this is hosted on unique ASN and addresses. Thanks, Conrad Rock Rockenhaus Greypony IT Consulting (254) 292-3350

1 0

3 questions
by niftybunny 29 Aug '19

29 Aug '19

Hi there, 1. anyone with any new news about the Darknet law in Germany or where you could ask for information? 2. Whats up with Torflow, still linked from Tor Atlas. As far as I can see it was last updated over 3,5 years ago? 3. So what happened to the new measurement? I can see a big spike https://metrics.torproject.org/bandwidth.html <https://metrics.torproject.org/bandwidth.html> and now its back to normal? Same with a lot of my relays, traffic doubled/tripled and now its the same or worse. niftybunny

2 2

Why is my Tor bridge relay not getting any traffic?
by Hikari 29 Aug '19

29 Aug '19

Hello everybody! I used to run a Tor bridge on Windows at home, where I have a 300/150 Mbps ISP. This Windows has memory leak and crashes after some hours, ad I believe that was making my bridge never get traffic. A few weeks ago I moved it to a Ubuntu server, also at home. I use uptimerobot.com to monitor if its port is reachable from outside and healthchecks.io to monitor if traffic entering from its local SOCKS port is reaching check.torproject.org. It's always up and reachable. But nyx reports it's rarely getting any traffic, and its bandwidth never surpasses 1KB/s. Its log heartbeat reports very little download and upload and always claims to has seen 0 unique clients. But how come, if my healthchecks.io monitor's curl call uses it every few minutes? metrics.torproject.org reports correct dates and uptime. Advertised Bandwidth is 58KB/s, way above what nyx reports. Flags are Fast, Running, V2Dir, Valid. What might be wrong? Or is it normal for a Tor bridge relay be this idle? This is my torrc removing identifiable data. |## Configuration file for a typical Tor user ## Last updated 9 October 2013 for Tor 0.2.5.2-alpha. ## (may or may not work for much older or much newer versions of Tor.) ## A handle for your relay, so people don't have to refer to it by key. Nickname MyNick ContactInfo mycontact ## Entry policies to allow/deny SOCKS requests based on IP address. SocksPort 9031 #SocksPort ::9031 #SocksPort 0.0.0.0:80 #SOCKSPolicy accept 192.168.* ## Send all messages of level 'notice' or higher to /var/log/tor/notices.log Log notice file /var/log/tor/notices.log ## Send every possible message to /var/log/tor/debug.log #Log debug file /var/log/tor/debug.log ## Use the system log instead of Tor's logfiles #Log notice syslog ## Uncomment this to start the process in the background... or use RunAsDaemon 1 ## The directory for keeping all the keys/etc. By default, we store ## things in $HOME/.tor on Unix, and in Application Data\tor on Windows. DataDirectory /var/lib/tor ## The port on which Tor will listen for local connections from Tor ## controller applications, as documented in control-spec.txt. ControlPort 9051 ## If you enable the controlport, be sure to enable one of these ## authentication methods, to prevent attackers from accessing it. CookieAuthentication 1 ################ This section is just for relays ##################### # ## See https://www.torproject.org/docs/tor-doc-relay for details. ## The IP address or full DNS name for incoming connections to your ## relay. Leave commented out and Tor will guess. Address hikari.mydomain.com ## Required: what port to advertise for incoming Tor connections. ORPort 80 ## Uncomment this to mirror directory information for others. Please do ## if you have enough bandwidth. DirPort 9030 # what port to advertise for directory connections ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy #ExtORPort 0.0.0.0:8000 ExtORPort 9041 ## Uncomment to return an arbitrary blob of html on your DirPort. Now you ## can explain what Tor is if anybody wonders why your IP address is ## contacting them. See contrib/tor-exit-notice.html in Tor's source ## distribution for a sample. #DirPortFrontPage /etc/tor/tor-exit-notice.html ExitPolicy reject *:* # don't run as an exit node BridgeRelay 1 # bridge PublishServerDescriptor 1 # published on bridge directory DB BridgeRecordUsageByCountry 1 # it's nice to see the country codes of users you are assisting #BandwidthRate 512000 #RelayBandwidthBurst 512000 #RelayBandwidthRate 512000 CellStatistics 1 PaddingStatistics 1 DirReqStatistics 1 EntryStatistics 1 ExitPortStatistics 1 ConnDirectionStatistics 1 HiddenServiceStatistics 1 ExtraInfoStatistics 1 #If non-zero, try to write to disk less frequently than we would otherwise. This is useful when running on flash memory or other media that support only a limited number of writes. (Default: 0) AvoidDiskWrites 0|

6 9

attack on my Finland exit/backup directory [9B31F1F1C1554F9FFB3455911F82E818EF7C7883]
by potlatch 28 Aug '19

28 Aug '19

I still haven't been able to rid myself of the Iranian servers revealed on the NYX connections page. I don't know their purpose but they slow the relay by about 85%. I have dropped them in the iptable input chain, restarted the VPS, but they show up after a day or two in spite. Today there were 121 of them with a large range of IPs. There have been as many as 1400 in a single day. None have identifiable hashed fingerprints. I've enclosed a couple attachments of my input table (partial) and the NYX connection page (also partial). Can anyone enlighten me regarding this situation? I will probably dump the exit relay if I can't fix this intrusion. Thanks people!! -potlatch Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

Re: [tor-relays] Why is my Tor bridge relay not getting any traffic?
by Hikari 27 Aug '19

27 Aug '19

Thanks. It's been a few weeks I moved my relay to Ubuntu. I changed my Nickname and ContactInfo when I did that, so my fingerprint is new. Why is it on email bucket? Am I able to move it to bridges.torproject.org? On 27/08/2019 08:14 PM, Philipp Winter wrote: > On Tue, Aug 27, 2019 at 03:03:37PM -0300, Hikari wrote: >> Hello. Here's my fingerprint ------------ > > Your bridge is in the email bucket. It may not be requested as often as > over moat, but give it some time and you'll eventually see users. > > Cheers, > Philipp >

1 0

Improving throughput on weak CPU?
by Jochen 27 Aug '19

27 Aug '19

Hi there, I'm the operator of the following two exit nodes: https://metrics.torproject.org/rs.html#search/family:94C268630BEDCB64E7F888… My CPU is an Intel C2750 (8 cores total), which supports hardware accelerated AES yet a single process still maxes out at only ~150mbit/s. To get the most out of the machine and my single IPv4 address, I simply ran another relay which works fine, and now I'm averaging at around ~315mbit/s. Is there anything else I can tweak to improve throughput without having to order more IP addresses? I'm running Arch with stock 5.2.9 linux kernel. That being said, true multi threading would be much appreciated and would help people like me a lot :-) Regards, Jochen

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays August 2019