Tor's history of D/DoS attacks; strategy for mitigation
I'm investigating the applicability of the IETF's DDoS Open Threat Signaling (DOTS) specifications[1] to the needs of privacy-preserving overlay networks, including VPNs but with particular interest in Tor. Specifically, now that the July 2022 D/DoS attack has finally come to a close, I'm wondering about: 1. the history, frequency, and magnitude of D/DoS attacks against the Tor network; 2. when these have taken the form of Tor traffic versus lower-level attacks on Tor nodes and HSDirs; and 3. how the new "proof of work over introduction circuits" scheme fits into Tor's overall strategy for mitigating D/DoS attacks. I've found plenty of current and historical GitLab tickets---but I'm wondering if there are more comprehensive documents or other resources I'm not aware of. --- cfm[2]. [1]: https://datatracker.ietf.org/wg/dots/documents/ [2]: I'm a maintainer of the SecureDrop project at the Freedom of the Press Foundation, but this work is supported by ARTICLE 19's Internet of Rights Fellowship.
On 6/26/23 04:10, Cory Francis Myers wrote:
I'm investigating the applicability of the IETF's DDoS Open Threat Signaling (DOTS) specifications[1] to the needs of privacy-preserving overlay networks, including VPNs but with particular interest in Tor.
Specifically, now that the July 2022 D/DoS attack has finally come to a close, I'm wondering about:
1. the history, frequency, and magnitude of D/DoS attacks against the Tor network;
We have seen high volumes of onion service activity indicative of internal onion service DDoS roughly once a year for the past several years. We also have seen periodic attacks against the directory authorities, going back several years.
2. when these have taken the form of Tor traffic versus lower-level attacks on Tor nodes and HSDirs; and
The most common attack has been either onion service related, or against the directory authorities. However, over the past year, we saw several attack attempts that appeared to target specific relays. This was a new phenomenon, at this scale. We also saw some evidence of DDoS attack attempts through Tor. Relay operators have developed tools to block connections to external IP addresses that see connection spikes. One such example tool is: https://github.com/artikel10/surgeprotector We have made several attempts to secure funding to develop mechanisms to rate limit scraping, spam, and externally-destined DDoS attack activity happening through Tor, but so far, these funding proposals have all been rejected.
3. how the new "proof of work over introduction circuits" scheme fits into Tor's overall strategy for mitigating D/DoS attacks.
Around when the proof of work branch got finalized, the onion service attacks ended. We are not sure if this is related to the ability to deploy the PoW branch ad-hoc, or if it was just a coincidence. Since the majority of DDoS activity has been onion service related, we expect this defense to act as a deterrent there, for most of the issues we have seen.
I've found plenty of current and historical GitLab tickets---but I'm wondering if there are more comprehensive documents or other resources I'm not aware of.
No. Many of the non-onion attacks we have noticed have confidential tickets. Many attacks were quite effective at degrading service, and appeared to have this as their goal. They were also appeared to be probing in nature, and often stopped after a few days or a week from starting. These attacks ran parallel to the larger onion service DDoS. We recently obtained funding to fix these kinds of specific attacks against Guards, dirauths, and Exits, but many issues will remain confidential until we do so. We do not want to advertise which of these probing attacks were actually effective vs not, or why. --- cfm[2].
[1]: https://datatracker.ietf.org/wg/dots/documents/
[2]: I'm a maintainer of the SecureDrop project at the Freedom of the Press Foundation, but this work is supported by ARTICLE 19's Internet of Rights Fellowship. _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
-- Mike Perry
On 2023-07-05 12:50, Mike Perry wrote:
The most common attack has been either onion service related, or against the directory authorities. However, over the past year, we saw several attack attempts that appeared to target specific relays. This was a new phenomenon, at this scale.
[…]
Since the majority of DDoS activity has been onion service related, we expect [the proof-of-work] defense to act as a deterrent there, for most of the issues we have seen.
[…]
We recently obtained funding to fix these kinds of specific attacks against Guards, dirauths, and Exits, but many issues will remain confidential until we do so. We do not want to advertise which of these probing attacks were actually effective vs not, or why.
Thanks very much for this summary, Mike. It sounds like there is a clear division between (a) attacks targeting onion services, to be mitigated by the proof-of-work defense; and (b) attacks with a clearnet source or target, to be mitigated by this new work in progress. For the latter, could there be value in a mechanism that allows nodes (especially relays) to coordinate either local or upstream blocking of traffic from D/DoS sources? This is the potential application I’m investigating of the IETF DOTS standard. But it may be an approach you’ve either already selected or ruled out. --- cfm. -- Cory Myers 0x0F786C3435E961244B69B9EC07AD35D378D10BA0
On 7/13/23 20:23, Cory Francis Myers wrote:
On 2023-07-05 12:50, Mike Perry wrote:
The most common attack has been either onion service related, or against the directory authorities. However, over the past year, we saw several attack attempts that appeared to target specific relays. This was a new phenomenon, at this scale.
[…]
Since the majority of DDoS activity has been onion service related, we expect [the proof-of-work] defense to act as a deterrent there, for most of the issues we have seen.
[…]
We recently obtained funding to fix these kinds of specific attacks against Guards, dirauths, and Exits, but many issues will remain confidential until we do so. We do not want to advertise which of these probing attacks were actually effective vs not, or why.
Thanks very much for this summary, Mike. It sounds like there is a clear division between (a) attacks targeting onion services, to be mitigated by the proof-of-work defense; and (b) attacks with a clearnet source or target, to be mitigated by this new work in progress.
I would separate the two parts of (b). Each will have different solutions, from our point of view. Addressing attacks coming from Tor exits remains unfunded. Addressing attacks against Tor relays is funded. Most the probing attacks against relays that we saw probed for resource exhaustion conditions, which we will address via those conditions themselves. We did get a report of at least one instance of the typical UDP reflection flood against a Tor relay, though. It was quite large, but we only heard this report from one relay operator (and there are several thousand relay operators).
For the latter, could there be value in a mechanism that allows nodes (especially relays) to coordinate either local or upstream blocking of traffic from D/DoS sources? This is the potential application I’m investigating of the IETF DOTS standard. But it may be an approach you’ve either already selected or ruled out.
"It depends". It is unlikely for us to get directly involved in IP address blacklist or IP address reputation games. Tor user experience is significantly degraded by these systems. While we are trying to pitch funding proposals to improve Tor exit IP address reputation, subjecting our user IP addresses to these systems seems anathema and unlikely. In general, we vastly prefer cryptographic rate limiting approaches, or deterrents like our pow system[1], over blacklist-based approaches. Now, if there were ideas being kicked around to cryptographically blind this data such that IP addresses were not revealed to anyone until they appear in multiple DoS event logs, that might be of interest. 1. https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/327-pow... -- Mike Perry
On Fri, Jul 14, 2023 at 01:32:55AM +0000, Mike Perry wrote:
Most the probing attacks against relays that we saw probed for resource exhaustion conditions, which we will address via those conditions themselves. We did get a report of at least one instance of the typical UDP reflection flood against a Tor relay, though. It was quite large, but we only heard this report from one relay operator (and there are several thousand relay operators).
Thanks for clarifying, Mike. This is the more-generic class of attack against which the DOTS standard would be most useful---which means it probably won't be, for Tor relays, even apart from your caveat below.
It is unlikely for us to get directly involved in IP address blacklist or IP address reputation games. Tor user experience is significantly degraded by these systems. While we are trying to pitch funding proposals to improve Tor exit IP address reputation, subjecting our user IP addresses to these systems seems anathema and unlikely.
Understood. Were this method to be effective, would you extend this objection even to coordinated *short-term* (requested/cancellable) mitigation, in contrast to a cumulative, long-lived reputation scheme?
In general, we vastly prefer cryptographic rate limiting approaches, or deterrents like our pow system[1], over blacklist-based approaches.
Now, if there were ideas being kicked around to cryptographically blind this data such that IP addresses were not revealed to anyone until they appear in multiple DoS event logs, that might be of interest.
Interesting! I will look into this approach as a possible extension of the DOTS standard. Thanks for the suggestion. --- cfm.
On 7/19/23 15:43, Cory Francis Myers wrote:
On Fri, Jul 14, 2023 at 01:32:55AM +0000, Mike Perry wrote:
Most the probing attacks against relays that we saw probed for resource exhaustion conditions, which we will address via those conditions themselves. We did get a report of at least one instance of the typical UDP reflection flood against a Tor relay, though. It was quite large, but we only heard this report from one relay operator (and there are several thousand relay operators).
Thanks for clarifying, Mike. This is the more-generic class of attack against which the DOTS standard would be most useful---which means it probably won't be, for Tor relays, even apart from your caveat below.
It is unlikely for us to get directly involved in IP address blacklist or IP address reputation games. Tor user experience is significantly degraded by these systems. While we are trying to pitch funding proposals to improve Tor exit IP address reputation, subjecting our user IP addresses to these systems seems anathema and unlikely.
Understood. Were this method to be effective, would you extend this objection even to coordinated *short-term* (requested/cancellable) mitigation, in contrast to a cumulative, long-lived reputation scheme?
I think where this is most likely to happen is at ISPs that relay operators use, for things like the UDP reflection attacks, rather than the relays themselves. David told me the other day that OVH actually stops such attacks against his relay every few weeks or so, so they might be more common than I realized, but just handled upstream in most cases. The problem with trying to apply this to Tor itself is that a) We need to focus our limited dev resources on addressing existing resource exhaustion bottlenecks that have been targeted, rather than reporting mechanisms, at least for the short and medium-term. b) It is possible for legitimate activity to trip the rate limits that we have in place on Tor relays today, occasionally. We do not want to broadcast such IP addresses, as they might actually be legitimate users. The cryptographic blinding idea I mentioned below would help with b, though. If some mechanism existed such that an IP was not revealed until it started tripping the limits of many relays, then this more strongly indicates that it is actually an attacker. There are some ideas in https://www.freehaven.net/anonbib/, if you search for Nymble, BLAC, and Blacklisting. It has been a while since this literature has been reviewed or updated for ECC even, though, so I don't have great recommendations atm :/
In general, we vastly prefer cryptographic rate limiting approaches, or deterrents like our pow system[1], over blacklist-based approaches.
Now, if there were ideas being kicked around to cryptographically blind this data such that IP addresses were not revealed to anyone until they appear in multiple DoS event logs, that might be of interest.
Interesting! I will look into this approach as a possible extension of the DOTS standard. Thanks for the suggestion.
--- cfm.
-- Mike Perry
participants (2)
-
Cory Francis Myers -
Mike Perry