Thanks for the configuration suggestions. I intentionally set the conntrack limit high, maybe that was not the best thing. I think I'll be putting it back.
Removing my extra IPTables code plus adding a reject for :8888 has made the exit behave properly again.
I wonder if the best possible course of action for this sort of thing would be within Tor itself. I don't know that it was a single client connection into Tor that was causing all this trouble, but maybe it was. One would think that one client should not be allowed to do something so severe with the TCP that it can single-handedly ruin a fast exit. Maybe a code change that forces a rate-limit that significantly slows down the ability of a single client to roll port scans should be considered by the devs.
On 26 Nov 2017, at 21:06, tor@t-3.net wrote:
Thanks for the configuration suggestions. I intentionally set the conntrack limit high, maybe that was not the best thing. I think I'll be putting it back.
Removing my extra IPTables code plus adding a reject for :8888 has made the exit behave properly again.
I wonder if the best possible course of action for this sort of thing would be within Tor itself. I don't know that it was a single client connection into Tor that was causing all this trouble, but maybe it was. One would think that one client should not be allowed to do something so severe with the TCP that it can single-handedly ruin a fast exit. Maybe a code change that forces a rate-limit that significantly slows down the ability of a single client to roll port scans should be considered by the devs.
Tor has code that limits the bandwidth of a single circuit, but it isn't active because the consensus parameter isn't set.
But I think you're talking about limiting the number of streams per circuit (no existing code for that).
Or limiting the number of circuits per client, which is very hard, because the exit doesn't know which circuits belong to the same client.
T
tor-relays@lists.torproject.org
-
teor -
tor＠t-3.net