On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter m16+tor@monksofcool.net wrote:
On 04.12.17 11:59, James wrote:
As a private individual, after just receiving my 4th abuse complaint in as many days it's time to stop running my exit node.
I've had an ongoing debate with a hosting service over a fresh exit node being abused for network scans (ports 80 and 443) almost hourly for the last few days. I can understand that they are pissed off, and the whole thing resulted in this particular exit being shut down by the hoster. If I could detect and prevent these scans, it would go a long way to avoid having my exit nodes shut down by hosting services.
With my exit node operator hat on, I too would like to see some sort of port-scanning prevention built into the network. In my case, I had to turn off exiting to the SSH port because we were getting daily complaints about abusive scanning for devices with weak admin passwords. Which is a shame, since there are plenty of legitimate uses for SSH-over-Tor.
The tricky part is designing some sort of exit-node-controlled new-connection rate limiting that's content-blind and won't interfere with legitimate uses. And "legitimate uses" include things like a web browser generating a burst of TCP connections to the same HTTP/1.1 server cluster, exitmap connecting to the same test server repeatedly via every exit node in the network, and so on. I would want to see any proposal document include a long list of known non-abusive traffic scenarios and an argument that the mechanism would not interfere with each.
Previous proposals have become bogged down in the process of trying to define "abuse".
Let's limit excessive use of scarce resources instead. It should have a similar effect, is easily made content-neutral, and doesn't require any agreed definition of legitimate and illegitimate uses.
Here's a quick sketch of a proposal - I would be happy to work with others to turn it into a Tor proposal and post it to tor-dev@. Here's what Tor proposals look like: https://gitweb.torproject.org/torspec.git/tree/proposals
Background:
Relays currently have token buckets that limit the number of bytes that can be sent per second. This limits relay bandwidth, but does not limit the use of other scarce resources, like file descriptors, TCP ports, and CPU time. (There is an existing file descriptor limit, but it is an absolute maximum, not a rate limit.)
Proposal:
We define relay-wide token buckets for circuit and stream creation. These token buckets are refilled on a regular basis. Every time a circuit or stream is created, a token is removed from the bucket. When the bucket is empty, the relay takes some action that slows down circuit or stream creation. (This could be a delay until the next refill, a randomised delay, or some more sophisticated exponential backoff system.)
We set these limits at default values that are unlikely to be exceeded during normal exit usage. (This needs measurement on live exits.)
This provides operators with tools to limit excessive usage, while we work on more fine-grained solutions.
Alternatives:
We could also define a stream limit per circuit, destination IP address, or destination port. However, this may be a level of complexity which we don't need. It also significantly increases the number of buckets required to implement the scheme. And it moves away from the original goal of limiting resource usage towards a scheme that allocates these resources more fairly between competing circuits or destinations. Designing a fairness scheme like this requires more research, including more sophisticated data collection on live exits.
There are also privacy concerns inherent in storing destination IP addresses and ports which would have to be addressed.
On 5 Dec 2017, at 06:00, Iain Learmonth irl@torproject.org wrote:
On 04/12/17 18:19, Ralph Seichter wrote: This is not about third party X complaining to the hoster about their network being scanned. The hoster itself is automatically monitoring all their machines for outgoing network scans, as these scans are prohibited by their terms of use.
I do wonder how much of this is related to the scarcity of IPv4 address space, prevalence of reputation systems and fear of ending up being labeled as "bad". When we move to IPv6, perhaps hosting providers would be more relaxed knowing that it doesn't matter so much if a /64 or even a /56 ends up bad in a reputation system, because for other customers you have other address space.
Tor already supports exiting over IPv6, and Tor Browser prefers IPv6 by default. Now we need Exit operators and major websites to enable IPv6.
I suspect the IP reputation space may take a few years to catch up with IPv6 - we should take advantage of that as much as we can.
T