another DirPort DoS attacker

[John Brooks]

I would be very interested to see what is being sent over these connections.
Since the directory is on port 443, it's possible that this is some
proxy/vulnerability scanner getting confused and hammering your server
thinking it's a webserver of interest. However, it should *not* be possible
for one IP to create that many directory connections to your tor server, and
use that much bandwidth with them. This definitely needs some limits added
(why would one IP ever need more than a couple directory connections to one
location?) to help make this sort of thing more difficult. A bit more
complicated, but it also might be a good idea to allow setting bandwidth
limits on directory connections seperately so you can ensure that they won't
interrupt relay traffic.

If it is something sending invalid, non-tor requests, perhaps it'd be a good
idea to stop accepting directory connections from IPs that are hammering you
with lots of requests resulting in file not found, method not supported,
etc. Especially with all of the newer research into latency-related attacks,
properly managing the resources of the server is very important.

If no one familiar with the code wants to (please do..), I could probably
hack up a patch to limit the number of directory connections from a single
IP. I haven't gotten around to reading much of the code, though, so it'd be
far easier for someone more familiar to it. As a quick alternative to that,
you could use iptables to set limits on the number of connections and amount
of bandwidth on the directory port.

I'm inclined to think this is an innocent case (rather than one targeted to
tor), mostly because it's on port 443 and there is no clear benefit to
attacking your node. M's message supports this. But these problems need to
be solved properly, or someday it will not be innocent at all :P

- John Brooks

On Tue, Sep 2, 2008 at 6:41 PM, Scott Bennett <bennett at cs.niu.edu> wrote:

>     On Tue, 2 Sep 2008 09:44:14 -0600 "John Brooks" <aspecialj at gmail.com>
> wrote:
> >That is odd; I don't see what purpose a DoS against a specific
> >directory/node would serve (unless you were specifically attacking a
> >connection routed through that node, or trying to use latency attacks). Is
> >it an exit node? Could be retaliation from something a user did through
> your
>
>      Yes, it is an exit for many, but not all, ports.
>     I hadn't thought about the latency-testing angle, but it's conceivable,
> I guess.  Mostly what it looks like is an attempt to a) clog the directory
> mirror service and/or b) clog the whole Internet connection to my server.
>
> >node by someone who doesn't understand tor, although choosing the
> directory
> >port is a bit strange.
> >
> >Another option would be that it's completely unrelated to tor. What port
> is
> >your directory on? If it's a common service/proxy port, it could be some
>
>      It's on 443.
>
> >exploit attempt or similar getting confused. It's a bit worrying if
> someone
> >cares about attacking tor itself that much, in an abstract way.
>
>      This is not the first incident I've reported.  (See archives for more
> over the past year.)  Unfortunately, when I recently dumped the jerks that
> I had been getting poor-quality service from for the past year, I failed to
> write down all the filter rules I'd added to their router before I returned
> it to them. :-]  There was rarely even a single connection attempt from any
> of them anymore at that time, so I wasn't too concerned.  But that means I
> now do not know whether this current trouble source is one of the older
> ones.
> I don't recognize the host+domain name, though, so I suspect it is a new
> one.
>     I would be very surprised to learn that my server is the only one being
> hassled in this fashion, but I know there are many, many tor servers that
> are not nearly as closely monitored for trouble by their operators as mine
> is. :-)
> >
> >Chances are it's nothing too worrisome, though.
> >
>      In the sense that it may not be something being done intentionally, I
> certainly hope you are right.  However, the disruptiveness of the attacks
> does worry me because a concerted, distributed attack *could* be made
> deliberately by an adversary with enough bandwidth to cripple the whole
> tor network's operation.  And such an attack could be carried out
> relatively
> cheaply.  It takes only a tiny bit of attacker transmit bandwidth to open
> hundreds or thousands of connections, but it takes a great deal of server
> transmit bandwidth to respond to them all.  Given that an awful lot of us
> are bottlenecked by the transmit side of asymmetric Internet connections,
> it looks like a real possiblity.  Remember that I found 300-400 ESTABLISHED
> TCP connections simultaneously from that one IP address, and new ones were
> opening continually as fast as earlier ones were served and closed.  It
> would be easy for someone to attack at least several servers at one time
> from an inexpensive asymmetric link like ADSL, cable, etc., so someone
> with real resources (e.g., government agencies) to have lots of small
> computers with lots of cheap Internet connections could take a large
> portion of us down in a matter of minutes and keep us that way as long as
> they liked.  In that sort of attack, setting useful filter rules would be
> nearly impossible because the source of the attack could be switched
> immediately.
>
>
>                                  Scott Bennett, Comm. ASMELG, CFIAG
> **********************************************************************
> * Internet:       bennett at cs.niu.edu                              *
> *--------------------------------------------------------------------*
> * "A well regulated and disciplined militia, is at all times a good  *
> * objection to the introduction of that bane of all free governments *
> * -- a standing army."                                               *
> *    -- Gov. John Hancock, New York Journal, 28 January 1790         *
> **********************************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20080903/7cdaed17/attachment.htm>