[tor-relays] connlimit: better to use "DROP" or "REJECT --reject-with tcp-reset"?

[teor]

> On 11 Jan 2018, at 08:10, Toralf Förster <toralf.foerster at gmx.de> wrote:
> 
> On 01/10/2018 06:39 AM, teor wrote:
>> iptables -I INPUT -p tcp --syn ! --dport 22 -m state --state NEW -m recent --set
>> iptables -I INPUT -p tcp --syn ! --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 100 -j DROP
> 
> What's about the following approach;
>  IPT="/sbin/iptables"
> 
>  $IPT -P INPUT   DROP
>  $IPT -P OUTPUT  ACCEPT
>  $IPT -P FORWARD DROP
> 
>  # trust already established connections
>  #
>  $IPT -A INPUT --match conntrack --ctstate ESTABLISHED -j ACCEPT
>  $IPT -A INPUT --match conntrack --ctstate RELATED     -j ACCEPT
>  $IPT -A INPUT --match conntrack --ctstate INVALID     -j DROP
> 
>  # Tor
>  #
>  for p in 443 80
>  do
>    $IPT -A INPUT -p tcp --syn --destination-port $p --match connlimit --connlimit-above 2 --connlimit-mask 32 -j DROP
>    $IPT -A INPUT -p tcp --destination-port $p -j ACCEPT
>  done
> 
> 
> Those rules should not prevent clients behind a NAT from accessing the relay as long as the clients do not come in in parallel.

As far as I can tell, this single rule has the same effect:

 # Tor
 #
 for p in 443 80
 do
   $IPT -A INPUT -p tcp --syn --destination-port $p --match connlimit --connlimit-above 2 --connlimit-mask 32 -j DROP
 done


> Objections ?

Bridges and hidden services often come in parallel.
As do large client deployments in areas without much IPv4 allocation.

We allow 2 relays per IPv4 address, and each relay makes 1-2 connections
to each other relay. (Or more, if the connections start failing. This is
a bug we want to fix.)

So if you're going to do this, please set a much higher limit than 2.
I would suggest at least 4, but 10 or more is better.

You might be able to set it higher if you put a limit on repeated
connection attempts.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20180111/49435033/attachment-0001.sig>