On Mon, 11 Dec 2017 at 18:07 Felix <zwiebel@quantentunnel.de> wrote:
Hi Alex
Great points.
conntrack -L -p tcp --dport 9001 | awk '{print $5}' | sort | uniq -c
| sort -n
On FreeBSD one can do:
In packetfilter:
# play with the numbers but more than 64k per ip if possible set limit { frags 70000, src-nodes 70000, states 70000, table-entries 100000 }
table <blockOR> persist
# 2000 is super high. Rate limit 50 new connects per 5 secs # overload but not flush pass in on $if_ext inet proto tcp from any to $relay_ip port $or_port flags S/SA modulate state (max-src-conn 2000,max-src-conn-rate 50/5,overload <blockOR>)
As cronjob:
# release block after 10 minutes pfctl -t blockOR -T expire 600
These measures protect your system. IMO for other or future cases we should keep the clients degree of freedom (researchers / fancy doers) as high as possible, being not too restrictive.
1. Open many OR connections (hundreds to thousands) 2. Leave open until tor runs out of sockets
If the ip is saturated for like 2 hours the relay might loose the hsdir flag. But today there are not enough resources in the game to generate an issue for the network.
I recommend against the blanket approach suggested previously of limiting whole sets of /24s, since that may inadvertently block mobile clients and is not effective against the current attack.
Right. In future one could put such loud clients besides useful ips a let the relays block the usefull.
2. the connections do not taper off if they are rejected. I banned these addresses from accessing Tor, and they continue to make dozens of connection attempts every second from each IP address. this means that this is probably not a good faith "test" or a misconfigured set of real Tor clients, but is instead malicious and using a modified or custom client.
The above rule limits the useless attempts to a certain limit and recovers after 10 minutes. This protects but gives the 'offender' the chance to tune his client to a better behaviour (in case he wants it).
3c. it is almost certainly not real clients using NAT; as far as I know, LeaseWeb does not use NAT, and Online.net only uses one-to-one NAT.
Good point. A general blocking rule should be smart enough to enable NAT clients anyway ?
-- Cheers, Felix _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi For the ones interested in Linux version, this translates to: -A INPUT -p tcp -m multiport --dports $or_port,$dir_port -m connlimit --connlimit-upto 2000 --connlimit-mask 24 -m hashlimit --hashlimit-upto 10/second --hashlimit-mode srcip --hashlimit-srcmask 16 --hashlimit-name mask24 -j ACCEPT -A INPUT -p tcp -m multiport --dports $or_port,$dir_port -j REJECT