Hello Tobias, i am glad that somebody else got notice and i agree, suspecting something nasty (or highly unusual) is going on. There was a discussion about that in Berlin in July already https://trac.torproject.org/projects/tor/wiki/org/meetings/BerlinRelayOperat... but no public follow-up since then. There seems to be a private person who is holding this family https://metrics.torproject.org/rs.html#search/family:1084200B44021D308EA4253... and ran between 10-15% exit probability in the last six months - which i personally judge as far too high for a single person, or even an entity. More information you can find here:https://apility.io/search/185.220.101.20 The person got invited to the second meeting in Berlin, but didn't show up to explain. Die Zeit bringt Rat. Erwartet's in Geduld! -- Schiller Regards Paul Tobias Westerhever:

Hello,

recently, I noticed some strange aspects related to networks of Torservers/Zwiebelfreunde. Since there was no way to get any further information on this topic so far, I am posting it here. Maybe someone can help.

(a) Torservers relay family decreased? The organisation used to maintain much more relays than their family [1] currently contains. At the moment, only four relays located in NL belong to them, while the Metrics page indicates some orphaned family members.

This coincidences with [2], but I am unaware of any announcements of Torservers/Zwiebelfreunde itself (i.e. tight financial situation). Does anybody have further details here?

(b) Who is the operator behind family B771AA877687F88E6F1CA5354756DF6C8A7B6B24 ? There are some /24 IPv4 BGP allocations claiming to belong to the umbrella organisation "Zwiebelfreunde e.V.", which operate(d|s) the relay family mentioned above.

I will ask further questions about this in (c) .

However, there is a _huge_ relay family (27 members, with a total bandwith of ~ 1,245 MB) located in 185.220.101.0/24 , which uses Zwiebelfreunde as a contact role and has not been changed since 2017-09-08.

The relays itself, however, all use <abuse@to-surf-and-protect.net> as contact address (which does not seem to be related to Zwiebelfreunde at all) and use a description beginning with "nifty".

Since most of them have both Guard and Exit flag assigned, I figure they are handling a huge consensus weight. Does anybody know the person/organisation behind them? Are they related to Zwiebelfreunde/Torservers? What is the physical location of the servers (BGP claims DE, but upstream AS200052 uses UK)?

(c) Strange BGP allocations using Zwiebelfreunde as contact role At the moment, 9 IPv4 BGP prefixes with a length of /24 are known to use a contact role pointing to Zwiebelfreunde [4] .

These are as follows: - 37.218.246.0/24 (Upstream AS47172 "Greenhost", claims EU, but is likely NL, 0 Tor relays found) - 193.235.207.0/24 (Upstream AS196689 "Digicube", claims EU, but is likely FR, 0 Tor relays found) - 192.36.61.0/24 (Upstream AS60781 "Leaseweb", claims EU, but is likely NL, 0 Tor relays found) - 192.36.41.0/24 (Upstream AS34305 "BaseIP", claims EU, but is likely NL, 0 Tor relays found) - 192.36.27.0/24 (Upstream AS60729 "Zwiebelfreunde" !, claims EU, physical location unknown, 0 Tor relays found) - 185.220.102.0/24 (Upstream AS60729 "Zwiebelfreunde" !, claims EU, physical location unknown, 0 Tor relays found) - 185.220.101.0/24 (Upstream AS200052 "Joshua Peter McQuistan", claims DE, physical location unknown, 27 Tor relays found)

What puzzles me here is: 1. None of these networks has any Tor relays known (or Metrics does not show them), which is strange as Torservers/Zwiebelfreunde is more or less dedicated to operate relays.

2. The appearing relays solely belong to the strange and huge family mentioned in (b) , which cannot be exactly pinpointed to be run by Torservers/Zwiebelfreunde.

3. I suspected the mentioned IP ranges to be fakely allocated, but most of them were not changed for more than half a year. Further, I never observed any traffic from or to these networks. If anybody does, please drop me a line.

4. All for relays which do belong to Torservers are located in AS43350 ("NForce Entertainment") and do not have their own IPv4 prefix.

***

As of these coincidences, and the observations mentioned in (a) and (b), I suspect something nasty (or highly unusual) is going on, but I have no clue what this might be.

It would be great if someone who is in Tor more deeply than I am could take a look at this. Also, if there is further information available, please tell me.

"Mit dem Wissen wächst der Zweifel. / Doubt grows with knowledge." -- Goethe

Best regards, T. Westerhever

Links: [1] https://metrics.torproject.org/rs.html#search/family:0FF233C8D78A17B8DB7C825... [2] https://blog.torservers.net/20180704/coordinated-raids-of-zwiebelfreunde-at-... [3] https://metrics.torproject.org/rs.html#search/family:B771AA877687F88E6F1CA53... [4] https://bgp.he.net/ _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Hi! On 08.09.2018 09:43, Tobias Westerhever wrote:

(a) Torservers relay family decreased? The organisation used to maintain much more relays than their family [1] currently contains. At the moment, only four relays located in NL belong to them, while the Metrics page indicates some orphaned family members.

Please note: "Torservers" is a umbrella project by 23 organizations https://torservers.net/partners.html , each of which has their own independent infrastructure. So far, only the German founding member Zwiebelfreunde has been using the @torservers.net addresses (which are open to other members as well), which adds to the confusion. We are a bunch of volunteers that are very bad about keeping everything well documented. There is nothing secret or strange happening, just some poor overworked few that have failed to attract flesh blood with time to take over. We have a bunch of exit relays on our own AS https://metrics.torproject.org/rs.html#search/185.220.102 and the NForce ones. We used to run more, but are shutting down more and more because of lack of time to properly maintain everything.

This coincidences with [2], but I am unaware of any announcements of Torservers/Zwiebelfreunde itself (i.e. tight financial situation). Does anybody have further details here?

It's less a problem of finances, but of time.

(b) Who is the operator behind family B771AA877687F88E6F1CA5354756DF6C8A7B6B24 ? There are some /24 IPv4 BGP allocations claiming to belong to the umbrella organisation "Zwiebelfreunde e.V.", which operate(d|s) the relay family mentioned above.

We became RIPE LIR, and as such have a /22 which we can re-assign to "end users". One such "end user" is nitfy, who was one of the few interested parties who repied to our offer of IP addresses on tor-relays some time back.

However, there is a _huge_ relay family (27 members, with a total bandwith of ~ 1,245 MB) located in 185.220.101.0/24 , which uses Zwiebelfreunde as a contact role and has not been changed since 2017-09-08.

185.220.101.0/24 does not use Zwiebelfreunde as contact role? This is niftys network, which uses IPs provided by Zwiebelfreunde but admin-c and tech-c point to nitfy.

(c) Strange BGP allocations using Zwiebelfreunde as contact role At the moment, 9 IPv4 BGP prefixes with a length of /24 are known to use a contact role pointing to Zwiebelfreunde [4] .

These are as follows: - 37.218.246.0/24 (Upstream AS47172 "Greenhost", claims EU, but is likely NL, 0 Tor relays found) - 193.235.207.0/24 (Upstream AS196689 "Digicube", claims EU, but is likely FR, 0 Tor relays found) - 192.36.61.0/24 (Upstream AS60781 "Leaseweb", claims EU, but is likely NL, 0 Tor relays found) - 192.36.41.0/24 (Upstream AS34305 "BaseIP", claims EU, but is likely NL, 0 Tor relays found) - 192.36.27.0/24 (Upstream AS60729 "Zwiebelfreunde" !, claims EU, physical location unknown, 0 Tor relays found)

We used to use those for a larger operation with partner organizations exclusively for bridges and are in the process of removing them and givign them back to the IP provider.

- 185.220.102.0/24 (Upstream AS60729 "Zwiebelfreunde" !, claims EU, physical location unknown, 0 Tor relays found)

We use this for exits, which are currently down because of some ongoing maintenance (while I am on vacation writing from a camping site in Italy).

- 185.220.101.0/24 (Upstream AS200052 "Joshua Peter McQuistan", claims DE, physical location unknown, 27 Tor relays found)

There should also be 185.220.103.0/24 in use for exits by another organization, and 185.220.104.0/24 currently unassigned.

2. The appearing relays solely belong to the strange and huge family mentioned in (b) , which cannot be exactly pinpointed to be run by Torservers/Zwiebelfreunde.

We own the IP space, but have delegated them to other parties for actual exit operation.

3. I suspected the mentioned IP ranges to be fakely allocated No, everything is correct, just heavily underdocumented and not well maintained. :)

Thanks for watching out! Moritz

On 9 Sep 2018, at 07:29, Moritz Bartl <moritz@torservers.net> wrote:

...

On 08.09.2018 22:19, Paul wrote: i am glad that somebody else got notice and i agree, suspecting something nasty (or highly unusual) is going on. There was a discussion about that in Berlin in July already https://trac.torproject.org/projects/tor/wiki/org/meetings/BerlinRelayOperat... but no public follow-up since then.

It's weird because nobody asked us, whereas the IP assignments clearly point to us (and the meeting even happened in a space I am responsible for)...

As far as I know, nobody asked any of the questions from the wiki on tor-relays@ (or #tor-relays). So I'll try to answer them here:

A large-scale operator (with more than 20 exit relays) was wondering about the effects of the newer tor versions and the MyFamilyconfiguration option.

After setting up the MyFamily saw a 50% drop on the number connections and the usage of the relay bandwidth;

MyFamily tells Tor clients that relays are run by the same entity. Clients avoid using more than one relay from a family in a circuit. This means that relay operators can't do end-to-end traffic correlation. (Which makes it easier for operators to refuse legal requests.) See https://www.torproject.org/docs/tor-manual.html.en Circuits are chosen at random. Exits are only used in the Exit position (and as HSDirs). So the it's unlikely that the bandwidth drop was caused by MyFamily. (The operator would also need to have 50% of the Guards and Middles in the Tor network, excluding any Exits.) If the operator would like help diagnosing the issue, we'll need more information: * the identities of the relays * the dates of the drop * did the consensus weight drop as well?

This person would like to push more bandwidth and would like to find out how to better achieve this scenario;

It depends on why the bandwidth is limited. Here are some common reasons: Are your exits using 50% or more of their bandwidth? Good! You are providing fast, low-latency Internet access. Ideal networks have about 10% utilisation. 100% utilisation causes delays and dropped connections. Tor Exits are at about 50% : https://metrics.torproject.org/bandwidth-flags.html Are some CPU cores maxed out? Run more Tor instances (but only 2 per IPv4). Are the relays a long way away from the bandwidth authorities (US/DE/SV)? Get relays that are closer. Did the bandwidth drop move the relays into a lower measurement partition? We're working on a partitionless bandwidth measurement system, sbws. We're not sure when it will be deployed, but we're hoping in 2019. Here are some more details: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow

The current feature for DDoS protection is really optional, or does it need to be manually enabled? (regarding the traffic drop on the relays mentioned before)

The DDoS protection is turned on in the consensus: https://consensus-health.torproject.org/#consensusparams (It is also on by default, with slightly different settings.) There is no need to manually enable the feature. And you shouldn't turn it off, because accepting DDoS connections makes other relays slow.

...

There seems to be a private person who is holding this family https://metrics.torproject.org/rs.html#search/family:1084200B44021D308EA4253... and ran between 10-15% exit probability in the last six months - which i personally judge as far too high for a single person, or even an entity.

Agreed. I had a longer discussion with nifty around diversity some time ago, but ultimately it is up to individual operators. I have no reason to doubt the legimitate interest of nifty to simply support the Tor network. There used to be times when single operators were in control of 80% of the exit capacity, and we worked hard to get it more diversified. There is a lot of room for improvement, and other networks like OVH see even more Tor traffic...

I have similar conversations with nifty. I think they simply want to improve the Tor network. I don't think asking operators to limit themselves is a good idea. Instead, we need to encourage people to run more exits. If you have time and skills, give that time to organisations that run exit relays (or run some yourself). If you have money, do the same. Otherwise, promote their work, and make it easy for them to help the network. T

Hi, nusenu:

Moritz Bartl:

...

On 08.09.2018 22:19, Paul wrote:

...

i am glad that somebody else got notice and i agree, suspecting something nasty (or highly unusual) is going on. There was a discussion about that in Berlin in July already https://trac.torproject.org/projects/tor/wiki/org/meetings/BerlinRelayOperat... but no public follow-up since then.

It's weird because nobody asked us, whereas the IP assignments clearly point to us (and the meeting even happened in a space I am responsible for)...

I noted the same thing on 2018-07-25 as well: https://lists.torproject.org/pipermail/tor-relays/2018-July/015759.html

maybe andz@torproject.org (author of the wiki page) can clarify?

Usually when a person organize a meetup it has the role of collecting/taking notes as the author of this wiki page did. I cannot speak for the people that made the comments/inquiries and that's why we have this list and many more communication channels (such as IRC). Regarding the IP assignments we had a talk at #torservers as well as private chats. I think Moritz clarified the IP assignments situation already. Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162

On 9/17/18 11:24 AM, nusenu wrote:

...

We have a bunch of exit relays on our own AS https://metrics.torproject.org/rs.html#search/185.220.102 and the NForce ones. We used to run more, but are shutting down more and more because of lack of time to properly maintain everything. are you actively looking for other (trusted) entities to take over / help you with operations?

Yes. We have talked to people in person since before 2013. I have tried to get you on board several times, for example to replace the website with a nice map of all torservers relays (by all partners), or a static map of all partner orgs. We would need an issue tracker to dump all the ideas in, but it won't help if there is nobody with capacity to coordinate. We do NOT need a tech sysadmin; the sys admin is the smallest and easiest bit. There is a lot of coordination necessary, because it is impossible to find someone to take over everything that is going on at once. We have spent countless hours on "trying to integrate new people" but if we lack the person(s) to coordinate, it is a lot of wasted effort for everyone. The alternative that I have been suggesting since 2014 is to "shut down" Torservers, to make it clear that it is in no way achieving its goals due to lack of time. -- Moritz Bartl https://www.torservers.net/

On 9/18/18 1:31 PM, nusenu wrote:

[but torservers.net says: "We run managed and unmanaged nodes" and "Our goal is to run exit nodes"?]

Yes. The collective group does that. Everything you state is correct.

ok than I misunderstood your earlier sentence ("but are shutting down more and more because of lack of time to properly **maintain** everything."), so you are not specifically looking for technical people but people coordinating things (what kind of things?)

Everything that one can think about to do, both as German Zwiebelfreunde as well as "as umbrella". For example, we never managed to produce financial transparency on either level, which is a shame also towards the partner organizations. We have no task list and I didn't start one because (from experience) that means spending a lot of time coordinating things.

Since I've seen the shutdown "notice" before I assume it won't be happening soon and sharply but I still would like to get an understanding of the scope of the "shutdown".> When you say "shut down Torservers" is that limited to the umbrella project or does that also include Zwiebelfreunde e.V., your relays and the RIPE membership/LIR (and therefore also affects those that make use of your IP space)?

It would be a slow shutdown, with probably LIR functions remaining. In some respect we are already "shut down" since we don't do much actively any more, neither as association nor as umbrella. We still perform the functions claimed on the website, and we still convert donations to exit traffic, but there's a lot more we could be doing. -- Moritz Bartl https://www.torservers.net/