Tor Relay Denial of Service Mitigation

Tor relays face several categories of DoS threats. Connection flooding: an attacker establishes thousands of TCP connections to the relay's ORPort, exhausting socket resources or consuming CPU with handshake processing. Tor's DoS mitigation includes connection limits and circuit-creation rate limiting. Circuit creation flooding: large numbers of circuit creation requests force the relay to perform expensive public-key cryptography (CREATE cell processing). Tor's DoS mitigation (introduced in Tor 0.3.6) rate-limits circuit creation per client IP. Bandwidth flooding: sending large volumes of traffic through circuits using the relay, consuming all available bandwidth. Mitigated by Tor's BandwidthRate limit. Hidden service descriptor flooding: for hidden service hosting relays (HSDirs), attackers can flood with fake descriptor uploads. Tor's HsDir protections limit this.

Tor's DoS mitigation directives (torrc): DoSCircuitCreationEnabled 1 enables circuit creation rate limiting (default: on in modern Tor). DoSCircuitCreationBurst 90 sets the maximum circuit creation requests from one IP within DoSCircuitCreationMinutes before triggering mitigation. DoSCircuitCreationMinutes 3 defines the observation window. DoSConnectionEnabled 1 enables connection-level DoS mitigation. DoSConnectionMaxConcurrentCount 100 limits concurrent connections from a single IP. DoSConnectionDefense 3 sets the action: 3 = refuse new connections from the offending IP for DoSConnectionDefenseTime seconds. DoSRefuseSingleHopClientRendezvous 1 refuses rendezvous requests from single-hop clients (prevents a specific circuit topology abuse). These settings activate Tor's kernel-integrated rate limiting when triggered.

Beyond Tor's built-in protections, OS-level controls provide additional defense. iptables (or nftables) rate limiting: iptables -A INPUT -p tcp --dport 9001 -m state --state NEW -m limit --limit 50/minute --limit-burst 100 -j ACCEPT followed by iptables -A INPUT -p tcp --dport 9001 -m state --state NEW -j DROP limits new connection establishment rate. For more sophisticated rate limiting: use Fail2ban with a Tor-specific jail that monitors /var/log/tor/notices.log for DoS-related entries and automatically bans offending IPs. The /proc/sys/net kernel parameters also affect connection handling: net.core.somaxconn = 65535 (increase listen queue), net.ipv4.tcp_syncookies = 1 (enable SYN cookie protection), and net.ipv4.tcp_max_syn_backlog = 4096 (increase SYN backlog). These kernel parameters help handle connection bursts without dropping legitimate connections.

Recognizing DoS patterns in relay logs: Tor's DoS mitigation generates log entries when mitigation is triggered. Entries like 'Detected DoS on circuit creation from ip X' or 'Detected too many connections from ip X' indicate active DoS mitigation. Monitoring commands: watch ss -s (socket statistics showing connection states), watch 'netstat -n | grep :9001 | awk "{print \$5}" | cut -d: -f1 | sort | uniq -c | sort -rn | head -10' (top IPs by connection count to ORPort). Set up monitoring alerts: use a monitoring system (Prometheus + node_exporter) to alert on high connection counts or CPU usage spikes. Tor metrics: the MetricsPort directive (MetricsPort 9035 in torrc) exposes relay metrics in Prometheus format, including DoS mitigation trigger counts.

After experiencing a DoS attack: (1) review logs to characterize the attack: connection flood, circuit flood, or bandwidth flood, (2) adjust DoS mitigation thresholds if default values were insufficient (lower DoSCircuitCreationBurst or DoSConnectionMaxConcurrentCount), (3) implement IP-level blocking for repeated offenders using iptables --dport 9001 -s -j DROP (though attackers may spoof or rotate IPs), (4) consider implementing a SYN proxy (Cloudflare Spectrum or similar) for ORPort traffic to absorb connection floods before they reach Tor, (5) report significant DoS incidents to the Tor Project via their relay-operators mailing list - patterns of attacks against relays can inform network-level defenses, (6) increase server resources if the attack exceeded the relay's capacity: move to a larger VPS plan with more CPU and memory to handle burst traffic.