Adding features to xt_recent and xt_cluster

Adding features to xt_recent and xt_cluster

[Karl Heiss]

I am looking into adding functionality to the xt_recent and xt_cluster
modules.  I would like to know if these changes would be something
that upstream would be interested in using.

For the xt_recent module, I will be updating the module to support
matching by destination IP, source-port and destination port.  Port
matching would be supported via the '--rsport' and '--rdport' flags,
and would default to the current behavior of matching IP only if
neither is specified.  Many might be wondering why I choose to include
matching by destination IP since it appears that xt_recent matches
destinations using --rdest.  However, xt_recent does not appear to
differentiate between source and destination addresses within it's
entry tables.  This means it never checks it's stored address against
skb->network_header->daddr during match.  See excerpt below from
net/netfilter/xt_recent.c:

static struct recent_entry *
recent_entry_lookup(const struct recent_table *table,
		    const union nf_inet_addr *addrp, u_int16_t family,
		    u_int8_t ttl)
{
	struct recent_entry *e;
	unsigned int h;

	if (family == NFPROTO_IPV4)
		h = recent_entry_hash4(addrp);
	else
		h = recent_entry_hash6(addrp);

	list_for_each_entry(e, &table->iphash[h], list)
		if (e->family == family &&
		    memcmp(&e->addr, addrp, sizeof(e->addr)) == 0 &&
		    (ttl == e->ttl || ttl == 0 || e->ttl == 0))
			return e;
	return NULL;
}


As for xt_cluster, I will be adding options for hashmode like those
offered by CLUSTERIP to allow matching based on sourceip,
sourceip-sourceport, or sourceip-sourceport-destport.  There is the
potential that I could add a fourth sourceip-destport option as well.

For both modules I am prepared to provide patches for both the kernel
and iptables userland after development is complete.   Any feedback is
greatly appreciated and please excuse any faux pas on my part as I am
new.

Karl Heiss

Re: Adding features to xt_recent and xt_cluster

[Jan Engelhardt]

On Wednesday 2011-06-08 16:57, Karl Heiss wrote:
>
>For the xt_recent module, I will be updating the module to support
>matching by destination IP, source-port and destination port. Port
>matching would be supported via the '--rsport' and '--rdport' flags,
>and would default to the current behavior of matching IP only if
>neither is specified.
>
>Many might be wondering why I choose to include matching by
>destination IP since it appears that xt_recent matches destinations
>using --rdest. However, xt_recent does not appear to differentiate
>between source and destination addresses within it's entry tables.

You could use two separate tables, which has the same effect as
storing entries with a unique key of <saddr-or-daddr-bit, addr>
in a single table, unless I missed something.

Re: Adding features to xt_recent and xt_cluster

[Karl Heiss]

On Wed, Jun 8, 2011 at 4:08 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Wednesday 2011-06-08 16:57, Karl Heiss wrote:
>>
>>For the xt_recent module, I will be updating the module to support
>>matching by destination IP, source-port and destination port. Port
>>matching would be supported via the '--rsport' and '--rdport' flags,
>>and would default to the current behavior of matching IP only if
>>neither is specified.
>>
>>Many might be wondering why I choose to include matching by
>>destination IP since it appears that xt_recent matches destinations
>>using --rdest. However, xt_recent does not appear to differentiate
>>between source and destination addresses within it's entry tables.
>
> You could use two separate tables, which has the same effect as
> storing entries with a unique key of <saddr-or-daddr-bit, addr>
> in a single table, unless I missed something.
>

I assume you mean something like this:

iptables -A INPUT -p tcp --dport 23 -m recent --rcheck --seconds 30 -j DROP
iptables -A INPUT -p tcp --dport 23 -m recent --set -j DROP

The problem is, unless you have a deterministic (from the view of
iptables) rule to match when you '--set', you cannot accurately match
a recent entry.  For instance, the rules below would not allow you to
deterministically know which sourceip-sourceport combination would
match which recent table name (clust1 or clust2).


iptables -A FORWARD -m recent --name clust1 --update -j clust1-chain
iptables -A FORWARD -m recent --name clust2 --update -j clust2-chain

iptables -A clust1-chain -m recent --name clust1 --set -j CLUSTERIP
--new --clustermac 01:00:5e:00:00:20 --total-nodes 2 --local-node 1
--hashmode sourceip-sourceport
iptables -A clust2-chain -m recent --name clust2 --set -j CLUSTERIP
--new --clustermac 01:00:5e:00:00:20 --total-nodes 2 --local-node 2
--hashmode sourceip-sourceport


In this case, I see no other way around this issue other than to store
the source port within the recent table.

PS.  After taking a second look at the code, I realized I stuck my
foot in my mouth about xt_recent not differentiating between saddr and
daddr.  It does indeed differentiate by choosing the correct address
from the incoming packet to match against the entry IPs.

Re: Adding features to xt_recent and xt_cluster

[Jan Engelhardt]

On Thursday 2011-06-09 14:29, Karl Heiss wrote:
>> You could use two separate tables, which has the same effect as
>> storing entries with a unique key of <saddr-or-daddr-bit, addr>
>> in a single table, unless I missed something.
>
>I assume you mean something like this:
>
>iptables -A INPUT -p tcp --dport 23 -m recent --rcheck --seconds 30 -j DROP
>iptables -A INPUT -p tcp --dport 23 -m recent --set -j DROP

I mean:

-A foo -p tcp [plus other conds] -m recent --name by-srcip --rsource --set
-A foo -p tcp [other conds] -m recent --name by-dstip --rdest --set
-A bar -p tcp -m recent --name by-srcip --rsource --rcheck
-A baz -p tcp -m recent --name by-dstip --rdest --rcheck

>PS.  After taking a second look at the code, I realized I stuck my
>foot in my mouth about xt_recent not differentiating between saddr and
>daddr.  It does indeed differentiate by choosing the correct address
>from the incoming packet to match against the entry IPs.