On Samstag, 10. August 2024 00:58:29 CEST George Hartley via tor-relays wrote:
Then these must be targeted attacks, as I have never encountered something like this during 10 years of relay operation under different providers and aliases.
Of course, these are targeted attacks and have been extreme since the Ukraine war. If a handful of servers of large relay orgs with hundreds of relays are brought down, it can affect 20-30% of the total exit traffic.
The attacks pushed the Junipers to their limits and the entire IX was at risk.
In the next few days I can show a live example of targeted hidden service attacks. 2 hs are currently public in the client software and are being attacked. 2 more will be added tomorrow and I am sure that DDoS will start shortly after. You can see this very clearly in PoW metrics on Grafa.
https://db4n0nym3.grafana.net/public-dashboards/ 71ad3412bfde44058993dccb07a5e593
Sorry, but the Tor logs that I am seeing suggest that most DoS gets mitigated.
You can't see everything in the Tor logs. Toralf has developed some tools to better monitor relays. Specifically ddos-inbound.sh helped me to develop rules. https://github.com/toralf/torutils
As far as I know, the concurrent connection (not circuit!) DoS defense is relatively new, so give the developers some time.
Also, any default IPTables rule-set should automatically either reject or just drop connections above a certain threshold.
That's why we have developed dynamic IP/NFtables rules for the guards. The whole story began here: https://gitlab.torproject.org/tpo/community/support/-/issues/40093 For Tor exits, the policy reject is of course more effective.
And from 10-20G you can no longer use conntrack. Linux does not scale. You can't do much with table inet filter. I drop the most stubborn IPs with ethtool using NIC hardware filtration. The rest with nftables dynamic sets in the ingress hook before prerouting.