[PATCH] chaostables

[PATCH] chaostables

[Jan Engelhardt]

Hello netfilter-devel,


I would like to submit chaostables (v0.5_svn23) for inclusion. Primary 
use is to detect, spoof and slowdown various sorts of port scans.
Implementation details can be found at http://jengelh.hopto.org/p/chaostables/

If you have any comments or suggestions, do not hestitate to 
let me know.


Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

---

 include/linux/netfilter/x_tables.h    |    2 
 include/linux/netfilter/xt_CHAOS.h    |   14 +
 include/linux/netfilter/xt_portscan.h |    8 +
 net/netfilter/Kconfig                 |   12 +
 net/netfilter/Makefile                |    3 
 net/netfilter/x_tables.c              |   12 +
 net/netfilter/xt_CHAOS.c              |  184 +++++++++++++++++++++++
 net/netfilter/xt_DELUDE.c             |  259 ++++++++++++++++++++++++++++++++
 net/netfilter/xt_portscan.c           |  271 ++++++++++++++++++++++++++++++++++
 9 files changed, 765 insertions(+)

Index: linux-2.6.21-rc3/include/linux/netfilter/x_tables.h
===================================================================
--- linux-2.6.21-rc3.orig/include/linux/netfilter/x_tables.h
+++ linux-2.6.21-rc3/include/linux/netfilter/x_tables.h
@@ -292,6 +292,8 @@ extern struct xt_table_info *xt_replace_
 					      int *error);
 
 extern struct xt_match *xt_find_match(int af, const char *name, u8 revision);
+extern struct xt_match *xt_request_find_match(int af, const char *name,
+						u8 revision);
 extern struct xt_target *xt_find_target(int af, const char *name, u8 revision);
 extern struct xt_target *xt_request_find_target(int af, const char *name, 
 						u8 revision);
Index: linux-2.6.21-rc3/include/linux/netfilter/xt_CHAOS.h
===================================================================
--- /dev/null
+++ linux-2.6.21-rc3/include/linux/netfilter/xt_CHAOS.h
@@ -0,0 +1,14 @@
+#ifndef _LINUX_XT_CHAOS_H
+#define _LINUX_XT_CHAOS_H 1
+
+enum xt_chaos_variant {
+	XTCHAOS_NORMAL,
+	XTCHAOS_TARPIT,
+	XTCHAOS_DELUDE,
+};
+
+struct xt_chaos_info {
+	enum xt_chaos_variant variant;
+};
+
+#endif /* _LINUX_XT_CHAOS_H */
Index: linux-2.6.21-rc3/include/linux/netfilter/xt_portscan.h
===================================================================
--- /dev/null
+++ linux-2.6.21-rc3/include/linux/netfilter/xt_portscan.h
@@ -0,0 +1,8 @@
+#ifndef _LINUX_XT_PORTSCAN_H
+#define _LINUX_XT_PORTSCAN_H 1
+
+struct xt_portscan_info {
+	unsigned int match_stealth, match_syn, match_cn, match_gr;
+};
+
+#endif /* _LINUX_XT_PORTSCAN_H */
Index: linux-2.6.21-rc3/net/netfilter/Kconfig
===================================================================
--- linux-2.6.21-rc3.orig/net/netfilter/Kconfig
+++ linux-2.6.21-rc3/net/netfilter/Kconfig
@@ -286,6 +286,14 @@ config NETFILTER_XTABLES
 
 # alphabetically ordered list of targets
 
+config NETFILTER_XT_TARGET_CHAOS
+	tristate '"CHAOS" target support'
+	depends on NETFILTER_XTABLES
+
+config NETFILTER_XT_TARGET_DELUDE
+	tristate '"DELUDE" target support'
+	depends on NETFILTER_XTABLES
+
 config NETFILTER_XT_TARGET_CLASSIFY
 	tristate '"CLASSIFY" target support'
 	depends on NETFILTER_XTABLES
@@ -562,6 +570,10 @@ config NETFILTER_XT_MATCH_POLICY
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
+config NETFILTER_XT_MATCH_PORTSCAN
+	tristate '"portscan" match support'
+	depends on NETFILTER_XTABLES && NF_CONNTRACK
+
 config NETFILTER_XT_MATCH_MULTIPORT
 	tristate "Multiple port match support"
 	depends on NETFILTER_XTABLES
Index: linux-2.6.21-rc3/net/netfilter/Makefile
===================================================================
--- linux-2.6.21-rc3.orig/net/netfilter/Makefile
+++ linux-2.6.21-rc3/net/netfilter/Makefile
@@ -37,8 +37,10 @@ obj-$(CONFIG_NF_CONNTRACK_TFTP) += nf_co
 obj-$(CONFIG_NETFILTER_XTABLES) += x_tables.o xt_tcpudp.o
 
 # targets
+obj-$(CONFIG_NETFILTER_XT_TARGET_CHAOS) += xt_CHAOS.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_CLASSIFY) += xt_CLASSIFY.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_CONNMARK) += xt_CONNMARK.o
+obj-$(CONFIG_NETFILTER_XT_TARGET_DELUDE) += xt_DELUDE.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_DSCP) += xt_DSCP.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_MARK) += xt_MARK.o
 obj-$(CONFIG_NETFILTER_XT_TARGET_NFQUEUE) += xt_NFQUEUE.o
@@ -63,6 +65,7 @@ obj-$(CONFIG_NETFILTER_XT_MATCH_MAC) += 
 obj-$(CONFIG_NETFILTER_XT_MATCH_MARK) += xt_mark.o
 obj-$(CONFIG_NETFILTER_XT_MATCH_MULTIPORT) += xt_multiport.o
 obj-$(CONFIG_NETFILTER_XT_MATCH_POLICY) += xt_policy.o
+obj-$(CONFIG_NETFILTER_XT_MATCH_PORTSCAN) += xt_portscan.o
 obj-$(CONFIG_NETFILTER_XT_MATCH_PKTTYPE) += xt_pkttype.o
 obj-$(CONFIG_NETFILTER_XT_MATCH_QUOTA) += xt_quota.o
 obj-$(CONFIG_NETFILTER_XT_MATCH_REALM) += xt_realm.o
Index: linux-2.6.21-rc3/net/netfilter/x_tables.c
===================================================================
--- linux-2.6.21-rc3.orig/net/netfilter/x_tables.c
+++ linux-2.6.21-rc3/net/netfilter/x_tables.c
@@ -206,6 +206,18 @@ struct xt_match *xt_find_match(int af, c
 }
 EXPORT_SYMBOL(xt_find_match);
 
+struct xt_match *xt_request_find_match(int af, const char *name, u8 revision)
+{
+	struct xt_match *match;
+
+	match = try_then_request_module(xt_find_match(af, name, revision),
+					"%st_%s", xt_prefix[af], name);
+	if(IS_ERR(match) || match == NULL)
+		return NULL;
+	return match;
+}
+EXPORT_SYMBOL_GPL(xt_request_find_match);
+
 /* Find target, grabs ref.  Returns ERR_PTR() on error. */
 struct xt_target *xt_find_target(int af, const char *name, u8 revision)
 {
Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
===================================================================
--- /dev/null
+++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
@@ -0,0 +1,184 @@
+/*
+	CHAOS target for netfilter
+
+	Copyright © Jan Engelhardt <jengelh [at] gmx de>, 2006 - 2007
+	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/icmp.h>
+#include <linux/in.h>
+#include <linux/ip.h>
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/stat.h>
+#include <linux/netfilter/x_tables.h>
+#include <linux/netfilter/xt_tcpudp.h>
+#include <linux/netfilter_ipv4/ipt_REJECT.h>
+#include <net/ip.h>
+#include <linux/netfilter/xt_CHAOS.h>
+#define PFX KBUILD_MODNAME ": "
+
+/* Module parameters */
+static unsigned int reject_percentage = ~0U * .01;
+static unsigned int delude_percentage = ~0U * .0101;
+module_param(reject_percentage, uint, S_IRUGO | S_IWUSR);
+module_param(delude_percentage, uint, S_IRUGO | S_IWUSR);
+
+/* References to other matches/targets */
+static struct xt_match *xm_tcp;
+static struct xt_target *xt_delude, *xt_reject, *xt_tarpit;
+
+static int have_delude, have_tarpit;
+
+/* Static data for other matches/targets */
+static const struct ipt_reject_info reject_params = {
+	.with = ICMP_HOST_UNREACH,
+};
+
+static const struct xt_tcp tcp_params = {
+	.spts = {0, ~0},
+	.dpts = {0, ~0},
+};
+
+/* CHAOS functions */
+static void xt_chaos_total(const struct xt_chaos_info *info,
+    struct sk_buff **pskb, const struct net_device *in,
+    const struct net_device *out, unsigned int hooknum)
+{
+	const int protoff = 4 * (*pskb)->nh.iph->ihl;
+	const int offset  = ntohs((*pskb)->nh.iph->frag_off) & IP_OFFSET;
+	const struct xt_target *destiny;
+	int hotdrop = 0, ret;
+
+	ret = xm_tcp->match(*pskb, in, out, xm_tcp, &tcp_params,
+	                    offset, protoff, &hotdrop);
+	if(!ret || hotdrop || (unsigned int)net_random() > delude_percentage)
+		return;
+
+	destiny = (info->variant == XTCHAOS_TARPIT) ? xt_tarpit : xt_delude;
+	destiny->target(pskb, in, out, hooknum, destiny, NULL);
+	return;
+}
+
+static unsigned int xt_chaos_target(struct sk_buff **pskb,
+    const struct net_device *in, const struct net_device *out,
+    unsigned int hooknum, const struct xt_target *target, const void *targinfo)
+{
+	/* Equivalent to:
+	 * -A chaos -m statistic --mode random --probability \
+	 *         $reject_percentage -j REJECT --reject-with host-unreach;
+	 * -A chaos -m statistic --mode random --probability \
+	 *         $delude_percentage -j DELUDE;
+	 * -A chaos -j DROP;
+	 */
+	const struct xt_chaos_info *info = targinfo;
+
+	if((unsigned int)net_random() <= reject_percentage)
+		return xt_reject->target(pskb, in, out, hooknum, target,
+		       &reject_params);
+
+	/* TARPIT/DELUDE may not be called from the OUTPUT chain */
+	if((*pskb)->nh.iph->protocol == IPPROTO_TCP &&
+	  info->variant != XTCHAOS_NORMAL && hooknum != NF_IP_LOCAL_OUT)
+		xt_chaos_total(info, pskb, in, out, hooknum);
+
+	return NF_DROP;
+}
+
+static int xt_chaos_checkentry(const char *tablename, const void *entry,
+    const struct xt_target *target, void *targinfo, unsigned int hook_mask)
+{
+	const struct xt_chaos_info *info = targinfo;
+	if(info->variant == XTCHAOS_DELUDE && !have_delude) {
+		printk(KERN_WARNING PFX "Error: Cannot use --delude when "
+		       "DELUDE module not available\n");
+		return 0;
+	}
+	if(info->variant == XTCHAOS_TARPIT && !have_tarpit) {
+		printk(KERN_WARNING PFX "Error: Cannot use --tarpit when "
+		       "TARPIT module not available\n");
+		return 0;
+	}
+	return 1;
+}
+
+static struct xt_target xt_chaos_info = {
+	.name       = "CHAOS",
+	.target     = xt_chaos_target,
+	.checkentry = xt_chaos_checkentry,
+	.table      = "filter",
+	.targetsize = sizeof(struct xt_chaos_info),
+	.hooks      = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
+	              (1 << NF_IP_LOCAL_OUT),
+	.family     = AF_INET,
+	.me         = THIS_MODULE,
+};
+
+static int __init xt_chaos_init(void)
+{
+	int ret = -EINVAL;
+
+	xm_tcp = xt_request_find_match(AF_INET, "tcp", 0);
+	if(xm_tcp == NULL) {
+		printk(KERN_WARNING PFX "Error: Could not find or load "
+		       "\"tcp\" match\n");
+		return -EINVAL;
+	}
+
+	xt_reject = xt_request_find_target(AF_INET, "REJECT", 0);
+	if(xt_reject == NULL) {
+		printk(KERN_WARNING PFX "Error: Could not find or load "
+		       "\"REJECT\" target\n");
+		goto out2;
+	}
+
+	xt_tarpit   = xt_request_find_target(AF_INET, "TARPIT", 0);
+	have_tarpit = xt_tarpit != NULL;
+	if(!have_tarpit)
+		printk(KERN_WARNING PFX "Warning: Could not find or load "
+		       "\"TARPIT\" target\n");
+
+	xt_delude   = xt_request_find_target(AF_INET, "DELUDE", 0);
+	have_delude = xt_delude != NULL;
+	if(!have_delude)
+		printk(KERN_WARNING PFX "Warning: Could not find or load "
+		       "\"DELUDE\" target\n");
+
+	if((ret = xt_register_target(&xt_chaos_info)) != 0) {
+		printk(KERN_WARNING PFX "xt_register_target returned "
+		       "error %d\n", ret);
+		goto out3;
+	}
+
+	return 0;
+
+ out3:
+ 	if(have_delude)
+ 		module_put(xt_delude->me);
+	if(have_tarpit)
+		module_put(xt_tarpit->me);
+	module_put(xt_reject->me);
+ out2:
+	module_put(xm_tcp->me);
+	return ret;
+}
+
+static void __exit xt_chaos_exit(void)
+{
+	xt_unregister_target(&xt_chaos_info);
+	module_put(xm_tcp->me);
+	module_put(xt_reject->me);
+	if(have_delude)
+		module_put(xt_delude->me);
+	if(have_tarpit)
+		module_put(xt_tarpit->me);
+	return;
+}
+
+module_init(xt_chaos_init);
+module_exit(xt_chaos_exit);
+MODULE_AUTHOR("Jan Engelhardt <jengelh@gmx.de>");
+MODULE_DESCRIPTION("netfilter CHAOS target");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("ipt_CHAOS");
Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
===================================================================
--- /dev/null
+++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
@@ -0,0 +1,259 @@
+/*
+	DELUDE target
+	Copyright © Jan Engelhardt <jengelh [at] gmx de>, 2007
+
+	Based upon linux-2.6.18.5/net/ipv4/netfilter/ipt_REJECT.c:
+	(C) 1999-2001 Paul `Rusty' Russell
+	(C) 2002-2004 Netfilter Core Team <coreteam@netfilter.org>
+
+	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/module.h>
+#include <linux/skbuff.h>
+#include <linux/ip.h>
+#include <linux/tcp.h>
+#include <linux/udp.h>
+#include <linux/icmp.h>
+#include <net/icmp.h>
+#include <net/ip.h>
+#include <net/tcp.h>
+#include <net/route.h>
+#include <net/dst.h>
+#include <linux/netfilter_ipv4/ip_tables.h>
+#ifdef CONFIG_BRIDGE_NETFILTER
+#	include <linux/netfilter_bridge.h>
+#endif
+#define PFX KBUILD_MODNAME ": "
+
+static inline struct rtable *route_reverse(struct sk_buff *skb,
+					   struct tcphdr *tcph, int hook)
+{
+	struct iphdr *iph = skb->nh.iph;
+	struct dst_entry *odst;
+	struct flowi fl = {};
+	struct rtable *rt;
+
+	/* We don't require ip forwarding to be enabled to be able to
+	 * send a RST reply for bridged traffic. */
+	if (hook != NF_IP_FORWARD
+#ifdef CONFIG_BRIDGE_NETFILTER
+	    || (skb->nf_bridge && skb->nf_bridge->mask & BRNF_BRIDGED)
+#endif
+	   ) {
+		fl.nl_u.ip4_u.daddr = iph->saddr;
+		if (hook == NF_IP_LOCAL_IN)
+			fl.nl_u.ip4_u.saddr = iph->daddr;
+		fl.nl_u.ip4_u.tos = RT_TOS(iph->tos);
+
+		if (ip_route_output_key(&rt, &fl) != 0)
+			return NULL;
+	} else {
+		/* non-local src, find valid iif to satisfy
+		 * rp-filter when calling ip_route_input. */
+		fl.nl_u.ip4_u.daddr = iph->daddr;
+		if (ip_route_output_key(&rt, &fl) != 0)
+			return NULL;
+
+		odst = skb->dst;
+		if (ip_route_input(skb, iph->saddr, iph->daddr,
+		                   RT_TOS(iph->tos), rt->u.dst.dev) != 0) {
+			dst_release(&rt->u.dst);
+			return NULL;
+		}
+		dst_release(&rt->u.dst);
+		rt = (struct rtable *)skb->dst;
+		skb->dst = odst;
+
+		fl.nl_u.ip4_u.daddr = iph->saddr;
+		fl.nl_u.ip4_u.saddr = iph->daddr;
+		fl.nl_u.ip4_u.tos = RT_TOS(iph->tos);
+	}
+
+	if (rt->u.dst.error) {
+		dst_release(&rt->u.dst);
+		return NULL;
+	}
+
+	fl.proto = IPPROTO_TCP;
+	fl.fl_ip_sport = tcph->dest;
+	fl.fl_ip_dport = tcph->source;
+
+	xfrm_lookup((struct dst_entry **)&rt, &fl, NULL, 0);
+
+	return rt;
+}
+
+static void send_reset(struct sk_buff *oldskb, int hook)
+{
+	struct sk_buff *nskb;
+	struct iphdr *iph = oldskb->nh.iph;
+	struct tcphdr _otcph, *oth, *tcph;
+	struct rtable *rt;
+	u_int16_t tmp_port;
+	u_int32_t tmp_addr;
+	int hh_len;
+
+	/* IP header checks: fragment. */
+	if (oldskb->nh.iph->frag_off & htons(IP_OFFSET))
+		return;
+
+	oth = skb_header_pointer(oldskb, oldskb->nh.iph->ihl * 4,
+				 sizeof(_otcph), &_otcph);
+	if (oth == NULL)
+ 		return;
+
+	/* DELUDE only answers SYN. */
+	if(!oth->syn || oth->ack || oth->fin || oth->rst)
+		return;
+
+	/* Check checksum */
+	if (nf_ip_checksum(oldskb, hook, iph->ihl * 4, IPPROTO_TCP))
+		return;
+
+	if ((rt = route_reverse(oldskb, oth, hook)) == NULL)
+		return;
+
+	hh_len = LL_RESERVED_SPACE(rt->u.dst.dev);
+
+	/* We need a linear, writeable skb.  We also need to expand
+	   headroom in case hh_len of incoming interface < hh_len of
+	   outgoing interface */
+	nskb = skb_copy_expand(oldskb, hh_len, skb_tailroom(oldskb),
+			       GFP_ATOMIC);
+	if (!nskb) {
+		dst_release(&rt->u.dst);
+		return;
+	}
+
+	dst_release(nskb->dst);
+	nskb->dst = &rt->u.dst;
+
+	/* This packet will not be the same as the other: clear nf fields */
+	nf_reset(nskb);
+	nskb->mark = 0;
+	skb_init_secmark(nskb);
+
+	skb_shinfo(nskb)->gso_size = 0;
+	skb_shinfo(nskb)->gso_segs = 0;
+	skb_shinfo(nskb)->gso_type = 0;
+
+	tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
+
+	/* Swap source and dest */
+	tmp_addr = nskb->nh.iph->saddr;
+	nskb->nh.iph->saddr = nskb->nh.iph->daddr;
+	nskb->nh.iph->daddr = tmp_addr;
+	tmp_port = tcph->source;
+	tcph->source = tcph->dest;
+	tcph->dest = tmp_port;
+
+	/* Truncate to length (no data) */
+	tcph->doff = sizeof(struct tcphdr)/4;
+	skb_trim(nskb, nskb->nh.iph->ihl*4 + sizeof(struct tcphdr));
+	nskb->nh.iph->tot_len = htons(nskb->len);
+
+	tcph->seq = oth->ack_seq;
+	tcph->ack_seq = 0;
+
+	/* Reset flags */
+	((u_int8_t *)tcph)[13] = 0;
+	tcph->syn = tcph->ack = 1;
+
+	tcph->window = 0;
+	tcph->urg_ptr = 0;
+
+	/* Adjust TCP checksum */
+	tcph->check = 0;
+	tcph->check = tcp_v4_check(sizeof(struct tcphdr),
+				   nskb->nh.iph->saddr,
+				   nskb->nh.iph->daddr,
+				   csum_partial((char *)tcph,
+						sizeof(struct tcphdr), 0));
+
+	/* Adjust IP TTL, DF */
+	nskb->nh.iph->ttl = dst_metric(nskb->dst, RTAX_HOPLIMIT);
+	/* Set DF, id = 0 */
+	nskb->nh.iph->frag_off = htons(IP_DF);
+	nskb->nh.iph->id = 0;
+
+	/* Adjust IP checksum */
+	nskb->nh.iph->check = 0;
+	nskb->nh.iph->check = ip_fast_csum((unsigned char *)nskb->nh.iph,
+					   nskb->nh.iph->ihl);
+
+	/* "Never happens" */
+	if (nskb->len > dst_mtu(nskb->dst))
+		goto free_nskb;
+
+	nf_ct_attach(nskb, oldskb);
+
+	NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, nskb, NULL, nskb->dst->dev,
+		dst_output);
+	return;
+
+ free_nskb:
+	kfree_skb(nskb);
+	return;
+}
+
+static unsigned int xt_delude_target(struct sk_buff **pskb,
+    const struct net_device *in, const struct net_device *out,
+    unsigned int hooknum, const struct xt_target *target, const void *targinfo
+#ifdef HAVE_TARGUSERINFO
+    ,
+    void *userinfo
+#endif
+    )
+{
+	/* WARNING: This code causes reentry within iptables.
+	   This means that the iptables jump stack is now crap.  We
+	   must return an absolute verdict. --RR */
+	send_reset(*pskb, hooknum);
+	return NF_DROP;
+}
+
+static int xt_delude_check(const char *tablename, const void *e_void,
+    const struct xt_target *target, void *targinfo,
+#ifdef HAVE_TARGINFOSIZE
+    unsigned int targinfosize,
+#endif
+    unsigned int hook_mask)
+{
+	if(hook_mask & ~((1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD))) {
+		printk(KERN_WARNING PFX "DELUDE may not be used in chains "
+		       "other than INPUT and FORWARD\n");
+		return 0;
+	}
+	return 1;
+}
+
+static struct xt_target xt_delude_info = {
+	.name       = "DELUDE",
+	.target     = xt_delude_target,
+	.checkentry = xt_delude_check,
+	.table      = "filter",
+	.hooks      = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
+	              (1 << NF_IP_LOCAL_OUT),
+	.proto      = IPPROTO_TCP,
+	.family     = AF_INET,
+	.me         = THIS_MODULE,
+};
+
+static int __init xt_delude_init(void)
+{
+	return xt_register_target(&xt_delude_info);
+}
+
+static void __exit xt_delude_exit(void)
+{
+	xt_unregister_target(&xt_delude_info);
+}
+
+module_init(xt_delude_init);
+module_exit(xt_delude_exit);
+MODULE_AUTHOR("Jan Engelhardt <jengelh@gmx.de>");
+MODULE_DESCRIPTION("netfilter DELUDE target");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("ipt_DELUDE");
Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
===================================================================
--- /dev/null
+++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c
@@ -0,0 +1,271 @@
+/*
+	portscan match for netfilter
+
+	Written by Jan Engelhardt, 2006 - 2007
+	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/in.h>
+#include <linux/ip.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/skbuff.h>
+#include <linux/stat.h>
+#include <linux/tcp.h>
+#include <linux/types.h>
+#include <linux/version.h>
+#include <linux/netfilter/x_tables.h>
+#include <linux/netfilter/xt_tcpudp.h>
+#include <linux/netfilter/xt_portscan.h>
+#include <net/netfilter/nf_nat_rule.h>
+#define PFX KBUILD_MODNAME ": "
+
+enum {
+	TCP_FLAGS_ALL3 = TCP_FLAG_FIN | TCP_FLAG_RST | TCP_FLAG_SYN,
+	TCP_FLAGS_ALL4 = TCP_FLAGS_ALL3 | TCP_FLAG_ACK,
+	TCP_FLAGS_ALL6 = TCP_FLAGS_ALL4 | TCP_FLAG_PSH | TCP_FLAG_URG,
+};
+
+/* Module parameters */
+static unsigned int
+	connmark_mask = ~0,
+	packet_mask   = ~0,
+	mark_seen     = 0x9,
+	mark_synrcv   = 0x1,
+	mark_closed   = 0x2,
+	mark_synscan  = 0x3,
+	mark_estab1   = 0x4,
+	mark_estab2   = 0x5,
+	mark_cnscan   = 0x6,
+	mark_grscan   = 0x7,
+	mark_valid    = 0x8;
+
+module_param(connmark_mask, uint, S_IRUGO | S_IWUSR);
+module_param(packet_mask,   uint, S_IRUGO | S_IWUSR);
+module_param(mark_seen,     uint, S_IRUGO | S_IWUSR);
+module_param(mark_synrcv,   uint, S_IRUGO | S_IWUSR);
+module_param(mark_closed,   uint, S_IRUGO | S_IWUSR);
+module_param(mark_synscan,  uint, S_IRUGO | S_IWUSR);
+module_param(mark_estab1,   uint, S_IRUGO | S_IWUSR);
+module_param(mark_estab2,   uint, S_IRUGO | S_IWUSR);
+module_param(mark_cnscan,   uint, S_IRUGO | S_IWUSR);
+module_param(mark_grscan,   uint, S_IRUGO | S_IWUSR);
+module_param(mark_valid,    uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(connmark_mask, "only set specified bits in connection mark");
+MODULE_PARM_DESC(packet_mask,   "only set specified bits in packet mark");
+MODULE_PARM_DESC(mark_seen,     "nfmark value for packet-seen state");
+MODULE_PARM_DESC(mark_synrcv,   "connmark value for SYN Received state");
+MODULE_PARM_DESC(mark_closed,   "connmark value for closed state");
+MODULE_PARM_DESC(mark_synscan,  "connmark value for SYN Scan state");
+MODULE_PARM_DESC(mark_estab1,   "connmark value for Established-1 state");
+MODULE_PARM_DESC(mark_estab2,   "connmark value for Established-2 state");
+MODULE_PARM_DESC(mark_cnscan,   "connmark value for Connect Scan state");
+MODULE_PARM_DESC(mark_grscan,   "connmark value for Grab Scan state");
+MODULE_PARM_DESC(mark_valid,    "connmark value for Valid state");
+
+/* TCP flag functions */
+static inline int tflg_ack4(const struct tcphdr *th)
+{
+	return (tcp_flag_word(th) & TCP_FLAGS_ALL4) == TCP_FLAG_ACK;
+}
+
+static inline int tflg_ack6(const struct tcphdr *th)
+{
+	return (tcp_flag_word(th) & TCP_FLAGS_ALL6) == TCP_FLAG_ACK;
+}
+
+static inline int tflg_fin(const struct tcphdr *th)
+{
+	return (tcp_flag_word(th) & TCP_FLAGS_ALL3) == TCP_FLAG_FIN;
+}
+
+static inline int tflg_rst(const struct tcphdr *th)
+{
+	return (tcp_flag_word(th) & TCP_FLAGS_ALL3) == TCP_FLAG_RST;
+}
+
+static inline int tflg_rstack(const struct tcphdr *th)
+{
+	return (tcp_flag_word(th) & TCP_FLAGS_ALL4) ==
+	       (TCP_FLAG_ACK | TCP_FLAG_RST);
+}
+
+static inline int tflg_syn(const struct tcphdr *th)
+{
+	return (tcp_flag_word(th) & TCP_FLAGS_ALL4) == TCP_FLAG_SYN;
+}
+
+static inline int tflg_synack(const struct tcphdr *th)
+{
+	return (tcp_flag_word(th) & TCP_FLAGS_ALL4) ==
+	       (TCP_FLAG_SYN | TCP_FLAG_ACK);
+}
+
+/* portscan functions */
+static inline int xt_portscan_stealth(const struct tcphdr *th)
+{
+	/*
+	 * "Connection refused" replies to our own probes must not be matched.
+	 */
+	if(tflg_rstack(th))
+		return 0;
+
+	if(tflg_rst(th) && printk_ratelimit()) {
+		printk(KERN_WARNING PFX "Warning: Pure RST received\n");
+		return 0;
+	}
+
+	/*
+	 * -p tcp ! --syn -m conntrack --ctstate INVALID: Looking for non-start
+	 * packets that are not associated with any connection -- this will
+	 * match most scan types (NULL, XMAS, FIN) and ridiculous flag
+	 * combinations (SYN-RST, SYN-FIN, SYN-FIN-RST, FIN-RST, etc.).
+	 */
+	return !tflg_syn(th);
+}
+
+static inline int xt_portscan_full(int mark, enum ip_conntrack_info ctstate,
+    int loopback, const struct tcphdr *tcph, int payload_len)
+{
+	if(mark == mark_estab2) {
+		/*
+		 * -m connmark --mark $ESTAB2
+		 */
+		if(tflg_ack4(tcph) && payload_len == 0)
+			return mark; /* keep mark */
+		else if(tflg_rst(tcph) || tflg_fin(tcph))
+			return mark_grscan;
+		else
+			return mark_valid;
+	} else if(mark == mark_estab1) {
+		/*
+		 * -m connmark --mark $ESTAB1
+		 */
+		if(tflg_rst(tcph) || tflg_fin(tcph))
+			return mark_cnscan;
+		else if(!loopback && tflg_ack4(tcph) && payload_len == 0)
+			return mark_estab2;
+		else
+			return mark_valid;
+	} else if(mark == mark_synrcv) {
+		/*
+		 * -m connmark --mark $SYN
+		 */
+		if(loopback && tflg_synack(tcph))
+			return mark; /* keep mark */
+		else if(loopback && tflg_rstack(tcph))
+			return mark_closed;
+		else if(tflg_ack6(tcph))
+			return mark_estab1;
+		else
+			return mark_synscan;
+	} else if(ctstate == IP_CT_NEW && tflg_syn(tcph)) {
+		/*
+		 * -p tcp --syn --ctstate NEW
+		 */
+		return mark_synrcv;
+	}
+	return mark;
+}
+
+static int xt_portscan_match(const struct sk_buff *skb,
+    const struct net_device *in, const struct net_device *out,
+    const struct xt_match *match, const void *matchinfo, int offset,
+    unsigned int protoff, int *hotdrop)
+{
+	const struct xt_portscan_info *info = matchinfo;
+	enum ip_conntrack_info ctstate;
+	struct ip_conntrack *ctdata;
+	const struct tcphdr *tcph;
+	struct tcphdr tcph_buf;
+
+	tcph = skb_header_pointer(skb, protoff, sizeof(tcph_buf), &tcph_buf);
+	if(tcph == NULL)
+		return 0;
+
+	/* Check for invalid packets: -m conntrack --ctstate INVALID */
+	if((ctdata = ip_conntrack_get(skb, &ctstate)) == NULL) {
+		if(info->match_stealth)
+			return xt_portscan_stealth(tcph);
+		/*
+		 * If @ctdata is NULL, we cannot match the other scan
+		 * types, return.
+		 */
+		return 0;
+	}
+
+	/*
+	 * If -m portscan was previously applied to this packet, the rules we
+	 * simulate must not be run through again. And for speedup, do not call
+	 * it either when the connection is already VALID.
+	 */
+	if((ctdata->mark & connmark_mask) == mark_valid ||
+	  (skb->mark & packet_mask) != mark_seen)
+	{
+		unsigned int n;
+		n = xt_portscan_full(ctdata->mark & connmark_mask, ctstate,
+		    in == &loopback_dev, tcph,
+		    skb->len - protoff - 4 * tcph->doff);
+
+		ctdata->mark = (ctdata->mark & ~connmark_mask) | n;
+		((struct sk_buff *)skb)->mark =
+			(skb->mark & ~packet_mask) | mark_seen;
+	}
+
+	return (info->match_syn && ctdata->mark == mark_synscan) ||
+	       (info->match_cn && ctdata->mark == mark_cnscan) ||
+	       (info->match_gr && ctdata->mark == mark_grscan);
+}
+
+static int xt_portscan_checkentry(const char *tablename, const void *entry,
+    const struct xt_match *match, void *matchinfo,
+#ifdef HAVE_MATCHINFOSIZE
+    unsigned int matchinfosize,
+#endif
+    unsigned int hook_mask)
+{
+	const struct xt_portscan_info *info = matchinfo;
+#ifdef HAVE_MATCHINFOSIZE
+	if(matchinfosize != XT_ALIGN(sizeof(struct xt_portscan_info))) {
+		printk(KERN_WARNING PFX "matchinfosize %u != %Zu\n",
+		       matchinfosize,
+		       XT_ALIGN(sizeof(struct xt_portscan_info)));
+		return 0;
+	}
+#endif
+	if((info->match_stealth & ~1) || (info->match_syn & ~1) ||
+	  (info->match_cn & ~1) || (info->match_gr & ~1)) {
+		printk(KERN_WARNING PFX "Invalid flags\n");
+		return 0;
+	}
+	return 1;
+}
+
+static struct xt_match xt_portscan = {
+	.name       = "portscan",
+	.match      = xt_portscan_match,
+	.checkentry = xt_portscan_checkentry,
+	.matchsize  = sizeof(struct xt_portscan_info),
+	.proto      = IPPROTO_TCP,
+	.family     = AF_INET,
+	.me         = THIS_MODULE,
+};
+
+static int __init xt_portscan_init(void)
+{
+	return xt_register_match(&xt_portscan);
+}
+
+static void __exit xt_portscan_exit(void)
+{
+	xt_unregister_match(&xt_portscan);
+	return;
+}
+
+module_init(xt_portscan_init);
+module_exit(xt_portscan_exit);
+MODULE_AUTHOR("Jan Engelhardt <jengelh@gmx.de>");
+MODULE_DESCRIPTION("netfilter portscan match module");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("ipt_portscan");
#<EOF>

Re: [PATCH] chaostables

[Patrick McHardy]

Jan Engelhardt wrote:

> Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
> ===================================================================
> --- /dev/null
> +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
> @@ -0,0 +1,184 @@
> +
> +static unsigned int xt_chaos_target(struct sk_buff **pskb,
> +    const struct net_device *in, const struct net_device *out,
> +    unsigned int hooknum, const struct xt_target *target, const void *targinfo)
> +{
> +	/* Equivalent to:
> +	 * -A chaos -m statistic --mode random --probability \
> +	 *         $reject_percentage -j REJECT --reject-with host-unreach;
> +	 * -A chaos -m statistic --mode random --probability \
> +	 *         $delude_percentage -j DELUDE;
> +	 * -A chaos -j DROP;
> +	 */

What does this do that can't be done by simply adding those individual
rules?

> +	const struct xt_chaos_info *info = targinfo;
> +
> +	if((unsigned int)net_random() <= reject_percentage)
> +		return xt_reject->target(pskb, in, out, hooknum, target,
> +		       &reject_params);
> +
> +	/* TARPIT/DELUDE may not be called from the OUTPUT chain */
> +	if((*pskb)->nh.iph->protocol == IPPROTO_TCP &&
> +	  info->variant != XTCHAOS_NORMAL && hooknum != NF_IP_LOCAL_OUT)
> +		xt_chaos_total(info, pskb, in, out, hooknum);
> +
> +	return NF_DROP;
> +}


> Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
> ===================================================================
> --- /dev/null
> +++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c

Looks like a copy of the REJECT target. What does it do,
why can't you use REJECT?

> Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
> ===================================================================
> --- /dev/null
> +++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c

We already have the psd match for years, but decided against merging
it.

Re: [PATCH] chaostables

[Alan Cox]

On Thu, 8 Mar 2007 07:35:05 +0100 (MET)
Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> Hello netfilter-devel,
> 
> 
> I would like to submit chaostables (v0.5_svn23) for inclusion. Primary 
> use is to detect, spoof and slowdown various sorts of port scans.
> Implementation details can be found at http://jengelh.hopto.org/p/chaostables/


Any chance of tweaking the name - it's just there is/was a chaosnet
protocol/network system and you don't want people to assume that since
its a chaosfilter its for chaosnet  ?

Re: [PATCH] chaostables

[James Morris]

On Thu, 8 Mar 2007, Alan Cox wrote:

> Any chance of tweaking the name - it's just there is/was a chaosnet
> protocol/network system and you don't want people to assume that since
> its a chaosfilter its for chaosnet  ?

That's exactly what I thought it was from the subject line.


- James
-- 
James Morris
<jmorris@namei.org>

Re: [PATCH] chaostables

[Jan Engelhardt]

(I suspect a mailserver issue on my side, since I did not receive the 
replies from Alan or Patrick. But lkml.org has them, so I will be 
replying to both them there.)

On Mar 8 2007 09:55, James Morris wrote:
>On Thu, 8 Mar 2007, Alan Cox wrote:
>
>> Any chance of tweaking the name - it's just there is/was a chaosnet 
>> protocol/network system and you don't want people to assume that 
>> since its a chaosfilter its for chaosnet ?
>
>That's exactly what I thought it was from the subject line.

Suggest something. (And then convince everyone who already set 
chaostables in stone to use the new name, namely search engines, 
bloggers, LWN, openwrt.) I don't think anyone seriously uses chaosnet 
nowadays. And just because there is a "quicktables" project does not 
mean there is a quick protocol filter.

Also note that the word 'chaostables' does not even appear in the patch, 
though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
can safely assume that CHAOS does what it says - make fun of nmap.


>> Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>> @@ -0,0 +1,184 @@
>> +
>> +static unsigned int xt_chaos_target(struct sk_buff **pskb,
>> +    const struct net_device *in, const struct net_device *out,
>> +    unsigned int hooknum, const struct xt_target *target, const void *targinfo)
>> +{
>> +	/* Equivalent to:
>> +	 * -A chaos -m statistic --mode random --probability \
>> +	 *         $reject_percentage -j REJECT --reject-with host-unreach;
>> +	 * -A chaos -m statistic --mode random --probability \
>> +	 *         $delude_percentage -j DELUDE;
>> +	 * -A chaos -j DROP;
>> +	 */
>
>What does this do that can't be done by simply adding those individual 
>rules?

It "wraps it all up", reducing the overall number of rules and user 
chains required in the filtering tables to implement the wanted logic. 
Reducing the number of filtering rules also reduces the time process a 
packet. These two are, in my opinion, a good thing.

Take xt_portscan as an example, which would require a minimum of 23 
filtering rules (which cannot reproduce the module's action in its 
fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
a single packet, repeatedly checking for "-p tcp", i.e. calling into 
xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
are never examined in xt_portscan.


>> Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>
>Looks like a copy of the REJECT target. What does it do,
>why can't you use REJECT?

Looking only at TCP,
REJECT sends a RST for any packet (if requested), or ICMP otherwise.
DELUDE sends a SYN-ACK on SYN, otherwise RST.
(And TARPIT, for reference, keeps the connection open anytime. Its code
is also quite a replication of REJECT.)

If you think it is better to merge the respond-with-SYNACK into REJECT 
rather than having DELUDE, say so.


>> Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c
>
>We already have the psd match for years, but decided against merging it.

On what basis? As far as I flew over psd's code, it uses a heuristic 
like "how often did that client recently connect" for match decision. 
(P2P clients randomly port knocking, anyone?) I would not think of that 
as a reliable way to tell portscans either. However, half-open TCP 
connect for example is a more clear action to define a portscan.



Jan
-- 

Re: [PATCH] chaostables

[Jan Engelhardt]

(I suspect a mailserver issue on my side, since I did not receive the 
replies from Alan or Patrick. But lkml.org has them, so I will be 
replying to both them there.)

On Mar 8 2007 09:55, James Morris wrote:
>On Thu, 8 Mar 2007, Alan Cox wrote:
>
>> Any chance of tweaking the name - it's just there is/was a chaosnet 
>> protocol/network system and you don't want people to assume that 
>> since its a chaosfilter its for chaosnet ?
>
>That's exactly what I thought it was from the subject line.

Suggest something. (And then convince everyone who already set 
chaostables in stone to use the new name, namely search engines, 
bloggers, LWN, openwrt.) I don't think anyone seriously uses chaosnet 
nowadays. And just because there is a "quicktables" project does not 
mean there is a quick protocol filter.

Also note that the word 'chaostables' does not even appear in the patch, 
though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
can safely assume that CHAOS does what it says - make fun of nmap.


>> Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>> @@ -0,0 +1,184 @@
>> +
>> +static unsigned int xt_chaos_target(struct sk_buff **pskb,
>> +    const struct net_device *in, const struct net_device *out,
>> +    unsigned int hooknum, const struct xt_target *target, const void *targinfo)
>> +{
>> +	/* Equivalent to:
>> +	 * -A chaos -m statistic --mode random --probability \
>> +	 *         $reject_percentage -j REJECT --reject-with host-unreach;
>> +	 * -A chaos -m statistic --mode random --probability \
>> +	 *         $delude_percentage -j DELUDE;
>> +	 * -A chaos -j DROP;
>> +	 */
>
>What does this do that can't be done by simply adding those individual 
>rules?

It "wraps it all up", reducing the overall number of rules and user 
chains required in the filtering tables to implement the wanted logic. 
Reducing the number of filtering rules also reduces the time process a 
packet. These two are, in my opinion, a good thing.

Take xt_portscan as an example, which would require a minimum of 23 
filtering rules (which cannot reproduce the module's action in its 
fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
a single packet, repeatedly checking for "-p tcp", i.e. calling into 
xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
are never examined in xt_portscan.


>> Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>
>Looks like a copy of the REJECT target. What does it do,
>why can't you use REJECT?

Looking only at TCP,
REJECT sends a RST for any packet (if requested), or ICMP otherwise.
DELUDE sends a SYN-ACK on SYN, otherwise RST.
(And TARPIT, for reference, keeps the connection open anytime. Its code
is also quite a replication of REJECT.)

If you think it is better to merge the respond-with-SYNACK into REJECT 
rather than having DELUDE, say so.


>> Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c
>
>We already have the psd match for years, but decided against merging it.

On what basis? As far as I flew over psd's code, it uses a heuristic 
like "how often did that client recently connect" for match decision. 
(P2P clients randomly port knocking, anyone?) I would not think of that 
as a reliable way to tell portscans either. However, half-open TCP 
connect for example is a more clear action to define a portscan.



Jan
-- 

Re: [PATCH] chaostables

[Patrick McHardy]

Jan Engelhardt wrote:
>>>Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>>>+	/* Equivalent to:
>>>+	 * -A chaos -m statistic --mode random --probability \
>>>+	 *         $reject_percentage -j REJECT --reject-with host-unreach;
>>>+	 * -A chaos -m statistic --mode random --probability \
>>>+	 *         $delude_percentage -j DELUDE;
>>>+	 * -A chaos -j DROP;
>>>+	 */
>>
>>What does this do that can't be done by simply adding those individual 
>>rules?
> 
> 
> It "wraps it all up", reducing the overall number of rules and user 
> chains required in the filtering tables to implement the wanted logic. 
> Reducing the number of filtering rules also reduces the time process a 
> packet. These two are, in my opinion, a good thing.


By that argument we could just codify every ruleset and put it in the
kernel. Its three simple rules. There is no chance I'm going to take
this part.

> Take xt_portscan as an example, which would require a minimum of 23 
> filtering rules (which cannot reproduce the module's action in its 
> fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
> a single packet, repeatedly checking for "-p tcp", i.e. calling into 
> xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
> are never examined in xt_portscan.


I'm guessing xt_portscan tries to detect and match on portscans, but
its not obvious why it looks at and changes skb->mark and nfct->ctmark,
so I suggest you start by explaining what it really does.

>>>+++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>>
>>Looks like a copy of the REJECT target. What does it do,
>>why can't you use REJECT?
> 
> 
> Looking only at TCP,
> REJECT sends a RST for any packet (if requested), or ICMP otherwise.
> DELUDE sends a SYN-ACK on SYN, otherwise RST.
> (And TARPIT, for reference, keeps the connection open anytime. Its code
> is also quite a replication of REJECT.)
> 
> If you think it is better to merge the respond-with-SYNACK into REJECT 
> rather than having DELUDE, say so.


I'd rather not add hacks to mildly annoy people anywhere.

>>We already have the psd match for years, but decided against merging it.
> 
> 
> On what basis? As far as I flew over psd's code, it uses a heuristic 
> like "how often did that client recently connect" for match decision. 
> (P2P clients randomly port knocking, anyone?) I would not think of that 
> as a reliable way to tell portscans either. However, half-open TCP 
> connect for example is a more clear action to define a portscan.


The question is what we gain by being able to detect portscans.
So far my opinion is thats its close to nothing. Besides that,
it should be possible to do this by using the recent match.

Re: [PATCH] chaostables

[Patrick McHardy]

Jan Engelhardt wrote:
>>>Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>>>+	/* Equivalent to:
>>>+	 * -A chaos -m statistic --mode random --probability \
>>>+	 *         $reject_percentage -j REJECT --reject-with host-unreach;
>>>+	 * -A chaos -m statistic --mode random --probability \
>>>+	 *         $delude_percentage -j DELUDE;
>>>+	 * -A chaos -j DROP;
>>>+	 */
>>
>>What does this do that can't be done by simply adding those individual 
>>rules?
> 
> 
> It "wraps it all up", reducing the overall number of rules and user 
> chains required in the filtering tables to implement the wanted logic. 
> Reducing the number of filtering rules also reduces the time process a 
> packet. These two are, in my opinion, a good thing.


By that argument we could just codify every ruleset and put it in the
kernel. Its three simple rules. There is no chance I'm going to take
this part.

> Take xt_portscan as an example, which would require a minimum of 23 
> filtering rules (which cannot reproduce the module's action in its 
> fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
> a single packet, repeatedly checking for "-p tcp", i.e. calling into 
> xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
> are never examined in xt_portscan.


I'm guessing xt_portscan tries to detect and match on portscans, but
its not obvious why it looks at and changes skb->mark and nfct->ctmark,
so I suggest you start by explaining what it really does.

>>>+++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>>
>>Looks like a copy of the REJECT target. What does it do,
>>why can't you use REJECT?
> 
> 
> Looking only at TCP,
> REJECT sends a RST for any packet (if requested), or ICMP otherwise.
> DELUDE sends a SYN-ACK on SYN, otherwise RST.
> (And TARPIT, for reference, keeps the connection open anytime. Its code
> is also quite a replication of REJECT.)
> 
> If you think it is better to merge the respond-with-SYNACK into REJECT 
> rather than having DELUDE, say so.


I'd rather not add hacks to mildly annoy people anywhere.

>>We already have the psd match for years, but decided against merging it.
> 
> 
> On what basis? As far as I flew over psd's code, it uses a heuristic 
> like "how often did that client recently connect" for match decision. 
> (P2P clients randomly port knocking, anyone?) I would not think of that 
> as a reliable way to tell portscans either. However, half-open TCP 
> connect for example is a more clear action to define a portscan.


The question is what we gain by being able to detect portscans.
So far my opinion is thats its close to nothing. Besides that,
it should be possible to do this by using the recent match.

Re: [PATCH] chaostables

[Alan Cox]

> Also note that the word 'chaostables' does not even appear in the patch, 
> though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
> can safely assume that CHAOS does what it says - make fun of nmap.

"entropy" ?
"randomness"

Re: [PATCH] chaostables

[Alan Cox]

> Also note that the word 'chaostables' does not even appear in the patch, 
> though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
> can safely assume that CHAOS does what it says - make fun of nmap.

"entropy" ?
"randomness"

Re: [PATCH] chaostables

[Jan Engelhardt]

On Mar 8 2007 18:15, Patrick McHardy wrote:
>
>> Take xt_portscan as an example, which would require a minimum of 23 
>> filtering rules (which cannot reproduce the module's action in its 
>> fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
>> a single packet, repeatedly checking for "-p tcp", i.e. calling into 
>> xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
>> are never examined in xt_portscan.
>
>
>I'm guessing xt_portscan tries to detect and match on portscans, but
>its not obvious why it looks at and changes skb->mark and nfct->ctmark,
>so I suggest you start by explaining what it really does.

xt_portscan needs to keep track of what packets the machine has already 
seen. So on the first SYN, the connection is marked with "1". (Then we 
send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
packet that is received will be an ACK or an RST. But it must come 
_exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
state which can be remembered is required. For that, an automaton is 
used, whose state is saved in the connection mark.

If you would like to find out more about the implementation, please have 
a look at http://jengelh.hopto.org/p/chaostables/fw.html section 3, 4, 
and perhaps 5.

As for the packet mark, refer to section 6. But for you: xt_portscan 
consists of "two" parts, one is "detect-and-mark" and the other is 
"match it". To have the following do the right thing

  -m portscan --cnscan  -j LOG --log-prefix "[evil user] "
  -m portscan --stealth -j LOG --log-prefix "[hideous evil user] "

the "detect-and-mark" code _must_ (in its common RFC meaning) only be 
executed once per packet.


>>>We already have the psd match for years, but decided against merging it.
>> 
>> On what basis? As far as I flew over psd's code, it uses a heuristic 
>> like "how often did that client recently connect" for match decision. 
>> (P2P clients randomly port knocking, anyone?) I would not think of that 
>> as a reliable way to tell portscans either. However, half-open TCP 
>> connect for example is a more clear action to define a portscan.
>
>The question is what we gain by being able to detect portscans.

You have a point with that. But then we could argue on hours about what 
we gain with life.

>So far my opinion is thats its close to nothing. Besides that,
>it should be possible to do this by using the recent match.

Perhaps. I'll just provide this little example of what is good for to 
check for portscans:

  -N block_it
  -A block_it -m recent --name block_it --update --seconds 60;

  -A INPUT -m portscan --cnscan -j block_it;
  -A INPUT -m recent --name block_it --rcheck -j DROP;

that is, to drop everything from evil hosts doing half-open scans for 
some time.

[ Ok, I used "recent", now I don't get what you meant by "Besides that,
  it should be possible to do this by using the recent match." -
  recent alone does not check for half-opens, nor connect-scans. It 
  checks for recentness of anything. I hope you can clarify. ]



Thank you,
Jan
-- 

Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,

On Thu, 08 Mar 2007 18:15:12 +0100, Patrick McHardy wrote:
>>>>Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>>>>+	/* Equivalent to:
>>>>+	 * -A chaos -m statistic --mode random --probability \
>>>>+	 *         $reject_percentage -j REJECT --reject-with host-unreach;
>>>>+	 * -A chaos -m statistic --mode random --probability \
>>>>+	 *         $delude_percentage -j DELUDE;
[2nd one should have had -p tcp]
>>>>+	 * -A chaos -j DROP;
>>>>+	 */
>>>
>>>What does this do that can't be done by simply adding those individual 
>>>rules?
>>
>>It "wraps it all up", reducing the overall number of rules and user 
>>chains required in the filtering tables to implement the wanted logic. 
>>Reducing the number of filtering rules also reduces the time process a 
>>packet. These two are, in my opinion, a good thing.
>
>By that argument we could just codify every ruleset and put it in the
>kernel. Its three simple rules. There is no chance I'm going to take
>this part.

While that is indeed true, I think users will have a judgement (perhaps 
call it "first impression") that puts a certain set of NF rules into 
either of the two categories "this is fundamental/generic enough to 
warrant its own module" and "this does not". While

  -A INPUT -s 134.76.0.0/16 -p tcp --dport 22 -j ACCEPT;
  -A INPUT -p tcp --dport 80 -j ACCEPT;
  -A INPUT -j REJECT;

is clearly something that only applies to one machine only, perhaps a
little subnet, or at best, the servers on the company network, it is not
"for everyone". xt_CHAOS on the other hand was meant - if you want so - as
a replacement for DROP/REJECT and the default policy, e.g.:

	# Block all evil, even if from inside the house.
		-A INPUT -m evil -j CHAOS;
	# Ignore stray packets not directed at us
		-A INPUT -d mybase -m this -j ACCEPT;
	# Management console
		-A INPUT -s yourbase -m that -j ACCEPT;
	# Chain policy (instead, or supplemental to, -P INPUT DROP)
		-A INPUT -j CHAOS;

(-m evil, -m this and -m that are placeholders and are not seriously
considered to get their own kernel module anytime.)

For me, this falls under generic-enough, but your (and other people's) mileage
migt vary.


Thank you for the comments,

Jan

Re: [PATCH] chaostables

[jimmy]

Alan Cox wrote:
>> Also note that the word 'chaostables' does not even appear in the patch, 
>> though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
>> can safely assume that CHAOS does what it says - make fun of nmap.
> 
> "entropy" ?
> "randomness"

fuzztables?

:-)

Re: [PATCH] chaostables

[Amin Azez]

* Jan Engelhardt wrote, On 08/03/07 20:26:
> xt_portscan needs to keep track of what packets the machine has already 
> seen. So on the first SYN, the connection is marked with "1". (Then we 
> send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
> packet that is received will be an ACK or an RST. But it must come 
> _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
> state which can be remembered is required. For that, an automaton is 
> used, whose state is saved in the connection mark.

There would me more point in having this as a new match if it didn't
trample on the connection mark, but used it's own slot or flag-bit.

Sam

Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,

On Mar 9 2007 09:35, Amin Azez wrote:
>* Jan Engelhardt wrote, On 08/03/07 20:26:
>> xt_portscan needs to keep track of what packets the machine has already 
>> seen. So on the first SYN, the connection is marked with "1". (Then we 
>> send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
>> packet that is received will be an ACK or an RST. But it must come 
>> _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
>> state which can be remembered is required. For that, an automaton is 
>> used, whose state is saved in the connection mark.
>
>There would me more point in having this as a new match if it didn't
>trample on the connection mark, but used it's own slot or flag-bit.

Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct would
increase the struct sizes, and that would penalize users who do not intend
to use xt_portscan.

I do not see why the packet/connection marks should not be used to record
additional information. After all, that is what users use marks for.
xt_portscan can be precisely configured how to set its marks (mask is
supported), so that it only takes away 4 bits of the 32-bit connection
mark and 1 bit of the 32-bit packet mark.

Almost never I required connection marking myself except for this
portscanning automaton and perhaps a little MARK here and there for
finely-tuned SNAT. Again, things might look different on your side(s).
QoS, while primarily using CLASSIFY, is one point where MARK can be used.
I would assume that those who use xt_portscan should be fine with the
remaining 24 bits.


Thank you,

Jan
-- 

Re: [PATCH] chaostables

[Amin Azez]

* Jan Engelhardt wrote, On 09/03/07 10:19:
> Hello,
>
> On Mar 9 2007 09:35, Amin Azez wrote:
>   
>> * Jan Engelhardt wrote, On 08/03/07 20:26:
>>     
>>> xt_portscan needs to keep track of what packets the machine has already 
>>> seen. So on the first SYN, the connection is marked with "1". (Then we 
>>> send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
>>> packet that is received will be an ACK or an RST. But it must come 
>>> _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
>>> state which can be remembered is required. For that, an automaton is 
>>> used, whose state is saved in the connection mark.
>>>       
>> There would me more point in having this as a new match if it didn't
>> trample on the connection mark, but used it's own slot or flag-bit.
>>     
For the record, I support inclusion of this extension in general.
It is true to say "but a netfilter guru could craft together a sequence
of mark-consuming rules to do something somewhat similar" the same is
also somewhat true for connlimit (packet limits) and so on. The point of
this match is that people don't have to.
> Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct would
> increase the struct sizes, and that would penalize users who do not intend
> to use xt_portscan.
>   
I understand what you say but it sounds a bit like saying: "but we
didn't make it very good because so few people would use it anyway"
which of course makes it even less attractive. I realise you have your
own interpretation but this is how it reads to me.
> I do not see why the packet/connection marks should not be used to record
> additional information
...
> Almost never I required connection marking myself 
I guessed as much. I use it heavily, with my xml rule generators.
> except for this
> portscanning automaton and perhaps a little MARK here and there for
> finely-tuned SNAT. Again, things might look different on your side(s).
>   
There's too many things fighting over the same few bits of the mark, and
in your case you are using it to track internal state of a connection
that has no relevance to the rest of the iptables/ebtables rules.

I'm suggesting that some of the people who would want to use the chaos
match, won't because of the mark issue.

This is not a new problem.

http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217
> From: Tom Eastep <teastep <at> shorewall.net>
> Subject: Re: RFC: Disable defered bridge hooks by default
<http://news.gmane.org/find-root.php?message_id=%3c44AEFE20.3020307%40shorewall.net%3e>

>
> Once again, netfilter marks are the solution of last resort. This is
> becoming very painful for those of us who produce general Netfilter
> configuration tools. The situation is exacerbated by the fact that
> ebtables doesn't support modifying the mark value via logical AND/OR and
> the other fwmark consumers (tc, ip) don't allow a mask when testing the
> fwmark value.

I suggested one solution
http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16244

and Patrick McHardy has suggested using ct_extend.

I've not looked into this further because I'm too busy doing xml
versions of iptables, ebtables, iproute anc tc.

[There's an ip route<->xml at:
http://mailman.ds9a.nl/pipermail/lartc/2007q1/020376.html
iptables now has xml<-> convertor ]

Sam

Re: [PATCH] chaostables

[Petr Tesařík]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

jimmy píše v Pá 09. 03. 2007 v 13:37 +0530:
> Alan Cox wrote:
> >> Also note that the word 'chaostables' does not even appear in the patch, 
> >> though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
> >> can safely assume that CHAOS does what it says - make fun of nmap.
> > 
> > "entropy" ?
> > "randomness"
> 
> fuzztables?

confuztables!

Petr

[-- Attachment #2: Toto je digitálně podepsaná část zprávy --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,


On Mar 9 2007 11:54, Amin Azez wrote:
>> Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct
>> would increase the struct sizes, and that would penalize users who do
>> not intend to use xt_portscan.
>
>I understand what you say but it sounds a bit like saying: "but we didn't
>make it very good because so few people would use it anyway" which of
>course makes it even less attractive. I realise you have your own
>interpretation but this is how it reads to me.

I just gave the reason why I designed it the way it is now. If you 
really feel it needs to be changed, well, I don't really object to that. 
chaostables has only seen like.. 1 1/2 version announcements (urls to 
tarballs, no patches) to mailing lists, and except for the few users who 
definitely tried it (based on questions I received), there have not been 
any suggestions for changes yet, which either tells me that nobody is 
interested or everything is fine.

>> I do not see why the packet/connection marks should not be used to record
>> additional information
>...
>> Almost never I required connection marking myself 
>I guessed as much. I use it heavily, with my xml rule generators.
>> except for this
>> portscanning automaton and perhaps a little MARK here and there for
>> finely-tuned SNAT. Again, things might look different on your side(s).
>
>There's too many things fighting over the same few bits of the mark, and
>in your case you are using it to track internal state of a connection
>that has no relevance to the rest of the iptables/ebtables rules.
>
>I'm suggesting that some of the people who would want to use the chaos
>match, won't because of the mark issue.
>
>This is not a new problem.
>
>http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217

	"""netfilter marks are the solution of last resort. This is
	becoming very painful for those of us who produce general
	Netfilter configuration tools.""" -Toam Eastep

I see. Thank you for the link. I think you are on the way to have me 
convinced.



Jan
-- 

Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,


On Mar 9 2007 11:54, Amin Azez wrote:
>> Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct
>> would increase the struct sizes, and that would penalize users who do
>> not intend to use xt_portscan.
>
>I understand what you say but it sounds a bit like saying: "but we didn't
>make it very good because so few people would use it anyway" which of
>course makes it even less attractive. I realise you have your own
>interpretation but this is how it reads to me.

I just gave the reason why I designed it the way it is now. If you 
really feel it needs to be changed, well, I don't really object to that. 
chaostables has only seen like.. 1 1/2 version announcements (urls to 
tarballs, no patches) to mailing lists, and except for the few users who 
definitely tried it (based on questions I received), there have not been 
any suggestions for changes yet, which either tells me that nobody is 
interested or everything is fine.

>> I do not see why the packet/connection marks should not be used to record
>> additional information
>...
>> Almost never I required connection marking myself 
>I guessed as much. I use it heavily, with my xml rule generators.
>> except for this
>> portscanning automaton and perhaps a little MARK here and there for
>> finely-tuned SNAT. Again, things might look different on your side(s).
>
>There's too many things fighting over the same few bits of the mark, and
>in your case you are using it to track internal state of a connection
>that has no relevance to the rest of the iptables/ebtables rules.
>
>I'm suggesting that some of the people who would want to use the chaos
>match, won't because of the mark issue.
>
>This is not a new problem.
>
>http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217

	"""netfilter marks are the solution of last resort. This is
	becoming very painful for those of us who produce general
	Netfilter configuration tools.""" -Toam Eastep

I see. Thank you for the link. I think you are on the way to have me 
convinced.



Jan
--