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