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: <AANLkTilbZ4PE7c6pep4bYvAx7ydx78qb4tKJi0vCjD52@mail.gmail.com>
Date:	Tue, 25 May 2010 22:42:10 +0800
From:	Changli Gao <xiaosuo@...il.com>
To:	Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
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

On Tue, May 25, 2010 at 8:17 PM, Jozsef Kadlecsik
<kadlec@...ckhole.kfki.hu> wrote:
> Hi,
>
> 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.

>
> Here you reason for the target that it protects conntrack itself, but in
> the Kconfig text you write that it protects the servers behind the
> firewall. Both can be true, but if the real goal is to defend the servers
> then your target could simply send a faked ACK to complete the three way
> handshake and that way TCP would not be crippled (conntrack timeout
> should still be adjusted).
>

Yes, both can be true. You descried above is called SYNDefender by
Checkpoint, and it doesn't work as well as SYNPROXY.

http://www.usenix.org/events/sec01/invitedtalks/oliver.pdf

-- 
Regards，
Changli Gao(xiaosuo@...il.com)
--
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