From: pablo@netfilter.org
To: netfilter-devel@vger.kernel.org
Cc: davem@davemloft.net, netdev@vger.kernel.org
Subject: [PATCH 24/25] netfilter: nf_conntrack: fix explicit helper attachment and NAT
Date: Tue, 8 May 2012 09:49:53 +0200 [thread overview]
Message-ID: <1336463394-3119-25-git-send-email-pablo@netfilter.org> (raw)
In-Reply-To: <1336463394-3119-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Explicit helper attachment via the CT target is broken with NAT
if non-standard ports are used. This problem was hidden behind
the automatic helper assignment routine. Thus, it becomes more
noticeable now that we can disable the automatic helper assignment
with Eric Leblond's:
9e8ac5a netfilter: nf_ct_helper: allow to disable automatic helper assignment
Basically, nf_conntrack_alter_reply asks for looking up the helper
up if NAT is enabled. Unfortunately, we don't have the conntrack
template at that point anymore.
Since we don't want to rely on the automatic helper assignment,
we can skip the second look-up and stick to the helper that was
attached by iptables. With the CT target, the user is in full
control of helper attachment, thus, the policy is to trust what
the user explicitly configures via iptables (no automatic magic
anymore).
Interestingly, this bug was hidden by the automatic helper look-up
code. But it can be easily trigger if you attach the helper in
a non-standard port, eg.
iptables -I PREROUTING -t raw -p tcp --dport 8888 \
-j CT --helper ftp
And you disabled the automatic helper assignment.
I added the IPS_HELPER_BIT that allows us to differenciate between
a helper that has been explicitly attached and those that have been
automatically assigned. I didn't come up with a better solution
(having backward compatibility in mind).
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/linux/netfilter/nf_conntrack_common.h | 4 ++++
net/netfilter/nf_conntrack_helper.c | 13 ++++++++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/linux/netfilter/nf_conntrack_common.h b/include/linux/netfilter/nf_conntrack_common.h
index 0d3dd66..d146872 100644
--- a/include/linux/netfilter/nf_conntrack_common.h
+++ b/include/linux/netfilter/nf_conntrack_common.h
@@ -83,6 +83,10 @@ enum ip_conntrack_status {
/* Conntrack is a fake untracked entry */
IPS_UNTRACKED_BIT = 12,
IPS_UNTRACKED = (1 << IPS_UNTRACKED_BIT),
+
+ /* Conntrack got a helper explicitly attached via CT target. */
+ IPS_HELPER_BIT = 13,
+ IPS_HELPER = (1 << IPS_HELPER_BIT),
};
/* Connection tracking event types */
diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c
index 55234dd..fee8fd7 100644
--- a/net/netfilter/nf_conntrack_helper.c
+++ b/net/netfilter/nf_conntrack_helper.c
@@ -181,10 +181,21 @@ int __nf_ct_try_assign_helper(struct nf_conn *ct, struct nf_conn *tmpl,
struct net *net = nf_ct_net(ct);
int ret = 0;
+ /* We already got a helper explicitly attached. The function
+ * nf_conntrack_alter_reply - in case NAT is in use - asks for looking
+ * the helper up again. Since now the user is in full control of
+ * making consistent helper configurations, skip this automatic
+ * re-lookup, otherwise we'll lose the helper.
+ */
+ if (test_bit(IPS_HELPER_BIT, &ct->status))
+ return 0;
+
if (tmpl != NULL) {
help = nfct_help(tmpl);
- if (help != NULL)
+ if (help != NULL) {
helper = help->helper;
+ set_bit(IPS_HELPER_BIT, &ct->status);
+ }
}
help = nfct_help(ct);
--
1.7.9.5
next prev parent reply other threads:[~2012-05-08 7:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-08 7:49 [PATCH 00/25] [v2] netfilter updates for net-next (upcoming 3.5) pablo
2012-05-08 7:49 ` [PATCH 01/25] netfilter: nf_ct_ecache: refactor notifier registration pablo
2012-05-08 7:49 ` [PATCH 02/25] netfilter: nf_ct_helper: allow to disable automatic helper assignment pablo
2012-05-08 7:49 ` [PATCH 03/25] netfilter: nf_conntrack: use this_cpu_inc() pablo
2012-05-08 7:49 ` [PATCH 04/25] netfilter: bridge: optionally set indev to vlan pablo
2012-05-08 7:49 ` pablo
2012-05-08 7:49 ` [PATCH 05/25] ipvs: timeout tables do not need GFP_ATOMIC allocation pablo
2012-05-08 7:49 ` [PATCH 06/25] ipvs: LBLC scheduler does not need GFP_ATOMIC allocation on init pablo
2012-05-08 7:49 ` [PATCH 07/25] ipvs: DH scheduler does not need GFP_ATOMIC allocation pablo
2012-05-08 7:49 ` [PATCH 08/25] ipvs: WRR " pablo
2012-05-08 7:49 ` [PATCH 10/25] ipvs: SH " pablo
2012-05-08 7:49 ` [PATCH 11/25] ipvs: use GFP_KERNEL allocation where possible pablo
2012-05-08 7:49 ` [PATCH 12/25] ipvs: ignore IP_VS_CONN_F_NOOUTPUT in backup server pablo
2012-05-08 7:49 ` [PATCH 13/25] ipvs: remove check for IP_VS_CONN_F_SYNC from ip_vs_bind_dest pablo
2012-05-08 7:49 ` [PATCH 14/25] ipvs: fix ip_vs_try_bind_dest to rebind app and transmitter pablo
2012-05-08 7:49 ` [PATCH 15/25] ipvs: always update some of the flags bits in backup pablo
2012-05-08 7:49 ` [PATCH 16/25] ipvs: wakeup master thread pablo
2012-05-08 7:49 ` [PATCH 17/25] ipvs: reduce sync rate with time thresholds pablo
2012-05-08 7:49 ` [PATCH 18/25] ipvs: add support for sync threads pablo
2012-05-08 7:49 ` [PATCH 19/25] ipvs: optimize the use of flags in ip_vs_bind_dest pablo
2012-05-08 7:49 ` [PATCH 20/25] ipvs: ip_vs_ftp: local functions should not be exposed globally pablo
2012-05-08 7:49 ` [PATCH 21/25] ipvs: ip_vs_proto: " pablo
2012-05-08 7:49 ` [PATCH 22/25] net: export sysctl_[r|w]mem_max symbols needed by ip_vs_sync pablo
2012-05-08 7:49 ` [PATCH 23/25] netfilter: nf_ct_expect: partially implement ctnetlink_change_expect pablo
2012-05-08 7:49 ` pablo [this message]
2012-05-08 7:49 ` [PATCH 25/25] netfilter: remove ip_queue support pablo
2012-05-08 16:49 ` [PATCH 00/25] [v2] netfilter updates for net-next (upcoming 3.5) David Miller
2012-05-08 17:10 ` Pablo Neira Ayuso
2012-05-08 17:12 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2012-05-08 0:21 [PATCH 00/25] " pablo
2012-05-08 0:22 ` [PATCH 24/25] netfilter: nf_conntrack: fix explicit helper attachment and NAT pablo
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=1336463394-3119-25-git-send-email-pablo@netfilter.org \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.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).