[tor-relays] Tor non-exit list

Mailing Lists tor-relays
1

Hi Dan,

For reference:

https://www.dan.me.uk/torlist/?full

First of all, thank you for your tools and other contributions. The mere
fact that your DNS blocklists are used by countless vendors should be a
compliment in itself, and I'd be happy to have that much impact with my
own projects.

As you already state on your own site ("Please think carefully
before choosing to use this list for blocking purposes"), your non-exit
Tor relay list is a bit unusual. I'm running ftp.halifax.rwth-aachen.de,
a major file mirror serving around 30 TByte of data at around 4 GBit/sec
(on average). Recently, we added Tor relays on the same IP address, and
your list correctly picked this up (137.226.34.46).

Now, I'm writing as this caused quite a lot of mayhem. Several
"security" appliance vendors didn't "think carefully" before adding your
non-exit list to their devices. Among those are Arbor Prevail, Check
Point, Ubiquiti (UniFi) - feel free to search for

  "ET TOR Known Tor Relay/Router (Not Exit) Node"

to see the effect of this. In addition to private users making use of
such devices, several banks/corporations/institutions started blocking
our IP address, causing some frustration with us and their admins, as
their Linux/Jenkins/... updates suddenly stopped working. As you might
have guessed, changing "security" configurations (even if they may be
wrong or questionable) is quite a challenge, and in some cases the
(motivated) admins weren't unable to fix this issue on their end.

As you seem to be well aware of what Tor is, what an exit relay does and
what a non-exit relay does, would you be willing to retire the non-exit
blocklist (at least the part that can be used for automated blocks)? I'd
argue that the current setup does more harm than good (assuming you
agree that Tor is a good thing in general). I'd be happy to discuss pros
and cons, but ultimately that's your decision to make.

Thanks
Carsten

···

--
Dr. Carsten Otto
http://verify.rwth-aachen.de/otto/

2 Likes
2

Hi Carsten,

While I appreciate your effort to make running (non-exit) relays more usable for regular internet usage, and I myself face similar issue. My relay is also my mail host. I sometimes cannot send or receive to certain organizations due to their firewall policies.

I do not think that asking to remove the complete non-exit list to be valuable to the security of the global internet.

While it is correct that sysadmins should maybe not block traffic just because it's a relay. There is many use cases where they should, most corporation end users do not need access to the Tor network daily, and many ransomware or other malware c2 servers leverage .onion services. By blocking Tor across the network it's a simple way to disarm the malware or prevent data loss to nefarious actors.

Secondly, running multiple services from your Tor relay is generally considered bad advice if I understand correctly. Especially critical infrastructure such as mirrors of popular packages. Tor relays should be dedicated hosts with minimal attack surface, we know they are attacked, monitored, and generally attract extra attention. Due to this other services you host on the same server are now at risk of extra surveillance or malicious attacks.

Just my two cents, I with DAN list non-exit did not exist either, but it has it's purposes.

Regards, tor

Carsten Otto:

···

Hi Dan,

For reference:
DNS Blacklists (RBL/DNSBL)
TOR Node List
https://www.dan.me.uk/torlist/?full

First of all, thank you for your tools and other contributions. The mere
fact that your DNS blocklists are used by countless vendors should be a
compliment in itself, and I'd be happy to have that much impact with my
own projects.

As you already state on your own site ("Please think carefully
before choosing to use this list for blocking purposes"), your non-exit
Tor relay list is a bit unusual. I'm running ftp.halifax.rwth-aachen.de,
a major file mirror serving around 30 TByte of data at around 4 GBit/sec
(on average). Recently, we added Tor relays on the same IP address, and
your list correctly picked this up (137.226.34.46).

Now, I'm writing as this caused quite a lot of mayhem. Several
"security" appliance vendors didn't "think carefully" before adding your
non-exit list to their devices. Among those are Arbor Prevail, Check
Point, Ubiquiti (UniFi) - feel free to search for

   "ET TOR Known Tor Relay/Router (Not Exit) Node"

to see the effect of this. In addition to private users making use of
such devices, several banks/corporations/institutions started blocking
our IP address, causing some frustration with us and their admins, as
their Linux/Jenkins/... updates suddenly stopped working. As you might
have guessed, changing "security" configurations (even if they may be
wrong or questionable) is quite a challenge, and in some cases the
(motivated) admins weren't unable to fix this issue on their end.

As you seem to be well aware of what Tor is, what an exit relay does and
what a non-exit relay does, would you be willing to retire the non-exit
blocklist (at least the part that can be used for automated blocks)? I'd
argue that the current setup does more harm than good (assuming you
agree that Tor is a good thing in general). I'd be happy to discuss pros
and cons, but ultimately that's your decision to make.

Thanks
Carsten

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

3

I do not think that asking to remove the complete non-exit list to be
valuable to the security of the global internet.

However, this non-exit list should not be activated automatically or with one-
click. There is no reason to block non-exit relays.

While it is correct that sysadmins should maybe not block traffic just
because it's a relay. There is many use cases where they should, most
corporation end users do not need access to the Tor network daily, and
many ransomware or other malware c2 servers leverage .onion services. By
blocking Tor across the network it's a simple way to disarm the malware
or prevent data loss to nefarious actors.

Ransomware links are usually opened from emails and Tor is not running on
company computers. Users cannot install anything either. How are they supposed
to reach the hidden services?

Users can bypass this blocklist with bridges from their private devices. There
are private things that are none of the sysadmins' business and for this some
users use Tor or VPN.

Secondly, running multiple services from your Tor relay is generally
considered bad advice if I understand correctly. Especially critical
infrastructure such as mirrors of popular packages. Tor relays should be
dedicated hosts with minimal attack surface, we know they are attacked,
monitored, and generally attract extra attention. Due to this other
services you host on the same server are now at risk of extra
surveillance or malicious attacks.

You are right that a dedicated IP for a Tor relay would be better.
On the other hand, we want more relays at universities.

Many users cannot reach the mirror Halifax = ftp2.de.debian.org

We should perhaps consider at the relay meeting on Saturday whether several
relay operators or the Tor Project could write to dan.me.uk. He shouldn't make
it so easy to activate the non-exit list. For example, UniFi devices are often
installed by inexperienced admins. They simply click on all the block lists
without knowing what they are.

···

On Donnerstag, 20. Juni 2024 02:00:18 CEST tor@nullvoid.me wrote:

--
â•°_â•Ż Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

4

boldsuck:

However, this non-exit list should not be activated automatically or with one-
click. There is no reason to block non-exit relays.

I agree, maybe this open letter is better aimed at the security vendors that include DAN's (non-exit) Tor relays list on a blocklist by default, or without warning about potential impact to other legitimate services (universities, libraries, shared hosting providers, hobbyist email, etc)

Ransomware links are usually opened from emails and Tor is not running on
company computers. Users cannot install anything either. How are they supposed
to reach the hidden services?

Once the malware runs it will phone home over Tor to the .onion, from a network perspective this will look like a TCP connection to an entry node. I can see many reasons to maintain a list on known entry nodes to prevent unauthorized applications or users from connection out of a network. Those lists should not be enabled by default to block.

We should perhaps consider at the relay meeting on Saturday whether several
relay operators or the Tor Project could write to dan.me.uk. He shouldn't make
it so easy to activate the non-exit list. For example, UniFi devices are often
installed by inexperienced admins. They simply click on all the block lists
without knowing what they are.

Maybe reaching out to UniFi would be better than to the DAN project.
I agree discussion with the rest of the relay community and a strong consensus on how to approach the over-blocking problem would be nice.

Regards,

···

On Donnerstag, 20. Juni 2024 02:00:18 CEST tor@nullvoid.me wrote:

5

First of all, thank you for your tools and other contributions. The mere
fact that your DNS blocklists are used by countless vendors should be a
compliment in itself, and I'd be happy to have that much impact with my
own projects. (…)

   Operating a non-exit Tor relay I face similar issues. I can’t trace them back to this particular blocklist, but with high confidence can tell the challenges we face are from indiscriminately using blacklists. Some of them do contain Tor non-exit relays. So I can do nothing more than I support Carsten’s plea.

   Over years no party blocking non-exit relays was able to provide me with a single example of an actual incident, despite continued claims it’s a “malicious traffic from *my* address”. After changes on their end that “malicious traffic” was magically no longer observed.

   I myself can’t conceive any actual attack coming from a non-exit relay with probability notably higher than from other machines on the internet. The relay itself isn’t designed to connect to machines other than Tor relays, so certainly its intended use doesn’t lead to higher risk. All other factors and attacks should at worst be the same as for the general population.

Cheers and thanks for providing the lists, mpan.

···

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like
6

I agree, maybe this open letter is better aimed at the security vendors that include DAN's (non-exit) Tor relays list on a blocklist by default, or without warning about potential impact to other legitimate services (universities, libraries, shared hosting providers, hobbyist email, etc)

   Security vendors are not the only users of such lists. There is much more entities and people, that use them without any intermediaries. Negotiating with every single of them is not only whack-a-moling, but also inefficient compared to addressing the issue at the source.

   The issue could be approached in other ways too, but I don’t find them satisfying. It would require things like changing the license, which is an idea I can’t stand behind. It would also demand more effort from Dan, which is unacceptable given he’s offering that free of charge, and likely lead to employing practices I despise.

Once the malware runs it will phone home over Tor to the .onion, from a network perspective this will look like a TCP connection to an entry node. I can see many reasons to maintain a list on known entry nodes to prevent unauthorized applications or users from connection out of a network. Those lists should not be enabled by default to block.

   That’s a good point, but there are things to note.

   Tor entry nodes are publicly known. An organization, that believes they need such a protection, may obtain the list directly from Tor Project. This requires additional effort, yes. But it should require effort. It’s not big, compared to how much it takes to make such a decision in a responsible manner. And it protects against blindly using blocklists without thinking.

   This is the same reasoning that was driving Polish internet operator (TP) to blanket block servers suspected of running IRC. Not merely connections to IRC, which is questionable on its own, but servers: so one couldn’t e.g. access websites of many FOSS projects. In my college I had to sign additional papers to be able to access some Wikipedia articles. URLs could contain a particular word also found on porn sites, so the college seen this as a risk of students committing the crime of exposing other students to inappropriate content. We see mandating backdoors in encryption, which use the same logic: encryption helps committing crimes. Finally, something probably most close to any Tor user’s heart: a requirement to be fully tracked everywhere or otherwise treated as a second class citizen. Yes, that is also commonly rationalized by protection against attacks. So it’s worth asking, if this is acceptable reasoning.

···

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like
7

Hi Carsten,

Although I understand why you're directing your comments to Dan, because
his site is popular, but you should note that even if he decides to take
that list down, his site is not the only way for people to get their
hands on the list. In fact anyone with basic know-how can extract them
from Tor metrics:

https://onionoo.torproject.org/details?type=relay&running=true

I've been generating [the same list and more in my
repository](GitHub - Enkidu-6/tor-relay-lists: Automatically updated lists of Tor Relays.)
for probably a couple of years now. Anyone who's using my [tor ddos
Mitigation iptables rules](GitHub - Enkidu-6/tor-ddos: iptables rules for Tor relay operators to mitigate ddos)
knowingly or not, is using that list.

My point is, that as long as the information is a matter of public
records and accessible freely on Tor metrics, you can't stop Admins from
using it. So any objections to the list should be pointed at Tor
organization as a whole for making it publicly available. And by the
way, not making it public will create a whole lot of other challenges.

Cheers.

···

On 6/19/2024 3:37 AM, Carsten Otto wrote:

Hi Dan,

For reference:
https://www.dan.me.uk/dnsbl
TOR Node List
https://www.dan.me.uk/torlist/?full

First of all, thank you for your tools and other contributions. The mere
fact that your DNS blocklists are used by countless vendors should be a
compliment in itself, and I'd be happy to have that much impact with my
own projects.

As you already state on your own site ("Please think carefully
before choosing to use this list for blocking purposes"), your non-exit
Tor relay list is a bit unusual. I'm running ftp.halifax.rwth-aachen.de,
a major file mirror serving around 30 TByte of data at around 4 GBit/sec
(on average). Recently, we added Tor relays on the same IP address, and
your list correctly picked this up (137.226.34.46).

Now, I'm writing as this caused quite a lot of mayhem. Several
"security" appliance vendors didn't "think carefully" before adding your
non-exit list to their devices. Among those are Arbor Prevail, Check
Point, Ubiquiti (UniFi) - feel free to search for

  "ET TOR Known Tor Relay/Router (Not Exit) Node"

to see the effect of this. In addition to private users making use of
such devices, several banks/corporations/institutions started blocking
our IP address, causing some frustration with us and their admins, as
their Linux/Jenkins/... updates suddenly stopped working. As you might
have guessed, changing "security" configurations (even if they may be
wrong or questionable) is quite a challenge, and in some cases the
(motivated) admins weren't unable to fix this issue on their end.

As you seem to be well aware of what Tor is, what an exit relay does and
what a non-exit relay does, would you be willing to retire the non-exit
blocklist (at least the part that can be used for automated blocks)? I'd
argue that the current setup does more harm than good (assuming you
agree that Tor is a good thing in general). I'd be happy to discuss pros
and cons, but ultimately that's your decision to make.

Thanks
Carsten

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays