Opened 12 years ago

Last modified 11 days ago

#469 needs_revision defect (None)

please limit connections by client

Reported by: weasel Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay, tor-dos
Cc: weasel, nickm, pankkake, arma, Sebastian Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor: SponsorV-can

Description (last modified by nickm)

I just had 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 > 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


[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (18)

comment:1 Changed 12 years ago by nickm

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.

comment:2 Changed 12 years ago by arma

As a first step, we should limit the number of not-yet-successfully-handshaked
connections from a given IP address. I'm guessing these 5500 connections were
just holding the TCP connection open, and didn't actually do an SSL handshake.

comment:3 Changed 12 years ago by weasel

They were all dir connections.

comment:4 Changed 12 years ago by WouT

My firewall only allows max 50 connections that are not handshaked yet and i can't set it higher (only lower ;)).
So i get many many SYN FLOOD messages when i run the server. Should the suggestion above solve this problem? It
would be nice if i could run the server again.

comment:5 Changed 11 years ago by nickm

I'd like to get this in, but it probably still needs a proposal. Moving to post-0.2.0.x, with possibility for

comment:6 Changed 11 years ago by esva

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

comment:7 Changed 10 years ago by nickm

Still needs a proposal; nobody wrote one. Moving to post-0.2.1.x.

comment:8 Changed 10 years ago by loafier

(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

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.

comment:9 Changed 10 years ago by arma

Chrisd posted a potential patch here:

comment:10 Changed 9 years ago by nickm

Description: modified (diff)
Milestone: post 0.2.1.xTor: 0.2.3.x-final
Status: newneeds_review

comment:11 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

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.

comment:12 Changed 7 years ago by nickm

Status: needs_reviewneeds_revision

comment:13 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:14 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:15 Changed 2 years ago by nickm

Cc: weasel,nickm,pankkake,arma,Sebastianweasel, nickm, pankkake, arma, Sebastian
Keywords: dos added
Points: 3
Severity: Normal

comment:16 Changed 23 months ago by nickm

Sponsor: SponsorV-can

comment:17 Changed 15 months ago by dgoulet

Keywords: tor-dos added; dos removed

Rename keyword "dos" to "tor-dos"

comment:18 Changed 15 months ago by dgoulet

This should be resolved with #24902 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.

Note: See TracTickets for help on using tickets.