[tor-relays] Network Scan through Tor Exit Node (Port 80)

[Mike Perry]

Thus spake cmeclax-sazri (cmeclax-sazri at 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-clients-entry-guards

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.


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20110228/dd9459d5/attachment.pgp>