Linux – iptables on tor exit node

firewalliptableslinuxnetworkingtor

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

Best Answer

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.

Related Solutions

How to limit P2P/torrent traffic on an OpenWrt 10.03 router

I agree with Caleb that splitting the bandwidth is probably going to be the easiest, however, as a more roundabout solution, you might want to take a look at Micro Transport Protocol. uTP has been designed by the uTorrent guys to try and mitigate latency issues caused by BitTorrent which I assume is the root of your issue. In my experience it works quite well and there's a noticeable difference on my ADSL connection, for example.

In the free software ecosystem, uTP is supported by KTorrent (4.0+) and Transmission (2.30+). Vuze also implements it, but not on Linux. And, of course, the official uTorrent client supports it.

Iptables: Matching Outgoing Traffic with Conntrack and Owner – Troubleshooting Drops

To cut a long story short, that ACK was sent when the socket didn't belong to anybody. Instead of allowing packets that pertain to a socket that belongs to user x, allow packets that pertain to a connection that was initiated by a socket from user x.

The longer story.

To understand the issue, it helps to understand how wget and HTTP requests work in general.

wget http://cachefly.cachefly.net/10mb.test

wget establishes a TCP connection to cachefly.cachefly.net, and once established sends a request in the HTTP protocol that says: "Please send me the content of /10mb.test (GET /10mb.test HTTP/1.1) and by the way, could you please not close the connection after you're done (Connection: Keep-alive). The reason it does that is because in case the server replies with a redirection for a URL on the same IP address, it can reuse the connection.

Now the server can reply with either, "here comes the data you requested, beware it's 10MB large (Content-Length: 10485760), and yes OK, I'll leave the connection open". Or if it doesn't know the size of the data, "Here's the data, sorry I can't leave the connection open but I'll tell when you can stop downloading the data by closing my end of the connection".

In the URL above, we're in the first case.

So, as soon as wget has obtained the headers for the response, it knows its job is done once it has downloaded 10MB of data.

Basically, what wget does is read the data until 10MB have been received and exit. But at that point, there's more to be done. What about the server? It's been told to leave the connection open.

Before exiting, wget closes (close system call) the file descriptor for the socket. Upon, the close, the system finishes acknowledging the data sent by the server and sends a FIN to say: "I won't be sending any more data". At that point close returns and wget exits. There is no socket associated to the TCP connection anymore (at least not one owned by any user). However it's not finished yet. Upon receiving that FIN, the HTTP server sees end-of-file when reading the next request from the client. In HTTP, that means "no more request, I'll close my end". So it sends its FIN as well, to say, "I won't be sending anything either, that connection is going away".

Upon receiving that FIN, the client sends a "ACK". But, at that point, wget is long gone, so that ACK is not from any user. Which is why it is blocked by your firewall. Because the server doesn't receive the ACK, it's going to send the FIN over and over until it gives up and you'll see more dropped ACKs. That also means that by dropping those ACKs, you're needlessly using resources of the server (which needs to maintain a socket in the LAST-ACK state) for quite some time.

The behavior would have been different if the client had not requested "Keep-alive" or the server had not replied with "Keep-alive".

As already mentioned, if you're using the connection tracker, what you want to do is let every packet in the ESTABLISHED and RELATED states through and only worry about NEW packets.

If you allow NEW packets from user x but not packets from user y, then other packets for established connections by user x will go through, and because there can't be established connections by user y (since we're blocking the NEW packets that would establish the connection), there will not be any packet for user y connections going through.