Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

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.

Update (Dec 2014)

My predictions were obviously true - I had several network abuse complaints from my internet provider.

To avoid service shutdown I had to employ following set of iptables rules (ONEW is a chain for outgoing TCP SYN (aka NEW) packets :

I'm not sure it will suffice but here it is:

-A ONEW -o lo -j ACCEPT
-A ONEW -p udp --dport 53 -m limit --limit 2/sec --limit-burst 5 -j ACCEPT
-A ONEW -m hashlimit --hashlimit-upto 1/second --hashlimit-mode dstip --hashlimit-dstmask 24 --hashlimit-name ONEW -j ACCEPT
-A ONEW -m limit --limit 1/sec -j LOG --log-prefix "REJECTED: "
-A ONEW -j REJECT --reject-with icmp-admin-prohibited
share|improve this question

4 Answers 4

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.

share|improve this answer

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:

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
I don't see any sensible way of combining Squid (which I know and like) with Tor... – filiprem Aug 16 '12 at 19:20
try with Zebra route. – PersianGulf Aug 16 '12 at 19:26
Do you mean redirecting tor exit traffic which goes to port 80, and piping it through squid to add some control? This resolves only a small part of the problem. The real cause is preventing Tor abuse for any IP based DDOS. – filiprem Aug 16 '12 at 19:48
You can use design your network in three layer: 1. outside layer 2. process layer. 3.user/server layer ====> It cause your security will be improved. – PersianGulf Aug 16 '12 at 20:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.