On Mon, 11 Dec 2017 at 18:07 Felix <zwie...@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
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
