[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-relays] Re: Abnormal Firewall-States since 0.4.9.10



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:tor@xxxxxxxx]
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 <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote:

 

 

_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx