[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimjY_0yKfMtAUxI7He-QH5R5AdDCR3V8eKSgbGq@mail.gmail.com>
Date: Thu, 20 May 2010 22:21:58 +0800
From: Changli Gao <xiaosuo@...il.com>
To: Patrick McHardy <kaber@...sh.net>
Cc: Netfilter Developer Mailing List
<netfilter-devel@...r.kernel.org>,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: RFC: netfilter: synproxy iptables target
On Thu, May 20, 2010 at 10:11 PM, Patrick McHardy <kaber@...sh.net> wrote:
> Changli Gao wrote:
>> I have implemented a simple SYNPROXY iptables target. It is much like
>> the SYNPROXY implementation in pf of OpenBSD, but won't have state
>> until the first connection is established with the help of syncookies.
>> The code is hosted at github:
>>
>> http://github.com/xiaosuo/xiaosuo/tree/master/synproxy/
>>
>> Currently, it can work with firewall and local socket.
>>
>> It is in the very early stage, and ugly. And I will add --timeout
>> parameter to this target as TCP_DFER_ACCEPT, so I can do NAT basing on
>> the request data.
>>
>> i.e.
>>
>> iptables -t nat -A OUTPUT -p tcp -m synproxy --http-url "*.jpg" -j
>> DNAT --to-destination $image_http_server:80
>>
>> And is there any chance to merge it into mainline?
>
> If you can state a good use case, sure. I don't know much about the
> PF synproxy myself.
>
pure synproxy can be used on firewall to protect the internal servers,
which don't support neither syncookies and synproxy, from the attack
of SYN-flood.
synproxy with defered connection relay acts as a layer 7 proxy, but
works in kernel space totally, unlike tcp splice tech., which needs
the applications in user space parse the requests, and establish the
connections.
--
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
Powered by blists - more mailing lists