I've noticed a new kind of possible attack on some of my relays, as early as Dec.23 which causes huge spikes of outbound traffic that eventually maxes out RAM and crashes Tor. The newest one today lasted for 5 hours switching between two of the three relays on the same IP.
During the attack, Tor becomes so busy processing the traffic that it becomes unresponsive to new connections for minutes at a time and effectively becomes a zombie exclusively processing the attacker's traffic until it eventually crashes and restarts. The interesting part is that when Tor restarts, it doesn't start from scratch building new circuits but it starts right from where it left out and keeps processing the previous connections.
I have tried shutting down Tor for over 5 minutes and within one minute of restart, The RAM maxes out and the outbound traffic reaches the previous heights.
This has been happening, not to all relays but to a select group of relays at a time and unless you're monitoring your Tor port from outside, you may not notice it's unresponsive. Another way to see if it's happening to you too is to check your monthly history on the metrics page and look for spikes of written bytes or sudden decrease of read bytes where you see a big gap between the two.
I have included charts and excerpts from the log in my post in Tor forum at below link:
https://forum.torproject.org/t/new-kind-of-attack/11122
I'd appreciate your insights and comments.
Thank you.
On 1/15/24 3:19 PM, Chris Enkidu-6 wrote:
I've noticed a new kind of possible attack on some of my relays, as early as Dec.23 which causes huge spikes of outbound traffic that eventually maxes out RAM and crashes Tor. The newest one today lasted for 5 hours switching between two of the three relays on the same IP.
I have included charts and excerpts from the log in my post in Tor forum at below link:
I've noticed this as well, on 0.4.8.10 across FreeBSD and Alpine platforms, against relays too new to receive any meaningful traffic from regular clients. MaxMemInQueues does not prevent the relay's eventual saturation of available memory on the system. The relays operated as exit nodes.
We're low on memory (cell queues total alloc: 6336 buffer total alloc: 1556480, tor compress total alloc: 1073827425 (zlib: 0, zstd: 0, lzma: 1073827249), rendezvous cache total alloc: 0). Killing circuits│withover-long queues. (This behavior is controlled by MaxMemInQueues.)
Hi
I've noticed a new kind of possible attack on some of my relays, as early as Dec.23 which causes huge spikes of outbound traffic that eventually maxes out RAM and crashes Tor. The newest one today lasted for 5 hours switching between two of the three relays on the same IP.
I have included charts and excerpts from the log in my post in Tor forum at below link:
I've noticed this as well, on 0.4.8.10 across FreeBSD and Alpine platforms, against relays too new to receive any meaningful traffic from regular clients. MaxMemInQueues does not prevent the relay's eventual saturation of available memory on the system. The relays operated as exit nodes.
We're low on memory (cell queues total alloc: 6336 buffer total alloc: 1556480, tor compress total alloc: 1073827425 (zlib: 0, zstd: 0, lzma: 1073827249), rendezvous cache total alloc: 0). Killing circuits│withover-long queues. (This behavior is controlled by MaxMemInQueues.)
I attached what is a typical picture for my entry relays. Between normal and aggressive is a factor of 3-20 in circuits. The relay frontside (inbound) seems not impacted.
Tor 0.4.8.9 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.7.3, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.5 and BSD 1302001 as libc.
MaxMemInQueues 2 GB
2023-12-31, normal The relay takes 3216M memory and 9k files are open YYYY MM DD hh mm Circuits txGB rxGB ConnIp4rx ConnIp6rx ConnIp4tx
ConnIp6tx 2023 12 31 00 55 41386 24 23 9165 563 2834 381 2023 12 31 01 55 39220 22 22 8550 472 2517 356 2023 12 31 02 55 38644 22 22 8411 456 2312 324 2023 12 31 03 55 40609 21 20 8650 496 2623 466 2023 12 31 04 55 37846 22 21 8424 504 3078 519 2023 12 31 05 55 35218 21 22 8210 457 2872 513 2023 12 31 06 55 35851 24 23 8126 472 2748 430 2023 12 31 07 55 35074 24 23 7971 404 2502 335 2023 12 31 08 55 34321 22 23 8069 448 2332 309 2023 12 31 09 55 35283 21 19 7909 430 1913 283 2023 12 31 10 55 33941 21 21 7709 457 1790 285 2023 12 31 11 55 33825 20 20 7643 484 1884 276 2023 12 31 12 55 32752 24 23 7328 474 1877 196 2023 12 31 13 55 32823 21 21 7333 511 1843 227 2023 12 31 14 55 29976 28 28 7058 473 1680 244 2023 12 31 15 55 28559 25 24 7096 503 1701 292 2023 12 31 16 55 28873 24 24 7217 493 1722 440 2023 12 31 17 55 29011 19 19 6994 487 1674 456 2023 12 31 18 55 32967 21 20 6710 455 1554 363 2023 12 31 19 55 28556 21 21 6714 450 1466 262 2023 12 31 20 55 27904 21 21 6558 384 1507 247 2023 12 31 21 55 27409 22 22 6130 390 1505 231 2023 12 31 22 55 26879 23 22 5929 390 1458 219 2023 12 31 23 55 25827 22 22 5627 376 1333 218 2024 01 01 00 55 28670 17 17 5955 451 1324 276
2024-01-11, aggressive The relay takes 7502M memory and 10k files are open YYYY MM DD hh mm Circuits txGB rxGB ConnIp4rx ConnIp6rx ConnIp4tx
ConnIp6tx 2024 01 11 00 55 125285 30 30 12105 900 3399 648 2024 01 11 01 55 110064 30 29 11827 995 3725 790 2024 01 11 02 55 45423 24 22 13148 633 2549 543 2024 01 11 03 55 99047 21 20 12944 710 2363 444 2024 01 11 04 55 122485 23 22 11627 705 3623 543 2024 01 11 05 55 113557 23 23 9414 701 3842 709 2024 01 11 06 55 115456 23 23 9265 760 3980 934 2024 01 11 07 55 114597 22 22 9428 798 3733 904 2024 01 11 08 55 120269 27 27 10494 824 3652 702 2024 01 11 09 55 117867 27 25 9936 822 3774 740 2024 01 11 10 55 115923 31 31 9441 812 3734 752 2024 01 11 11 55 116081 28 28 9861 852 3850 714 2024 01 11 12 55 109707 25 24 10266 913 3639 659 2024 01 11 13 55 340445 48 29 15059 1750 3565 623 2024 01 11 14 55 637652 100 16 15583 1594 3886 824 2024 01 11 15 55 553291 100 13 10128 790 3410 700 2024 01 11 16 55 599953 97 16 19689 2965 3293 625 2024 01 11 17 55 559004 100 20 19513 3108 2743 545 2024 01 11 18 55 854193 90 18 51 664 3908 580 2024 01 11 19 55 752697 84 16 13 643 4069 749 2024 01 11 20 55 65342 47 8 17236 2092 2663 663 2024 01 11 21 55 42592 5 4 7842 334 2502 562 2024 01 11 22 55 118705 17 15 11781 781 4688 1169 2024 01 11 23 55 129431 23 23 12623 1145 4946 1128 2024 01 12 00 55 123173 22 21 13507 1154 4759 1119
On Montag, 15. Januar 2024 23:19:37 CET Chris Enkidu-6 wrote:
I've noticed a new kind of possible attack on some of my relays, as early as Dec.23 which causes huge spikes of outbound traffic
I have included charts and excerpts from the log in my post in Tor forum at below link:
This seems to be related to what we already had in September: https://forum.torproject.org/t/excessive-unbalanced-relay-traffic/9291
It is always only intermittent and only some off my relays are affected. https://forum.torproject.org/t/excessive-unbalanced-relay-traffic/9291/8
Hi,
I just received a DDOS attack on a pretty settled exit relay. Who DDOS a Exit relay but the state or victim of it potential abuses?
Here the relay is in India.
Thank you for sharing this observation. I firmly believe in the similar situation applying.
On 16.01.2024 15:29, lists@for-privacy.net wrote:
On Montag, 15. Januar 2024 23:19:37 CET Chris Enkidu-6 wrote:
I've noticed a new kind of possible attack on some of my relays, as early as Dec.23 which causes huge spikes of outbound traffic
I have included charts and excerpts from the log in my post in Tor forum at below link:
This seems to be related to what we already had in September: https://forum.torproject.org/t/excessive-unbalanced-relay-traffic/9291
It is always only intermittent and only some off my relays are affected. https://forum.torproject.org/t/excessive-unbalanced-relay-traffic/9291/8
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Donnerstag, 18. Januar 2024 19:37:22 CET eff_03675549@posteo.se wrote:
I just received a DDOS attack on a pretty settled exit relay.
Surgeprotector is very helpful for exits https://github.com/artikel10/surgeprotector
Tor-nightly 0.4.9.0-alpha-dev fixed https://gitlab.torproject.org/tpo/core/tor/-/issues/40676
by trinity https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/735
ReevaluateExitPolicy 1
tor-relays@lists.torproject.org
-
boldsuck -
Chris Enkidu-6 -
eff_03675549＠posteo.se -
Felix -
Jordan Savoca -
lists＠for-privacy.net