Skip to contentSkip to conversation

netfilter: Extend SYNPROXY with a --continue option

PATCH In review Jesper Dangaard Brouer 2 participants 3 messages Aug 28, 2013 – Aug 29, 2013

Subsystems (3)
Networking Network drivers netfilter
lore
Share & tools
lore

Jesper Dangaard Brouer

author
#0 lore raw

PATCH 1/1 netfilter: Extend SYNPROXY with a --continue option

Packets reaching SYNPROXY are default dropped, as they are most likely invalid (given the state matching). In other configurations it might be beneficial to let packet not consumed by SYNPROXY (SYN and ACK) to continue being processed by the stack.

Introducing a --continue option/flag for the SYNPROXY target to allow these unmatched packets to continue being processed. This would also help in debugging the module via LOG.

Signed-off-by Jesper Dangaard Brouer <[email protected]>

---
Comment:
This patch depend on the one send earlier, and I also have the userspace iptables part ready, if this patch is received positively

 include/uapi/linux/netfilter/xt_SYNPROXY.h |    1 +
 net/ipv4/netfilter/ipt_SYNPROXY.c          |    9 ++++++++-
 net/ipv6/netfilter/ip6t_SYNPROXY.c         |    9 ++++++++-
 3 files changed, 17 insertions(+), 2 deletions(-)
include/uapi/linux/netfilter/xt_SYNPROXY.h +1 -0
index 2d59fba..6b788bc 100644
@@ -6,6 +6,7 @@
 #define XT_SYNPROXY_OPT_SACK_PERM	0x04
 #define XT_SYNPROXY_OPT_TIMESTAMP	0x08
 #define XT_SYNPROXY_OPT_ECN		0x10
+#define XT_SYNPROXY_OPT_CONTINUE	0x20
 
 struct xt_synproxy_info {
 	__u8	options;
net/ipv4/netfilter/ipt_SYNPROXY.c +8 -1
index 90e489e..3a09759 100644
@@ -285,9 +285,16 @@ synproxy_tg4(struct sk_buff *skb, const struct xt_action_param *par)
 					  XT_SYNPROXY_OPT_ECN);
 
 		synproxy_send_client_synack(skb, th, &opts);
-	} else if (th->ack && !(th->fin || th->rst || th->syn))
+		return NF_DROP;
+
+	} else if (th->ack && !(th->fin || th->rst || th->syn)) {
 		/* ACK from client */
 		synproxy_recv_client_ack(snet, skb, th, &opts, ntohl(th->seq));
+		return NF_DROP;
+	}
+
+	if (info->options & XT_SYNPROXY_OPT_CONTINUE)
+		return XT_CONTINUE;
 
 	return NF_DROP;
 }
net/ipv6/netfilter/ip6t_SYNPROXY.c +8 -1
index a5af0bf..02f41fa 100644
@@ -300,9 +300,16 @@ synproxy_tg6(struct sk_buff *skb, const struct xt_action_param *par)
 					  XT_SYNPROXY_OPT_ECN);
 
 		synproxy_send_client_synack(skb, th, &opts);
-	} else if (th->ack && !(th->fin || th->rst || th->syn))
+		return NF_DROP;
+
+	} else if (th->ack && !(th->fin || th->rst || th->syn)) {
 		/* ACK from client */
 		synproxy_recv_client_ack(snet, skb, th, &opts, ntohl(th->seq));
+		return NF_DROP;
+	}
+
+	if (info->options & XT_SYNPROXY_OPT_CONTINUE)
+		return XT_CONTINUE;
 
 	return NF_DROP;
 }
#1 lore raw
Quoted 8 lines · Jesper Dangaard Brouer

Packets reaching SYNPROXY are default dropped, as they are most likely invalid (given the state matching). In other configurations it might be beneficial to let packet not consumed by SYNPROXY (SYN and ACK) to continue being processed by the stack.

Introducing a --continue option/flag for the SYNPROXY target to allow these unmatched packets to continue being processed. This would also help in debugging the module via LOG.

I don't think we should add an option for this. Just DROP packets consumed by the target and have the other ones continue.

author Nacked-by NAK
#2 lore raw
Quoted 6 lines · On Wed, 28 Aug 2013 18:00:42 +0200 Patrick McHardy <[email protected]> wrote:
Quoted 5 lines · Jesper Dangaard Brouer

Packets reaching SYNPROXY are default dropped, as they are most likely invalid (given the state matching). In other configurations it might be beneficial to let packet not consumed by SYNPROXY (SYN and ACK) to continue being processed by the stack.

Quoted 6 lines
Quoted 3 lines

Introducing a --continue option/flag for the SYNPROXY target to allow these unmatched packets to continue being processed. This would also help in debugging the module via LOG.

I don't think we should add an option for this. Just DROP packets consumed by the target and have the other ones continue.

I agree. I'll send a new patch, defaulting to XT_CONTINUE.

Self:

Nacked-by Jesper Dangaard Brouer <[email protected]>
Signature · 5 lines
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer