All of lore.kernel.org
 help / color / mirror / Atom feed
From: Samuel <sj-netfilter@cookinglinux.org>
To: netfilter-devel@lists.netfilter.org
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Nicolas Bouliane <nib@cookinglinux.org>
Subject: [testsuite] ipt_recent
Date: Thu, 30 Dec 2004 01:16:26 -0500	[thread overview]
Message-ID: <41D39D3A.8050308@cookinglinux.org> (raw)

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

Hi rusty,

Here's the testcase for the ipt_recent module.

Note that it really doesn't behave like I think it should.

Cheers,

--peejix

[-- Attachment #2: 40ipt_recent.sh --]
[-- Type: text/plain, Size: 6990 bytes --]

#! /bin/sh
{

##
# Test #1: Incoming packets with differents source addresses
# For each source ip .2, .3 & .4; throw 10 packets.
# Increase kernel time after all nth packets are sent.
# Do NOT increase time for fifth packet so we burst the balloon
# So get NF_DROP'ed on 5th packet in a 1hit/1sec ratio.
# 
# Also test invert behaviour.

for p in '' '! '; do # Test normal and then negated rule
	echo iptables -I INPUT -m recent --name testcase --rsource \
		--hitcount 1 --seconds 1 ${p}--update -j DROP
	echo iptables -A INPUT -m recent --name testcase --set --rsource -j ACCEPT

	for pkt in 1 2 3 4 5 6 7 8 9 10; do # The 10 packets we send
		for h in 2 3 4; do # From each of 192.168.0.2, .3 & .4
			if [ ! "$pkt" -eq "5" ]; then

			[ -z $p ] && verdict=NF_ACCEPT || verdict=NF_DROP

			# Fifth packet triggers the 1:1 ratio.
			else
			# Negation doesn't behave as it should..
			#[ -z $p ] && verdict=NF_DROP || verdict=NF_ACCEPT
			# FIXME: This doesn't make much sense...
			# It always match so expect NF_DROP.
			verdict=NF_DROP
			fi

			echo expect gen_ip hook:NF_IP_LOCAL_IN iptable_filter $verdict '*'
			echo gen_ip IF=eth0 192.168.0.$h 192.168.0.1 0 17 1 2
		done

		# Increasing by one triggers the 1:1 ratio, use 2.
		[ ! "$pkt" -eq "4" ] && echo time +2
	done
	
	echo iptables -D INPUT -m recent --name testcase --rsource \
		--hitcount 1 --seconds 1 ${p}--update -j DROP
	echo iptables -D INPUT -m recent --name testcase --set --rsource -j ACCEPT
done

##
# Test #2: Forwarded packets with differents destination addresses
# For each destination ip .2, .3 & .4; throw 10 packets.
# Increase kernel time after all nth packets are sent.
# Do NOT increase time for fifth packet so we burst the balloon
# So get NF_DROP'ed on 5th packet in a 1hit/1sec ratio.
#
# This doesn't increase coverage but at least make sure
# that feature works :)
# 
# Also test invert behaviour. (Isn't it cool?)

for p in '' '! '; do # Test normal and then negated rule
	echo iptables -I FORWARD -m recent --name testcase --rdest \
		--hitcount 1 --seconds 1 ${p}--update -j DROP
	echo iptables -A FORWARD -m recent --name testcase --set --rdest -j ACCEPT

	for pkt in 1 2 3 4 5 6 7 8 9 10; do # The 10 packets we send
		for h in 2 3 4; do # To each of 192.168.1.2, .3 & .4
			if [ ! "$pkt" -eq "5" ]; then

			[ -z $p ] && verdict=NF_ACCEPT || verdict=NF_DROP

			# Fifth packet triggers the 1:1 ratio.
			else
			# Negation doesn't behave as it should..
			#[ -z $p ] && verdict=NF_DROP || verdict=NF_ACCEPT
			# FIXME: This doesn't make much sense...
			# It always match so expect NF_DROP.
			verdict=NF_DROP
			fi

			echo expect gen_ip hook:NF_IP_FORWARD iptable_filter $verdict '*'
			echo gen_ip IF=eth0 192.168.0.1 192.168.1.$h 0 17 1 2
		done

		# Increasing by one triggers the 1:1 ratio, use 2.
		[ ! "$pkt" -eq "4" ] && echo time +2
	done
	
	echo iptables -D FORWARD -m recent --name testcase --rdest \
		--hitcount 1 --seconds 1 ${p}--update -j DROP
	echo iptables -D FORWARD -m recent --name testcase --set --rdest -j ACCEPT
done

##
# Test #3: Using the TTL lookup feature.
# Throw 5 packets where the 1st and 5th are twins (same TTL)
# So get NF_DROP'ed on 5th packet
#
# Let's see how it behaves when we first stamp the TTL after routing
# and do the checkup before routing. (insane scenario, I know)
#
# I must admit I wasn't sure of the result, nice to see it works. --peejix

echo iptables -t mangle -I PREROUTING -m recent --name testcase --rsource \
	--rttl --rcheck -j DROP
echo iptables -I INPUT -m recent --name testcase --set --rttl --rsource -j ACCEPT

for ttl in 50 51 52 53; do # The 4 packets we send
	echo expect gen_ip hook:NF_IP_PRE_ROUTING iptable_mangle NF_ACCEPT '*'
	echo gen_ip IF=eth0 TTL=$ttl 192.168.0.2 192.168.0.1 0 17 1 2
done

# The 5th packet that matches the TTL stamped
echo expect gen_ip hook:NF_IP_PRE_ROUTING iptable_mangle NF_DROP '*'
echo gen_ip IF=eth0 TTL=50 192.168.0.2 192.168.0.1 0 17 1 2

echo iptables -t mangle -D PREROUTING -m recent --name testcase --rsource \
	--rttl --rcheck -j DROP
echo iptables -D INPUT -m recent --name testcase --set --rttl --rsource -j ACCEPT

##
# Test #4: Using --hitcount in solo limiting 5 packets & more.
# We expect to NF_DROP 5th and 6th packet. IMO
#
# FIXME: Actually it only drops 6th packet. Shouldn't this
#			acts the same on 5th packet ?
echo iptables -I INPUT -m recent --name testcase --rsource \
	--hitcount 5 --rcheck -j DROP
echo iptables -A INPUT -m recent --name testcase --set --rsource -j ACCEPT

for pkt in 1 2 3 4 5; do # The 4 packets we send + an unexpected 5th
	echo expect gen_ip hook:NF_IP_LOCAL_IN iptable_filter NF_ACCEPT '*'
	echo gen_ip IF=eth0 192.168.0.2 192.168.0.1 0 17 1 2
done

# The 5th and 6th packet _should_ get NF_DROP verdict
# However, only sixth packet will do. (Bug?)
echo expect gen_ip hook:NF_IP_LOCAL_IN iptable_filter NF_DROP '*'
echo gen_ip IF=eth0 192.168.0.2 192.168.0.1 0 17 1 2

echo iptables -D INPUT -m recent --name testcase --rsource \
	--hitcount 5 --rcheck -j DROP
echo iptables -D INPUT -m recent --name testcase --set --rsource -j ACCEPT

##
# Test #5: Using --seconds in solo with a 1 seconds lap.
#

echo iptables -I INPUT -m recent --name testcase --rsource \
		--seconds 1 --update -j DROP
echo iptables -A INPUT -m recent --name testcase --set --rsource -j ACCEPT

for pkt in 1 2 3 4 5; do # The 5 packets we send
	# We do not increase time for 3rd packet. hence we expect NF_DROP
	[ ! "$pkt" -eq "3" ] && { verdict=NF_ACCEPT; echo time +2; } || verdict=NF_DROP
	echo expect gen_ip hook:NF_IP_LOCAL_IN iptable_filter $verdict '*'
	echo gen_ip IF=eth0 192.168.0.2 192.168.0.1 0 17 1 2
done

echo iptables -D INPUT -m recent --name testcase --rsource \
		--seconds 1 --update -j DROP
echo iptables -D INPUT -m recent --name testcase --set --rsource -j ACCEPT

##
# Test #6: Simplest scenario to introduce --remove thingie.
# (1) A new address is tagged (NF_ACCEPT)
# (2) The address match, so we remove from the list. (NF_DROP)
# (3) Back to step 1.
# 

echo iptables -I INPUT -m recent --name testcase --rsource --remove -j DROP
echo iptables -A INPUT -m recent --name testcase --set --rsource -j ACCEPT

for loop in 1 2 3; do # Try this 3 time
	for pkt in 1 2; do # Send 2 packets
		[ "$pkt" -eq "2" ] && verdict=NF_DROP || verdict=NF_ACCEPT
	
		echo expect gen_ip hook:NF_IP_LOCAL_IN iptable_filter $verdict '*'
		echo gen_ip IF=eth0 192.168.0.2 192.168.0.1 0 17 1 2
	done
done

echo iptables -D INPUT -m recent --name testcase --rsource --remove -j DROP
echo iptables -D INPUT -m recent --name testcase --set --rsource -j ACCEPT

##
# Test #7: Look for arguments that don't fit together
# --update, --set, --rcheck and --update are action parms.
for parm1 in '--update' '--set' '--rcheck' '--update'; do
	for parm2 in '--update' '--set' '--rcheck' '--update'; do
		echo expect iptables iptables: command failed
		echo iptables -I INPUT -m recent --name testcase $parm1 $parm2
	done
done

} > $TMPFILE
$NFSIM $NFSIM_ARGS < $TMPFILE

             reply	other threads:[~2004-12-30  6:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-30  6:16 Samuel [this message]
2004-12-30 14:18 ` [testsuite] ipt_recent Stephen Frost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41D39D3A.8050308@cookinglinux.org \
    --to=sj-netfilter@cookinglinux.org \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=nib@cookinglinux.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.