From: Patrick McHardy <kaber@trash.net>
To: pablo@netfilter.org
Cc: netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
mph@one.com, jesper.brouer@gmail.com, as@one.com
Subject: [PATCH 0/5] netfilter: SYNPROXY target v3
Date: Tue, 27 Aug 2013 08:50:11 +0200 [thread overview]
Message-ID: <1377586216-7024-1-git-send-email-kaber@trash.net> (raw)
The following patches contain the latest version of the SYNPROXY target.
The SYNPROXY operates by marking the initial SYN from the client as UNTRACKED
and directing it to the SYNPROXY target. The target responds with a SYN/ACK
containing a cookie and encodes options such as window scaling factor, SACK
perm etc. into the timestamp, if timestamps are used (similar to TCP). The
window size is set to zero. The response is also sent as untracked packet.
When the final ACK is received the cookie is validated, the original options
extracted and a SYN to the original destination is generated. The SYN to the
original destination uses the avertised window from the final ACK and the
options from the initial SYN packet. The SYN is not sent as untracked, so
from a connection tracking POV it will look like the original packet from
the client and instantiate a new connection. When the server responds with
a SYN/ACK a final ACK for the server is generated and a window update with
the window size announced by the server is sent to the client. At this
point the connection is handed of to conntrack and the only thing the
target is still involved in is timestamp translation through the registerd
hooks.
Since the SYN proxy can't know the options the server supports, they have
to be specified as parameters to the SYNPROXY target. The assumption is that
these options are constant as long as you don't change settings on the
server. Since the SYN proxy can't know the initial sequence number and
timestamp values the server will use, both have to be translated in the
direction server->client. Sequence number translation is done using the
standard sequence number translation mechanisms originally only used for
NAT, timestamps are translated in a hook registered by the SYNPROXY target.
Usage is as follows:
iptables -t raw -A PREROUTING -i eth0 -p tcp --dport 80 --syn -j NOTRACK
iptables -A INPUT -i eth0 -p tcp --dport 80 -m state UNTRACKED,INVALID \
-j SYNPROXY --sack-perm --timestamp --mss 1480 --wscale 7 --ecn
echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
The second rule catches untracked packets and directs them to the target.
The purpose of disabling loose tracking is to have the final ACK from the
client not be picked up by conntrack, so it won't create a new conntrack
entry and will be marked INVALID and also get directed to the target.
We did some extensive testing on Monday and it verified all retransmit
bugs have been fixed. With 1.4Mpps SYNs the load on a 16 way Xeon L6530
2.13 Ghz machine was between 3% and 6%.
There's one single change since v2:
Reopened TCP connections while the conntrack is in CLOSE state weren't
handled properly. The sequence number and timestamp adjustments need
to be reset in this case. Another counter has been introduced for this.
>From my POV, these patches are ready for merging now.
Please apply.
next reply other threads:[~2013-08-27 6:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-27 6:50 Patrick McHardy [this message]
2013-08-27 6:50 ` [PATCH 1/5] netfilter: nf_conntrack: make sequence number adjustments usuable without NAT Patrick McHardy
2013-08-27 6:50 ` [PATCH 2/5] net: syncookies: export cookie_v4_init_sequence/cookie_v4_check Patrick McHardy
2013-08-27 6:50 ` [PATCH 3/5] netfilter: add SYNPROXY core/target Patrick McHardy
2013-08-27 6:50 ` [PATCH 4/5] net: syncookies: export cookie_v6_init_sequence/cookie_v6_check Patrick McHardy
2013-08-27 6:50 ` [PATCH 5/5] netfilter: add IPv6 SYNPROXY target Patrick McHardy
2013-08-27 8:35 ` [PATCH 0/5] netfilter: SYNPROXY target v3 Jesper Dangaard Brouer
2013-08-27 9:05 ` Patrick McHardy
2013-08-27 12:08 ` Jesper Dangaard Brouer
2013-08-27 12:05 ` Martin Topholm
2013-08-27 22:49 ` Pablo Neira Ayuso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1377586216-7024-1-git-send-email-kaber@trash.net \
--to=kaber@trash.net \
--cc=as@one.com \
--cc=jesper.brouer@gmail.com \
--cc=mph@one.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).