Thus spake cmeclax-sazri (cmeclax-sazri@ixazon.dynip.com):
Here's my proposal: Add a parameter PortScanLimit to the relays section of torrc. It can be set to any nonnegative integer. If PortScanLimit is n>0, then as soon as a circuit has made n failed attempts to connect, the relay shuts down the circuit. If PortScanLimit is 0, there is no limit on failed attempts to connect. Relay operators in jurisdictions or ISPs that prohibit port scanning can set this to, say, 10, and relay operators not in such jurisdictions who have no qualms about their exit node being used for scanning can set it to 0. This parameter should not be listed in the directory; any client running a port scan will eventually find an exit that allows scanning, if there are any.
This isn't a bad idea on face, but it has some finer points that need a little thought. For instance, what if n connections have failed, but some are still alive? And what if this behavior is triggered by a malicious or broken website with tons of external, broken elements.
If the circuit is just forcibly closed, streams that did carry traffic could be cut short.. If the circuit is not closed, the client will wonder why all of their future Tor streams are now failing. Which one do we choose? Is the first really that bad? It seems in this case, the website is already broken, so no one should mind.. But what about other protocols?
The other problem is that one could imagine a port scanner or attacker that pre-builds all of the circuits it needs.. Does this mean that this defense is pointless, or will only stopping the script kiddies be enough here? What is the likelyhood that someone will distribute a Tor Controller specifically designed to use tor in an optimal fashion with nmap? This would be the way that this defense gets broken, possibly even unintentionally.
Note that we can try to solve this problem in a more general sense: https://blog.torproject.org/blog/research-problem-adaptive-throttling-tor-cl...
But if a client is only sending RELAY_BEGIN cells, it can still send a lot of them before any of these throttling limits kick in. I would be surprised if this was enough for an effective synflood, but it is enough to portscan.