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 mentioned the exit flag, but you didn't specify whether that relay also had the guard flag.
Generally speaking it is correct, that if you fire up a fresh tor client with default settings for the first time it will most likely pick a relay with the guard flag and no exit flag as their guard relay, but...:
Tor clients keep local state over a considerable amount of time. Most notably they pick their guard relays rarely.
It is possible that a relay that has the guard+exit flags today, only had the guard flag yesterday and the operator decided to enable exiting by changing the exit policy just this morning. So if that relay was picked as guard yesterday, their guard probability of today might not matter so much. I recall a gitlab.tpo issue that discussed the details of whether tor clients should change guards when their picked guard lost/gained flags. Maybe someone else could paste a link to it.
related content for the interested reader: https://lists.torproject.org/pipermail/tor-relays/2020-October/019002.html
https://gitlab.torproject.org/tpo/core/tor/-/issues/40230
Wouldn't the same protection you mentioned kick in and stop a client?
The protection I mentioned (reenter the tor network via exits blocking) does not interfere with a tor client directly connecting to a guard.
In the old days of vidalia you could actually see that in real time.
for anyone missing that experience, onioncircuits can help you there :) but it has less features than vidalia used to have. https://gitlab.tails.boum.org/tails/onioncircuits
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.
Yes tor clients preemptively create circuits before creating actual streams to reduce latency.
There's no such thing as DDoS mitigation without rate limiting.
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.
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
Not investigating such cases is a missed opportunity to find potential bugs or a new detection mechanism for malicious relays. It is also a missed opportunity to help protect the tor network at a higher level, because it is unlikely that everyone is using (the same) filters.
Filters that result in blocks for a large fraction of the tor network are more likely a sign of an unsuitable filters than an indicator that most of the tor network is engaging in attack against other relays, especially when they include well known and long term trusted operators.
This a good topic to be added to the Expectations for Relay Operators document. https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-Re...
At the very least relays blocking/dropping some packets of other relays should be very transparent about it.
kind regards, nusenu