netdev - Re: [PATCH RFC] netfilter: iptables target SYNPROXY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1005252100500.21791@blackhole.kfki.hu>
Date:	Tue, 25 May 2010 21:03:06 +0200 (CEST)
From:	Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
To:	Changli Gao <xiaosuo@...il.com>
cc:	Patrick McHardy <kaber@...sh.net>,
	"David S. Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH RFC] netfilter: iptables target SYNPROXY

Hi,

On Tue, 25 May 2010, Changli Gao wrote:

> On Tue, May 25, 2010 at 8:17 PM, Jozsef Kadlecsik
> <kadlec@...ckhole.kfki.hu> wrote:
>
> > On Tue, 25 May 2010, Changli Gao wrote:
> >
> >> iptables target SYNPROXY.
> >>
> >> This patch implements an iptables target SYNPROXY, which works in the raw table
> >> of the PREROUTING chain, before conntracking system. Syncookies is used, so no
> >> new state is introduced into the conntracking system. In fact, until the first
> >> connection is established, conntracking system doesn't see any packets. So when
> >> there is a SYN-flood attack, conntracking system won't be busy on finding and
> >> deleting the un-assured ct.
> >
> > My main problem with your target is that by using it, important and useful
> > TCP options are lost: timestamp and SACK. That pushes back TCP by almost
> > twenty years.
> 
> Yea. Only MSS option is  supported. But it is better than being DoSed.
> And you can set a threshold for SYNPROXY with limit match, then there
> isn't any difference if there isn't any SYN-flood attack.

If I (have to) limit SYNPROXY, why shouldn't I better limit the SYN 
packets directly instead?

Best regards,
Jozsef
-
E-mail  : kadlec@...ckhole.kfki.hu, kadlec@...l.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html