iptables on tor exit node

Question

I want to run an open Tor router.

My exit policy will be similar to ReducedExitPolicy.

But I also want to make it hard for the tor network to abuse my resources.

Cases I want to prevent clients from doing via Tor:

• Hammering one site with very many packets.
• Aggresive netscans of whole IP blocks

Cases I do NOT want to prevent clients from doing via Tor:

• uploading a few hudreds of image files to the cloud
• seeding a torrent

My question is, can this be done at all, and how?

My first thought was some firewall (Linux/iptables or *BSD/ipfw/pf) - but this will probably be useless due to inherent properties of the Onion router.

Is there any ongoing torproject team development on this topic?

I also ask for general hints on securing Tor exit nodes.

Update (Sep 2012)

From helpful answers and some other research I think this can not be done.

The best you can do to stop people from abusing exit node to contribute in DDOS, is to detect very frequent packets directed to one IP.

The "very frequent" threshold depends on total node bandwidth... If it is wrong, there will be false positives, blocking legitimate traffic of realtime TCP apps and traffic sourced from very many clients to one destination.

Answer 1

Keep in mind that:

• Tor clients switch virtual circuits every 10 minutes or so to my current understanding. This means the source IP is changing around that time frame. You are unlikely to prevent any behavior you deem malicious for longer than that duration.

• Note that the fact that Tor only proxies TCP traffic and not any other protocol limits abuse possibilities quite a bit.

iptables can let you treat new outgoing TCP connections differently than existing ones. Anything that is ESTABLISHED,RELATED should be ACCEPTED or put through a "existing TCP connections" chain, and outgoing TCP that doesn't get caught by that could be rate limited. Any outgoing Tor traffic should be subject to this.

I believe between the above and using the "Reduced Exit Policy" would be about the best you can do.

Ideally, don't run anything else on your Tor box except:

• You'll probably at least have SSH up, put it on a different port than 22.
• You'll probably want to run a simple webserver to display this page. A chroot'ed mini-httpd instance should do. Don't use inetd.

Don't run Tor on a box that is being used for anything else. Make sure you have read the "Exit Relays" section of the Tor Legal FAQ and fully understand its implications. Also read and do all of this.

Answer 2

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

Answer 3

The limited bandwidth of the rest of the Tor network will solve those problems for you. Also if you are worried, run just relay, not an exit node.

Answer 4

I have a better solution : squid cache server. Squid cache server available to configure defining acl and you deny or accept each acl. It's very interesting that squid team defining a set of rules in their wiki that your question found there iptables,PF or others can't do your jobs , because just work in another layers.