On 11 Jan 2018, at 08:10, Toralf Förster toralf.foerster@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 ------------------------------------------------------------------------