[PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Richard Weinberger]

Hi,

as a firewall admin I would like to see which rules allow
the connections through my firewall.
A relationship between conntrack and firewall rules would be nice.
The next five patches bring this feature to the Linux Netfilter.

First a small example.
Consider this iptables rules:
-A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id 1
-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE --rule-id 2
-A INPUT -p tcp --dport 22 -m state --state NEW -j APPROVE --rule-id 3
-A INPUT -p icmp -m state --state NEW -j APPROVE --rule-id 4

The APPROVE target is the same as ACCEPT but it stores also a rule id into 
the connection tracking entry.

"conntrack -L" shows us this two entries:
tcp      6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2 sport=51444 \
	dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444 [ASSURED] \
	mark=0 established=1 related=0 new=3 reply=2 use=1

icmp     1 28 src=192.168.1.2 dst=149.20.20.133 type=8 code=0 id=63239 \
	src=149.20.20.133 dst=192.168.1.2 type=0 code=0 id=63239 mark=0 \
	established=2 related=0 new=2 reply=1 use=1

1. We observe a SSH connection from 192.168.1.1 to 192.168.1.2,
it was allowed by rule 1, 3 and 2. (0 indicates that no rule was involved)
2. An ICMP ping from 192.168.1.2 to 149.20.20.133 which was allowed
by the rules 1 and 2.

The ruleid conntrack extension adds four u_int16_t values.
Thus we can have up to 2^16 rules, I think this is enough
and is not much overhead.
Alternatively we a pointer to a string could also be useful.
Maybe in conjunction with xt_comment...

What do you think?
Any feedback is welcome!

//richard

--
Richard Weinberger (3):
  netfilter: add ruleid extension
  netfilter: add APPROVE target
  netfilter: implement ctnetlink_dump_ruleid()

 include/linux/netfilter/nfnetlink_conntrack.h |    4 +
 include/linux/netfilter/xt_APPROVE.h          |    8 +++
 include/net/netfilter/nf_conntrack_extend.h   |    2 +
 include/net/netfilter/nf_conntrack_ruleid.h   |   25 +++++++
 net/netfilter/Kconfig                         |   12 ++++
 net/netfilter/Makefile                        |    3 +-
 net/netfilter/nf_conntrack_core.c             |    6 ++
 net/netfilter/nf_conntrack_netlink.c          |   23 +++++++-
 net/netfilter/nf_conntrack_ruleid.c           |   44 +++++++++++++
 net/netfilter/xt_APPROVE.c                    |   85 +++++++++++++++++++++++++
 10 files changed, 210 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/netfilter/xt_APPROVE.h
 create mode 100644 include/net/netfilter/nf_conntrack_ruleid.h
 create mode 100644 net/netfilter/nf_conntrack_ruleid.c
 create mode 100644 net/netfilter/xt_APPROVE.c

[PATCH 1/3] netfilter: add ruleid extension

[Richard Weinberger]

The ruleid extension makes it possible to store rule ids into
connection tracking entries.
Each connection tracking entry can up to four rule ids.
For ESTABLISHED, RELATED, NEW and REPLY.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 include/net/netfilter/nf_conntrack_extend.h |    2 +
 include/net/netfilter/nf_conntrack_ruleid.h |   25 +++++++++++++++
 net/netfilter/Makefile                      |    2 +-
 net/netfilter/nf_conntrack_core.c           |    6 ++++
 net/netfilter/nf_conntrack_ruleid.c         |   44 +++++++++++++++++++++++++++
 5 files changed, 78 insertions(+), 1 deletions(-)
 create mode 100644 include/net/netfilter/nf_conntrack_ruleid.h
 create mode 100644 net/netfilter/nf_conntrack_ruleid.c

diff --git a/include/net/netfilter/nf_conntrack_extend.h b/include/net/netfilter/nf_conntrack_extend.h
index 0772d29..12053c2 100644
--- a/include/net/netfilter/nf_conntrack_extend.h
+++ b/include/net/netfilter/nf_conntrack_extend.h
@@ -11,6 +11,7 @@ enum nf_ct_ext_id {
 	NF_CT_EXT_ACCT,
 	NF_CT_EXT_ECACHE,
 	NF_CT_EXT_ZONE,
+	NF_CT_EXT_RULEID,
 	NF_CT_EXT_NUM,
 };
 
@@ -19,6 +20,7 @@ enum nf_ct_ext_id {
 #define NF_CT_EXT_ACCT_TYPE struct nf_conn_counter
 #define NF_CT_EXT_ECACHE_TYPE struct nf_conntrack_ecache
 #define NF_CT_EXT_ZONE_TYPE struct nf_conntrack_zone
+#define NF_CT_EXT_RULEID_TYPE struct nf_conn_ruleid
 
 /* Extensions: optional stuff which isn't permanently in struct. */
 struct nf_ct_ext {
diff --git a/include/net/netfilter/nf_conntrack_ruleid.h b/include/net/netfilter/nf_conntrack_ruleid.h
new file mode 100644
index 0000000..98f7d0a
--- /dev/null
+++ b/include/net/netfilter/nf_conntrack_ruleid.h
@@ -0,0 +1,25 @@
+/*
+ * (C) 2011 Richard Weinberger <richard@nod.at>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _NF_CONNTRACK_RULEID_H
+#define _NF_CONNTRACK_RULEID_H
+
+#include <net/net_namespace.h>
+#include <linux/netfilter/nf_conntrack_common.h>
+#include <linux/netfilter/nf_conntrack_tuple_common.h>
+#include <net/netfilter/nf_conntrack.h>
+#include <net/netfilter/nf_conntrack_extend.h>
+
+struct nf_conn_ruleid {
+	u_int16_t rule[IP_CT_NUMBER - 1];
+};
+
+extern int nf_conntrack_ruleid_init(struct net *net);
+extern void nf_conntrack_ruleid_fini(struct net *net);
+
+#endif /* _NF_CONNTRACK_RULEID_H */
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 441050f..f5bff47 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -1,6 +1,6 @@
 netfilter-objs := core.o nf_log.o nf_queue.o nf_sockopt.o
 
-nf_conntrack-y	:= nf_conntrack_core.o nf_conntrack_standalone.o nf_conntrack_expect.o nf_conntrack_helper.o nf_conntrack_proto.o nf_conntrack_l3proto_generic.o nf_conntrack_proto_generic.o nf_conntrack_proto_tcp.o nf_conntrack_proto_udp.o nf_conntrack_extend.o nf_conntrack_acct.o
+nf_conntrack-y	:= nf_conntrack_core.o nf_conntrack_standalone.o nf_conntrack_expect.o nf_conntrack_helper.o nf_conntrack_proto.o nf_conntrack_l3proto_generic.o nf_conntrack_proto_generic.o nf_conntrack_proto_tcp.o nf_conntrack_proto_udp.o nf_conntrack_extend.o nf_conntrack_acct.o nf_conntrack_ruleid.o
 nf_conntrack-$(CONFIG_NF_CONNTRACK_EVENTS) += nf_conntrack_ecache.o
 
 obj-$(CONFIG_NETFILTER) = netfilter.o
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 27a5ea6..818126a 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -42,6 +42,7 @@
 #include <net/netfilter/nf_conntrack_extend.h>
 #include <net/netfilter/nf_conntrack_acct.h>
 #include <net/netfilter/nf_conntrack_ecache.h>
+#include <net/netfilter/nf_conntrack_ruleid.h>
 #include <net/netfilter/nf_conntrack_zones.h>
 #include <net/netfilter/nf_nat.h>
 #include <net/netfilter/nf_nat_core.h>
@@ -1502,9 +1503,14 @@ static int nf_conntrack_init_net(struct net *net)
 	ret = nf_conntrack_ecache_init(net);
 	if (ret < 0)
 		goto err_ecache;
+	ret = nf_conntrack_ruleid_init(net);
+	if (ret < 0)
+		goto err_ruleid;
 
 	return 0;
 
+err_ruleid:
+	nf_conntrack_ecache_fini(net);
 err_ecache:
 	nf_conntrack_acct_fini(net);
 err_acct:
diff --git a/net/netfilter/nf_conntrack_ruleid.c b/net/netfilter/nf_conntrack_ruleid.c
new file mode 100644
index 0000000..887f4cd
--- /dev/null
+++ b/net/netfilter/nf_conntrack_ruleid.c
@@ -0,0 +1,44 @@
+/*
+ * (C) 2011 Richard Weinberger <richard@nod.at>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/netfilter.h>
+#include <linux/kernel.h>
+
+#include <net/netfilter/nf_conntrack.h>
+#include <net/netfilter/nf_conntrack_extend.h>
+#include <net/netfilter/nf_conntrack_ruleid.h>
+
+static struct nf_ct_ext_type ruleid_extend __read_mostly = {
+	.len	= sizeof(struct nf_conn_ruleid),
+	.align	= __alignof__(struct nf_conn_ruleid),
+	.id	= NF_CT_EXT_RULEID,
+};
+
+int nf_conntrack_ruleid_init(struct net *net)
+{
+	int ret = 0;
+
+	if (net_eq(net, &init_net)) {
+		ret = nf_ct_extend_register(&ruleid_extend);
+		if (ret < 0) {
+			printk(KERN_ERR "nf_conntrack_ruleid: Unable to register extension\n");
+			goto out;
+		}
+	}
+
+	return 0;
+
+out:
+	return ret;
+}
+
+void nf_conntrack_ruleid_fini(struct net *net)
+{
+	if (net_eq(net, &init_net))
+		nf_ct_extend_unregister(&ruleid_extend);
+}
-- 
1.6.6.1

[PATCH 2/3] netfilter: add APPROVE target

[Richard Weinberger]

This new target is related to the ruleid extension.
It accepts a packet and stores it's rule id into
the connection tracking entry.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 include/linux/netfilter/xt_APPROVE.h |    8 +++
 net/netfilter/Kconfig                |   12 +++++
 net/netfilter/Makefile               |    1 +
 net/netfilter/xt_APPROVE.c           |   85 ++++++++++++++++++++++++++++++++++
 4 files changed, 106 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/netfilter/xt_APPROVE.h
 create mode 100644 net/netfilter/xt_APPROVE.c

diff --git a/include/linux/netfilter/xt_APPROVE.h b/include/linux/netfilter/xt_APPROVE.h
new file mode 100644
index 0000000..c62c6bc
--- /dev/null
+++ b/include/linux/netfilter/xt_APPROVE.h
@@ -0,0 +1,8 @@
+#ifndef _XT_APPROVE_H
+#define _XT_APPROVE_H
+
+struct nf_approve_info {
+	u_int16_t ruleid;
+};
+
+#endif /* _XT_APPROVE_H */
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 1534f2b..34cd76c 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -546,6 +546,18 @@ config NETFILTER_XT_TARGET_TRACE
 	  If you want to compile it as a module, say M here and read
 	  <file:Documentation/kbuild/modules.txt>.  If unsure, say `N'.
 
+config NETFILTER_XT_TARGET_APPROVE
+	tristate  '"APPROVE" target support'
+	depends on NF_CONNTRACK
+	depends on NETFILTER_ADVANCED
+	help
+	  The APPROVE target allows you to add a rule ID to the
+	  connection tracking entry. So you can see which rules
+	  allowed a connection.
+
+	  If you want to compile it as a module, say M here and read
+	  <file:Documentation/kbuild/modules.txt>.  If unsure, say `N'.
+
 config NETFILTER_XT_TARGET_SECMARK
 	tristate '"SECMARK" target support'
 	depends on NETWORK_SECMARK
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index f5bff47..db8a342 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_TCPMSS) += xt_TCPMSS.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP) += xt_TCPOPTSTRIP.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_TEE) += xt_TEE.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_TRACE) += xt_TRACE.o
+obj-$(CONFIG_NETFILTER_XT_TARGET_APPROVE) += xt_APPROVE.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_IDLETIMER) += xt_IDLETIMER.o
 
 # matches
diff --git a/net/netfilter/xt_APPROVE.c b/net/netfilter/xt_APPROVE.c
new file mode 100644
index 0000000..345465b
--- /dev/null
+++ b/net/netfilter/xt_APPROVE.c
@@ -0,0 +1,85 @@
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/spinlock.h>
+
+#include <linux/netfilter.h>
+#include <linux/netfilter/x_tables.h>
+#include <linux/netfilter/nf_conntrack_common.h>
+#include <linux/netfilter/xt_APPROVE.h>
+
+#include <net/netfilter/nf_conntrack.h>
+#include <net/netfilter/nf_conntrack_ruleid.h>
+
+MODULE_DESCRIPTION("Xtables: Accept a packet and mark connection with an ID");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("ipt_APPROVE");
+MODULE_ALIAS("ip6t_APPROVE");
+
+static unsigned int
+approve_tg(struct sk_buff *skb, const struct xt_action_param *par)
+{
+	enum ip_conntrack_info cti;
+	struct nf_conn *nfc;
+	struct nf_conn_ruleid *nfcr;
+	const struct nf_approve_info *ri = par->targinfo;
+
+	nfc = nf_ct_get(skb, &cti);
+	if (!nfc)
+		goto out;
+
+	if (nf_ct_is_untracked(nfc))
+		goto out;
+
+	spin_lock_bh(&nfc->lock);
+
+	nfcr = nf_ct_ext_find(nfc, NF_CT_EXT_RULEID);
+
+	if (!nfcr) {
+		nfcr = nf_ct_ext_add(nfc, NF_CT_EXT_RULEID, GFP_ATOMIC);
+
+		/* we're out of memory */
+		if (!nfcr)
+			goto out;
+	}
+
+	nfcr->rule[cti] = ri->ruleid;
+
+	spin_unlock_bh(&nfc->lock);
+
+out:
+	return NF_ACCEPT;
+}
+
+static int approve_tg_check(const struct xt_tgchk_param *par)
+{
+	const struct nf_approve_info *ri = par->targinfo;
+
+	if (ri->ruleid < 1)
+		return -EINVAL;
+
+	return 0;
+}
+
+static struct xt_target approve_tg_reg __read_mostly = {
+	.name       = "APPROVE",
+	.revision   = 0,
+	.family     = NFPROTO_UNSPEC,
+	.table			= "filter",
+	.target     = approve_tg,
+	.targetsize	= sizeof(struct nf_approve_info),
+	.checkentry	= approve_tg_check,
+	.me         = THIS_MODULE,
+};
+
+static int __init approve_tg_init(void)
+{
+	return xt_register_target(&approve_tg_reg);
+}
+
+static void __exit approve_tg_exit(void)
+{
+	xt_unregister_target(&approve_tg_reg);
+}
+
+module_init(approve_tg_init);
+module_exit(approve_tg_exit);
-- 
1.6.6.1

[PATCH 3/3] netfilter: implement ctnetlink_dump_ruleid()

[Richard Weinberger]

ctnetlink_dump_ruleid() dumps the rule ids within a
connection tracking entry via netlink.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 include/linux/netfilter/nfnetlink_conntrack.h |    4 ++++
 net/netfilter/nf_conntrack_netlink.c          |   23 ++++++++++++++++++++++-
 2 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/include/linux/netfilter/nfnetlink_conntrack.h b/include/linux/netfilter/nfnetlink_conntrack.h
index 19711e3..8f48b99 100644
--- a/include/linux/netfilter/nfnetlink_conntrack.h
+++ b/include/linux/netfilter/nfnetlink_conntrack.h
@@ -42,6 +42,10 @@ enum ctattr_type {
 	CTA_SECMARK,		/* obsolete */
 	CTA_ZONE,
 	CTA_SECCTX,
+	CTA_RULEID_ESTABLISHED,
+	CTA_RULEID_RELATED,
+	CTA_RULEID_NEW,
+	CTA_RULEID_REPLY,
 	__CTA_MAX
 };
 #define CTA_MAX (__CTA_MAX - 1)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index b729ace..4bded09 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -42,6 +42,7 @@
 #include <net/netfilter/nf_conntrack_tuple.h>
 #include <net/netfilter/nf_conntrack_acct.h>
 #include <net/netfilter/nf_conntrack_zones.h>
+#include <net/netfilter/nf_conntrack_ruleid.h>
 #ifdef CONFIG_NF_NAT_NEEDED
 #include <net/netfilter/nf_nat_core.h>
 #include <net/netfilter/nf_nat_protocol.h>
@@ -132,6 +133,25 @@ nla_put_failure:
 }
 
 static inline int
+ctnetlink_dump_ruleid(struct sk_buff *skb, const struct nf_conn *ct)
+{
+	struct nf_conn_ruleid *nfcr = nf_ct_ext_find(ct, NF_CT_EXT_RULEID);
+
+	if (!nfcr)
+		return 0;
+
+	NLA_PUT_BE16(skb, CTA_RULEID_ESTABLISHED, htons(nfcr->rule[IP_CT_ESTABLISHED]));
+	NLA_PUT_BE16(skb, CTA_RULEID_RELATED, htons(nfcr->rule[IP_CT_RELATED]));
+	NLA_PUT_BE16(skb, CTA_RULEID_NEW, htons(nfcr->rule[IP_CT_NEW]));
+	NLA_PUT_BE16(skb, CTA_RULEID_REPLY, htons(nfcr->rule[IP_CT_IS_REPLY]));
+
+	return 0;
+
+nla_put_failure:
+	return -1;
+}
+
+static inline int
 ctnetlink_dump_timeout(struct sk_buff *skb, const struct nf_conn *ct)
 {
 	long timeout = (ct->timeout.expires - jiffies) / HZ;
@@ -411,7 +431,8 @@ ctnetlink_fill_info(struct sk_buff *skb, u32 pid, u32 seq,
 	    ctnetlink_dump_id(skb, ct) < 0 ||
 	    ctnetlink_dump_use(skb, ct) < 0 ||
 	    ctnetlink_dump_master(skb, ct) < 0 ||
-	    ctnetlink_dump_nat_seq_adj(skb, ct) < 0)
+	    ctnetlink_dump_nat_seq_adj(skb, ct) < 0 ||
+	    ctnetlink_dump_ruleid(skb, ct) < 0)
 		goto nla_put_failure;
 
 	nlmsg_end(skb, nlh);
-- 
1.6.6.1

[PATCH] iptables: Add APPROVE target

[Richard Weinberger]

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 extensions/libxt_APPROVE.c           |   83 ++++++++++++++++++++++++++++++++++
 extensions/libxt_APPROVE.man         |    1 +
 include/linux/netfilter/xt_APPROVE.h |    8 +++
 3 files changed, 92 insertions(+), 0 deletions(-)
 create mode 100644 extensions/libxt_APPROVE.c
 create mode 100644 extensions/libxt_APPROVE.man
 create mode 100644 include/linux/netfilter/xt_APPROVE.h

diff --git a/extensions/libxt_APPROVE.c b/extensions/libxt_APPROVE.c
new file mode 100644
index 0000000..4142bfa
--- /dev/null
+++ b/extensions/libxt_APPROVE.c
@@ -0,0 +1,83 @@
+#include <stdbool.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <getopt.h>
+#include <stddef.h>
+
+#include <xtables.h>
+
+#include <linux/netfilter/x_tables.h>
+#include <linux/netfilter/xt_APPROVE.h>
+
+static const struct option approve_opts[] = {
+	{.name = "rule-id", .has_arg = true, .val = 'i'},
+	XT_GETOPT_TABLEEND
+};
+
+static void approve_help(void)
+{
+	printf("APPROVE target options:\n"
+		"--rule-id id		assign numberic id to the rule.\n");
+}
+
+static int approve_parse(int c, char **argv, int invert, unsigned int *flags,
+	const void *entry, struct xt_entry_target **target)
+{
+	struct nf_approve_info *ridi = (void *)(*target)->data;
+
+	if(c == 'i') {
+		xtables_param_act(XTF_NO_INVERT, "APPROVE", "--rule-id", invert);
+		ridi->ruleid = strtoul(optarg, NULL, 0);
+
+		if(ridi->ruleid < 1)
+			xtables_error(PARAMETER_PROBLEM,
+				"--rule-id must be greater than 0");
+
+		*flags = 1;
+
+		return true;
+	}
+
+	return false;
+}
+
+static void approve_print(const void *ip, const struct xt_entry_target *target,
+	int numeric)
+{
+	struct nf_approve_info *ridi = (void *)target->data;
+
+	printf("--rule-id %i\n", ridi->ruleid);
+}
+
+static void approve_save(const void *ip, const struct xt_entry_target *target)
+{
+	struct nf_approve_info *ridi = (void *)target->data;
+
+	printf("--rule-id %i\n", ridi->ruleid);
+}
+
+static void approve_final_check(unsigned int flags)
+{
+	if(flags != 1)
+		xtables_error(PARAMETER_PROBLEM,
+			"--rule-id must be specified");
+}
+
+static struct xtables_target approve_target = {
+	.family		= NFPROTO_UNSPEC,
+	.name		= "APPROVE",
+	.version	= XTABLES_VERSION,
+	.size		= XT_ALIGN(sizeof(struct nf_approve_info)),
+	.userspacesize	= XT_ALIGN(sizeof(struct nf_approve_info)),
+	.help		= approve_help,
+	.parse		= approve_parse,
+	.final_check	= approve_final_check,
+	.extra_opts	= approve_opts,
+	.print		= approve_print,
+	.save		= approve_save
+};
+
+void _init(void)
+{
+	xtables_register_target(&approve_target);
+}
diff --git a/extensions/libxt_APPROVE.man b/extensions/libxt_APPROVE.man
new file mode 100644
index 0000000..ce08911
--- /dev/null
+++ b/extensions/libxt_APPROVE.man
@@ -0,0 +1 @@
+Richard was too lazy to write a manpage...
diff --git a/include/linux/netfilter/xt_APPROVE.h b/include/linux/netfilter/xt_APPROVE.h
new file mode 100644
index 0000000..c62c6bc
--- /dev/null
+++ b/include/linux/netfilter/xt_APPROVE.h
@@ -0,0 +1,8 @@
+#ifndef _XT_APPROVE_H
+#define _XT_APPROVE_H
+
+struct nf_approve_info {
+	u_int16_t ruleid;
+};
+
+#endif /* _XT_APPROVE_H */
-- 
1.6.6.1

[PATCH] conntrack: Implement ruleid support

[Richard Weinberger]

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 include/internal/object.h                          |    1 +
 .../libnetfilter_conntrack.h                       |    1 +
 .../linux_nfnetlink_conntrack.h                    |    4 +++
 src/conntrack/build.c                              |   13 ++++++++++++
 src/conntrack/compare.c                            |   13 ++++++++++++
 src/conntrack/copy.c                               |   10 +++++++++
 src/conntrack/getter.c                             |    6 +++++
 src/conntrack/parse.c                              |   21 ++++++++++++++++++++
 src/conntrack/setter.c                             |   10 +++++++++
 src/conntrack/snprintf_default.c                   |   13 ++++++++++++
 src/conntrack/snprintf_xml.c                       |   11 ++++++++++
 11 files changed, 103 insertions(+), 0 deletions(-)

diff --git a/include/internal/object.h b/include/internal/object.h
index 76a0566..f955e53 100644
--- a/include/internal/object.h
+++ b/include/internal/object.h
@@ -160,6 +160,7 @@ struct nf_conntrack {
 	u_int32_t	use;
 	u_int32_t	id;
 	u_int16_t	zone;
+	u_int16_t	ruleid[4];
 
 /* xt_helper uses a length size of 30 bytes, however, no helper name in
  * the tree has exceeded 16 bytes length. Since 2.6.29, the maximum
diff --git a/include/libnetfilter_conntrack/libnetfilter_conntrack.h b/include/libnetfilter_conntrack/libnetfilter_conntrack.h
index aaf1638..c72c333 100644
--- a/include/libnetfilter_conntrack/libnetfilter_conntrack.h
+++ b/include/libnetfilter_conntrack/libnetfilter_conntrack.h
@@ -128,6 +128,7 @@ enum nf_conntrack_attr {
 	ATTR_TCP_WSCALE_REPL = 60,		/* u8 bits */
 	ATTR_ZONE,				/* u16 bits */
 	ATTR_SECCTX,				/* string */
+	ATTR_RULEID,				/* u16 bits * 4 */
 	ATTR_MAX
 };
 
diff --git a/include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h b/include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h
index 3b0c009..aef20ac 100644
--- a/include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h
+++ b/include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h
@@ -46,6 +46,10 @@ enum ctattr_type {
 	CTA_SECMARK,		/* obsolete */
 	CTA_ZONE,
 	CTA_SECCTX,
+	CTA_RULEID_ESTABLISHED,
+	CTA_RULEID_RELATED,
+	CTA_RULEID_NEW,
+	CTA_RULEID_REPLY,
 	__CTA_MAX
 };
 #define CTA_MAX (__CTA_MAX - 1)
diff --git a/src/conntrack/build.c b/src/conntrack/build.c
index f80089a..54a97d7 100644
--- a/src/conntrack/build.c
+++ b/src/conntrack/build.c
@@ -367,6 +367,16 @@ static void __build_mark(struct nfnlhdr *req,
 	nfnl_addattr32(&req->nlh, size, CTA_MARK, htonl(ct->mark));
 }
 
+static void __build_ruleid(struct nfnlhdr *req,
+			 size_t size,
+			 const struct nf_conntrack *ct)
+{
+	nfnl_addattr16(&req->nlh, size, CTA_RULEID_ESTABLISHED, htons(ct->ruleid[0]));
+	nfnl_addattr16(&req->nlh, size, CTA_RULEID_RELATED, htons(ct->ruleid[1]));
+	nfnl_addattr16(&req->nlh, size, CTA_RULEID_NEW, htons(ct->ruleid[2]));
+	nfnl_addattr16(&req->nlh, size, CTA_RULEID_REPLY, htons(ct->ruleid[3]));
+}
+
 static void __build_secmark(struct nfnlhdr *req,
 			    size_t size,
 			    const struct nf_conntrack *ct)
@@ -469,6 +479,9 @@ int __build_conntrack(struct nfnl_subsys_handle *ssh,
 	if (test_bit(ATTR_MARK, ct->set))
 		__build_mark(req, size, ct);
 
+	if (test_bit(ATTR_RULEID, ct->set))
+		__build_ruleid(req, size, ct);
+
 	if (test_bit(ATTR_SECMARK, ct->set))
 		__build_secmark(req, size, ct);
 
diff --git a/src/conntrack/compare.c b/src/conntrack/compare.c
index 1cdad1c..ef79011 100644
--- a/src/conntrack/compare.c
+++ b/src/conntrack/compare.c
@@ -300,6 +300,17 @@ cmp_mark(const struct nf_conntrack *ct1,
 }
 
 static int 
+cmp_ruleid(const struct nf_conntrack *ct1,
+	 const struct nf_conntrack *ct2,
+	 unsigned int flags)
+{
+	return (ct1->ruleid[0] == ct2->ruleid[0] &&
+		ct1->ruleid[1] == ct2->ruleid[1] &&
+		ct1->ruleid[2] == ct2->ruleid[2] &&
+		ct1->ruleid[3] == ct2->ruleid[3]);
+}
+
+static int 
 cmp_timeout(const struct nf_conntrack *ct1,
 	    const struct nf_conntrack *ct2,
 	    unsigned int flags)
@@ -398,6 +409,8 @@ static int cmp_meta(const struct nf_conntrack *ct1,
 		return 0;
 	if (!__cmp(ATTR_SECCTX, ct1, ct2, flags, cmp_secctx))
 		return 0;
+	if (!__cmp(ATTR_RULEID, ct1, ct2, flags, cmp_ruleid))
+		return 0;
 
 	return 1;
 }
diff --git a/src/conntrack/copy.c b/src/conntrack/copy.c
index 9148640..ced0427 100644
--- a/src/conntrack/copy.c
+++ b/src/conntrack/copy.c
@@ -312,6 +312,15 @@ static void copy_attr_mark(struct nf_conntrack *dest,
 	dest->mark = orig->mark;
 }
 
+static void copy_attr_ruleid(struct nf_conntrack *dest,
+			   const struct nf_conntrack *orig)
+{
+	dest->ruleid[0] = orig->ruleid[0];
+	dest->ruleid[1] = orig->ruleid[1];
+	dest->ruleid[2] = orig->ruleid[2];
+	dest->ruleid[3] = orig->ruleid[3];
+}
+
 static void copy_attr_secmark(struct nf_conntrack *dest,
 			      const struct nf_conntrack *orig)
 {
@@ -486,5 +495,6 @@ const copy_attr copy_attr_array[ATTR_MAX] = {
 	[ATTR_TCP_WSCALE_ORIG]		= copy_attr_tcp_wscale_orig,
 	[ATTR_TCP_WSCALE_REPL]		= copy_attr_tcp_wscale_repl,
 	[ATTR_ZONE]			= copy_attr_zone,
+	[ATTR_RULEID]			= copy_attr_ruleid,
 	[ATTR_SECCTX]			= copy_attr_secctx,
 };
diff --git a/src/conntrack/getter.c b/src/conntrack/getter.c
index 8a093c6..6601943 100644
--- a/src/conntrack/getter.c
+++ b/src/conntrack/getter.c
@@ -222,6 +222,11 @@ static const void *get_attr_mark(const struct nf_conntrack *ct)
 	return &ct->mark;
 }
 
+static const void *get_attr_ruleid(const struct nf_conntrack *ct)
+{
+	return &ct->ruleid;
+}
+
 static const void *get_attr_secmark(const struct nf_conntrack *ct)
 {
 	return &ct->secmark;
@@ -386,4 +391,5 @@ const get_attr get_attr_array[ATTR_MAX] = {
 	[ATTR_TCP_WSCALE_REPL]		= get_attr_tcp_wscale_repl,
 	[ATTR_ZONE]			= get_attr_zone,
 	[ATTR_SECCTX]			= get_attr_secctx,
+	[ATTR_RULEID]			= get_attr_ruleid,
 };
diff --git a/src/conntrack/parse.c b/src/conntrack/parse.c
index 841693e..4d308e1 100644
--- a/src/conntrack/parse.c
+++ b/src/conntrack/parse.c
@@ -538,4 +538,25 @@ void __parse_conntrack(const struct nlmsghdr *nlh,
 
 	if (cda[CTA_SECCTX-1])
 		__parse_secctx(cda[CTA_SECCTX-1], ct);
+
+	if (cda[CTA_RULEID_ESTABLISHED-1]) {
+		ct->ruleid[0] = ntohs(*(u_int16_t *)NFA_DATA(cda[CTA_RULEID_ESTABLISHED-1]));
+		set_bit(ATTR_RULEID, ct->set);
+	}
+
+	if (cda[CTA_RULEID_RELATED-1]) {
+		ct->ruleid[1] = ntohs(*(u_int16_t *)NFA_DATA(cda[CTA_RULEID_RELATED-1]));
+		set_bit(ATTR_RULEID, ct->set);
+	}
+
+	if (cda[CTA_RULEID_NEW-1]) {
+		ct->ruleid[2] = ntohs(*(u_int16_t *)NFA_DATA(cda[CTA_RULEID_NEW-1]));
+		set_bit(ATTR_RULEID, ct->set);
+	}
+
+	if (cda[CTA_RULEID_REPLY-1]) {
+		ct->ruleid[3] = ntohs(*(u_int16_t *)NFA_DATA(cda[CTA_RULEID_REPLY-1]));
+		set_bit(ATTR_RULEID, ct->set);
+	}
+
 }
diff --git a/src/conntrack/setter.c b/src/conntrack/setter.c
index 99ac8d7..b3025bd 100644
--- a/src/conntrack/setter.c
+++ b/src/conntrack/setter.c
@@ -223,6 +223,15 @@ static void set_attr_mark(struct nf_conntrack *ct, const void *value)
 	ct->mark = *((u_int32_t *) value);
 }
 
+static void set_attr_ruleid(struct nf_conntrack *ct, const void *value)
+{
+	u_int16_t *tmp = value;
+	ct->ruleid[0] = tmp[0];
+	ct->ruleid[1] = tmp[1];
+	ct->ruleid[2] = tmp[2];
+	ct->ruleid[3] = tmp[3];
+}
+
 static void set_attr_secmark(struct nf_conntrack *ct, const void *value)
 {
 	ct->secmark = *((u_int32_t *) value);
@@ -411,4 +420,5 @@ const set_attr set_attr_array[ATTR_MAX] = {
 	[ATTR_TCP_WSCALE_REPL]	= set_attr_tcp_wscale_repl,
 	[ATTR_ZONE]		= set_attr_zone,
 	[ATTR_SECCTX]		= set_attr_do_nothing,
+	[ATTR_RULEID]		= set_attr_ruleid,
 };
diff --git a/src/conntrack/snprintf_default.c b/src/conntrack/snprintf_default.c
index abb9d9f..b7bc287 100644
--- a/src/conntrack/snprintf_default.c
+++ b/src/conntrack/snprintf_default.c
@@ -202,6 +202,14 @@ __snprintf_mark(char *buf, unsigned int len, const struct nf_conntrack *ct)
 }
 
 static int
+__snprintf_ruleid(char *buf, unsigned int len, const struct nf_conntrack *ct)
+{
+	return (snprintf(buf, len, "established=%u related=%u new=%u reply=%u ", 
+		ct->ruleid[0], ct->ruleid[1], ct->ruleid[2], 
+		ct->ruleid[3]));
+}
+
+static int
 __snprintf_secmark(char *buf, unsigned int len, const struct nf_conntrack *ct)
 {
 	return (snprintf(buf, len, "secmark=%u ", ct->secmark));
@@ -322,6 +330,11 @@ int __snprintf_conntrack_default(char *buf,
 		BUFFER_SIZE(ret, size, len, offset);
 	}
 
+	if (test_bit(ATTR_RULEID, ct->set)) {
+		ret = __snprintf_ruleid(buf+offset, len, ct);
+		BUFFER_SIZE(ret, size, len, offset);
+	}
+
 	if (test_bit(ATTR_SECMARK, ct->set)) {
 		ret = __snprintf_secmark(buf+offset, len, ct);
 		BUFFER_SIZE(ret, size, len, offset);
diff --git a/src/conntrack/snprintf_xml.c b/src/conntrack/snprintf_xml.c
index 97f6650..2259dfa 100644
--- a/src/conntrack/snprintf_xml.c
+++ b/src/conntrack/snprintf_xml.c
@@ -339,6 +339,16 @@ int __snprintf_conntrack_xml(char *buf,
 		BUFFER_SIZE(ret, size, len, offset);
 	}
 
+	if (test_bit(ATTR_RULEID, ct->set)) {
+		ret = snprintf(buf+offset, len,
+			"<ruleid><established>%u</established>"
+			"<related>%u</related><new>%u</new>"
+			"<reply>%u</reply></ruleid>",
+			ct->ruleid[0], ct->ruleid[1], ct->ruleid[2],
+			ct->ruleid[3]);
+		BUFFER_SIZE(ret, size, len, offset);
+	}
+
 	if (test_bit(ATTR_SECMARK, ct->set)) {
 		ret = snprintf(buf+offset, len, 
 				"<secmark>%u</secmark>", ct->secmark);
@@ -387,6 +397,7 @@ int __snprintf_conntrack_xml(char *buf,
 	    test_bit(ATTR_ZONE, ct->set) ||
 	    test_bit(ATTR_USE, ct->set) ||
 	    test_bit(ATTR_STATUS, ct->set) ||
+	    test_bit(ATTR_RULEID, ct->set) ||
 	    test_bit(ATTR_ID, ct->set)) {
 	    	ret = snprintf(buf+offset, len, "</meta>");
 		BUFFER_SIZE(ret, size, len, offset);
-- 
1.6.6.1

Re: [PATCH 2/3] netfilter: add APPROVE target

[Jan Engelhardt]

On Thursday 2011-01-20 23:47, Richard Weinberger wrote:

>This new target is related to the ruleid extension.
>It accepts a packet and stores it's rule id into
>the connection tracking entry.
>
>Signed-off-by: Richard Weinberger <richard@nod.at>
>---
> include/linux/netfilter/xt_APPROVE.h |    8 +++
> net/netfilter/Kconfig                |   12 +++++
> net/netfilter/Makefile               |    1 +
> net/netfilter/xt_APPROVE.c           |   85 ++++++++++++++++++++++++++++++++++

Until the situation with preexisting modules is solved,
let's at least not add anymore modules with cased names.

xt_approve.{c,h} please. (Do retain the module aliases however.)

> 4 files changed, 106 insertions(+), 0 deletions(-)
> create mode 100644 include/linux/netfilter/xt_APPROVE.h
> create mode 100644 net/netfilter/xt_APPROVE.c
>
>diff --git a/include/linux/netfilter/xt_APPROVE.h b/include/linux/netfilter/xt_APPROVE.h
>new file mode 100644
>index 0000000..c62c6bc
>--- /dev/null
>+++ b/include/linux/netfilter/xt_APPROVE.h
>@@ -0,0 +1,8 @@
>+#ifndef _XT_APPROVE_H
>+#define _XT_APPROVE_H
>+
>+struct nf_approve_info {
>+	u_int16_t ruleid;
>+};

Intended to be "struct xt_approve_info"?

>+
>+#endif /* _XT_APPROVE_H */
>diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
>index 1534f2b..34cd76c 100644
>--- a/net/netfilter/Kconfig
>+++ b/net/netfilter/Kconfig
>@@ -546,6 +546,18 @@ config NETFILTER_XT_TARGET_TRACE
> 	  If you want to compile it as a module, say M here and read
> 	  <file:Documentation/kbuild/modules.txt>.  If unsure, say `N'.
> 
>+config NETFILTER_XT_TARGET_APPROVE
>+	tristate  '"APPROVE" target support'
>+	depends on NF_CONNTRACK
>+	depends on NETFILTER_ADVANCED
>+	help
>+	  The APPROVE target allows you to add a rule ID to the
>+	  connection tracking entry. So you can see which rules
>+	  allowed a connection.
>+
>+	  If you want to compile it as a module, say M here and read
>+	  <file:Documentation/kbuild/modules.txt>.  If unsure, say `N'.
>+

Do please keep the list sorted rather than throwing it somewhere :)

>diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
>index f5bff47..db8a342 100644
>--- a/net/netfilter/Makefile
>+++ b/net/netfilter/Makefile
>@@ -62,6 +62,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_TCPMSS) += xt_TCPMSS.o
> obj-$(CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP) += xt_TCPOPTSTRIP.o
> obj-$(CONFIG_NETFILTER_XT_TARGET_TEE) += xt_TEE.o
> obj-$(CONFIG_NETFILTER_XT_TARGET_TRACE) += xt_TRACE.o
>+obj-$(CONFIG_NETFILTER_XT_TARGET_APPROVE) += xt_APPROVE.o
> obj-$(CONFIG_NETFILTER_XT_TARGET_IDLETIMER) += xt_IDLETIMER.o

Likewise.

>+static unsigned int
>+approve_tg(struct sk_buff *skb, const struct xt_action_param *par)
>+{
>+	enum ip_conntrack_info cti;
>+	struct nf_conn *nfc;
>+	struct nf_conn_ruleid *nfcr;
>+	const struct nf_approve_info *ri = par->targinfo;

(There is no strict rule to use three-letter variable names. It's
just that skb and par are often typed and thus warrant having it.)

>+	if (!nfcr) {
>+		nfcr = nf_ct_ext_add(nfc, NF_CT_EXT_RULEID, GFP_ATOMIC);
>+
>+		/* we're out of memory */
>+		if (!nfcr)
>+			goto out;
>+	}
>+
>+	nfcr->rule[cti] = ri->ruleid;
>+
>+	spin_unlock_bh(&nfc->lock);
>+
>+out:
>+	return NF_ACCEPT;
>+}

In the error case, you forget to unlock the spinlock.

Re: [PATCH 2/3] netfilter: add APPROVE target

[Richard Weinberger]

Am Freitag 21 Januar 2011, 00:17:48 schrieb Jan Engelhardt:
> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
> >This new target is related to the ruleid extension.
> >It accepts a packet and stores it's rule id into
> >the connection tracking entry.
> >
> >Signed-off-by: Richard Weinberger <richard@nod.at>
> >---
> >
> > include/linux/netfilter/xt_APPROVE.h |    8 +++
> > net/netfilter/Kconfig                |   12 +++++
> > net/netfilter/Makefile               |    1 +
> > net/netfilter/xt_APPROVE.c           |   85
> > ++++++++++++++++++++++++++++++++++
> 
> Until the situation with preexisting modules is solved,
> let's at least not add anymore modules with cased names.
> 
> xt_approve.{c,h} please. (Do retain the module aliases however.)
> 
> > 4 files changed, 106 insertions(+), 0 deletions(-)
> > create mode 100644 include/linux/netfilter/xt_APPROVE.h
> > create mode 100644 net/netfilter/xt_APPROVE.c
> >
> >diff --git a/include/linux/netfilter/xt_APPROVE.h
> >b/include/linux/netfilter/xt_APPROVE.h new file mode 100644
> >index 0000000..c62c6bc
> >--- /dev/null
> >+++ b/include/linux/netfilter/xt_APPROVE.h
> >@@ -0,0 +1,8 @@
> >+#ifndef _XT_APPROVE_H
> >+#define _XT_APPROVE_H
> >+
> >+struct nf_approve_info {
> >+	u_int16_t ruleid;
> >+};
> 
> Intended to be "struct xt_approve_info"?

Ok, will rename...

> 
> >+
> >+#endif /* _XT_APPROVE_H */
> >diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
> >index 1534f2b..34cd76c 100644
> >--- a/net/netfilter/Kconfig
> >+++ b/net/netfilter/Kconfig
> >@@ -546,6 +546,18 @@ config NETFILTER_XT_TARGET_TRACE
> >
> > 	  If you want to compile it as a module, say M here and read
> > 	  <file:Documentation/kbuild/modules.txt>.  If unsure, say `N'.
> >
> >+config NETFILTER_XT_TARGET_APPROVE
> >+	tristate  '"APPROVE" target support'
> >+	depends on NF_CONNTRACK
> >+	depends on NETFILTER_ADVANCED
> >+	help
> >+	  The APPROVE target allows you to add a rule ID to the
> >+	  connection tracking entry. So you can see which rules
> >+	  allowed a connection.
> >+
> >+	  If you want to compile it as a module, say M here and read
> >+	  <file:Documentation/kbuild/modules.txt>.  If unsure, say `N'.
> >+
> 
> Do please keep the list sorted rather than throwing it somewhere :)

Ok.

> 
> >diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
> >index f5bff47..db8a342 100644
> >--- a/net/netfilter/Makefile
> >+++ b/net/netfilter/Makefile
> >@@ -62,6 +62,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_TCPMSS) += xt_TCPMSS.o
> >
> > obj-$(CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP) += xt_TCPOPTSTRIP.o
> > obj-$(CONFIG_NETFILTER_XT_TARGET_TEE) += xt_TEE.o
> > obj-$(CONFIG_NETFILTER_XT_TARGET_TRACE) += xt_TRACE.o
> >
> >+obj-$(CONFIG_NETFILTER_XT_TARGET_APPROVE) += xt_APPROVE.o
> >
> > obj-$(CONFIG_NETFILTER_XT_TARGET_IDLETIMER) += xt_IDLETIMER.o
> 
> Likewise.

Ok.

> 
> >+static unsigned int
> >+approve_tg(struct sk_buff *skb, const struct xt_action_param *par)
> >+{
> >+	enum ip_conntrack_info cti;
> >+	struct nf_conn *nfc;
> >+	struct nf_conn_ruleid *nfcr;
> >+	const struct nf_approve_info *ri = par->targinfo;
> 
> (There is no strict rule to use three-letter variable names. It's
> just that skb and par are often typed and thus warrant having it.)

I like short names. :-)

> 
> >+	if (!nfcr) {
> >+		nfcr = nf_ct_ext_add(nfc, NF_CT_EXT_RULEID, GFP_ATOMIC);
> >+
> >+		/* we're out of memory */
> >+		if (!nfcr)
> >+			goto out;
> >+	}
> >+
> >+	nfcr->rule[cti] = ri->ruleid;
> >+
> >+	spin_unlock_bh(&nfc->lock);
> >+
> >+out:
> >+	return NF_ACCEPT;
> >+}
> 
> In the error case, you forget to unlock the spinlock.

*ashamed*, will fix.

Thanks for your review!
//richard

Re: [PATCH 2/3] netfilter: add APPROVE target

[Jan Engelhardt]

On Friday 2011-01-21 00:22, Richard Weinberger wrote:
>> >+
>> >+struct nf_approve_info {
>> >+	u_int16_t ruleid;
>> >+};
>> 
>> Intended to be "struct xt_approve_info"?
>
>Ok, will rename...

Oh, and as per "Writing Netfilter Modules", __u16 should be used
in headers exported to userspace.

Re: [PATCH 2/3] netfilter: add APPROVE target

[Richard Weinberger]

Am Freitag 21 Januar 2011, 00:27:30 schrieb Jan Engelhardt:
> On Friday 2011-01-21 00:22, Richard Weinberger wrote:
> >> >+
> >> >+struct nf_approve_info {
> >> >+	u_int16_t ruleid;
> >> >+};
> >> 
> >> Intended to be "struct xt_approve_info"?
> >
> >Ok, will rename...
> 
> Oh, and as per "Writing Netfilter Modules", __u16 should be used
> in headers exported to userspace.

You mean http://jengelh.medozas.de/documents/Netfilter_Modules.pdf?

*reading*,
//richad

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Jan Engelhardt]

On Thursday 2011-01-20 23:47, Richard Weinberger wrote:

>Hi,
>
>as a firewall admin I would like to see which rules allow
>the connections through my firewall.
>A relationship between conntrack and firewall rules would be nice.
>The next five patches bring this feature to the Linux Netfilter.
>
>First a small example.
>Consider this iptables rules:
>-A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id 1
>-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE --rule-id 2
>-A INPUT -p tcp --dport 22 -m state --state NEW -j APPROVE --rule-id 3
>-A INPUT -p icmp -m state --state NEW -j APPROVE --rule-id 4
>
>The APPROVE target is the same as ACCEPT but it stores also a rule id into 
>the connection tracking entry.


What about connmark? You could have used that. Perhaps combined with the 
use of -j TRACE that can show which rules were processed before a 
verdict was issued.

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Richard Weinberger]

Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
> >Hi,
> >
> >as a firewall admin I would like to see which rules allow
> >the connections through my firewall.
> >A relationship between conntrack and firewall rules would be nice.
> >The next five patches bring this feature to the Linux Netfilter.
> >
> >First a small example.
> >Consider this iptables rules:
> >-A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id 1
> >-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE --rule-id 2
> >-A INPUT -p tcp --dport 22 -m state --state NEW -j APPROVE --rule-id 3
> >-A INPUT -p icmp -m state --state NEW -j APPROVE --rule-id 4
> >
> >The APPROVE target is the same as ACCEPT but it stores also a rule id into
> >the connection tracking entry.
> 
> What about connmark? You could have used that. Perhaps combined with the
> use of -j TRACE that can show which rules were processed before a
> verdict was issued.

Yeah, I know commark and TRACE but they are quite clumsy to use for such a purpose.
Especially writing firewall rules becomes more complex.

//richard

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Pablo Neira Ayuso]

On 21/01/11 00:02, Richard Weinberger wrote:
> Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
>> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
>>> Hi,
>>>
>>> as a firewall admin I would like to see which rules allow
>>> the connections through my firewall.
>>> A relationship between conntrack and firewall rules would be nice.
>>> The next five patches bring this feature to the Linux Netfilter.
>>>
>>> First a small example.
>>> Consider this iptables rules:
>>> -A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id 1
>>> -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE --rule-id 2
>>> -A INPUT -p tcp --dport 22 -m state --state NEW -j APPROVE --rule-id 3
>>> -A INPUT -p icmp -m state --state NEW -j APPROVE --rule-id 4
>>>
>>> The APPROVE target is the same as ACCEPT but it stores also a rule id into
>>> the connection tracking entry.
>>
>> What about connmark? You could have used that. Perhaps combined with the
>> use of -j TRACE that can show which rules were processed before a
>> verdict was issued.
> 
> Yeah, I know commark and TRACE but they are quite clumsy to use for such a purpose.

Why are the clumsy for this purpose?

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Richard Weinberger]

Am Freitag 21 Januar 2011, 11:00:48 schrieb Pablo Neira Ayuso:
> On 21/01/11 00:02, Richard Weinberger wrote:
> > Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
> >> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
> >>> Hi,
> >>> 
> >>> as a firewall admin I would like to see which rules allow
> >>> the connections through my firewall.
> >>> A relationship between conntrack and firewall rules would be nice.
> >>> The next five patches bring this feature to the Linux Netfilter.
> >>> 
> >>> First a small example.
> >>> Consider this iptables rules:
> >>> -A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id 1
> >>> -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE --rule-id
> >>> 2 -A INPUT -p tcp --dport 22 -m state --state NEW -j APPROVE --rule-id
> >>> 3 -A INPUT -p icmp -m state --state NEW -j APPROVE --rule-id 4
> >>> 
> >>> The APPROVE target is the same as ACCEPT but it stores also a rule id
> >>> into the connection tracking entry.
> >> 
> >> What about connmark? You could have used that. Perhaps combined with the
> >> use of -j TRACE that can show which rules were processed before a
> >> verdict was issued.
> > 
> > Yeah, I know commark and TRACE but they are quite clumsy to use for such
> > a purpose.
> 
> Why are the clumsy for this purpose?

Because I would need more than one iptables command to model a firewall rule.
Or can you show me a simple iptables configuration using connmark which 
achieves the same as my APPROVE example above?

//richard

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Pablo Neira Ayuso]

On 21/01/11 12:13, Richard Weinberger wrote:
> Am Freitag 21 Januar 2011, 11:00:48 schrieb Pablo Neira Ayuso:
>> On 21/01/11 00:02, Richard Weinberger wrote:
>>> Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
>>>> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
>>>>> Hi,
>>>>>
>>>>> as a firewall admin I would like to see which rules allow
>>>>> the connections through my firewall.
>>>>> A relationship between conntrack and firewall rules would be nice.
>>>>> The next five patches bring this feature to the Linux Netfilter.
>>>>>
>>>>> First a small example.
>>>>> Consider this iptables rules:
>>>>> -A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id 1
>>>>> -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE --rule-id
>>>>> 2 -A INPUT -p tcp --dport 22 -m state --state NEW -j APPROVE --rule-id
>>>>> 3 -A INPUT -p icmp -m state --state NEW -j APPROVE --rule-id 4
>>>>>
>>>>> The APPROVE target is the same as ACCEPT but it stores also a rule id
>>>>> into the connection tracking entry.
>>>>
>>>> What about connmark? You could have used that. Perhaps combined with the
>>>> use of -j TRACE that can show which rules were processed before a
>>>> verdict was issued.
>>>
>>> Yeah, I know commark and TRACE but they are quite clumsy to use for such
>>> a purpose.
>>
>> Why are the clumsy for this purpose?
> 
> Because I would need more than one iptables command to model a firewall rule.
> Or can you show me a simple iptables configuration using connmark which 
> achieves the same as my APPROVE example above?

Just a couple of extra rules to restore and save the connmark. Right?

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Richard Weinberger]

Am Freitag 21 Januar 2011, 12:26:09 schrieb Pablo Neira Ayuso:
> On 21/01/11 12:13, Richard Weinberger wrote:
> > Am Freitag 21 Januar 2011, 11:00:48 schrieb Pablo Neira Ayuso:
> >> On 21/01/11 00:02, Richard Weinberger wrote:
> >>> Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
> >>>> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
> >>>>> Hi,
> >>>>> 
> >>>>> as a firewall admin I would like to see which rules allow
> >>>>> the connections through my firewall.
> >>>>> A relationship between conntrack and firewall rules would be nice.
> >>>>> The next five patches bring this feature to the Linux Netfilter.
> >>>>> 
> >>>>> First a small example.
> >>>>> Consider this iptables rules:
> >>>>> -A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id 1
> >>>>> -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE
> >>>>> --rule-id 2 -A INPUT -p tcp --dport 22 -m state --state NEW -j
> >>>>> APPROVE --rule-id 3 -A INPUT -p icmp -m state --state NEW -j APPROVE
> >>>>> --rule-id 4
> >>>>> 
> >>>>> The APPROVE target is the same as ACCEPT but it stores also a rule id
> >>>>> into the connection tracking entry.
> >>>> 
> >>>> What about connmark? You could have used that. Perhaps combined with
> >>>> the use of -j TRACE that can show which rules were processed before a
> >>>> verdict was issued.
> >>> 
> >>> Yeah, I know commark and TRACE but they are quite clumsy to use for
> >>> such a purpose.
> >> 
> >> Why are the clumsy for this purpose?
> > 
> > Because I would need more than one iptables command to model a firewall
> > rule. Or can you show me a simple iptables configuration using connmark
> > which achieves the same as my APPROVE example above?
> 
> Just a couple of extra rules to restore and save the connmark. Right?

With my extension you can see which rule accepted the connection
in the states ESTABLISHED, RELATED, NEW and REPLY.
So we have 4 rule ids per connection.

Let's look again at this connection:
tcp      6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2 sport=51444 \
        dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444 [ASSURED] \
        mark=0 established=1 related=0 new=3 reply=2 use=1

We can observe that the connection in state ESTABLISHED was allowed by rule 1, 
NEW by rule 3 and REPLY by rule 2.

To model this using conntrack we need more than a few more restore and save rules...
(Assuming all rule ids are 8bit, because connmark is 32bit)

This is why I've made this contribution.
It makes it very easy to model such tasks.

//richard

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Pablo Neira Ayuso]

On 21/01/11 12:56, Richard Weinberger wrote:
> Am Freitag 21 Januar 2011, 12:26:09 schrieb Pablo Neira Ayuso:
>> On 21/01/11 12:13, Richard Weinberger wrote:
>>> Am Freitag 21 Januar 2011, 11:00:48 schrieb Pablo Neira Ayuso:
>>>> On 21/01/11 00:02, Richard Weinberger wrote:
>>>>> Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
>>>>>> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> as a firewall admin I would like to see which rules allow
>>>>>>> the connections through my firewall.
>>>>>>> A relationship between conntrack and firewall rules would be nice.
>>>>>>> The next five patches bring this feature to the Linux Netfilter.
>>>>>>>
>>>>>>> First a small example.
>>>>>>> Consider this iptables rules:
>>>>>>> -A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id 1
>>>>>>> -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE
>>>>>>> --rule-id 2 -A INPUT -p tcp --dport 22 -m state --state NEW -j
>>>>>>> APPROVE --rule-id 3 -A INPUT -p icmp -m state --state NEW -j APPROVE
>>>>>>> --rule-id 4
>>>>>>>
>>>>>>> The APPROVE target is the same as ACCEPT but it stores also a rule id
>>>>>>> into the connection tracking entry.
>>>>>>
>>>>>> What about connmark? You could have used that. Perhaps combined with
>>>>>> the use of -j TRACE that can show which rules were processed before a
>>>>>> verdict was issued.
>>>>>
>>>>> Yeah, I know commark and TRACE but they are quite clumsy to use for
>>>>> such a purpose.
>>>>
>>>> Why are the clumsy for this purpose?
>>>
>>> Because I would need more than one iptables command to model a firewall
>>> rule. Or can you show me a simple iptables configuration using connmark
>>> which achieves the same as my APPROVE example above?
>>
>> Just a couple of extra rules to restore and save the connmark. Right?
> 
> With my extension you can see which rule accepted the connection
> in the states ESTABLISHED, RELATED, NEW and REPLY.
> So we have 4 rule ids per connection.
> 
> Let's look again at this connection:
> tcp      6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2 sport=51444 \
>         dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444 [ASSURED] \
>         mark=0 established=1 related=0 new=3 reply=2 use=1
> 
> We can observe that the connection in state ESTABLISHED was allowed by rule 1, 
> NEW by rule 3 and REPLY by rule 2.
> 
> To model this using conntrack we need more than a few more restore and save rules...
> (Assuming all rule ids are 8bit, because connmark is 32bit)
> 
> This is why I've made this contribution.
> It makes it very easy to model such tasks.

I think that it's better to do this in user-space. You have the trace
infrastructure which actually logs stuff via NFLOG. You can write some
user-space tool using libnetfilter_log that can accumulate the trace for
some traffic and display friendlier output (which seems to be what you
want).

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Richard Weinberger]

Am Freitag 21 Januar 2011, 13:24:27 schrieb Pablo Neira Ayuso:
> On 21/01/11 12:56, Richard Weinberger wrote:
> > Am Freitag 21 Januar 2011, 12:26:09 schrieb Pablo Neira Ayuso:
> >> On 21/01/11 12:13, Richard Weinberger wrote:
> >>> Am Freitag 21 Januar 2011, 11:00:48 schrieb Pablo Neira Ayuso:
> >>>> On 21/01/11 00:02, Richard Weinberger wrote:
> >>>>> Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
> >>>>>> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
> >>>>>>> Hi,
> >>>>>>> 
> >>>>>>> as a firewall admin I would like to see which rules allow
> >>>>>>> the connections through my firewall.
> >>>>>>> A relationship between conntrack and firewall rules would be nice.
> >>>>>>> The next five patches bring this feature to the Linux Netfilter.
> >>>>>>> 
> >>>>>>> First a small example.
> >>>>>>> Consider this iptables rules:
> >>>>>>> -A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id
> >>>>>>> 1 -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE
> >>>>>>> --rule-id 2 -A INPUT -p tcp --dport 22 -m state --state NEW -j
> >>>>>>> APPROVE --rule-id 3 -A INPUT -p icmp -m state --state NEW -j
> >>>>>>> APPROVE --rule-id 4
> >>>>>>> 
> >>>>>>> The APPROVE target is the same as ACCEPT but it stores also a rule
> >>>>>>> id into the connection tracking entry.
> >>>>>> 
> >>>>>> What about connmark? You could have used that. Perhaps combined with
> >>>>>> the use of -j TRACE that can show which rules were processed before
> >>>>>> a verdict was issued.
> >>>>> 
> >>>>> Yeah, I know commark and TRACE but they are quite clumsy to use for
> >>>>> such a purpose.
> >>>> 
> >>>> Why are the clumsy for this purpose?
> >>> 
> >>> Because I would need more than one iptables command to model a firewall
> >>> rule. Or can you show me a simple iptables configuration using connmark
> >>> which achieves the same as my APPROVE example above?
> >> 
> >> Just a couple of extra rules to restore and save the connmark. Right?
> > 
> > With my extension you can see which rule accepted the connection
> > in the states ESTABLISHED, RELATED, NEW and REPLY.
> > So we have 4 rule ids per connection.
> > 
> > Let's look again at this connection:
> > tcp      6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2 sport=51444
> > \
> > 
> >         dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444
> >         [ASSURED] \ mark=0 established=1 related=0 new=3 reply=2 use=1
> > 
> > We can observe that the connection in state ESTABLISHED was allowed by
> > rule 1, NEW by rule 3 and REPLY by rule 2.
> > 
> > To model this using conntrack we need more than a few more restore and
> > save rules... (Assuming all rule ids are 8bit, because connmark is
> > 32bit)
> > 
> > This is why I've made this contribution.
> > It makes it very easy to model such tasks.
> 
> I think that it's better to do this in user-space. You have the trace
> infrastructure which actually logs stuff via NFLOG. You can write some
> user-space tool using libnetfilter_log that can accumulate the trace for
> some traffic and display friendlier output (which seems to be what you
> want).

Using the TRACE target the kernel would produce a lot of log messages which may slow
down the firewall. Especially when tracing ESTABLISHED connections.
My extension does not have this overhead.

All I want is a friendlier output from conntrack, why should I reinvent the wheel?

//richard

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Pablo Neira Ayuso]

On 21/01/11 13:53, Richard Weinberger wrote:
> Am Freitag 21 Januar 2011, 13:24:27 schrieb Pablo Neira Ayuso:
>> On 21/01/11 12:56, Richard Weinberger wrote:
>>> Am Freitag 21 Januar 2011, 12:26:09 schrieb Pablo Neira Ayuso:
>>>> On 21/01/11 12:13, Richard Weinberger wrote:
>>>>> Am Freitag 21 Januar 2011, 11:00:48 schrieb Pablo Neira Ayuso:
>>>>>> On 21/01/11 00:02, Richard Weinberger wrote:
>>>>>>> Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
>>>>>>>> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> as a firewall admin I would like to see which rules allow
>>>>>>>>> the connections through my firewall.
>>>>>>>>> A relationship between conntrack and firewall rules would be nice.
>>>>>>>>> The next five patches bring this feature to the Linux Netfilter.
>>>>>>>>>
>>>>>>>>> First a small example.
>>>>>>>>> Consider this iptables rules:
>>>>>>>>> -A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE --rule-id
>>>>>>>>> 1 -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j APPROVE
>>>>>>>>> --rule-id 2 -A INPUT -p tcp --dport 22 -m state --state NEW -j
>>>>>>>>> APPROVE --rule-id 3 -A INPUT -p icmp -m state --state NEW -j
>>>>>>>>> APPROVE --rule-id 4
>>>>>>>>>
>>>>>>>>> The APPROVE target is the same as ACCEPT but it stores also a rule
>>>>>>>>> id into the connection tracking entry.
>>>>>>>>
>>>>>>>> What about connmark? You could have used that. Perhaps combined with
>>>>>>>> the use of -j TRACE that can show which rules were processed before
>>>>>>>> a verdict was issued.
>>>>>>>
>>>>>>> Yeah, I know commark and TRACE but they are quite clumsy to use for
>>>>>>> such a purpose.
>>>>>>
>>>>>> Why are the clumsy for this purpose?
>>>>>
>>>>> Because I would need more than one iptables command to model a firewall
>>>>> rule. Or can you show me a simple iptables configuration using connmark
>>>>> which achieves the same as my APPROVE example above?
>>>>
>>>> Just a couple of extra rules to restore and save the connmark. Right?
>>>
>>> With my extension you can see which rule accepted the connection
>>> in the states ESTABLISHED, RELATED, NEW and REPLY.
>>> So we have 4 rule ids per connection.
>>>
>>> Let's look again at this connection:
>>> tcp      6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2 sport=51444
>>> \
>>>
>>>         dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444
>>>         [ASSURED] \ mark=0 established=1 related=0 new=3 reply=2 use=1
>>>
>>> We can observe that the connection in state ESTABLISHED was allowed by
>>> rule 1, NEW by rule 3 and REPLY by rule 2.
>>>
>>> To model this using conntrack we need more than a few more restore and
>>> save rules... (Assuming all rule ids are 8bit, because connmark is
>>> 32bit)
>>>
>>> This is why I've made this contribution.
>>> It makes it very easy to model such tasks.
>>
>> I think that it's better to do this in user-space. You have the trace
>> infrastructure which actually logs stuff via NFLOG. You can write some
>> user-space tool using libnetfilter_log that can accumulate the trace for
>> some traffic and display friendlier output (which seems to be what you
>> want).
> 
> Using the TRACE target the kernel would produce a lot of log messages which may slow
> down the firewall. Especially when tracing ESTABLISHED connections.
> My extension does not have this overhead.

AFAICS, this is an ad-hoc optimization for a specific case that you
need. So, it's basically a subset of the trace infrastructure.

> All I want is a friendlier output from conntrack, why should I reinvent the wheel?

Why doing things in user-space is reinventing the wheel?

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Richard Weinberger]

Am Freitag 21 Januar 2011, 14:25:42 schrieb Pablo Neira Ayuso:
> On 21/01/11 13:53, Richard Weinberger wrote:
> > Am Freitag 21 Januar 2011, 13:24:27 schrieb Pablo Neira Ayuso:
> >> On 21/01/11 12:56, Richard Weinberger wrote:
> >>> Am Freitag 21 Januar 2011, 12:26:09 schrieb Pablo Neira Ayuso:
> >>>> On 21/01/11 12:13, Richard Weinberger wrote:
> >>>>> Am Freitag 21 Januar 2011, 11:00:48 schrieb Pablo Neira Ayuso:
> >>>>>> On 21/01/11 00:02, Richard Weinberger wrote:
> >>>>>>> Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
> >>>>>>>> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
> >>>>>>>>> Hi,
> >>>>>>>>> 
> >>>>>>>>> as a firewall admin I would like to see which rules allow
> >>>>>>>>> the connections through my firewall.
> >>>>>>>>> A relationship between conntrack and firewall rules would be
> >>>>>>>>> nice. The next five patches bring this feature to the Linux
> >>>>>>>>> Netfilter.
> >>>>>>>>> 
> >>>>>>>>> First a small example.
> >>>>>>>>> Consider this iptables rules:
> >>>>>>>>> -A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE
> >>>>>>>>> --rule-id 1 -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED
> >>>>>>>>> -j APPROVE --rule-id 2 -A INPUT -p tcp --dport 22 -m state
> >>>>>>>>> --state NEW -j APPROVE --rule-id 3 -A INPUT -p icmp -m state
> >>>>>>>>> --state NEW -j APPROVE --rule-id 4
> >>>>>>>>> 
> >>>>>>>>> The APPROVE target is the same as ACCEPT but it stores also a
> >>>>>>>>> rule id into the connection tracking entry.
> >>>>>>>> 
> >>>>>>>> What about connmark? You could have used that. Perhaps combined
> >>>>>>>> with the use of -j TRACE that can show which rules were processed
> >>>>>>>> before a verdict was issued.
> >>>>>>> 
> >>>>>>> Yeah, I know commark and TRACE but they are quite clumsy to use for
> >>>>>>> such a purpose.
> >>>>>> 
> >>>>>> Why are the clumsy for this purpose?
> >>>>> 
> >>>>> Because I would need more than one iptables command to model a
> >>>>> firewall rule. Or can you show me a simple iptables configuration
> >>>>> using connmark which achieves the same as my APPROVE example above?
> >>>> 
> >>>> Just a couple of extra rules to restore and save the connmark. Right?
> >>> 
> >>> With my extension you can see which rule accepted the connection
> >>> in the states ESTABLISHED, RELATED, NEW and REPLY.
> >>> So we have 4 rule ids per connection.
> >>> 
> >>> Let's look again at this connection:
> >>> tcp      6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2
> >>> sport=51444 \
> >>> 
> >>>         dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444
> >>>         [ASSURED] \ mark=0 established=1 related=0 new=3 reply=2 use=1
> >>> 
> >>> We can observe that the connection in state ESTABLISHED was allowed by
> >>> rule 1, NEW by rule 3 and REPLY by rule 2.
> >>> 
> >>> To model this using conntrack we need more than a few more restore and
> >>> save rules... (Assuming all rule ids are 8bit, because connmark is
> >>> 32bit)
> >>> 
> >>> This is why I've made this contribution.
> >>> It makes it very easy to model such tasks.
> >> 
> >> I think that it's better to do this in user-space. You have the trace
> >> infrastructure which actually logs stuff via NFLOG. You can write some
> >> user-space tool using libnetfilter_log that can accumulate the trace for
> >> some traffic and display friendlier output (which seems to be what you
> >> want).
> > 
> > Using the TRACE target the kernel would produce a lot of log messages
> > which may slow down the firewall. Especially when tracing ESTABLISHED
> > connections. My extension does not have this overhead.
> 
> AFAICS, this is an ad-hoc optimization for a specific case that you
> need. So, it's basically a subset of the trace infrastructure.

But without the overhead...

> > All I want is a friendlier output from conntrack, why should I reinvent
> > the wheel?
> 
> Why doing things in user-space is reinventing the wheel?

When I'm using TRACE I'll get a lot of log messages.
But I'm not interested in logs, I have already enough of them.
I want a session table where I can see what sessions are allowed by
which rules.
I would have to write a tool like conntrack which builds me a session table
from all these logs.

//richard

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Pablo Neira Ayuso]

On 21/01/11 14:38, Richard Weinberger wrote:
> Am Freitag 21 Januar 2011, 14:25:42 schrieb Pablo Neira Ayuso:
>>> Using the TRACE target the kernel would produce a lot of log messages
>>> which may slow down the firewall. Especially when tracing ESTABLISHED
>>> connections. My extension does not have this overhead.
>>
>> AFAICS, this is an ad-hoc optimization for a specific case that you
>> need. So, it's basically a subset of the trace infrastructure.
> 
> But without the overhead...

I guess that one runs after defining the rule-set for first time or if
it finds a problem in his rule-set. Not in his daily ruleset.

>>> All I want is a friendlier output from conntrack, why should I reinvent
>>> the wheel?
>>
>> Why doing things in user-space is reinventing the wheel?
> 
> When I'm using TRACE I'll get a lot of log messages.
> But I'm not interested in logs, I have already enough of them.

I know that.

I'm proposing you to make a program in user-space that can process them
and print the output in some compact format, more useful than the current.

> I want a session table where I can see what sessions are allowed by
> which rules.

I know what you want but who else in this world needs this in the Linux
kernel.

Of course, you can maintain this hack in your internal tree if you need it.

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Richard Weinberger]

Am Freitag 21 Januar 2011, 14:57:57 schrieb Pablo Neira Ayuso:
> On 21/01/11 14:38, Richard Weinberger wrote:
> > Am Freitag 21 Januar 2011, 14:25:42 schrieb Pablo Neira Ayuso:
> >>> Using the TRACE target the kernel would produce a lot of log messages
> >>> which may slow down the firewall. Especially when tracing ESTABLISHED
> >>> connections. My extension does not have this overhead.
> >> 
> >> AFAICS, this is an ad-hoc optimization for a specific case that you
> >> need. So, it's basically a subset of the trace infrastructure.
> > 
> > But without the overhead...
> 
> I guess that one runs after defining the rule-set for first time or if
> it finds a problem in his rule-set. Not in his daily ruleset.

TRACE is a debug tool.
My extension is not it helps me to see what is going on now.
Sometimes I see a session in conntrack and have to ask me 
"What the heck is this session doing here?!".
This is why I've made APPROVE and ruleid.

> >>> All I want is a friendlier output from conntrack, why should I reinvent
> >>> the wheel?
> >> 
> >> Why doing things in user-space is reinventing the wheel?
> > 
> > When I'm using TRACE I'll get a lot of log messages.
> > But I'm not interested in logs, I have already enough of them.
> 
> I know that.
> 
> I'm proposing you to make a program in user-space that can process them
> and print the output in some compact format, more useful than the current.
> 
> > I want a session table where I can see what sessions are allowed by
> > which rules.
> 
> I know what you want but who else in this world needs this in the Linux
> kernel.

Quite all commercial firewalls have this feature, why shouldn't netfilter have it?

> Of course, you can maintain this hack in your internal tree if you need it.

Ok, you hate my extension.
Why do you consider it as hack?
It does does not touch anything unless you are using the APPROVE target.

//richard

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Mr Dash Four]

>>> All I want is a friendlier output from conntrack, why should I reinvent
>>> the wheel?
>>>       
>> Why doing things in user-space is reinventing the wheel?
>>     
>
> When I'm using TRACE I'll get a lot of log messages.
> But I'm not interested in logs, I have already enough of them.
> I want a session table where I can see what sessions are allowed by
> which rules.
> I would have to write a tool like conntrack which builds me a session table
> from all these logs.
>   
I personally like the patch and find it quite useful, though I also 
think that tracing/tracking/matching sessions and rules could be 
improved and made more easier for the end user. That is especially true 
when one has a large number of rules in a particular chain.

As things stand, in order to trace a particular session and match it 
with a rule (using your patch) I have to execute iptables (or conntrack) 
twice in order to get what I need. Even if I use the line-numbers option 
to show rule numbers in a particular chain, that won't be straight 
forward when I have large number of rules.

It would be better if this matching is done (again, by using the rule 
numbers provided by your patch) with a userspace tool, may be conntrack, 
or similar, which shows those matches as well as the rules in question, 
and present them in a form, which does not require me to scan for those 
matches over and over. Just my two pence, of course, and I hope I am 
on-topic this time!

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Mr Dash Four]

> "conntrack -L" shows us this two entries:
> tcp      6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2 sport=51444 \
> 	dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444 [ASSURED] \
> 	mark=0 established=1 related=0 new=3 reply=2 use=1
>
> icmp     1 28 src=192.168.1.2 dst=149.20.20.133 type=8 code=0 id=63239 \
> 	src=149.20.20.133 dst=192.168.1.2 type=0 code=0 id=63239 mark=0 \
> 	established=2 related=0 new=2 reply=1 use=1
>   
Isn't there supposed to be secctx (SELinux context) field showing as 
well or is this still not implemented in the conntrack tools?

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Richard Weinberger]

Am Freitag 21 Januar 2011, 01:04:47 schrieb Mr Dash Four:
> > "conntrack -L" shows us this two entries:
> > tcp      6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2 sport=51444
> > \
> > 
> > 	dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444 [ASSURED]
> > 	\ mark=0 established=1 related=0 new=3 reply=2 use=1
> > 
> > icmp     1 28 src=192.168.1.2 dst=149.20.20.133 type=8 code=0 id=63239 \
> > 
> > 	src=149.20.20.133 dst=192.168.1.2 type=0 code=0 id=63239 mark=0 \
> > 	established=2 related=0 new=2 reply=1 use=1
> 
> Isn't there supposed to be secctx (SELinux context) field showing as
> well or is this still not implemented in the conntrack tools?

SELinux is disabled on my box.

//richard

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Mr Dash Four]

> SELinux is disabled on my box.
>   
Still, isn't it supposed to show secctx=0 (or was it secctx=-1) if 
SELinux is in permissive/disabled mode?

secctx support for conntrack-tools [was Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules]

[Pablo Neira Ayuso]

On 21/01/11 01:13, Mr Dash Four wrote:
> 
>> SELinux is disabled on my box.
>>   
> Still, isn't it supposed to show secctx=0 (or was it secctx=-1) if
> SELinux is in permissive/disabled mode?

The support is here:

http://git.netfilter.org/cgi-bin/gitweb.cgi?p=libnetfilter_conntrack.git;a=commit;h=fdda1474cc8654430f245b7f01c30e8ff171fa60

Please, Mr Dash Four, this thread clearly has no relationship with the
issue that you're commenting. So you're violating the mailing list rules.

Open a new thread, otherwise you confuse people (as it is happening now).

Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules

[Pablo Neira Ayuso]

On 21/01/11 01:04, Mr Dash Four wrote:
> 
>> "conntrack -L" shows us this two entries:
>> tcp      6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2
>> sport=51444 \
>>     dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444
>> [ASSURED] \
>>     mark=0 established=1 related=0 new=3 reply=2 use=1
>>
>> icmp     1 28 src=192.168.1.2 dst=149.20.20.133 type=8 code=0 id=63239 \
>>     src=149.20.20.133 dst=192.168.1.2 type=0 code=0 id=63239 mark=0 \
>>     established=2 related=0 new=2 reply=1 use=1
>>   
> Isn't there supposed to be secctx (SELinux context) field showing as
> well or is this still not implemented in the conntrack tools?

http://git.netfilter.org/cgi-bin/gitweb.cgi?p=libnetfilter_conntrack.git;a=commit;h=fdda1474cc8654430f245b7f01c30e8ff171fa60