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

teor teor2345 at gmail.com
Thu Jan 11 01:10:56 UTC 2018

> 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"
>  # 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
   $IPT -A INPUT -p tcp --syn --destination-port $p --match connlimit --connlimit-above 2 --connlimit-mask 32 -j DROP

> 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.


Tim Wilson-Brown (teor)

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

-------------- 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>

More information about the tor-relays mailing list