Re: [tor-relays] Tor non-exit list

[Chris Enkidu-6]

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=true

I've been generating [the same list and more in my
repository](https://github.com/Enkidu-6/tor-relay-lists?tab=readme-ov-file#tor-relay-lists)
for probably a couple of years now. Anyone who's using my [tor ddos
Mitigation iptables rules](https://github.com/Enkidu-6/tor-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
> https://www.dan.me.uk/tornodes
> 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
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Way to be notified when relay goes offline?

[Chris Enkidu-6]

Or, like me, you can run your own monitoring service:

https://github.com/louislam/uptime-kuma

docker-compose.yml  content:

```

version: '3.8'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    volumes:
  - uptime-kuma:/app/data
    ports:
  - "3001:3001"  # :
    restart: always

volumes:
  uptime-kuma:

```




On 2/4/2024 4:33 PM, mail--- via tor-relays wrote:
> Hi,
>
> > Is there a way to be notified when a relay goes offline? Thanks.
>
> For a few relays you could make an account on weather.torproject.org
> and add your email address and relays. But pretty much any other
> remote monitoring tool will suffice as well.
>
> Cheers,
>
> tornth
>
>
> Feb 4, 2024, 22:30 by keifer@gmail.com:
>
> Hi,
>
> So my relay at 
> 
> https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D
>  
> went offline for a few days, and I was unaware. Is there a way to
> be notified when a relay goes offline? Thanks.
> --Keifer
>
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] A new kind of attack?

[Chris Enkidu-6]

I've noticed a new kind of possible attack on some of my relays, as
early as Dec.23 which causes huge spikes of outbound traffic that
eventually maxes out RAM and crashes Tor. The newest one today lasted
for 5 hours switching between two of the three relays on the same IP.

During the attack, Tor becomes so busy processing the traffic that it
becomes unresponsive to new connections for minutes at a time and
effectively becomes a zombie exclusively processing the attacker's
traffic until it eventually crashes and restarts. The interesting part
is that when Tor restarts, it doesn't start from scratch building new
circuits but it starts right from where it left out and keeps processing
the previous connections.

I have tried shutting down Tor for over 5 minutes and within one minute
of restart, The RAM maxes out and the outbound traffic reaches the
previous heights.

This has been happening, not to all relays but to a select group of
relays at a time and unless you're monitoring your Tor port from
outside, you may not notice it's unresponsive. Another way to see if
it's happening to you too is to check your monthly history on the
metrics page and look for spikes of written bytes or sudden decrease of
read bytes where you see a big gap between the two.

I have included charts and excerpts from the log in my post in Tor forum
at below link:

https://forum.torproject.org/t/new-kind-of-attack/11122

I'd appreciate your insights and comments.

Thank you.

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

Re: [tor-relays] Relay that's been running for a long time suddenly saying it's new?

[Chris Enkidu-6]

It's not just you. 3 of my relays show as new for the past few days and
they still do. It doesn't seem to affect the traffic though so I'm
assuming it's just a reporting issue and Authorities don't see your
relay as new.


On 1/12/2024 1:00 PM, Keifer Bly wrote:
> Hi,
>
> So my relay
> at 
> https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D
> is suddenly saying it's a new relay. Don't know why this would happen
> as it's been running for a few years, but suddenly saying it's new?
>
> Thanks.
>
> --Keifer
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay data limit

[Chris Enkidu-6]

Hi Dan,

There's of course another option. Change your provider unless it's
important to you to use them in particular. The market is full of good
deals with very good bandwidth allowances. I really don't understand how
some providers can get away with using bandwidth as money grab.

I use my own bare metal but I also got myself a VPS for some tests and
once I was done with my tests, it was so cheap that I kept it and turned
it into a Tor relay. I'm not suggesting that you use them, I'm just
showing you one of the options out there

https://www.webtropia.com/en/cloud-vps.html

For 4.99 (4.49 if you're outside Europe because they won't charge you
tax) you'll get 4 cores 8 GB Ram and 40 TB of monthly bandwidth and they
don't count the download.

I've set up the relay bandwidth to  ``` RelayBandwidthRate 176 MBits ```
and it's been consistently relaying about 36 to 38 TB monthly for the
past 10 months and never goes over 40. I hardly even look at it except
for updates.

There are plenty of providers out there that offer you good deals like this

Cheers


On 12/22/2023 10:30 AM, Dan wrote:
> Hi George,
>
> Thanks for all the input.
>
>> Or, just ask the provider for more bandwidth per month, generally now in 
>> 2023 it's pretty damn cheap.
> I had not considered this, but when contacted my VPS provider offered another 
> 5TB for an additional $3/month. Considering the box only costs $4/month, I 
> think this is the best option.
>
> I'll probably remove all limits for January and just see how much traffic 
> gets transferred.
>
> ---
> Thanks,
> Dan
>
>
>>  
> On Thursday, December 21st, 2023 at 8:04 AM, George Hartley via tor-relays 
>  wrote:
>
>
>> Hi Dan,
>>
>>> 1 - Is it better for the network if the relay is active 24/7, even if 
>>> sometimes it's much slower?
>> Generally according to the relay requirements a relay is considered useful 
>> if it can at least route 2MB/s or 16 MBit/s steadily.
>>
>> However, I think you should get away with 1MB/s or 8 MBit/s.
>>
>>>  2 - Will it negatively affect my relay's reputation if sometimes it's very 
>>> slow?
>> The Tor authorities might reduce your middle probability, but you will not 
>> be punished in any way, and as soon as automatic bandwidth measurements 
>> confirm that you have more capacity available,
>>
>> the authorities should start directing more traffic to your relay.
>>
>> Some possible other ideas:
>>
>> Rate-limit traffic to your relay using RelayBandwidthRate and 
>> RelayBandwidthBurst, but with only 5TB of monthly traffic you will end up 
>> rate-limiting it to somewhere in the 1,8 to 2MB/s range to not hit your 
>> traffic cap.
>>
>> Or, just ask the provider for more bandwidth per month, generally now in 
>> 2023 it's pretty damn cheap.
>>
>> All the best,
>> George
>>
>>
>>
>>> Hi all,
>>>
>>> I've been running a middle relay on a VPS for about 2 months now. The 
>>> provider limits the monthly data transferred to 5TB but does not charge for 
>>> over-usage. Instead, the bandwidth is throttled to 1Mb/s after the limit is 
>>> reached until the 1st of the next month.
>>>
>>> I currently have AccountingMax set to 2.5 TB (since it's the max in each 
>>> direction) and AccountingStart set to "month 1 00:00". Generally that 5TB 
>>> limit is hit between the 15th and 17th of the month, causing the relay to 
>>> go dormant until the 1st.
>>>
>>> What I'm wondering is:
>>>
>>> 1 - Is it better for the network if the relay is active 24/7, even if 
>>> sometimes it's much slower?
>>> 2 - Will it negatively affect my relay's reputation if sometimes it's very 
>>> slow?
>>>
>>> Thank you
>>>
>>> --
>>> Dan
>>>
>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit operators on the 0.4.8.x series, please upgrade to 0.4.8.10 ASAP!

[Chris Enkidu-6]

And epel repo for Centos and Almalinux pretty please...


On 12/8/2023 3:20 PM, Georg Koppen wrote:
> Hello exit node operators!
>
> Today (2023-12-08) the Network Team has released a new Tor version,
> 0.4.8.10[1]. This update contains a fix to a remotely triggerable
> crash bug (TROVE-2023-007) affecting exit relays on the 0.4.8.x
> series. Please upgrade as soon as possible to maintain network
> stability and security if your relays are on that series.
>
> For those of you running their Tor relays using the Tor Debian
> repository, expect a new deb package to be available soon.
>
> Please note that this bug is specific to Tor exit relays on the
> 0.4.8.x series and does not impact other relays nor Tor clients or Tor
> powered apps (Tor Browser, Orbot, OnionShare).
>
> Thanks,
> Georg
>
> [1] https://forum.torproject.org/t/security-release-0-4-8-10/10536
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay no longer acting as a gaurd node?

[Chris Enkidu-6]

Just wondering, you haven't set a bandwidth limit on that node, have
you? Setting an AccountingMax directive will cause you to lose your
Guard flag since your server can't be available at all times.


On 11/9/2023 10:03 AM, Jonathan Proulx wrote:
> Hi All,
>
> A little while ago one of my relays switched from usually acting as a
> guard node to never acting as a guard node:
>
> https://metrics.torproject.org/rs.html#details/9715C81BA8C5B0C698882035F75C67D6D643DBE3
>
> Doesn't matter to me if it's a guard or not jsut want to understand
> what's changed and if it's a problem. Do I have a misconfiguration?
>
> -Jon
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Receiving abuse reports for Non-Exit Relay

[Chris Enkidu-6]

As others have mentioned, this does not look like a Tor issue to me. It
more seems like a compromised or misconfigured server.

You mentioned you reinstalled the OS. Did you use the same root
password? My suggestion is that you go about this step by step. First
reinstall the OS with a different root password and no additional
software or configuration. Wait to see if you get any abuse reports. The
next step, install Tor and wait to see if you get an abuse report. And
the last step would be installing any additional packages that you might
be currently using for anything else if any.

This method could narrow down the cause.



On 7/23/2023 6:07 PM, John Crow via tor-relays wrote:
> Hello all,
>
> In the past 24 hrs, I have been receiving complaints from my hosting
> provider that they're receiving hundreds of abuse reports related to
> port scanning. I have no clue why I'm all of the sudden receiving
> abuse reports when this non-exit relay has been online for months
> without issues. In addition, I have other non-exit relays hosted by
> the same provider with no issues and more across other providers.
>
> I proceeded to reinstall the OS and reconfigure Tor.  I was then
> quickly notified by my hosting provider again of more abuse reports
> all showing port 22 as target port.
>
> I have not changed my torrc at all and it's still setup as a non-exit
> relay. No other applications/services were installed alongside Tor.
> Tor Metrics does not show the relay as Exit either.
>
> It feels like Tor Exit Traffic is leaking through my non-exit relay?
>
> Has anyone else experienced any behavior similar to this? Any ideas on
> how to fix or prevent this?
>
> prsv admin
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay Bandwidth

[Chris Enkidu-6]

Hi,

The reason you find the answers confusing is because the whole thing is
confusing. A lot of what you see advertised by hosts is somehow
misleading. For example they advertise a 1000 mb/s network speed and
then they give you 3 TB of bandwidth. The truth is that even if you have
a sustained network speed of 100 mb/s, you'll be using 32.8 TB of
bandwidth for the month. To use 3 TB a month, you need to have a
sustained upload speed of 9 mb/s which is far below the speeds of a home
Internet.

As for the math, use [the Hosting bandwidth converter on this yet
another confusing
page](https://www.calculator.net/bandwidth-calculator.html#hosting)

The second confusing part is that just because you set your
RelayBandwidthRate to whatever number, it doesn't mean you'll be
relaying that much. It could be a lot less depending on a lot of factors
and especially during the first month or two and a lot more depending on
your RelayBandwidthBurst. So you can't just set that numbers and be sure
of the outcome.

Your best choice would be to change provider, pay much less and get a
lot more bandwidth. The second best answer is what @Bauruine suggested.
Set your daily used bandwidth to 100 GB assuming DO, like most hosts,
only charges for uploads.

```

AccountingMax 100 GBytes
AccountingStart day 00:00

```

This basically means from midnight to midnight, you'd be relaying 100 GB
upload 100 GB download and then hibernate until the next day. Not my
personal favourite but an option nonetheless.


On 3/31/2023 3:34 PM, sysmanager7 via tor-relays wrote:
> Greetings all!
>
> Setting up a new Digital Ocean Tor Relay. DO is giving me 3000 Gig a
> month. Is there a tutorial that I can use to calculate the bandwidth?
> I've searched around the web and for some reason people seem to dance
> around the question.  They give examples not relevant to me and zero
> math showing how the came to their answer.
>
> As usual, any help will be appreciated :-)
>
>    Sysmanager7
>
> Sent with Proton Mail  secure email.
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts

[Chris Enkidu-6]

Hi, Danny

Those theoretical concerns may or may not be valid as I don't have
enough expertise about how Tor operates under the hood to comment on it,
but I can tell you that currently there are a few different DDoS attacks
with different purposes but they don't seem to have the surgical
accuracy you're suggesting. What I can tell you though is what I
mentioned in my other post. Allowing the numbers of established
connections per IP as you suggest would not end well for average operator.

My script also generates a file by the name rules.sh for users to
examine and see what actually happened to their system when they ran my
script. It's nothing but iptables rules in plain text with no fancy
scripts or codes. Any operator can modify that file as they wish and
let's say change 2 to 5 and run it again. The new rules will apply and
replace the original. I did that on purpose because I believe users
shouldn't run a script when they may not have the expertise to be able
to tell what the script does simply because they trust me and then hope
for the best.

However if you choose to change those numbers be prepared to be the test
subject instead of me. :)

Cheers


On 2/8/2023 12:09 AM, Xiaoqi Chen (Danny) wrote:
> @Enkidu
>
> As an user of your filtering script, I want to first say thank you for
> maintaining the script!
>
> > The idea that all relays must be able to connect to other relays any
> time and in any shape or form they choose can not exist in real world
> of DDoS mitigation.
>
> I totally agree, however I want to also add a note here regarding
> privacy:
> If an adversary can nudge a user to choose some particular circuit /
> relay and
> avoid other circuits, they can break the privacy guarantee of Tor
> network.
> Aggressive automated rate limiting might provide adversaries with this
> opportunity,
> as an adversary might find ways to "trigger" the filtering and cause
> more circuits between
> "good" relays to be blocked, and clients will automatically fall back
> to circults that
> go through two or more malicious relays operated by the adversary
> (leading to deanonymization).
>
> This attack surface is a pure theoretical speculation and probably not
> happening right now.
> Still, at a high level we need to be careful when designing automated
> filtering mechanisms,
> and I suggest erring on the more conservative side. E.g., 5 incoming
> connections per relay
> instance, so if an IP has 4 or 8 relay instances it can have 4*5=20 or
> 8*5=40 connections.
> (Of course, the quota should depend on flags, so an attacker can't
> just spin up 8 new relays per IP.)
>
> Also, it might be good to have a more conservative (higher) rate limit
> by default and
> let users turn it down as necessary.
> --
> Danny
>
> On Tue, Feb 7, 2023 at 8:34 AM Chris Enkidu-6  <mailto:t...@wcbsecurity.com>> wrote:
>
> @nusenu
>
> Thank you very much for taking the time to help me understand things
> better. I can use all the help I can get.
>
>     > You can also not be sure whether it is an actual authenticated
> relay to relay
>     > connection or a client to relay connection just by looking
> at the
> source IP.
>
>
>     > In a vanilla current tor version it is not possible to use a tor
> client
>     > to connect via an exit to another relay's ORPort so this is very
> unlikely.
>
>
>     > An exit can share it's source IP with tor clients for example
> behind NAT
>
> Sorry I'm confused here. Those statements seem to contradict each
> other
> or there's something here
> I misunderstood. Even if that happens, why would a client connect
> directly to an Exit and get the
> Exit to connect to another relay or Guard using the Exit's IP address?
> Wouldn't the same protection you mentioned kick in and
> stop a client?
>
>
>     > I was not able to follow you there. I was unable to find any
> exit
> relay that
>     > has more than one ORPort on IPv4 (I identify relays by
> fingerprint
> not by IP address).
>
> Sorry, I should have been more careful in using my words. In the world
> of firewalls and iptables
> we identify connections by IPAddress:port pairs hence my inaccurate
> wording. A relay has only one ORPort
> but an IP address can have 4.
>
>
>     > I think there is a misunderstanding there. One important
> point to
> take away:
>     > Relays do not chose the next hop in a circuit, tor clients do.
>     > So if my tor clients picks a circuit with these relays:
>     > client -> A -> B -> C -> example.com <htt

Re: [tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts

[Chris Enkidu-6]

> DDoS rate limit filters do not require an all or nothing approach,
> different source IPs can be handled differently
> see toralf's use of onionoo to feed ipsets as an example.
> I would recommend to use tor's controlport as a source of information instead 
> though
> because onionoo is not meant to be used for such real time needs.
We do the same. You can take a look at the rules. There's no all or
nothing approach. Regardless, this doesn't change the fact that in
either approach there's always a time when someone, somewhere will not
be able to connect due to their behaviour.

The ipsets are pulled from [my
repository](https://github.com/Enkidu-6/tor-relay-lists) to avoid
putting undue pressure on oniooo server and my lists are updated every
half an hour. This means one query as opposed to very many for each user.

We do have a ban list and cron jobs to remove relays from the list
periodically -even though I'm not a fan of it- to avoid an all out ban.
However the number of allowed connections remain the same regardless
whether you're in the ban list or not.

ipsets are set to allow authorities and snowflake servers to have as
many connections as they need. Dual-or relays are in another ipset and
they can have more connections per IP. That will still stay limited. How
many would be necessary, is the main reason I started this discussion.

> I don't think relays should silently drop
> other relays packets without first trying:
> - to confirm that accepting that IP would render the relay (mostly) unusable 
> (by first running in a mode that accepts relay IPs)
> - to understand the actual root cause
> - to contact the relay operator at the other
> - to report relays they consider malicious

Firewalls and iptables don't work that way. They make those decisions in
fractions of milliseconds and do what they're told. Now, if you're
suggesting that I should do all of that before writing a rule to protect
my server, I do what I can with the time I have and to a reasonable level.

No new versions of rules are released unless I run them for 2 weeks on
my own servers and check for all possible side effects. I spend time to
investigate the relays that are misbehaving to the best of my knowledge
and ability and spend as much time as I'm willing to spend on it. Again
it's all about that compromise I was talking about. I'm not looking to
achieve an ideal solution for an ideal world. That's not achievable and
would be a waste of time trying. My purpose for this discussion is to
find the best way to keep the balance of that compromise in our favour
and not do damage to the overall health of the Tor network.

Now to clarify a few things, I'll explain my process. The rules are
tested on two relays with 20 MiB Max Advertised bandwidth each and each
one has full use of 12 CPUs and about 5-7 GB of RAM and NumCPUs of 30.
By the way this is far better than the systems majority of relays are
run on. Majority of operators run their relays on VPS systems with 1-4
CPUs and 1-4 GB of RAM.

The idea is that if a ruleset causes my relay to go to the overloaded
status, it will certainly do more damage to weaker relays. I can tell
you with absolute certainty that with the current state of the DDoS
we're experiencing if we allow more than 2 connections per IP (1 would
be better) the average relay will have overloaded status at least 2-3
times a week if not more. Again we're talking about average relays not
beasts.

Now to get back to my original question, I'll try to make it a bit more
clear. It may help you answer my question better. Here are the current
statistics:

Since the start of the new rule of 4 relays per IP, 14 operators have
decided to take advantage of it. Together combined, they are operating
214 relays, out which about more or less 100 something relays are
actually new relays added to the network. Some added two, some added
only one. Among them I've seen fake email addresses, those who haven't
even added the new relays to their family, etc.. By the way those
numbers haven't increased in the past 2 or3 days and remained pretty
much the same.

All of these relays with 3-4 Tor instances are running on a total of 54
IP addresses, 39 of which running purely Exit relays on all instances of
Tor on the IP with 0% guard probability and 0% middle probability. Their
status might change after a couple of weeks to a month when they join
the network with full capacity and I'll be monitoring that.

So I ask my question again, with the current state, right at this
moment, If I allow those limited IP addresses only 2 established
connections at a time instead of 4, will that break anything or cause
any harm to the health of the Tor network as a whole? My own answer is
absolutely not, but I eagerly await everyone's opinion.

Cheers.


On 2/7/2023 6:07 PM, nusenu wrote:
>> Even if that happens, why would a client connect
>> directly to an Exit and get the
>> Exit to connect to another relay or Guard using the Exit's IP address?
>
> You 

Re: [tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts

[Chris Enkidu-6]

@nusenu

Thank you very much for taking the time to help me understand things
better. I can use all the help I can get.

    > You can also not be sure whether it is an actual authenticated
relay to relay
    > connection or a client to relay connection just by looking at the
source IP.


    > In a vanilla current tor version it is not possible to use a tor
client
    > to connect via an exit to another relay's ORPort so this is very
unlikely.


    > An exit can share it's source IP with tor clients for example
behind NAT

Sorry I'm confused here. Those statements seem to contradict each other
or there's something here
I misunderstood. Even if that happens, why would a client connect
directly to an Exit and get the
Exit to connect to another relay or Guard using the Exit's IP address?
Wouldn't the same protection you mentioned kick in and
stop a client?


    > I was not able to follow you there. I was unable to find any exit
relay that
    > has more than one ORPort on IPv4 (I identify relays by fingerprint
not by IP address).

Sorry, I should have been more careful in using my words. In the world
of firewalls and iptables
we identify connections by IPAddress:port pairs hence my inaccurate
wording. A relay has only one ORPort
but an IP address can have 4.


    > I think there is a misunderstanding there. One important point to
take away:
    > Relays do not chose the next hop in a circuit, tor clients do.
    > So if my tor clients picks a circuit with these relays:
    > client -> A -> B -> C -> example.com
    > and B can not reach C, B can not say "oh I can not reach C I'll
pick D instead for you",


I understand that and I think it might be my fault again for not being
clear. It doesn't matter who makes
that choice. What matters is that the choice is being made. My
understanding is that the moment you open
your Tor Browser, it starts establishing connections and building
multiple circuits and keeps them in a pool.

In the old days of vidalia you could actually see that in real time.
Many established circuits were just
sitting there waiting. Each time you try to browse a page, Tor doesn't
say, oh let's find a relay. It picks
a circuit from a pool of already Established ones. If Tor tries to build
a circuit with a relay and it's unable to,
it will try another one that works and keeps it in the pool for when
it's needed. Again, I may be wrong.
Feel free to tell me if I am.

If that wasn't the case, any time I rebooted, someone would scream for
being disconnected
from the Internet. Evey single relay is important but not that important.


    > Blocking relay to relay communication should not be done
    > as it breaks a core assumption of the tor network (every relay can
talk
    > to all other relays ORPorts)


Okay, now let's be clear about DDoS mitigations. There's no such thing
as DDoS mitigation without rate limiting.
Both my rules and @toralf rules and frankly any other rules that anyone
could come up with by themselves, includes
rate limiting.This means that at any given time, someone, somewhere is
not allowed to connect due to their behaviour.

The idea that all relays must be able to connect to other relays any
time and in any shape or form they choose can not
exist in real world of DDoS mitigation. Right at this moment I have
about 1600 relays that have established connections
to me and I probably have as many connections to other relays and my
relay is happily operating at about its
Max Advertised Bandwidth. Do I really need to keep 6000 relays in my
allow list and let them do whatever they want?
Giving 6000 servers a free reign on your system is unheard of in the
security world.


DDoS mitigation like anything else in life is about compromise. Ideals
are sacrificed in favour of "good to haves" and
"good to haves" are sacrificed in favour of survival. Otherwise you'd be
a part of the currently
[over 2000 relays that are
overloaded](https://github.com/Enkidu-6/tor-relay-lists/blob/main/overloaded.txt)
and passing it along.

When I'm attacked, it's not just about me. I'm relaying that attack to
the next relay and they relay that to the next
one. So the idea that I should accept the attack when it's coming from
another relay is simply unacceptable.

Again I'd like to be very clear, this is not about blocking relays, it's
about rate limiting. They do get to connect
but at a reasonable rate. For example, there's no justifiable reason for
a relay to try to connect to another relay
at a rate of 10 times a second for 15 minutes straight.

So if for example we say a relay can have two Established connections to
me, we're not blocking them. If they do need
the connection, they use it. If they close a connection and at some
point they need one, they can open another one. But
they can't have 10 connections at the same time.

Again, My goal here with my questions is to find a way to keep the
balance of that compromise in our favour. But thinking
that we can go on without making those compromises would 

[tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts

[Chris Enkidu-6]

Hello Everyone,

Before I make changes to [my
scripts](https://github.com/Enkidu-6/tor-ddos), I need to understand a
few things and any help is much appreciated.

- First, Does an Exit relay with zero Guard probability and zero middle
relay probability need to initiate circuits with a Guard or middle relay
and assuming it fails, would that affect my relay, relaying traffic to
that Exit node as a part of my own circuit? To clarify the question, I
have 2 Established connections to two Or Ports of an exit relay, the
relay has no connections to me, Does that break anything?

- I have a few Exit relays as permanent residents in my block list, not
because I want them to be there but because, no matter how many times I
remove them, day or night, they'll be back in seconds for making too
many concurrent attempts. I'm assuming this is due to the fact that
Exits are being used to attack other relays but I may be wrong which is
why I need someone to clarify this for me and hence another reason for
question one.

- Each relay has Established connections to many other relays and if
they're guard they will also have many connections to regular users and
their Tor browsers until they have enough traffic to reach their
MaxAdvertisedBandwidth. Obviously we don't Establish connections to all
6300 relays out there. So if we do not allow each IP more than two
connections and they need 4, They'll have two from us and they'll move
on to another relay and get the other two and get the job done and we
will reach our Max Bandwidth anyway by accepting traffic from other
relays. Diversity of relays as opposed to concentration of some relays.
Am I correct in my assumption that this will have little to no effect on
the health of the Tor network as a whole?

Thanks for reading, I'm not going to make this longer than it is already.

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