[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-relays] Re: How is this attack causing 900 Mbps download and 100 Mbps upload?
Hi forest, and everyone,
I would like to share a further update following my earlier reports about abnormal BEGIN_DIR activity on three non-exit Tor relays.
We have now completed a reproducible retrospective analysis of another prolonged incident on October 17–18, following the earlier episodes on October 4–5, October 8, and October 12–13.
This time we had two independent monitoring systems:
- Tor Sentinel, collecting standard Tor MetricsPort measurements, including BEGIN_DIR activity, circuit counts and Tor process metrics.
- Linux OS Sentinel, independently collecting host and process resource indicators, including CPU, memory, swap and Linux pressure statistics.
The second system was added after the earlier incidents revealed that MetricsPort can become temporarily unresponsive during severe overload.
Our main observations are:
- Two ARM relays, hosted by different providers (Hetzner and Oracle Cloud), again experienced substantial, prolonged BEGIN_DIR-related workload. A third, smaller Oracle AMD relay did not show comparable BEGIN_DIR activity.
- The two affected relays showed different resource profiles. The Hetzner relay experienced very low available memory and substantial swap occupancy. The Oracle ARM relay showed considerable CPU pressure and more monitoring failures despite retaining a much larger memory reserve.
- The Tor processes remained running. A bandwidth configuration change and reload reported on the Hetzner relay did not immediately end its prolonged abnormal state.
- Locally observed HSDir flag transitions did not provide a simple explanation for the onset of the workload. We are distinguishing these observations from independently verified directory consensus changes.
- The recorded BEGIN_DIR peaks are lower bounds on the maximum successfully observed rates, not necessarily the true maxima, because measurements can be lost during overload.
We have preserved and validated the underlying measurements and analysis scripts. However, in accordance with Tor’s relay-operator privacy expectations, I am not publishing high-resolution traffic or host statistics. I would be happy to discuss an appropriate private channel for technical review.
A few questions for operators and developers:
- Have others observed MetricsPort timeouts or degraded responsiveness during comparable BEGIN_DIR workloads?
- Have Tor’s MaxMemInQueues protection or circuit-killing notices appeared during these incidents?
- Is there any progress on understanding why the experimental BEGIN_DIR rate-limiting approach discussed earlier did not appear effective?
- Can Network Health or the directory-authority community help clarify whether overload-related descriptor or consensus effects might explain some of the observed flag changes?
- Would a coordinated comparison of daily incident summaries from independent operators be useful?
I do not have evidence identifying the origin or intent of this traffic, and I do not want to imply that all reports necessarily have the same cause.
My goal is to contribute reliable observations and help identify what further evidence would be useful.
Regards,
KhanKrum
_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx