please limit connections by client
I just had 213.26.168.50 perform a denial of service against Tor26. It opened over 5000 connections to tor26, which not only ate a bit of CPU, but also used up all available file descriptors, causing tor26 to drop new connections:
Jul 23 13:26:11.701 [notice] accept failed: Too many open files. Dropping incoming connection.
Please implement some limit of connections per clients. There are a few other minor abusers too, which probably means this also could use some thinking at the client:
sudo netstat -na | grep 86.59.21.38 > 38 cat 38 | grep ESTABLISHED | awk '{print $5}' | sed -e 's/:.*//' | sort | uniq -c | sort -n | tail [..] 11 61.60.x.y [slightly anonymized] 13 212.249.x.y 16 59.120.x.y 19 81.120.x.y 25 65.122.x.y 31 202.185.x.y 32 125.16.x.y 5649 213.26.x.y
cheers,
[Automatically added by flyspray2trac: Operating System: All]
Activity
changed milestone to %Tor: unspecified
Good idea. Let's do this one in 0.2.0.x. I don't know the best rule here, though. Possibilities:
- We could limit the connections that any given IP can have open. That could fail badly for NAT situations.
- When low on connections, we could start killing connections, preferring ones from clients with many connections on the same IP.
- Other.
I'm getting these same kind of attacks about once a week too. (I'm running a relay with no exit) My "/var/log/tor/tor.log" file gets filled with "[notice] accept failed: Too many open files. Dropping incoming connection." After tor.log grows in size to ~3G my /var/log partition is full, interfering with other services running on that server. I'm going to try disabling DirPort setting in /etc/tor/torrc for now.
I have an ADSL internet connection with a dd-wrt router bridged to my ADSL modem. I am port forwarding the tor ports from the dd-wrt router to my tor server running iptables. I run a blacklist script to dynamically add new chains to iptables to block IPs with too many failed ssh logins. Not sure if there's a script to do something similar for tor by blocking IPs with too many connections.
Trac:
Username: esva-
(arg, with line wrapping)
I think what Roger said about the ssl handshake on OR server connections can be applied to Dir server connections as well. There should be a limit of how many Dir conns a client has stuck in DIR_CONN_STATE_SERVER_COMMAND_WAIT. On my testing server, I can use netcat to connect to the OR port and Dir port and it just hangs, which is certainly wasteful if a client opens up a ton of connections.
There could be a new configuration option -- something like MaxUnusedConnections -- which would limit the total number of unhandshaked OR conns and unused Dir conns the client can have open at the same time to a set number before Tor starts to deny further access from their IP.
Trac:
Username: loafier 
Chrisd posted a potential patch here: http://archives.seul.org/or/dev/Apr-2009/msg00002.html
-
Trac:
Description: I just had 213.26.168.50 perform a denial of service against Tor26. It opened over 5000 connections to tor26, which not only ate a bit of CPU, but also used up all available file descriptors, causing tor26 to drop new connections:Jul 23 13:26:11.701 [notice] accept failed: Too many open files. Dropping incoming connection.
Please implement some limit of connections per clients. There are a few other minor abusers too, which probably means this also could use some thinking at the client:
sudo netstat -na | grep 86.59.21.38 > 38 cat 38 | grep ESTABLISHED | awk '{print $5}' | sed -e 's/:.*//' | sort | uniq -c | sort -n | tail [..] 11 61.60.x.y [slightly anonymized] 13 212.249.x.y 16 59.120.x.y 19 81.120.x.y 25 65.122.x.y 31 202.185.x.y 32 125.16.x.y 5649 213.26.x.y
cheers,
[Automatically added by flyspray2trac: Operating System: All]
to
I just had 213.26.168.50 perform a denial of service against Tor26. It opened over 5000 connections to tor26, which not only ate a bit of CPU, but also used up all available file descriptors, causing tor26 to drop new connections:
Jul 23 13:26:11.701 [notice] accept failed: Too many open files. Dropping incoming connection.
Please implement some limit of connections per clients. There are a few other minor abusers too, which probably means this also could use some thinking at the client:
sudo netstat -na | grep 86.59.21.38 > 38 cat 38 | grep ESTABLISHED | awk '{print $5}' | sed -e 's/:.*//' | sort | uniq -c | sort -n | tail [..] 11 61.60.x.y [slightly anonymized] 13 212.249.x.y 16 59.120.x.y 19 81.120.x.y 25 65.122.x.y 31 202.185.x.y 32 125.16.x.y 5649 213.26.x.y
cheers,
[Automatically added by flyspray2trac: Operating System: All]
Status: new to needs_review
Keywords: N/A deleted, N/A added
Parent: N/A to N/A
Milestone: post 0.2.1.x to Tor: 0.2.3.x-final -
Hm, no. We're going to want a different solution here than the one in the linked-to patch. It limits the number of unused connections per IP, which is a good thing, but trivial to circumvent. We also need to limit the number of concurrent connections and the rate of connection attempts.
Trac:
Actualpoints: N/A to N/A
Milestone: Tor: 0.2.3.x-final to Tor: unspecified
Points: N/A to N/A 
This should be resolved with #24902 (moved) which limits the number of concurrent connections from client IP address. As long as you are a public relay, you should defend.
We might want to improve on this for dirauth with #4581 (moved).
moved to tpo/core/tor#469 (closed)
