[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] Pretty sure our exit was being synflooded



> On 26 Nov 2017, at 21:06, tor@xxxxxxx 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 mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays