adaption of a DDoS prevention solution
Recent DDoS attacks caused me to update the DDoS solution [1] and to roll it out to Tor instances using [2]. The metrics below shows the effect for the (highly overloaded vCPU before), the throughput and the amount of protocol violations of a tiny Tor cloud instance: Another example is Tor instance at a bare metal server, attacked between 12 and 13 UTC (no Tor metrics during that time) and again after 16 UTC. The new rule set was developed between 14 and 15, and fully applies after a reboot at 15:20: The graph below shows that the ipset (which holds malicious ip addresses to be blocked) was not updated at the first attack. But with the new rule set in place it was updated soon at the 2nd attack. The yellow line in the 2nd graph shows the portion of the change. And finally the DOS Tor metric for this instance indicates that the Tor process has much less DOS to handle than before: I'm still fine tuning the solution. [1] https://github.com/toralf/torutils#the-rule-set [2] https://github.com/toralf/tor-relays -- Toralf
On 18/07/2026 22:15, Toralf Förster via tor-relays wrote:
I'm still fine tuning the solution. Well, and I should definitly fine-tune my mailer setting to allow sending images.
Whilst my 2nd attempt to send a compelte email is still awaiting forum moderator approval here are the images: https://imgur.com/a/uZPL54w -- Toralf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. It would be good if you could describe the operation of the firewall in detail so that I can more easily re-implement it with nftables. What is described on the README doesn't seem to be the entire picture. I'm also curious if you could export a list of IPs involved in the current attack so that I can blacklist them in the meantime. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCal1hwgAKCRAw+TRLM+X4 xhkXAQDgxOLF0P+0WbZbiZ0cTT5hsNJjOqsyFWHLfoA0uoonmwD8D+ovBY5JmUmx GtUHZl3A3pTI1Dy3J2K3n2Af6rhn7Q4= =40AE -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. So far, this is what I have for IPv4 (without any persistence features, so the sets disappear on restart), but I have nothing yet for IPv6 because I'm trying to figure out a better way to apply blocks with more fine-grained comparisons than "/64 for Hetzner etc, /80 for IONOS etc". flush ruleset table inet filter { set tor_ddos { type ipv4_addr flags timeout timeout 24h } set tor_connlimit { type ipv4_addr } define tor_trusted = { # snowflake servers 141.212.118.18, 193.187.88.42, 193.187.88.43, 193.187.88.44, 193.187.88.45, 193.187.88.46, # directory authorities 45.66.35.11, 66.111.2.131, 128.31.0.39, 131.188.40.189, 171.25.193.9, 193.23.244.244, 199.58.81.140, 204.13.164.118, 216.218.219.41, 217.196.147.77 } chain tor_input { ip saddr $tor_trusted accept ip saddr @tor_ddos log prefix "ddos-block " drop add @tor_connlimit { ip saddr ct count over 8 } log prefix "excessive-connections " drop meter tor-ddos-fast { ip saddr timeout 2m limit rate over 8/minute burst 8 packets } add @tor_ddos { ip saddr } log prefix "add-ddos-fast " drop meter tor-ddos-slow { ip saddr timeout 1h limit rate over 16/hour burst 16 packets } add @tor_ddos { ip saddr } log prefix "add-ddos-slow " drop accept } chain input { type filter hook input priority filter; policy drop; iif lo accept ct state { established, related } accept ct state new jump { tcp dport 9001 tcp flags syn jump tor_input tcp dport 22 accept } icmp type echo-request limit rate 25/second accept } chain output { type filter hook output priority filter; policy accept; } chain forward { type filter hook forward priority filter; policy drop; } } -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCal2ReQAKCRAw+TRLM+X4 xqQTAQCvT5L3BmfIkBUfP0wM28sTgUHKnPu0ixdElgOgOpSsZgEAwzOYh+CRdW9C 1lOzZZiu/PbBKoxB+NuPioKEXq30Egw= =G2JJ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Thankfully you do publish the source code. I've adapted it to IPv6, but I have some concerns. For example, I frequently see various Hetzner IPs getting quickly added to the blacklist. They appear to be from a reseller of Hetzner who has more than a /64. I worry that I might be blocking some VPN, but then again how would hundreds of people be using one of my little relays as their guard all on the same VPN? How can I determine if the rapidly growing list (which seems like it's someone with a /48 on a Hetzner IP) is including legitimate people? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCal8TaAAKCRAw+TRLM+X4 xnJoAQCmNGKTXK3B4ka1P0/PANWRHbyabDLgoqfK3WLwp49mXQEAzWHMZLS3gQWB K4KdXGy7WXsnnqEKk5BfOJgozOVOOQ4= =qKZC -----END PGP SIGNATURE-----
participants (2)
-
forest-relay-contact＠cryptolab.net -
Toralf Förster