Shutting down my ~40 guards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Within a matter of minutes, quite a few of my relays have come under attack again. As there has been no progress in mitigating the attacks despite several new releases of Tor coming out and no information from the devs about any in-progress mitigations or even plans to develop a mitigation, I'm no longer able to run relays that are eligible for the HSDir flag. The attacks have been causing financial strain to me and straining my relationship with my hosting providers, many of which I have spent significant effort to convince to allow Tor. If someone knows of a mitigation, can poke the devs to write one, can point me in the right direction for writing my own without getting my relays marked bad for behaving in a non-standard way, or knows of a way to get my relays blacklisted from the HSDir flag besides just setting DirCache 0 (which also prevents being a guard), please tell me. This is a difficult decision, but if there's really no plan or progress in developing a mitigation for these attacks, I'll be shutting down ~40 guards over the next several days. I just don't know what else to do. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCasyPGgAKCRAw+TRLM+X4 xq01APsF9oxsd74W9sK/cO+xnt4HWZWZ/A7MWc8s2WUHN7telwD/SeoVfuzjaJIM 0NcyOUQVi9jzqkqfr4JEnASneNkh8g0= =dFuQ -----END PGP SIGNATURE-----
Hey Forest I can see you've done a huge amount of work for the Tor network. Losing your relays would be a huge loss. I hope the developers take this seriously and respond soon. Sent with Proton Mail secure email. On Monday, October 12th, 2026 at 10:45 AM, forest via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello.
Within a matter of minutes, quite a few of my relays have come under attack again. As there has been no progress in mitigating the attacks despite several new releases of Tor coming out and no information from the devs about any in-progress mitigations or even plans to develop a mitigation, I'm no longer able to run relays that are eligible for the HSDir flag. The attacks have been causing financial strain to me and straining my relationship with my hosting providers, many of which I have spent significant effort to convince to allow Tor.
If someone knows of a mitigation, can poke the devs to write one, can point me in the right direction for writing my own without getting my relays marked bad for behaving in a non-standard way, or knows of a way to get my relays blacklisted from the HSDir flag besides just setting DirCache 0 (which also prevents being a guard), please tell me.
This is a difficult decision, but if there's really no plan or progress in developing a mitigation for these attacks, I'll be shutting down ~40 guards over the next several days. I just don't know what else to do.
Regards, forest
What do people think is the motive behind these attacks? And, who? Dawn
On Oct 12, 2026 at 6:56 AM, kullikovana via tor-relays <tor-relays@lists.torproject.org> wrote:
Hey Forest I can see you've done a huge amount of work for the Tor network. Losing your relays would be a huge loss. I hope the developers take this seriously and respond soon.
Sent with Proton Mail secure email.
On Monday, October 12th, 2026 at 10:45 AM, forest via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello.
Within a matter of minutes, quite a few of my relays have come under attack again. As there has been no progress in mitigating the attacks despite several new releases of Tor coming out and no information from the devs about any in-progress mitigations or even plans to develop a mitigation, I'm no longer able to run relays that are eligible for the HSDir flag. The attacks have been causing financial strain to me and straining my relationship with my hosting providers, many of which I have spent significant effort to convince to allow Tor.
If someone knows of a mitigation, can poke the devs to write one, can point me in the right direction for writing my own without getting my relays marked bad for behaving in a non-standard way, or knows of a way to get my relays blacklisted from the HSDir flag besides just setting DirCache 0 (which also prevents being a guard), please tell me.
This is a difficult decision, but if there's really no plan or progress in developing a mitigation for these attacks, I'll be shutting down ~40 guards over the next several days. I just don't know what else to do.
Regards, forest
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2026-10-12 11:54, kullikovana via tor-relays wrote:
I hope the developers take this seriously and respond soon.
I've talked with gk about it and he passed it to the others devs but there's only so much they can do with limited funding. On 2026-10-12 12:05, dawn.belle.flood via tor-relays wrote:
What do people think is the motive behind these attacks? And, who?
I have no idea who, but they're attacking relays with the HSDir flag and causing them to lose the flag. Unfortunately, I don't think there's any way to avoid getting the HSDir flag in order to avoid being targeted without also losing the guard flag. But avoiding getting the flag is just doing what the attacker wants anyway. So some kind of censorship against onion services, or research into efficient DoS attacks against HSDirs for future censorship, I guess. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaszTNgAKCRAw+TRLM+X4 xlDBAP9q2Fq+YZDsCroYjug19eGeDKTOsI/eCXSgos92b1uiEQEA5nTfp8wxCCf7 aV0SXu/yFAXSxpJu+c2QVnqblYtfVAg= =43De -----END PGP SIGNATURE-----
On Monday, 12 October 2026 14:05 dawn.belle.flood via tor-relays wrote:
What do people think is the motive behind these attacks? And, who?
This will almost certainly be another multi-national law enforcement operation, similar to Operation Lobos, Habitance, or most recently, Liberty Lane. https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torpr... These operations against long running HiddenServices often take years and are costly. The most important thing is that ordinary Tor users are not deanonymized. The relay is forced to restart e.g. by the out-of-memory (OOM) killer and loses its HSDir status. https://www.petsymposium.org/foci/2024/foci-2024-0014.pdf https://www.computer.org/csdl/proceedings-article/sp/2026/606500b316/2bojw45... There’s nothing the Tor devs can do about that, either. Keep your relays running as stably as possible. Don't get upset about status flags. Enjoy life & German (CanG) ;-) My solution: - I was at the C-IX with niftybunny and fully populated all 24 RAM slots on both servers. - I’ve been testing BBR congestion control and fq for a few days now. This has significantly reduced the CPU load. :-) -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
Am 12.10.26 um 14:30 schrieb forest via tor-relays:
I have no idea who, but they're attacking relays with the HSDir flag and causing them to lose the flag. Unfortunately, I don't think there's any way to avoid getting the HSDir flag in order to avoid being targeted without also losing the guard flag. But avoiding getting the flag is just doing what the attacker wants anyway.
Would it be acceptable for you to become middle-only? A much better thing that shutting the relays down. -- Gruß Marco Muell und Spam bitte an abfalleimer2002@stinkedores.dorfdsl.de
On Monday, 12 October 2026 14:30 forest via tor-relays wrote:
I have no idea who, but they're attacking relays with the HSDir flag and causing them to lose the flag. Unfortunately, I don't think there's any way to avoid getting the HSDir flag in order to avoid being targeted without also losing the guard flag. But avoiding getting the flag is just doing what the attacker wants anyway.
_avoid_ getting the HSDir flag? Öööh, I actually want exactly the opposite. The HSDir flag should be assigned / calculated just like the Guard flag and persist after a restart. The more trusted relays lose their HSDir flag, the easier it becomes for attackers to deanonymize Onion Services. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
Am 12.10.26 um 15:45 schrieb boldsuck via tor-relays:
On Monday, 12 October 2026 14:05 dawn.belle.flood via tor-relays wrote:
What do people think is the motive behind these attacks? And, who?
This will almost certainly be another multi-national law enforcement operation, similar to Operation Lobos, Habitance, or most recently, Liberty Lane. https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torpr...
These operations against long running HiddenServices often take years and are costly. The most important thing is that ordinary Tor users are not deanonymized.
Does it help that less relays have the HSDir flag for the attacker? What about the many relays with low bandwidth running at home-user sites? Are they also being attacked that much?
The relay is forced to restart e.g. by the out-of-memory (OOM) killer and loses its HSDir status. https://www.petsymposium.org/foci/2024/foci-2024-0014.pdf https://www.computer.org/csdl/proceedings-article/sp/2026/606500b316/2bojw45... There’s nothing the Tor devs can do about that, either.
Keep your relays running as stably as possible. Don't get upset about status flags. Enjoy life & German (CanG) ;-)
Don't smoke too much. :-)
My solution: - I was at the C-IX with niftybunny and fully populated all 24 RAM slots on both servers. - I’ve been testing BBR congestion control and fq for a few days now. This has significantly reduced the CPU load. :-)
I operate a relay that got and lost the guard flag many times, but keeps the HSDir flag. I currently do not see attacks that make the relay unusable or something else. -- Gruß Marco Muell und Spam bitte an abfalleimer2002@stinkedores.dorfdsl.de
Thank you for your contributions forest (as a former relay op myself, and current full-time onion services user) We know it ain't easy and we appreciate you. Do what you have to do. Hopefully you'll be able & willing to return to hosting guards when that makes sense. On Mon Oct 12, 2026 at 12:40 AM PDT, forest via tor-relays wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello.
Within a matter of minutes, quite a few of my relays have come under attack again. As there has been no progress in mitigating the attacks despite several new releases of Tor coming out and no information from the devs about any in-progress mitigations or even plans to develop a mitigation, I'm no longer able to run relays that are eligible for the HSDir flag. The attacks have been causing financial strain to me and straining my relationship with my hosting providers, many of which I have spent significant effort to convince to allow Tor.
If someone knows of a mitigation, can poke the devs to write one, can point me in the right direction for writing my own without getting my relays marked bad for behaving in a non-standard way, or knows of a way to get my relays blacklisted from the HSDir flag besides just setting DirCache 0 (which also prevents being a guard), please tell me.
This is a difficult decision, but if there's really no plan or progress in developing a mitigation for these attacks, I'll be shutting down ~40 guards over the next several days. I just don't know what else to do.
Regards, forest -----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCasyPGgAKCRAw+TRLM+X4 xq01APsF9oxsd74W9sK/cO+xnt4HWZWZ/A7MWc8s2WUHN7telwD/SeoVfuzjaJIM 0NcyOUQVi9jzqkqfr4JEnASneNkh8g0= =dFuQ -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
On Monday, 12 October 2026 19:48 Marco Moock via tor-relays wrote:
Does it help that less relays have the HSDir flag for the attacker?
HSDir's are the 'decentralized' DNS servers of the darknet. They are essential for Hidden (Onion) Services to function! Law enforcement is killing the other relays in order to collect the .onion addresses using their own HSDir. Usually the start of an LA operation for subsequent timing analyses and guard discovery. The nice neighbor on the server rack above me (the one with the powerhouse CPU) got the journalists' documents back then. https://marx.wtf/2024/10/10/law-enforcement-undermines-tor/ https://marx.wtf/2024/09/25/operation-liberty-lane/
What about the many relays with low bandwidth running at home-user sites? Are they also being attacked that much?
I have no idea what criteria these guys have, but servers in the data center are certainly preferred for dynamic IPs.
I operate a relay that got and lost the guard flag many times, but keeps the HSDir flag. I currently do not see attacks that make the relay unusable or something else.
With relais @home, the guard flag often comes and goes due to the calculation 'xy days running & your bandwidth % compared to all guards'. Quote from dir-spec/assigning-flags-vote “Guard” – A router is a possible Guard if *all* of the following apply: - It is Fast, - It is Stable, - Its Weighted Fractional Uptime is at least the median for "familiar" active routers, - It is "familiar", - Its bandwidth is at least AuthDirGuardBWGuarantee (if set, 2 MB by default), OR its bandwidth is among the 25% fastest relays, - It qualifies for the V2Dir flag as described below (this constraint was added in 0.3.3.x, because in 0.3.0.x clients started avoiding guards that didn't also have the V2Dir flag). -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
If this is the case is there a way to discover which HSDir flagged relays have not been attacked and marked them for bad-relays investigation? On October 12, 2026 8:33:32 PM UTC, boldsuck via tor-relays <tor-relays@lists.torproject.org> wrote:
On Monday, 12 October 2026 19:48 Marco Moock via tor-relays wrote:
Does it help that less relays have the HSDir flag for the attacker?
HSDir's are the 'decentralized' DNS servers of the darknet. They are essential for Hidden (Onion) Services to function! Law enforcement is killing the other relays in order to collect the .onion addresses using their own HSDir. Usually the start of an LA operation for subsequent timing analyses and guard discovery.
The nice neighbor on the server rack above me (the one with the powerhouse CPU) got the journalists' documents back then. https://marx.wtf/2024/10/10/law-enforcement-undermines-tor/ https://marx.wtf/2024/09/25/operation-liberty-lane/
What about the many relays with low bandwidth running at home-user sites? Are they also being attacked that much?
I have no idea what criteria these guys have, but servers in the data center are certainly preferred for dynamic IPs.
I operate a relay that got and lost the guard flag many times, but keeps the HSDir flag. I currently do not see attacks that make the relay unusable or something else.
With relais @home, the guard flag often comes and goes due to the calculation 'xy days running & your bandwidth % compared to all guards'.
Quote from dir-spec/assigning-flags-vote
“Guard” – A router is a possible Guard if *all* of the following apply: - It is Fast, - It is Stable, - Its Weighted Fractional Uptime is at least the median for "familiar" active routers, - It is "familiar", - Its bandwidth is at least AuthDirGuardBWGuarantee (if set, 2 MB by default), OR its bandwidth is among the 25% fastest relays, - It qualifies for the V2Dir flag as described below (this constraint was added in 0.3.3.x, because in 0.3.0.x clients started avoiding guards that didn't also have the V2Dir flag).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2026-10-12 13:45, boldsuck via tor-relays wrote:
This will almost certainly be another multi-national law enforcement operation, similar to Operation Lobos, Habitance, or most recently, Liberty Lane.
I doubt that. What benefit would law enforcement get by forcing an onion onto their own HSDir that they wouldn't get just by making a connection to the service itself? The most they could do is censor it.
There’s nothing the Tor devs can do about that, either.
What about limiting the number of BEGIN_DIR streams per circuit? On 2026-10-12 13:52, Marco Moock via tor-relays wrote:
Would it be acceptable for you to become middle-only? A much better thing that shutting the relays down.
That's my short-term plan, yeah. The problem is that I currently have the most diverse set of relays in terms of jurisdiction on the network, and a lot of that has come from personally talking with the owners of various hosting providers and convincing them to allow me to run relays. But these attacks have soured their relationship with me due to the very high CPU use and network use, so I'm not sure if they'll let me renew. On 2026-10-12 20:33, boldsuck via tor-relays wrote:
Law enforcement is killing the other relays in order to collect the .onion addresses using their own HSDir
That was only possible in the v2 days, but v3 onion services are blinded which means it's not possible to find out the .onion address even if you are their HSDir. There's very little an attacker can do in the position of HSDir besides selective censorship (if they already know the .onion, they can match it to the descriptor and censor it). CCing Tobias Höller who I know is working on HSDir research and might have some insight into this whole situation. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCas1lIwAKCRAw+TRLM+X4 xkoNAQCexeIQSeUXEkYj5js1n3Vj3YvqnLMH1YCcDb6nYJ4sBAEAnzbkidpFfTnD nfZZiX6u9Htks8ANskVt1VA1iRZPBgc= =EmG6 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 After looking through the code a little, would a mitigation like this work? It just re-uses the existing DoSStreamCreation defense. I haven't tested it at all, but it looks like it should work. Would it be allowed for me to test this patch on the live network on my relays? All it does is move the code that handles BEGIN_DIR commands below the DoS rate-limiter so torrc's DoSStreamCreationEnable will throttle them. diff -Npura a/src/core/or/connection_edge.c b/src/core/or/connection_edge.c --- a/src/core/or/connection_edge.c 2026-10-12 23:32:06.855730637 +0000 +++ b/src/core/or/connection_edge.c 2026-10-12 23:32:06.855730637 +0000 @@ -4324,19 +4324,10 @@ connection_exit_begin_conn(const relay_m n_stream->on_circuit = circ; if (msg->command == RELAY_COMMAND_BEGIN_DIR) { - tor_addr_t tmp_addr; - tor_assert(or_circ); - if (or_circ->p_chan && - channel_get_addr_if_possible(or_circ->p_chan, &tmp_addr)) { - tor_addr_copy(&n_stream->base_.addr, &tmp_addr); - } - return connection_exit_connect_dir(n_stream); + log_debug(LD_EXIT,"about to start the dns_resolve()."); } - log_debug(LD_EXIT,"about to start the dns_resolve()."); - - // in the future we may want to have a similar defense for BEGIN_DIR and - // BEGIN sent to OS. + /* limit BEGIN, BEGIN_DIR, and RESOLVE stream creation per circuit. */ dos_defense_type = dos_stream_new_begin_or_resolve_cell(or_circ); switch (dos_defense_type) { case DOS_STREAM_DEFENSE_NONE: @@ -4353,6 +4344,16 @@ connection_exit_begin_conn(const relay_m return -END_CIRC_REASON_RESOURCELIMIT; } + if (msg->command == RELAY_COMMAND_BEGIN_DIR) { + tor_addr_t tmp_addr; + tor_assert(or_circ); + if (or_circ->p_chan && + channel_get_addr_if_possible(or_circ->p_chan, &tmp_addr)) { + tor_addr_copy(&n_stream->base_.addr, &tmp_addr); + } + return connection_exit_connect_dir(n_stream); + } + /* send it off to the gethostbyname farm */ switch (dns_resolve(n_stream)) { case 1: /* resolve worked; now n_stream is attached to circ. */ Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCas1wGgAKCRAw+TRLM+X4 xoVYAQCNuo927s2AAIaZ7MLLbdDq6fmQjZIUfz0lHJ/dNT4a3wD+NuDBw51r2XlQ kZPKsroCemN4WgM35Mo8DPYQjCXCLQA= =E2LN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nope, looks like that patch did nothing whatsoever. The relay I tested it on is still receiving over 10,000 BEGIN_DIRs every second. I don't understand why. But limiting the number of BEGIN_DIR requests per circuit per second should be very easy for someone familiar with the code. I will try a few more attempts myself. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCas23PQAKCRAw+TRLM+X4 xv2DAQCb+7iyisbTv327mVLHBtXFX8CwDCoIWW3WoZmsfWM63gEA7ZG5q1kcCI8X qjYJVmwkkfx7m7+eR1l70rjmEgH7egE= =h3Lj -----END PGP SIGNATURE-----
Am 13.10.26 um 00:53 schrieb forest via tor-relays:
That was only possible in the v2 days, but v3 onion services are blinded which means it's not possible to find out the .onion address even if you are their HSDir. There's very little an attacker can do in the position of HSDir besides selective censorship (if they already know the .onion, they can match it to the descriptor and censor it).
CCing Tobias Höller who I know is working on HSDir research and might have some insight into this whole situation.
Are relays known which have HSDir and do such censorship attacks? Is there a good way to detect such attacks? -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Hi forest My second relay is not even month old. ive gotten the hsdir and guard flags already three times and get attacked right away. Now i had hsdir two days and yesterday evening i got guard and in the morning my tor client was crashed and logs told again what happened. The same thing. Im new to this and thinking about giving up. All the stats are f*cked again etc. Sent with Proton Mail secure email. On Tuesday, October 13th, 2026 at 7:52 AM, forest via tor-relays <tor-relays@lists.torproject.org> wrote:
Nope, looks like that patch did nothing whatsoever. The relay I tested it on is still receiving over 10,000 BEGIN_DIRs every second.
I don't understand why. But limiting the number of BEGIN_DIR requests per circuit per second should be very easy for someone familiar with the code. I will try a few more attempts myself.
Regards, forest
forest via tor-relays <tor-relays@lists.torproject.org>:
Nope, looks like that patch did nothing whatsoever. The relay I tested it on is still receiving over 10,000 BEGIN_DIRs every second.
Was it determined that the attack you describe is general and not specifically aimed at you and all the relays you operate? We have not observed anything like this on any HSDir-flagged relay we have access to or this attack was not efficient enough to trouble the normal functioning of those relays.
Hi there. My very first relay is 33 days old and I got under attack 3 times, but it go HSDir flag 5 times - dont know what is the pattern. Two times when it worked stable was after lowering the Bandwidth to 20 MByte. I don't give up. I set MaxMeminQueues to 1/3 of total memory and (in o proper .conf file ) MemoryHigh twice as MaxMemInQueues and MemoryMax to aprrox 2/3 of total memory hoping there is a way of getting rid of OOM Killer. If this isn't enough next time I will think of ram to double ( more expensive VPS ) while leaving MaxMemInQueues and MemoryHigh at same level. Maybe there will enough space to delay OOM Killer long enough to wait attack is over? Am I thinking correctly or is it stupid? Regards, 3hn92a On Tue, 13 Oct 2026, kullikovana via tor-relays wrote:
Hi forest My second relay is not even month old. ive gotten the hsdir and guard flags already three times and get attacked right away. Now i had hsdir two days and yesterday evening i got guard and in the morning my tor client was crashed and logs told again what happened. The same thing.
Im new to this and thinking about giving up. All the stats are f*cked again etc.
Sent with Proton Mail secure email.
On Tuesday, October 13th, 2026 at 7:52 AM, forest via tor-relays <tor-relays@lists.torproject.org> wrote:
Nope, looks like that patch did nothing whatsoever. The relay I tested it on is still receiving over 10,000 BEGIN_DIRs every second.
I don't understand why. But limiting the number of BEGIN_DIR requests per circuit per second should be very easy for someone familiar with the code. I will try a few more attempts myself.
Regards, forest
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Hi I run a small Guard relay that was fine until yesterday. It got attacked and lost the Guard and the Stable flag. At first I thought I could get away with my small RPi 4 relay. Seems to be a very widespread attack against Guards. Best, Mike On 13.10.2026 17:31, 3hn92a--- via tor-relays wrote:
Hi there. My very first relay is 33 days old and I got under attack 3 times, but it go HSDir flag 5 times - dont know what is the pattern. Two times when it worked stable was after lowering the Bandwidth to 20 MByte.
I don't give up. I set MaxMeminQueues to 1/3 of total memory and (in o proper .conf file ) MemoryHigh twice as MaxMemInQueues and MemoryMax to aprrox 2/3 of total memory hoping there is a way of getting rid of OOM Killer. If this isn't enough next time I will think of ram to double ( more expensive VPS ) while leaving MaxMemInQueues and MemoryHigh at same level. Maybe there will enough space to delay OOM Killer long enough to wait attack is over? Am I thinking correctly or is it stupid?
Regards, 3hn92a
On Tue, 13 Oct 2026, kullikovana via tor-relays wrote:
Hi forest My second relay is not even month old. ive gotten the hsdir and guard flags already three times and get attacked right away. Now i had hsdir two days and yesterday evening i got guard and in the morning my tor client was crashed and logs told again what happened. The same thing.
Im new to this and thinking about giving up. All the stats are f*cked again etc.
Sent with Proton Mail secure email.
On Tuesday, October 13th, 2026 at 7:52 AM, forest via tor-relays <tor- relays@lists.torproject.org> wrote:
Nope, looks like that patch did nothing whatsoever. The relay I tested it on is still receiving over 10,000 BEGIN_DIRs every second.
I don't understand why. But limiting the number of BEGIN_DIR requests per circuit per second should be very easy for someone familiar with the code. I will try a few more attempts myself.
Regards, forest
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
I have been experiencing the same attack against my relays. Highly asymmetrical traffic flood until the tor process runs out of memory and is restarted. The attack stops when the HSDir flag is lost. I've doubled the amount of memory available as a temporary work around. For now none of my relays have reacquired the HSDir flag and are not being attacked, including guards. On 14/10/26 01:04, Mzungu via tor-relays wrote:
forest via tor-relays <tor-relays@lists.torproject.org>:
Nope, looks like that patch did nothing whatsoever. The relay I tested it on is still receiving over 10,000 BEGIN_DIRs every second. Was it determined that the attack you describe is general and not specifically aimed at you and all the relays you operate?
We have not observed anything like this on any HSDir-flagged relay we have access to or this attack was not efficient enough to trouble the normal functioning of those relays. _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
On Thursday, 15 October 2026 00:42:51 CEST Jack via tor-relays wrote:
The attack stops when the HSDir flag is lost. I've doubled the amount of memory available as a temporary work around.
And grab yourself a bag of popcorn :-) The darknet is currently tearing itself apart. dread's admin exported the domain keys to God knows where + GoBalance &| EndGame vulnerability: ThatGuy has hijacked the dread domain http://conclave4lqag2lhujgw7hezccnanv75i3yessvgf3rpmxanic2lqhad.onion/t/66/ https://monero.observer/dread-main-onion-private-key-exposed/ -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2026-10-15 11:43, boldsuck via tor-relays wrote:
And grab yourself a bag of popcorn :-) The darknet is currently tearing itself apart.
dread's admin exported the domain keys to God knows where + GoBalance &| EndGame vulnerability: ThatGuy has hijacked the dread domain
That doesn't seem to be related to the DoS in any way. I only vaguely recognize the name Dread, but seeing that they accidentally posted their private onion key is not surprising. Some people have terrible security. Since it was just a PEBKAC issue and not a Tor issue, I'm unconcerned. Unfortunately, while I had ~30 HSDirs just a few days ago, I now have four as a result of the attacks. And they're likely going soon too. I am trying to hold out a little bit longer in hopes of an update with a fix. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCatDBzgAKCRAw+TRLM+X4 xm6lAQDW0QG//IG2R7KiU82MnCoJULNVk8RC3ytEuKdZpeIh+AD8D5tfxQpc+Wmr XJQJHqvddvxFIHUYUNIMaAnkLyt8TAo= =4P2a -----END PGP SIGNATURE-----
On 15/10/26 22:05, forest via tor-relays wrote:
That doesn't seem to be related to the DoS in any way.
Agreed, unrelated but definitely popcorn worthy :-)
Unfortunately, while I had ~30 HSDirs just a few days ago, I now have four as a result of the attacks. And they're likely going soon too. I am trying to hold out a little bit longer in hopes of an update with a fix.
Not sure of the criteria for HSDir but no sign of any of my relays getting it back. The attack seems to be fairly effective but really remains to be seen what the purpose of it is.
On Thursday, 15 October 2026 14:05:12 CEST forest via tor-relays wrote:
That doesn't seem to be related to the DoS in any way. I only vaguely
Clearly, this has nothing to do with HSDir attacks. After all, they wouldn't harm themselves ;-) To attack other .onion services, they launch DoS attacks directly against the service &| its introduction points. BTW a reminder for HS: Enable 'Rate limiting at the Introduction Points' for your Hidden Services. This helps the entire network. ## HiddenService options are per onion service: ## https://community.torproject.org/onion-services/advanced/dos/ HiddenServiceEnableIntroDoSDefense 1 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
On Thursday, 15 October 2026 14:45:26 CEST boldsuck via tor-relays wrote:
Enable 'Rate limiting at the Introduction Points' for your Hidden Services. This helps the entire network.
## HiddenService options are per onion service: ## https://community.torproject.org/onion-services/advanced/dos/ HiddenServiceEnableIntroDoSDefense 1 ... https://archive.torproject.org/websites/lists.torproject.org/pipermail/tor-r...
-- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
Two main defenses we've found successful across ~800 guard relays the last 5 months of the various attacks: 1) Over provision CPU and RAM Few cores available per relay and enough RAM to let a few relays spike from 16-30GB (max we've seen is 90GB for one relay). 2) Use mimallc to return the freed RAM faster than glibc, avoiding OOM more often Swap can help temporarily until mimallc frees the RAM Worse case, in torrc set dircache 0 . Will remove the relay from guard and HSDir flags and the majority of the attacks. Still able to serve traffic and contribute to Tor with less stress on the server resources. Few blogs with more details from the beginning of the June and July attacks, which are still ongoing: https://1aeo.com/blog https://1aeo.com/blog/tor-dos-year-under-flood-2025-2026.html -------- Original Message -------- On Thursday, 10/15/26 at 06:12 boldsuck via tor-relays <tor-relays@lists.torproject.org> wrote: On Thursday, 15 October 2026 14:45:26 CEST boldsuck via tor-relays wrote:
Enable 'Rate limiting at the Introduction Points' for your Hidden Services. This helps the entire network.
## HiddenService options are per onion service: ## https://community.torproject.org/onion-services/advanced/dos/ HiddenServiceEnableIntroDoSDefense 1 ... https://archive.torproject.org/websites/lists.torproject.org/pipermail/tor-r...
-- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2026-10-15 16:45, Tor at 1AEO via tor-relays wrote:
Two main defenses we've found successful across ~800 guard relays the last 5 months of the various attacks:
1) Over provision CPU and RAM Few cores available per relay and enough RAM to let a few relays spike from 16-30GB (max we've seen is 90GB for one relay).
2) Use mimallc to return the freed RAM faster than glibc, avoiding OOM more often Swap can help temporarily until mimallc frees the RAM
I'm sure that works for large dedicated servers, but there's not much that can be done when you have 62 VPSes and a Raspberry Pi with 1-2 GB each spread across the globe. All my servers are resource constrained, although I do use jemalloc2 (but not mimalloc) to reduce memory use. In my situation, memory use isn't even the limiting factor. My relays rarely OOM before the provider suspends them for bandwidth overuse. The full solution is to expand on these: https://gitlab.torproject.org/tpo/core/tor/-/work_items/40589 https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/756 It's a security issue related to TROVE-2022-003, which had a fix that was incomplete and did not mitigate a related vulnerability. A proper fix _should_ stop the attacker dead in their tracks or at last vastly increase their resource requirements.
Few blogs with more details from the beginning of the June and July attacks, which are still ongoing: https://1aeo.com/blog
The circuit-building attack is under control on my relays, since I'm protecting from it on the firewall-level using a ruleset inspired by toralf's iptables generator. Unfortunately, the BEGIN_DIR flood cannot be mitigated using that method since each connection contains multiple multiplexed circuits, each of which can multiplex multiple streams. Thank you very much for your work on documenting present and past DoS attacks against the Tor network, btw! Your insight is invaluable. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCatFLXwAKCRAw+TRLM+X4 xqgdAP4gB/a41kd35xX1Kg8TRq2j4LLiwGGCBNGwpWqzbLFKLwD8CWnW9C8NRAED Xi1zUAHBoAWtR8wS8pu0DasRMV7a0QM= =aTX/ -----END PGP SIGNATURE-----
Would setting a bandwidth limit and hibernating your nodes instead of shutting them down be also a stopgap measure? https://support.torproject.org/relays/performance/bandwidth-limits/ On October 15, 2026 9:52:27 PM UTC, forest via tor-relays <tor-relays@lists.torproject.org> wrote:
On 2026-10-15 16:45, Tor at 1AEO via tor-relays wrote:
Two main defenses we've found successful across ~800 guard relays the last 5 months of the various attacks:
1) Over provision CPU and RAM Few cores available per relay and enough RAM to let a few relays spike from 16-30GB (max we've seen is 90GB for one relay).
2) Use mimallc to return the freed RAM faster than glibc, avoiding OOM more often Swap can help temporarily until mimallc frees the RAM
I'm sure that works for large dedicated servers, but there's not much that can be done when you have 62 VPSes and a Raspberry Pi with 1-2 GB each spread across the globe. All my servers are resource constrained, although I do use jemalloc2 (but not mimalloc) to reduce memory use.
In my situation, memory use isn't even the limiting factor. My relays rarely OOM before the provider suspends them for bandwidth overuse.
The full solution is to expand on these:
https://gitlab.torproject.org/tpo/core/tor/-/work_items/40589 https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/756
It's a security issue related to TROVE-2022-003, which had a fix that was incomplete and did not mitigate a related vulnerability. A proper fix _should_ stop the attacker dead in their tracks or at last vastly increase their resource requirements.
Few blogs with more details from the beginning of the June and July attacks, which are still ongoing: https://1aeo.com/blog
The circuit-building attack is under control on my relays, since I'm protecting from it on the firewall-level using a ruleset inspired by toralf's iptables generator. Unfortunately, the BEGIN_DIR flood cannot be mitigated using that method since each connection contains multiple multiplexed circuits, each of which can multiplex multiple streams.
Thank you very much for your work on documenting present and past DoS attacks against the Tor network, btw! Your insight is invaluable.
Regards, forest
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2026-10-15 22:07, tor--- via tor-relays wrote:
Would setting a bandwidth limit and hibernating your nodes instead of shutting them down be also a stopgap measure?
Setting a bandwidth limit would automatically set DirCache 0 which would also prevent them from being guards. I'll keep as many as I can as non- guards, but I don't know how many I'll get to keep, since some providers have indicated that they might not allow me to renew the service due to the impact on their infrastructure the attacks have had. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCatFRdQAKCRAw+TRLM+X4 xgULAQCZbqno2vRB7ffcroV+FZr738F6h9XxYGkjFYxqmdVTFQD/QJzjt+R7jDcd EG1KOF0P9R8aHzViwHVHjdRUH1VhswQ= =Hx0L -----END PGP SIGNATURE-----
What about setting BandWidthBurst at the same level that BandwidthRate ? I did this when last attack took place ( both set to low rates ) and I had seen symetric traffic before final OOM. Regards, 3hn92a On Thu, 15 Oct 2026, forest via tor-relays wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2026-10-15 22:07, tor--- via tor-relays wrote:
Would setting a bandwidth limit and hibernating your nodes instead of shutting them down be also a stopgap measure?
Setting a bandwidth limit would automatically set DirCache 0 which would also prevent them from being guards. I'll keep as many as I can as non- guards, but I don't know how many I'll get to keep, since some providers have indicated that they might not allow me to renew the service due to the impact on their infrastructure the attacks have had.
Regards, forest -----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCatFRdQAKCRAw+TRLM+X4 xgULAQCZbqno2vRB7ffcroV+FZr738F6h9XxYGkjFYxqmdVTFQD/QJzjt+R7jDcd EG1KOF0P9R8aHzViwHVHjdRUH1VhswQ= =Hx0L -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
On Friday, 16 October 2026 00:18:23 CEST forest via tor-relays wrote:
On 2026-10-15 22:07, tor--- via tor-relays wrote:
Would setting a bandwidth limit and hibernating your nodes instead of shutting them down be also a stopgap measure?
Setting a bandwidth limit would automatically set DirCache 0 which would also prevent them from being guards.
With e.g.: RelayBandwidthRate 30 MBytes RelayBandwidthBurst 100 MBytes you get *all* flags. I’ve always had it enabled on all my relays, additionally on a VPS: MaxAdvertisedBandwidth https://github.com/boldsuck/tor-relay-bootstrap/blob/master/etc/tor/torrc -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
participants (12)
-
3hn92a＠cock.li -
boldsuck -
dawn.belle.flood -
fjord -
forest -
Jack -
kullikovana -
Marco Moock -
Mike Dylan Poppelaars -
Mzungu -
Tor at 1AEO -
tor＠nullvoid.me