Hi,
yes your right – I saw the spike pretty early but wasn’t on the right track at first. To my defence. I thought I might be possbile that the other relays (which might were updated before mine) were cause of the issue. My current conclusions: - Obviously all relay families affected (Linux, BSD, Windows) - Attack comes primarily from Contabo VPS Subnets (Contabo AS) mostly from 13.140.128.0/18, 212.41.0.0/16, 212.47.0.0/16 - Current Measurement: 250K TCP Connections from Contabo AS - Attack burns CPU Cycles but does not affect normal operation (for me) - Attack might not be „Code-related“ and thus the version change was likely irrelevant. Also, the connections seem to build up very fast, I had to restart the relay due to CPE changes yesterday, today we‘re back at 309k TCP Connections total, which is insane for the short uptime. Regards, Joker Von: Tor at 1AEO [mailto:[email protected]] Gesendet: Dienstag, 14. Juli 2026 15:35 An: support and questions about running Tor relays (exit, non-exit, bridge) Cc: 'ProSecureRelays' Betreff: Re: [tor-relays] Re: Abnormal Firewall-States since 0.4.9.10 Sharing a hypothesis: This is likely not the 0.4.9.10 upgrade — your own numbers point that way: the state counts were already elevated in the days before you updated (120–145k, and 190k the day before, against your 20–45k norm). The timing instead lines up with the network-wide circuit-building DoS wave running since Jun 25 23:00 UTC (the "Circuit-building DoS wave: 20x peak, 8x sustained circuits on guard relays" thread on this list). From Tor's public archives alone: relays signing overload-general climbed from a 2–3% baseline to 12.2% of the network (1,254 relays) on Jul 12, and Running-flag churn roughly tripled — saturated relays failing the directory authorities' reachability probes while still relaying. A full state table is the same failure taken further — nothing new can connect — which would explain a relay dropping off entirely for hours once it hits its state-table max, as reported later in this thread. On the ~200–250 connections per source address: that would be consistent with Tor's stock defense if that machine runs 4–5 relay instances. DoSConnectionMaxConcurrentCount (consensus default 50) is enforced per tor process, not per host, so N co-hosted relays legally accept 50×N connections from a single source. Worth checking how many relays share that host. We think that per-process enforcement is a real gap — it's one of the changes we've suggested to the Tor Project, with the rest of what we've measured: * https://1aeo.com/blog/defending-against-circuit-dos-june-2026.html * Network-wide picture, from public data alone: https://1aeo.com/blog/tor-network-dos-wave-june-2026.html Attaching two charts from public Tor data about the network that might help frame what's happening broadly. On Tuesday, July 7th, 2026 at 3:54 PM, ProSecureRelays via tor-relays <[email protected]> wrote:
_______________________________________________ tor-relays mailing list -- [email protected] To unsubscribe send an email to [email protected]
