I've thought about constructing iptables rules to limit the number of SYN packets for the same host per second or such

Multiple flows to the same host don't really bother routers of any class. Old routers choke when looking up many hosts in the routing table. So your proposed rules against port-scanning single hosts wouldn't help. Unless each SYN to a host is generated from multiple Tor-based IP-scanner's, in which case your node or Tor would probably be underwater from the parallel scans anyways.

Is there a known proper way to protect yourself from being used as a network scan relay?

You can't really implement rules to block IP-scanning because you'll just take yourself offline. Which is exactly what ISP's do when their router falls over. The problem is fixed at the source, not the dest. In the TCP only case of Tor, best you can easily do is 'reject *:port' the ports being scanned, thus denying service to the scanner's Tor client and thus emitting no such traffic yourself. If it's well-known ports, such is life for your relay.

I am hosting a 3-5MB/s tor exit relay ... does not want to route network scanning traffic since it is a severe load to their routers.

If they can't deal with a single host doing IP-routing lookups, sounds like they need to replace their 10yr old Crisco routers or exit the biz.

On 7/31/12 7:18 PM, amki wrote:

Hiho,

I am hosting a 3-5MB/s tor exit relay but as of today my hoster has closed my server because of network scanning. Is there a known proper way to protect yourself from being used as a network scan relay?

I've thought about constructing iptables rules to limit the number of SYN packets for the same host per second or such, but I'm not sure if this is allowed or will get me flagged as a bad exit node.

My hoster is quite ok with us generating some abuse complaints per month, but does not want to route network scanning traffic since it is a severe load to their routers. Any help would be appreciated

That's a problem i tried to address in several way using system administration tools (from portscan detectors to the most esoteric iptables modules/combination) but didn't succeed. It would require probably custom software to be developed to detect outgoing portscan and then mark the traffic diverting it in an iptables rules that apply specific rate limiting/blocking. The portscanning patterns that imho trigger abuses are mostly two: a) Multiple target IPs of the same netblock for a single TCP port within a short timeframe b) Multiple TCP port for a single target IP within a short timeframe It would be reasonably easy to make such an algorithm that would detect outgoing portscan, with limited risks to hurt other Tor traffic, implement it with netfilter API, so that it would be possible to "mark" that traffic. Then, what you want to do with "market traffic" maybe just log, or block, or rate limit, or limit the number of connections market in this way. Imho finding a reasonably way and algorithm to detect outgoing portscan and shape them would be very useful, even if i know that it doesn't get that much community acceptance being blocking/limiting a controversial topic. -naif