I am getting these warnings, not very often, and the exit (restricted) is working well otherwise:
"Dec 11 18:07:23.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)" Some posts about this elsewhere hinted this warning could be caused by attacks. I am not seeing attacks otherwise. Gerry -----Original Message----- From: tor-relays [mailto:[email protected]] On Behalf Of Felix Sent: 11 December 2017 17:08 To: [email protected] Subject: Re: [tor-relays] DoS attacks are real (probably) 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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
