It will be harder than usual to prevent these attacks since the source IP is not constant. However, to my knowledge to routes in tor are only changed every few minutes or so.

So you could still deploy some of the standard limitation/filtering rules but with a higher threshold, since you must assume there is a whole network behind your source IPs.

You can filter:

• bad or typical fingerprinting/scanning packets (bad TCP/IP flags, XMAS, most ICMP types etc)
• INVALID packets that don't fit to ongoing or new connections (-m state)
• NEW connections starting at some rather high threshold

However, be aware that such things are typically done on inbound traffic. You don't know what kind of protocols your "customers" will run and you might restrict them in ways that can be annoying/unclear.

Also, for rate-limiting NEW (or stateless) packets you may want to consider some more involved scheme where the rejected(never DROP unless its obviously an attack!) packets are randomized. This way, a regular user can just try to hit reload and get lucky, even though the overall rate is currently at the limit, while a concurrent port scanner will not be able to circumvent your rate limit.

Also ask on the Tor mailing lists, you're probably not the first to have such thoughts: https://lists.torproject.org/cgi-bin/mailman/listinfo

It will be harder than usual to prevent these attacks since the source IP is not constant. However, to my knowledge the routes in tor are only changed every few minutes or so.

So you could still deploy some of the standard limitation/filtering rules but with a higher threshold, since you must assume there is a whole network behind your source IPs.

You can filter:

• bad or typical fingerprinting/scanning packets (bad TCP/IP flags, XMAS, most ICMP types etc)
• INVALID packets that don't fit to ongoing or new connections (-m state)
• NEW connections starting at some rather high threshold

However, be aware that such things are typically done on inbound traffic. You don't know what kind of protocols your "customers" will run and you might restrict them in ways that can be annoying/unclear.

Also, for rate-limiting NEW (or stateless) packets you may want to consider some more involved scheme where the rejected(never DROP unless its obviously an attack!) packets are randomized. This way, a regular user can just try to hit reload and get lucky, even though the overall rate is currently at the limit, while a concurrent port scanner will not be able to circumvent your rate limit.

Also ask on the Tor mailing lists, you're probably not the first to have such thoughts: https://lists.torproject.org/cgi-bin/mailman/listinfo