from beurton@fnet.fr: Darren Reed's IP filter

1 files changed, 99 insertions, 0 deletions

diff --git a/usr.sbin/ipftest/ipftest.1 b/usr.sbin/ipftest/ipftest.1
new file mode 100644
index 00000000000..2e6991a0d09
--- /dev/null
+++ b/usr.sbin/ipftest/ipftest.1
@@ -0,0 +1,99 @@
+.LP
+.TH ipftest 8
+.SH NAME
+ipftest - test packet filter rules with arbitary input.
+.SH SYNOPSIS
+ipftest [-vbdPSTE] [-I interface] -r <filename> [-i <filename>]
+.SH DESCRIPTION
+.LP
+.PP
+\fBipftest\fP is provided for the purpose of being able to test a set of
+filter rules without having to put them in place, in operation and procede
+to test their effectiveness.  The hope is that this minimises disruptions
+in providing a secure IP environment.
+.PP
+\fBipftest\fP will parse any standard ruleset for use with \fBipf\fP
+and apply input, returning output as to the result.  However, \fBipftest\fP
+will return one of three values for packets passed through the filter:
+pass, block or nomatch.  This is intended to give the operator a better
+idea of what is happening with packets passing through their filter
+ruleset.
+.PP
+When used without eiether of \fB-S\fP, \fB-T\fP or \fB-E\fP,
+\fBipftest\fP uses its own text input format to generate "fake" IP packets.
+The format used is as follows:
+.nf
+		"in"|"out" "on" if ["tcp"|"udp"|"icmp"]
+			srchost[,srcport] dsthost[,destport] [FSRPAU]
+.fi
+.PP
+This allows for a packet going "in" or "out" of an interface (if) to be
+generated, being one of the three main protocols (optionally), and if
+either TCP or UDP, a port parameter is also expected.  If TCP is selected,
+it is possible to (optionally) supply TCP flags at the end.  Some examples
+are:
+.nf
+		# a UDP packet coming in on le0
+		in on le0 udp 10.1.1.1,2210 10.2.1.5,23
+		# an IP packet coming in on le0 from localhost - hmm :)
+		in on le0 localhost 10.4.12.1
+		# a TCP packet going out of le0 with the SYN flag set.
+		out on le0 tcp 10.4.12.1,2245 10.1.1.1,23 S
+.fi
+.SH OPTIONS
+.IP -v
+Verbose mode.  This provides more information about which parts of rule
+matching the input packet passes and fails.
+.IP -d
+Turn on filter rule debugging.  Currently, this only shows you what caused
+the rule to not match in the IP header checking (addresses/netmasks, etc).
+.IP -b
+Cause the output to be a brief summary (one-word) of the result of passing
+the packet through the filter; either "pass", "block" or "nomatch".
+This is used in the regression testing.
+.IP -I <interface>
+Set the interface name (used in rule matching) to be the name supplied.
+This is useful with the \fB-P, -S, -T\fP and \fB-E\fP options, where it is
+not otherwise possible to associate a packet with an interface.  Normal
+"text packets" can override this setting.
+.IP -P
+The input file specified by \fB-i\fP is a binary file produced using libpcap
+(ie tcpdump version 3).  Packets are read from this file as being input
+(for rule purposes).  An interface maybe specified using \fB-I\fP.
+.IP -S
+The input file is to be in "snoop" format (see RFC 1761).  Packets are read
+from this file and used as input from any interface.  This is perhaps the
+most useful input type, currently.
+.IP -T
+The input file is to be text output from tcpdump.  The text formats which
+are currently supported are those which result from the following tcpdump
+option combinations:
+.PP
+.nf
+		tcpdump -n
+		tcpdump -nq
+		tcpdump -nqt
+		tcpdump -nqtt
+		tcpdump -nqte
+.fi
+.LP
+.IP -E
+The input file is to be text output from etherfind.  The text formats which
+are currently supported are those which result from the following etherfind
+option combinations:
+.PP
+.nf
+		etherfind -n
+		etherfind -n -t
+.fi
+.LP
+.IP -i <filename>
+Specify the filename to take input from.  Default is stdin.
+.IP -r <filename>
+Specify the filename from which to read filter rules.
+.SH FILES
+.SH SEE ALSO
+ipf(1), ipf(5), snoop(1m), tcpdump(8), etherfind(8c)
+.SH BUGS
+Not all of the input formats are sufficiently capable of introducing a
+wide enough variety of packets for them to be all useful in testing.