[tor-relays] Tor Server - DDOS or High Load

Wed Dec 3 21:09:43 UTC 2014

Also, when a Tor relay goes offline, the traffic is redistributed across
the Tor network. It is unlikely you would receive the high speed traffic of
a node just because it went offline, unless a few HIGHLY unlikely variables
occur.

Also, all of the clients will be completely disconnected which were using
the Tor server; it is impossible to "re-patch" the connections, given the
anonymous nature of Tor.

On Wed, Dec 3, 2014 at 4:07 PM, Austin Bentley <ab6d9 at mst.edu> wrote:

> Hey bud,
>
> Your adsl connection has a low advertised bandwidth, and doesn't make many
> connections with regards to tor; thus, the CPU usage is correct. Look up
> your server's fingerprint or nickname on Tor Globe to see how much of the
> tor network travels through your server.
>
> CPU load is usually associated with a lot of bandwidth or a inefficiency
> in the server. I've heard that a 100mbit tor server using full 12.5MB/s
> up/down will saturate the core dedicated to the Tor process; this is
> presumably why a lot of servers run multiple Tor instances on different
> cores and IP addresses. However, in your case, it is likely
>
> The large amount of connections is generally caused by a few things:
> 1. You've been running a very stable server for a long period of time and
> have sufficient bandwidth to provide connectivity for a large number of
> clients; additional flags, such as Guard, HSDir, V2Dir, and Exit will
> likely result in more connections. This is not likely with your server,
> given your advertised bandwidth is only 68.44kb/s.
> 2. A single client is using your server for a lot of connections.
> 3. An anomaly/attack in the Tor network (somewhat unlikely, I don't know
> if any have been documented.)
> 4. An attack against your server. This is very hard to do through the Tor
> network; an attack against a Tor relay using Tor is an attack against all
> Tor relays. HOWEVER, they could be attacking your port which you use to
> host your tor server.
>
>
> Just for reference, here's my tor stats:
> Advertised B/W: ~4MB/s
> Connections (555 inbound, 5 outbound, 93 exit, 1 socks, 5 circuit, 1
> control)
> Tor is averaging 9%-13% CPU usage; 198MB memory.
>
> More info on my server:
>
> https://globe.torproject.org/#/relay/EF84089646304169F439A8F473742D74F027BA1B
>
>
>
> I hope this answered your question, if not, send a reply and hopefully
> I'll reply sometime.
>
> On Wed, Dec 3, 2014 at 2:22 PM, webmaster <webmaster at defcon-cc.dyndns.org>
> wrote:
>
>>
>> Am 03.12.2014 um 19:04 schrieb Toralf Förster:
>> > On 12/03/2014 06:17 PM, webmaster wrote:
>> >> At first I thought: Fuck, someone intruded into my machine.
>> >> But after some looking through Arm I found many (>100) INBOUND
>> connections.
>> > "many" ?
>> >
>> > I do have usually something like this :
>> >       Connections (782 inbound, 458 outbound, 245 exit, 1 control):
>> > for and advertised bandwidth of 4 MBit, so >100 are quite normal.
>> >
>> > Probably you should raise the ulimit, I do have for da dedicated server
>> (and Gentoo) :
>> >
>> > tfoerste at tor-relay ~ $ cat /etc/conf.d/tor
>> > #
>> > # Set the file limit
>> > rc_ulimit="-n 30000"
>> >
>>
>> I'm running the server through a relatively slow adsl connection
>> (6,9 MBit/s down,  733 kBit/s up). Advertised Bandwidth: 68.44 kB/s.
>>
>> My ulimit is set to 1024 (os default). I will keep the ulimit setting at
>> the default value because i see now reason for increasing it.
>>
>> Actually my server handles 28 inbound, 5 outbound and 14 circuits. The
>> load is approx. 2%.
>>
>> From my point of view this strange behavior isn't common for my tor
>> server because usually the cpu load of the tor process is below 10%.
>>
>>
>> What happens to the tor network when a tor server with high bandwidth
>> goes off-line? Maybe this could be a reason?
>>
>>
>> --
>> -----BEGIN PGP PUBLIC KEY BLOCK-----
>> Version: GnuPG v2.0.17 (MingW32)
>>
>> mQENBFHMmT8BCAC0smvU7Bq1ABxAhvBRn7d4ekkk95aCE4TTQo4wy1z/rGLhQfdt
>> dhiD+Vy61vGrsdK3ei5sW6rBvX2m8+YmBi+8AAgSiZmS0JM3Zz3cmTi5oh0D/yM8
>> 4aDj7wQYfJyzSmYN8InAQ5eA77lwIdqG27kR9wga2szeJwCnWReta0R+7YFkpUW+
>> zUlf4SWcUx5SmBsaiELQpm+Qcn+fyopo12RX6YVmoNPBvN2nDXDnRhUCKGc+0xhD
>> UrBpCHrApK6sTnMsD34ClCLTL2L1gckQ0AsQqY3PJlx3R8kIJxlmr6R3WnjPMIG0
>> lqrukB9PcOrHM1MZXK1gK6AtypHBN98lr8Z9ABEBAAG0KndlYm1hc3RlciA8d2Vi
>> bWFzdGVyQGRlZmNvbi1jYy5keW5kbnMub3JnPokBPgQTAQIAKAUCUcyZPwIbIwUJ
>> CWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQcN1vxvRQl+0SEwf+KXjf
>> YtiSUSVS11uqeQ/8g46NwmNa91P3toZvEd7vhLSbjnL9bi/vApzNnUTGT3VP4/NA
>> dg9SbR4qKlSr8T+YikRMV3tiuiVq8m7g00qM9y8MIomwJTounz8VdO/aJXFSOxAK
>> Bb6ElREADspCzr2qSZCnozWUzbd+b8owbGeRRq3e33Aa5Nlm/xDRxGDWANbaIA8q
>> Gkibvy3vWEwrxiwsakvHGaEZnPEtlNm3M1xcmFAuyl73qzUMkLN0u9E/2igo4EB5
>> EdMb5Ab5hfWdljxBqJr0tsvMfSK4VkzMCbKYkTqHZIRPQnhiSBE6Yo1Q6RCl/Hht
>> bkvU4RA0J+NkXMZljrkBDQRRzJk/AQgA0HojJnK0uhEkAnbmszYsf477DV+LD02s
>> ZEAlLGhJlf9qYaDiPMPwaZ3nK8/PYKzPpBWfHgRQP97rLHPIVJYl3BHDa/nWeZ2b
>> e/HzYhpX0djbK9qe6W/CTfGbXmC/y+4dDGB8dvtTAW3JILm7xEdwiWtywozEVy7V
>> lnMK4JQvlfOh+3XO6qv71FXyuRkObvkYzqvxUYHewtvvObcVxXHP0C0O6LB44iAW
>> 2boZVVuiHdudnyNAezJajPMUT8SnI0bwL6+0TgnHL4cKNUEPQljIrrvi+9nCkq7V
>> uBtnsYtyoo2reoxmCbX/Z1zZsxdUcKpeJHlc5AypyN8DUJ+APJ9NnwARAQABiQEl
>> BBgBAgAPBQJRzJk/AhsMBQkJZgGAAAoJEHDdb8b0UJftOY0H/1TChmQrJC/qzefW
>> PK7EqFlBg3TIEXdu8JHjF42ZOgzQRfp7E2wWzEx0Y45lNXMs6Yg15hWCEDaUDF6F
>> 5WZKNrP8xIldyR9Aw7fyKqjZ9UuKovqofHsCiaSO7nWzGM6GF3nBDNI9NcFve/wN
>> wggyjAbohOJrJGal3N0HlG3cakqjEmjBe1gQEMC0ZPlWstb/cqqr49TNPrRmQc4P
>> SyGffh8Xqhw94m1LDBXFEaYe7AxjNk1sPAVfO1rOdLF6GOun/UwgbhDQX/Rb9C3t
>> AhjSgyFEiR/gfrUZ7R6SY51qOUf1lN5ZN85C/x27XoZWYlsNaH3Ei6nG+yeswBMk
>> ZRMbezQ=
>> =Med3
>> -----END PGP PUBLIC KEY BLOCK-----
>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20141203/6c39f927/attachment.html>